[01:58] <sistpoty> hey bddebian: I'll upload an ftbfs fixed version of gmult any minute. Please don't ask, why it does work with my patch, that was an epiphany and I have no real clue about the build system :(
[01:58] <sistpoty> bddebian: hence I'd very much like to not file a but in unstable about that... but in case it works for you as well... ;)
[02:09] <LaserJock> sistpoty: what are you doing up so late?
[02:10] <sistpoty> hey LaserJock
[02:10] <sistpoty> LaserJock: I'm waiting for my spouse to return home
[02:11] <LaserJock> sistpoty: what TZ are you in? Seems awfully late/early for Europe
[02:11] <sistpoty> LaserJock: utc+2 and, yes, it's quite late for me
[02:12] <LaserJock> I'm tired and I'm -4 :-)
[02:12] <sistpoty> hehe
[02:12] <bddebian> Bunch a sissies! :)
[02:13] <bddebian> sistpoty: Did you already post/upload gmult?
[02:13] <LaserJock> bddebian: did I hear that you made DD?
[02:13] <sistpoty> bddebian: uploaded: yes, but it's still in the queue
[02:13] <bddebian> LaserJock: Yeah, a while ago.  Amazing eh? :)
[02:13] <LaserJock> I can't believe it
[02:14] <bddebian> Hey! :'-(
[02:14] <LaserJock> ;-)
[02:14] <sistpoty> LaserJock: you missed the bits about ftp-master, I guess
[02:14] <bddebian> Heh
[02:14] <bddebian> Well just ftp assistant
[02:14] <LaserJock> ohhhhh!
[02:14] <LaserJock> I think I did see that in my mail box
[02:14] <LaserJock> and to think, we never thought he'd amount to anythin :p
[02:14] <bddebian> I'm totally absent from Ubuntu these days though
[02:15] <bddebian> LaserJock: Amen brother! :)
[02:15] <sistpoty> well, I always new to cheat revu by reviewing only stuff that went through bddebian before :P
[02:15] <LaserJock> heh
[02:15] <bddebian> bah
[02:17] <LaserJock> I'm sadly absent from Ubuntu these days as well
[02:17] <LaserJock> I can't believe somebody actually gave me a real job
[02:17] <LaserJock> I was starting to think I was going to  be a grad student forever
[02:17] <bddebian> heh
[02:17] <LaserJock> I had been there longer than all of the secretaries
[02:17] <bddebian> You can have my "real" job! :)
[02:18] <LaserJock> I'd been through 3 department chairs
[02:18] <bddebian> dang
[02:18] <LaserJock> and I'd seen 6 new faculty hired
[02:18] <LaserJock> 2 of which I was on the hiring committee
[02:19] <bddebian> sistpoty: Is it a small patch?
[02:19] <LaserJock> you know you've been there too long when professors you helped hire are getting tenure :-)
[02:19] <bddebian> hehe
[02:20] <LaserJock> I like my new job, but I'm not sure about Boston/New England yet
[02:21] <LaserJock> weather's been nice, but the traffic sucks
[02:21] <sistpoty> bddebian: yep
[02:21] <bddebian> Yeah Boston is about the worst traffic I've ever seen and I lived in California for 12 years :)
[02:22] <sistpoty> bddebian: http://paste.ubuntu.com/278359/
[02:22] <bddebian> wtf?
[02:23]  * sistpoty hides under http://launchpadlibrarian.net/31703518/buildlog_ubuntu-karmic-amd64.gmult_7.2-1_FAILEDTOBUILD.txt.gz
[02:26] <bddebian> sistpoty: I'm not doubting you, I'm just confused by that one :)
[02:27] <sistpoty> heh
[02:28] <sistpoty> well, usually I can tell exactly what went wrong, and I even believe that I'm not too bad with automake... in this case it still escapes me why the patch fixes the problem though
[02:28] <bddebian> Aye
[02:29] <sistpoty> ok, spouse just returned home... must leave now... cya
[02:30] <bddebian> Later man, thanks
[02:30] <LaserJock> you know
[02:30] <sistpoty> cya bddebian and LaserJock
[02:30] <LaserJock> we'd get so much more done on Ubuntu if it wasn't for spouses ;-)
[02:30] <sistpoty> haha
[02:30] <bddebian> Heh and jobs
[02:30] <LaserJock> but don't tell mine I said that :p
[02:30] <sistpoty> heh
[02:30] <sistpoty> <- now really leaves, cya
[03:39] <zooko> Hi folks.  Anybody interested in uploading Tahoe-LAFS to the Karmic Queue?  http://revu.ubuntuwire.com/p/tahoe-lafs
[03:59] <ScottK> Note: It's a reupload due to a licensing issue.
[03:59] <ScottK> So it's OK/desired even though it's late in the cycle.
[04:02] <jdong> plus, it sounds like a pretty damn cool project :)
[04:03] <ScottK> zooko:^^^^ There's your victim.
[04:04] <jdong> ROFL
[04:05] <jdong> ok let wrap up what I'm doing and take a look :)
[04:05] <jdong> boy you think after these years I'd learn what speaking up means in IRC ;-)
[04:06] <zooko> :-)
[04:11] <ScottK> jdong: I'd do it, but then I couldn't be the archive admin to review it.  Thanks.
[04:21] <jdong> ok, lemme look :)
[04:24] <jdong> zooko: sponsored :)
[04:26] <zooko> jdong: whoo!  :-)
[04:27] <jdong> I'll keep my fingers crossed for you too ;-)
[04:31] <zooko> Thank you very much!
[04:31] <jdong> sure thing, anytime!
[04:32]  * ScottK digs around.  Finds the remote for jdong's alarm clock and hands it over to zooko to make sure "anytime" is enforcable.
[04:33] <jdong> well as long as it's not the 150dB one on Digg or my roommate's which is always in some foreign timezone, that's fine :)
[04:34] <dtchen> git fetch
[04:34] <dtchen> bah, sorry
[04:35] <jdong> while you're here... ALSA on my 17" MBP
[04:35] <jdong> kidding ;-) another time
[04:35] <dtchen> you know the drill: ubuntu-bug alsa-base
[04:36] <jdong> it's already got a fairly lengthy LP bug... *finds number*
[04:36] <jdong> bug 337947?
[04:37] <jdong> idn what information it needs; with the latest posted patches and/or forcing model=mb5 I've got sound in everything, just no jack sense
[04:40] <dtchen> jdong: right, that bug is pretty unhelpful for me WRT your specific issue, because i have no way of knowing if your codec matches the reporter's precisely
[04:40] <jdong> dtchen: *nods* in that case I shall boot that machine up right now :)
[04:40] <dtchen> jdong: it is more helpful to just post another bug report with that info attached (which ubuntu-bug alsa-base will do)
[04:40] <jdong> will do, thank you sir
[04:42] <zooko> Okay folks, I'm definitely about to fall asleep.  As soon as Tahoe-LAFS is apt-gettable I'll post about it on my blog and identi.ca and so on and invite Tahoe-LAFS users to install Karmic and test it out.
[04:43] <jdong> whoo :)
[04:43] <jdong> good night, man!
[04:44] <zooko> Tomorrow I'm taking my children to aikido, then soccer, then having my father over for a visit, so at some point tomorrow night or Sunday I'll probably check for Tahoe-LAFS in Karmic...
[04:45]  * zooko tries to fall asleep, but is having too much fun listening to http://radio1190.org/1190high.m3u
[04:45] <jdong> whew, what a packed day
[04:45] <jdong> kids these days are involved in so many things
[04:49] <dtchen> headdesk. i hate brown paperbag bugs.
[05:19] <jdong> dtchen: ok I filed bug 437034 regarding my issue
[05:19] <jdong> thanks in advance
[05:19] <dtchen> jdong: thanks
[05:31] <Amaranth> Oh, should I file a bug for my laptop needing model=mb3?
[07:35] <wrapster> im a beginner at packaging and wanted to clarify a few things... have a look at this http://pastie.org/631355... (as an eg ) i wanted to know if all the files present in the upstream dir are necessary.. or can we do without some?
[07:51] <jmarsden> wrapster: You seem to have mixed source files with temp files from the build process in the same directory??  That's horribly confusing.  if you want to repackage flex, apt-get source flex and start from there.
[07:52] <wrapster> jmarsden: yeah thats where i started from .. i had already built flex but guess i needed to pull the source then ask the question ... :)
[07:52] <wrapster> sorry about that..
[07:52] <wrapster> will get back in a while
[07:53] <jmarsden> wrapster: Oh, then run make clean or make -f debian/rules clean    or both and try again :)
[07:57] <wrapster> jmarsden: is this better to base my question on? http://pastie.org/631368
[07:58] <jmarsden> Probably... but now you just have source files, so of course they are all needed... what makes you think otherwise?
[07:59] <jmarsden> Well, you could consider config.guess and config.sub disposable... but... what are you really trying to do here?
[08:02] <wrapster> jmarsden: when i looked at ways of packaging...(when my seniors were doing it) i thought i saw them remove files that ended with *.ex so was wondering what they are and why are they being removed.. forgot to ask then.. so troubing you.
[08:03] <wrapster> how about in the debian dir? apart from control,rules,changelog,copyright are there any other files that are necessary? to build a pkg?
[08:03] <jmarsden> Inside the debian/ dir if you use dh_make to generate a starting set of debian packaging files you can get that; but here you are starting from an existing package so there should not be any files around which are unnecessary.
[08:04] <jmarsden> wrapster: To build "a" package, or to build this one in particular?
[08:04] <wrapster> to build a pkg
[08:05] <jmarsden> at minimum you should only need those 4.  See https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20from%20Scratch
[08:06] <jmarsden> That guide also talks about removing the *.ex files, by the way.  Reading the whole guide is *strongly* recommended.
[14:36] <sistpoty> hi folks
[14:36]  * ScottK waves to sistpoty.
[14:36] <sistpoty> hi ScottK
[14:36] <diwic> hi there
[14:50] <ScottK> zooko: What are the licensing terms for src/allmydata/util/mathutil.py?
[15:28] <ScottK> sistpoty: IIRC maven is one of those things where you generally want the crack of the day, so while we'd need someone to shepherd through a set of updates, I'm don't think we need to be really picky about testing.
[15:29] <sistpoty> ScottK: ok, but I'd at least like to see a rudimentary test though
[15:29] <ScottK> OK.
[15:33] <less11> Hi all, I need to know where to ask questions ubuntu boot process (more specifically, initrd related questions)
[15:33] <ScottK> less11: I think there is an #ubuntu-boot channel.  I know there's a LP team with a mailing list.
[15:36] <less1> ScottK: thanks.. :-)
[17:47] <lamalex> Does anyone know about cdbs simple-patchsys?
[17:47] <lamalex> how do I create a new patch? Do I edit the code then do a diff and revert the code?
[17:49] <diwic> cdbs-edit-patch
[17:50] <Darxus> If I created a new package today, which didn't qualify for karmic, what would happen to it?
[17:51] <lamalex> Darxus: get it into debian and have it sync for lucid
[17:52] <diwic> lamalex: if you have the choice, switching to quilt is generally recommended
[17:52] <lamalex> diwic: yeah, but I don't have the authority to do that unfortunately
[17:52] <pochu> diwic: is it?
[17:53] <pochu> oh, generally
[17:54] <diwic> pochu: I believe most people think so (myself included), but I'm not sure if it is an official policy.
[17:54] <Darxus> Ohh, a name for what comes after kamric :P
[17:55] <Darxus> Packages can't be added to lucid yet though?
[17:56] <pochu> no
[17:57] <Darxus> Heh, wikipedia is already updated.
[18:00] <Darxus> Which event on the Lucid release schedule markes when new packages can be uploaded?
[18:00] <Darxus> https://wiki.ubuntu.com/LucidReleaseSchedule
[18:01] <lamalex> diwic: thanks
[18:02] <lamalex> Darxus: they can be uploaded at any point before feature freeze
[18:02] <lamalex> but debian import freeze is where it won't be synced from debian
[18:02] <lamalex> so I would try and get it uploaded into debian as soon as possible
[18:02] <Darxus> lamalex: Well, since they can't be uploaded now, that's not true.  When is the soonest they can be uploaded?
[18:03] <RainCT> (*automatically synced, you can still manually request syncs afterwards)
[18:03] <lamalex> Darxus: idk, as soon as the repos open I guess
[18:03] <RainCT> Darxus: as soon as the archive is opened, which is usually a few weeks after the previous release coming out
[18:03] <lamalex> nov 5 maybe?
[18:04] <Darxus> RainCT: Thanks.
[18:04] <Darxus> That should be on the schedule :)
[18:07] <Darxus> I just contacted the last person to edit the schedule and asked him to add it.
[18:11] <Darxus> Can you give me an example of a package that only has a couple .h files?
[18:11] <joaopinto> Darxus, .h are usually contained on -dev packages
[18:12] <Darxus> joaopinto: I know, I'm looking through them, thanks.
[18:15] <Darxus> $ for file in `dpkg -l '*dev' | grep ^i | awk '{print $2}'` ; do echo -n  `dpkg -L $file | wc -l` >> headercount.txt ; echo " $file " >> headercount.txt; done
[18:16] <Darxus> I love linux.
[18:17] <Darxus> libbz2-dev looks good.
[18:19] <Darxus> Well, before I start trying to build a new package for the first time I should ask if this makes sense.
[18:19] <Darxus> Nvidia has made hardware acceleration of video decoding available.
[18:20] <Darxus> Support is included in the source of the karmic mplayer package, but it's not enabled.
[18:20] <Darxus> Enabling it requires two .h files from nvidia.
[18:20] <Darxus> So I should package these two .h files and make that a build-dep of mplayer, right?
[18:21] <Darxus> (I have it working on my computer.  It's awesome.)
[18:21] <joaopinto> Darxus, have you checked those .h files copyright ?
[18:22] <Darxus> joaopinto: Just did.  It's good.
[18:23] <Darxus> 'Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction...'
[18:23] <joaopinto> Darxus, if the copyright is compatible with mplayer, it makes more sense to add those 2 .h as a building patch
[18:24] <joaopinto> i mean, to mplayer
[18:24] <Darxus> Does it?  What about other players that might build against it?
[18:27] <Darxus> Bah, trying to find somebody at nvidia to ask for a version number.
[18:27] <joaopinto> there are some cases of .h files repeated on several sources, if those 2 .h are part of a library it makes sense to package the entire lib :)
[18:33] <Darxus> joaopinto: I believe this support only exists as patches nvidia made to mplayer and these two .h files.
[18:34] <Darxus> So.. should I be making a package of two .h files?
[18:37] <Darxus> I don't think I got an answer to this before:  Do I need to use my real name when packaging/signing for upload to the archives, if I make it to that point?
[18:38] <sistpoty> Darxus: it's highly encouraged to use the real name
[18:38] <sistpoty> Darxus: header files belong to the package with the library that actually has the implementation, a standalone package with only two header files would be a little bit strange
[18:40] <sistpoty> (i.e. to the -dev package actually, see the library packaging guide for details)
[18:40] <Darxus> I finally had the sense to google to see what debian is doing with this.  There's an RFP bug:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511555
[18:41] <ScottK> diwic: Very few people are neutral on the subject of quilt.  I think saying it's generally recommended overstates the case.
[18:43]  * sistpoty shoves more packages into ScottK's queue :)
[18:43] <ScottK> Excellent
[18:44] <Darxus> "Headers are alreay included in the nvidia source package"
[18:52] <Darxus> Looks like those headers are already packaged in nvidia-glx-185-dev in karmic, heh.
[18:58] <Darxus> Except they're not actually in there :(
[19:04] <ScottK> kirkland: I'm going over Universe stuff and accepting it.  Your versioning of the sobby upload seems a bit odd to me.  Didn't you want 0.4.5-1ubuntu1?
[19:29] <sistpoty> meh, no ftbfs bugs in the universe sponsors list... where's my whip? *g*
[19:35]  * sistpoty is off again, cya
[22:09] <hyperair> kirkland: i think i might have bugged you about this previously, but checking for $TERM screws up ssh sessions with byobu-launcher grandly.
[22:09] <hyperair> kirkland: please, just check *anything* except TERM
[22:09] <hyperair> what's wrong with just checking STY?
[22:10] <hyperair> in fact, what are the cases where STY goes missing?
[22:11]  * hyperair reads the bug report.
[22:12] <hyperair> i take it that it's acceptable to have byobu *not* launch, and instead have "exec byobu-launcher" just exit the shell instead.
[22:12] <hyperair> great. just great.
[22:13] <hyperair> $ ssh <IP_ADDRESS>
[22:13] <hyperair> Connection to <IP_ADDRESS> closed.
[22:13] <hyperair> whee. fun.
[22:14] <hyperair> in the first place, what's wrong with having byobu-inside-byobu when you ssh to another machine that has byobu in it?
[22:15] <hyperair> hmm byobu is in main. maybe i should have ranted in #ubuntu-devel instead.
[22:15] <hyperair> oh well, what's done is done.
[23:45] <ScottK> zooko: Did you see my ping from this morning about licensing?


[02:46] <guiverc> The_LoudSpeaker, i rebooted and didn't have anything to know which grub option I was selecting (dual boot with numerous options, BIOS on this box; change I'd not noticed before; though I don't boot very often), will explore when I can on other boxes & provide more detail..    i don't think this box likes lubuntu-artwork change..
[02:47]  * guiverc has been concentrating on focal.1 & ignoring groovy of late..
[05:03] <The_LoudSpeaker> guiverc: the change was on groovy.
[05:03] <guiverc> yeah, this (my main box) is groovy+bionic, and groovy owns grub, so it was groovy
[05:04] <The_LoudSpeaker> And if placing the config in /boot/default/grub.d/ doesn't work then I don't know what works. 🤷🏻♂
[05:04] <guiverc> Grub appears with a list of options, but I could NOT tell which was being selected, worse as I scroll up/down the page to view all
[05:05] <The_LoudSpeaker> Did you check on a clean install btw?
[05:05] <guiverc> i'll test it on a freshly installed system when I get a chance..  this is NOT a clean machine (17.10rc install long ago)
[05:06] <The_LoudSpeaker> The root of grub here is on your groovy install? You said it was multi os system right? Maybe grub's root is not grooy
[05:06] <The_LoudSpeaker> Yup. Please let me know if a clean install works.
[05:08] <The_LoudSpeaker> I am in village rn and I don't have good enough internet to download and test. I will upgrade my data plan when the current one finishes and will test then.
[05:13] <guiverc> My current focus is 20.04.1, so I'll test it for sure, but won't be today.. I'd clean install, then install-alongside (so multiple entries) then look..  but won't be today.
[05:13] <guiverc> The_LoudSpeaker, ^
[05:14] <The_LoudSpeaker> Yup. Works. Anytime you are free.


[00:00] <huwshimi> hatch: I don't think we have an asset for that ellipsis yet, so maybe you can crop it out of the mockup for now
[00:07] <gary_poster> hatch, for the source view, "Nice tests.  LGTM with additional text I mention.  qa good.  Thank you!"
[00:08] <gary_poster> huwshimi, I think I don't have any bundle tasks for you today.  Are you choosing one from your backlog?
[00:08] <huwshimi> gary_poster: I'm just adding the icon to the bundle charm details panel and trying to get showing/hiding working and then I'll move to the backlog
[00:08] <hatch> gary_poster: thanks :)
[00:09] <hatch> huwshimi: damn why won't you guys let me use UNICODE!!!!!! … … … … …
[00:09] <hatch> lol
[00:09] <gary_poster> huwshimi, sounds perfect.  thanks!  hatch, notice huwshimi is trying to do that part of what we talked about, but there's still other bits
[00:09] <gary_poster> hatch, huwshimi, running away.  ttyl and thanks!
[00:10] <hatch> enjoy!
[00:10] <huwshimi> gary_poster: Have a good evening :)
[00:10] <huwshimi> hatch: You can use unicode if you can make it look like the mockup :)
[00:10] <hatch> lol
[00:10] <hatch> deal!
[00:10] <huwshimi> hatch: (hint, you won't be able to) :)
[00:10] <hatch> ok I'm going to be taking over from where you leave off on that panel so don't forget to push your changes up :)
[00:10] <hatch> haha
[00:11] <huwshimi> hatch: Yep, nearly done here
[00:15] <hatch> oh haha cool
[00:20] <huwshimi> hatch: What does scene inside events mean "events: {      scene: {"?
[00:21] <huwshimi> hatch: This is inside topology/bundle.js
[00:23] <bcsaller> huwshimi: event bindings
[00:24] <huwshimi> bcsaller: how does that differ to our usual bindings which just live inside 'events' without the scene?
[00:24] <bcsaller> they are mapped to d3's event system
[00:25] <bcsaller> part of the topology system, the docs on d3-components go over this, should be in the docs dir
[00:25] <huwshimi> bcsaller: Ah I see
[00:25] <huwshimi> I'll take a look, thanks
[00:30] <huwshimi> bcsaller: So how do I get the event from a scene event?
[00:30] <bcsaller> huwshimi: you mean in the handler?
[00:31] <bcsaller> often you don't need to, 'this' is the DOM element and the 1st arg is the bound model that was triggered, but if you need the event d3.event should be correct
[00:31] <huwshimi> bcsaller: yeah, I want to do a "[event].halt()"
[00:32] <bcsaller> d3.event.halt() then
[00:34] <huwshimi> bcsaller: Forgive my ignorance, the d3 in that case is the first function parameter of the handler?
[00:34] <bcsaller> d3 is a global
[00:35] <bcsaller> d3.event is also global, js is single threaded so there can only be one event at a time
[00:35] <huwshimi> bcsaller: Heh, yeah, I just figured that out :)
[00:36] <huwshimi> bcsaller: Thanks for that, this is working now :)
[00:36] <bcsaller> great
[00:46] <huwshimi> hatch: That branch is now proposed, so once that lands you are good to go.
[11:12] <bac> hi rick
[11:12] <bac> rick_h_: i mean
[11:14] <bac> rick_h_: when you're around could you review the changes that benji asked for in https://code.launchpad.net/~bac/charmworld/update-branch/+merge/190229 .  he's marked it approved but i think the lander will want the new revision approved too.  on interesting change is adding 'lint' to 'make check'
[11:47] <rick_h_> bac: looking
[11:50] <rick_h_> bac: cool approved
[11:50] <rick_h_> bac: the new landing from jenkins doesn't care about the new revs ime but cool to peek
[11:51] <rick_h_> bac: marked approved and watching staging whee
[11:52] <bac> thanks rick_h_.  i'll write a commit message and then it should go.
[11:52] <rick_h_> oh oops, hah
[11:52] <bac> done
[12:12] <rick_h_> bac: hmm, CI isn't picking it up. Are you a member of juju-jitsu?
[12:13] <rick_h_> looks like you are
[12:14] <rick_h_> abentley isn't around yet to ask about it. He was changing stuff with it the other day
[12:37] <bac> rick_h_: do you have any insight into the lander?  or just been watching the MP?
[12:38] <rick_h_> bac: I was watching jenkins
[12:39] <rick_h_> bac: the way things are working now jenkins pulls the branch on its own
[12:39] <rick_h_> bac: so since it's not loading it, I'm guessing it's due to recent changes. It was working for my branches earlier this week
[12:39] <rick_h_> abentley should be around in the next hour to ask about it.
[12:40] <rick_h_> he'll probably want to test something :)
[12:40] <bac> rick_h_: ok. abentley said it runs every minute so we'll just have to wait
[12:40] <bac> for him to appear and enlighten us
[12:40] <rick_h_> yea
[12:41] <rick_h_> gary_poster: around for one-one or bypass this week?
[12:41] <gary_poster> rick_h_, sorry trying to wrap up
[12:41] <rick_h_> gary_poster: np
[12:54] <bac> hi abentley, when you have a chance could you look into why the lander is not picking up my branch, reviewed and approved at https://code.launchpad.net/~bac/charmworld/update-branch/+merge/190229 ?
[12:54] <gary_poster> rick_h_, ok now :-P
[12:54] <gary_poster> benji, will be late :-/
[12:55] <benji> gary_poster: np
[12:55] <abentley> bac: I will.  Thanks for pointing it out.
[12:55] <bac> thanks
[13:07] <frankban> gary_poster: added "Charm details link not working correctly" to urgent
[13:07] <gary_poster> frankban, thank you
[13:09] <abentley> bac: That issue turned out to be a config issue where a list was expected but a string was supplied.
[13:10] <abentley> bac: The previous code was using "if x in y", so it didn't notice that y was a string, not a collection.
[13:14] <adeuring> bac, benji, abentley: could one of you review this mp: https://code.launchpad.net/~adeuring/charmworld/use-charmtools-tarball/+merge/190361 ?
[13:14] <benji> adeuring: I'll take a look.
[13:14] <adeuring> thanks
[13:19] <bac> abentley: so is the lander working on a queue of branches?  i see gary's is up now.
[13:20] <abentley> bac: It's not an explicit queue, it just finds the first thing it can land and tries landing it.
[13:21] <bac> abentley: oh, i see my MP is marked merged.  cool.
[13:35] <bac> abentley: does the lander update the charmworld revno on staging automatically now?
[13:36] <abentley> bac: yes.
[13:36] <bac> oh, cool.  i was just about to do it manually.  hey is the process documented somewhere so i can quit bugging you with dumb questions?
[13:37] <bac> abentley: ^^
[13:38] <abentley> OTP
[14:00] <abentley> benji: Your canary work is preventing download-cache from being updated, which means that adeuring's branch cannot land: http://<IP_ADDRESS>:8080/job/charmworld-autoland-lxc/28/console
[14:01] <benji> :(
[14:03] <abentley> bac: So, the first question wasn't dumb at all-- I had misconfigured the lander as part of the change I announced yesterday.  That's a one-time thing.
[14:03] <gary_poster> benji do you need to address that or can we talk now?
[14:04] <abentley> bac: What sort of documentation would be helpful?
[14:04] <benji> gary_poster: I don't know.   abentley: do you want me to address that issue?
[14:04] <abentley> benji: Could you please discuss it with adeuring, figure out a solution, and then one of you can implement it?
[14:05] <benji> abentley: sure
[14:05] <benji> gary_poster: I'll ping you when I'm available (or we can postpone)
[14:05] <rick_h_> anthonydillon: sorry for the delay. If you get back around let me know and can walk you through it
[14:05] <bac> gary_poster: our call is now.  or are you talking to benji first?
[14:05] <abentley> benji: Thanks.
[14:05] <gary_poster> benji, ack
[14:05] <adeuring> benji: well, I'd like to land my last branch sooner or later ;) It's not a matter of minutes, of course
[14:05] <gary_poster> bac, are you available now?
[14:06] <bac> i am
[14:06] <gary_poster> bac, let's do it
[14:06] <benji> abentley: does the lander update a long-lived checkout or build a new one every time?
[14:06] <abentley> benji: It updates a long-lived checkout.
[14:06] <benji> :(
[14:07] <benji> It would be better to do fresh checkouts every time (not just for issues like this, but it's better hygiene in general).
[14:07] <abentley> benji: Makefiles wouldn't be necessary if we didn't use long-lived source trees.
[14:08]  * benji ponders that assertion.
[14:08] <abentley> benji: If you were always building from scratch, you wouldn't want a dependency system, you'd want a traditional script.
[14:09] <benji> true, but no one ever *always* builds from scratch
[14:11] <abentley> benji: So ideally, build-from-scratch and incrementally-update-and-build should both work.  We could test both.  I'm not convinced one is better than the other.
[14:13] <benji> yep both should definately work; build-from-scratch must work, otherwise we just have software that only exists in a usable form on particular had disks scatered across the planet :)
[14:14] <benji> from my perspective incrementally-update-and-build is a nicity that -- given the limitations of make -- can never be truely achieved
[14:14] <abentley> benji: But incrementally-update is trickier, so I think that's the one worth testing.
[14:15] <benji> I disagree.  From-scratch must work, so it must be tested.
[14:15] <benji> (if it's not tested, it doesn't work, and all that)
[14:17] <abentley> benji: I disagree.  We have a vcs, so we can incrementally build every revision starting with revno 1 if necessary, so build-from-scratch is no more necesary than incremental.
[14:18] <benji> I've already stated my rebuttle to that argument, and I need to work on the issue at hand.
[14:20] <abentley> benji: I don't see a rebuttal.  I just introduced a new argument.
[14:20] <benji> I may have misunderstood.  We can talk about it once I've addressed the immediate issue.
[14:28] <luca__> gary_poster: is there a url flag so we can see Bundles and Ice-cream?
[14:32] <rick_h_> bac: http://staging.jujucharms.com/charms/precise/juju-gui/json looks good and complete!
[14:32] <rick_h_> bac: so I think we'll call this case closed with your branch fix?
[14:33] <abentley> benji: I think the syntax on "then : bzr up download-cache" may be malformed.  I think the colon is preventing execution of the "bzr up".
[14:33] <bac> cool rick_h_, OTP
[14:33] <rick_h_> bac: k
[14:33] <frankban> guihelp: I need 1 review + 1 QA for https://codereview.appspot.com/14439054 . Is anyone available? thanks!
[14:33] <benji> abentley: hmm, I'll take a look at that
[14:33] <hatch> frankban: I can
[14:34] <frankban> hatch: thanks
[14:34] <gary_poster> frankban, had a good conversation about quickstart with rick_h_ .  should share with you
[14:35] <gary_poster> maybe after our daily call
[14:35] <frankban> gary_poster: sounds good
[14:36] <bac> rick_h_: just looked, yep it does look good.
[14:39] <benji> abentley: I think you're right.
[14:40] <abentley> benji: I know that colon is a do-nothing in some contexts.  e.g. ": echo foo" does not echo.
[14:41] <adeuring> benji: , abentley: yes, that seems to be the problem. I'll remove the ':' in my branch.
[14:41] <benji> yeah, it is for evaluating expressions for their side-effects
[14:42] <benji> that's how I'll make my millions: an easy way to test make files
[14:44] <benji> so... this works in dev because pip actually downloads the file from the Internet; we should disable that so dev matches the IC/prod enviroment
[14:44] <benji> gary_poster: ok, I'm ready for a call whenever
[14:45] <gary_poster> thanks benji.  arranged it in calendar
[14:46] <benji> k
[14:48] <benji> I retract that.  pip didn't download from the internet.
[14:52] <hatch> frankban: still spinning up core to qa - will hopefully have it all tested in 20minss
[14:52] <frankban> hatch: cool
[14:54] <hatch> ORDER PLACED: Oct. 1 2013     DELIVERY ESTIMATE: Friday Oct. 25 2013 - Friday Nov. 1 2013 by 8:00pm
[14:54] <hatch> NOOOOOOO amazon why do you hate me so
[14:55] <rick_h_> hatch: lol
[14:55] <rick_h_> hatch: gotta go prime baby
[14:55] <hatch> haha I'm guessing the book isn't in stock
[14:55] <hatch> that's even slow for their usual Canadian dogsled delivery team
[14:56] <hatch> I was thinking of going prime, but I can't remember the last time I paid for shipping
[15:03] <adeuring> abentley: my branch failed again. Do I understand the report right that lint errors are considered bad too?
[15:06] <rick_h_> adeuring: that was a recent change bac included
[15:06] <hatch> frankban: I'm hoping it's still switching to your branch - but it's been rejecting my connections for a while now
[15:06] <rick_h_> adeuring: make check now checks lint as well
[15:06] <hatch> and of course
[15:06] <hatch> there it goes
[15:06] <hatch> lol
[15:06] <rick_h_> hatch: it takes a while
[15:06] <rick_h_> hatch: I ran into that yesterday with Makyo's branch
[15:06] <adeuring> rick_h_: thanks. I was just not sure if missed something
[15:06] <rick_h_> adeuring: naw, we're shifting the sand beneath your feet :)
[15:07] <adeuring> ;)
[15:07] <abentley> adeuring: That's how it looks.  I'm just running a make target.
[15:07] <bac> adeuring: yes, that just landed.  i should've announced it but it came out of a discussion we had yesterday, after your EOD
[15:07] <abentley> adeuring: I'm just running "make check".  Whatever's in that target will run.
[15:07] <frankban> hatch: on ec2 "juju debug-log" can help. if you are using the local provider, then you can just "tailf ~/.juju/local/log/unit-juju-gui-0.log"
[15:08] <hatch> ahh I should do that from now on
[15:08] <hatch> yeah using local provider
[15:09] <hatch> done
[15:09] <hatch> sorry forgot to type LGTM ;)
[15:09] <frankban> :-)
[15:10] <hatch> hmm the card I was working on is gone
[15:10] <hatch> ohh huw stole it
[15:13] <bac> there is a new fitbit out that allows you to check the time of day, right on your wrist!  revolutionary!
[15:13] <hatch> bac: HAHA I was JUST thinkign the same thing
[15:13] <hatch> lol
[15:13] <bac> i sure hope they patent that wrist-mounted time display
[15:14] <hatch> I think it would clash with my watches
[15:14] <abentley> hatch: How many watches do you wear at a time?
[15:15] <hatch> one - but none are digital or silicone :)
[15:16] <abentley> rick_h_: You said bootstrap-dropdown isn't working.  I remember the tools dropdown working.   I didn't realize that it was working tbh
[15:16]  * rick_h_ shrinks my window really small
[15:16] <frankban> gary_poster: should I add a card in urgent to remember us to make a new charm release after we release the GUI?
[15:17] <gary_poster> frankban, yes thank you
[15:17] <rick_h_> abentley: no idea. If it's meant to work then I'll try to track history on it and see why it's 404'ing then.
[15:22] <abentley> rick_h_: Not very important functionality, and if it's been disabled for a while, no rush to restore it.
[15:22] <rick_h_> abentley: I think this was work when huw moved the ui to be with ubuntu style guidelines
[15:23] <rick_h_> abentley: all of bootstrap is removed so removing the file.
[15:31] <bac> bcsaller: i see export is now using blob urls.  did that just happen?  sadly safari cannot handle them.
[15:32] <rick_h_> bac: or benji got a sec for a tiny review please? https://code.launchpad.net/~rharding/charmworld/jc-bundle/+merge/190396
[15:32] <bac> rick_h_: yes
[15:32] <rick_h_> ty
[15:34] <hatch> gary_poster: is where huw left the bundle topology details popup where we want to leave it for now?
[15:35] <gary_poster> hatch, hey.  yeah, meant to highlight that to you.  I think we could add next/prev, but lower priority. later
[15:35] <hatch> ok cool - so I'll do the charms panel now?
[15:35] <bcsaller> bac: I believe that has been there for some time. There are very few options for generating downloadable files in the browser. When did safari make the supported list?
[15:36] <bac> bcsaller: it hasn't but there have been discussions.
[15:36] <bac> bcsaller: it was more of a sad-face comment than something than a bug.
[15:37] <rick_h_> bac: bcsaller there was a thread about supporting it recently though I don't think it made the official list
[15:37] <rick_h_> safari that is
[15:37] <bcsaller> bac: with the server doing exports now we can generate a url there and get more support, but with fakebackend and so on I think the blob stuff is still a good option
[15:39] <rick_h_> hatch: those icons in the bundle looking purdy
[15:40] <hatch> rick_h_: I know right? For the amount of crap I give you about the tokens it was sure easy to implement :P
[15:40] <hatch> but don't tell rick_h_ I said that
[15:40] <hatch> it'll go to his head
[15:40] <rick_h_> hatch: :) yea hopefully you're finding that once you get past learning the 'rules' the browser stuff isn't as horrible as it seems
[15:41] <rick_h_> hatch: if not then shush no one asked you anyway :P
[15:41] <hatch> lol
[15:41] <hatch> did you get a chance to look into that attribute issue last night?
[15:41] <bac> rick_h_: done
[15:41] <hatch> I didn't :/
[15:42] <rick_h_> hatch: no, I was busy trying to implement chrome 'add to homescreen' to my own app. :P
[15:42] <rick_h_> bac: ty much kind sir!
[15:42] <hatch> rick_h_: hah - hard to do?
[15:42] <rick_h_> hatch: no, it just hates me and won't give me the pretty icon on the home screen I wanted
[15:43] <rick_h_> hatch: and then started redoing the chrome extension without any framework bits
[15:43] <hatch> ahh cool cool
[15:43] <rick_h_> so no, I didn't play with the ATTR setter thing at all. off time and all that :)
[15:44] <hatch> haha
[15:44] <hatch> those triangles still look weird to me
[15:44] <rick_h_> hatch: +1
[15:44] <hatch> http://comingsoon.jujucharms.com/precise/juju-gui-77/#bws-related-charms
[15:44] <hatch> on the details page they even look worse
[15:45] <hatch> they looked good in the mockups
[15:45] <hatch> I don't know why not here
[15:45] <rick_h_> hatch: can you find the mockups? I was looking trying to find some wireframe to see what we're missing but all the wireframe/visuals i can find in google docs have the *
[15:45] <hatch> hmm
[15:46] <rick_h_> hatch: because I'm kind of with you. I've never been a big fan but I don't remember it looking this 'off'
[15:48] <hatch> rick_h_: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1NEtGaHJYZGM4enM the button states png
[15:48] <hatch> I think it's because on the bundle token it had more 'stuff' to fill in the whitespace
[15:48] <rick_h_> hatch: yea, and not really in context for things like the related charms/etc
[15:48] <rick_h_> many things look ok in isolation, but in context...
[15:49] <rick_h_> hatch: the background colors of the tokens isn't right either.
[15:50] <gary_poster> jujugui call in 10!
[15:50] <rick_h_> hatch: oh nvm
[15:50] <gary_poster> hah!
[15:50] <Makyo> jujugui call in 10
[15:50] <hatch> lol
[15:50] <rick_h_> hatch: we don't have the hover color change
[15:50] <Makyo> Darn :)
[15:50] <rick_h_> Weekly Numbers: Makyo - 3; gary_poster - 1
[15:50] <gary_poster> my shining moment
[15:50] <rick_h_> :P
[15:50] <gary_poster> :-)
[15:51] <gary_poster> hey benji, did you have the call with mark b?  did he get back to us?  I've been a bit swamped
[15:51] <benji> gary_poster: he never got back to us (that I saw)
[15:51] <gary_poster> ok
[15:52] <gary_poster> too bad
[15:53] <gary_poster> hey jujugui, somebody give the second review of bcsaller's https://codereview.appspot.com/14485046/ so he can land it!
[15:53] <hatch> on it
[15:53] <gary_poster> thanks hatch
[15:54] <gary_poster> Makyo, that branch should replace some but not all of my branch that I shared with you yesterday evening .  We can talk about details later if you want
[15:54] <hatch> gary_poster: to QA just drag the deployer file?
[15:54] <Makyo> gary_poster, alright, just going through the annotations stuff now.  It is annotation, but I need to make sure which ones need changing.
[15:55] <gary_poster> cool thanks Makyo
[15:56] <gary_poster> hatch, I think verifying that export has x-y annotations again is the core qa element.  bcsaller, am I right?
[15:56] <gary_poster> hatch, drag deployer file might not yet work still until we have my change--or at least my change makes it more reliable
[15:57] <bcsaller> gary_poster: actually its a little trickier than that for a reason that caught me, the gui-x/y didn't make it back to the client models before, but even once it started working I couldn't tell at first because we delete them as soon as we apply them in the draw code
[15:57] <hatch> yeah it fails
[15:57] <bcsaller> I spent a while on that in the "this should be working stage"
[15:57] <hatch> can't dd the wp-deployer.yaml
[15:57] <bcsaller> that worked for me last night, testing
[15:58] <bcsaller> and the tests import that all the time
[15:58] <hatch> Object {err: "[object Object]", DeploymentId: undefined}
[15:58] <hatch> ohh
[15:58] <gary_poster> the way we handle next in the go sandbox is broken without my branch <shrug>
[15:58] <hatch> manage.jujucharms.com doesn't have mysql-26 or wordpress-15
[15:58] <Makyo> jujugui call in 2
[15:59] <gary_poster> hatch try benji's
[15:59] <gary_poster> might work
[15:59] <gary_poster> but gui will always miss the first delta returned to it until my branch lands
[16:04] <bac> rick_h_: i just put both of our faces on the release card.  first one to it tomorrow wins.
[16:04] <rick_h_> bac: cool, see you at noon :P
[16:04] <bac> :)
[16:19] <bcsaller> hatch: the dnd import has issues with the charmworldv3 flag, works without, seeing if there is a simple resolution
[16:24] <hatch> cool thanks - yeah that should probably be fixed heh
[16:28] <bcsaller> hatch: it appears to be an issue with not having backfilled charms in api3, if I set the revision in the import to current it works fine, but it gets 'no such charm' for older version in the bundle
[16:29] <hatch> ohhh ok cool
[16:29] <hatch> I'll qa without the flag
[16:32] <rick_h_> bcsaller: yep, benji is working on that so hopefully made better soon
[16:33] <hatch> bcsaller: so I drag it to the canvas, it lays out in a certain 'layout' then it snaps to a different layout on the next delta
[16:36] <hatch> bcsaller: so I add 3 services, relate them, lay them out, export, refresh, import - layout is different
[16:37] <hatch> does that mean that QA is no good?
[16:38] <bcsaller> hatch: There is an issue with export, its using the client db, and we delete the position annotations, when we apply them. It should either use an env call to get its YAML or we can't delete env. Either of those are non-trivial changes
[16:38] <hatch> ok so as long as the export file has the annotations we are good?
[16:39] <bcsaller> hatch: yes, but it won't the way its setup now.
[16:39] <bcsaller> the server and the client both get the annotation
[16:39] <bcsaller> thats what this branch fixed
[16:39] <bcsaller> but then the client deletes the position
[16:39] <bcsaller> so more changes are required
[16:41] <hatch> oh ok so there is no way to qa this
[16:41] <hatch> because the export doesn't contain the xy annotations
[16:41] <bcsaller> the export should have position, that isn't what I was verifying before
[16:41] <hatch> hmm
[16:41] <bcsaller> maybe that should be another branch, but I could do it here
[16:42] <hatch> yeah it's definitely not in there
[16:42] <bcsaller> yes, are you reading what I'm saying? does it not make sense? :)
[16:42] <rick_h_> hatch: lol anthonydillon got bit by double dispatch. "Yep, we know about that one" :)
[16:42] <hatch> lol
[16:43] <bcsaller> itit gets set on the client, applied and then removed by the client
[16:43] <bcsaller> and then we use the client db for the export
[16:43] <bcsaller> which no longer has it
[16:43] <anthonydillon> rick_h_, Good to know :)
[16:43] <hatch> ok then because you just said it should have it haha
[16:43] <hatch> so I was confused
[16:44] <bcsaller> it does have it, but then it removes it when used. so it has it only till it draws it in the right position
[16:44] <hatch> no the file does not have the xy positions
[16:44] <bcsaller> ahh, right
[16:44] <hatch> which makes sense from what you're saying
[16:44] <hatch> I think we were just talkign around eachother haha
[16:44] <bcsaller> yeah, the wire protocol was broken before
[16:48] <bcsaller> hatch: so this is a real fix and I'd like to land it. The solution to the other problem should be another branch. Ideally that would be the server doing the export but that really means core support. Because we don't have that I need to look at a) not deleting the position on application (which might be a big change) or b) polling the position on client generated export (which is best but another branch)
[16:49] <bcsaller> I guess that means the export deployer call can take an optional topology to ask for position info during the export
[16:50] <hatch> it's lgtm'd
[16:50] <hatch> hmm
[16:51] <hatch> well we really need a way to export the xy's - without it they won't be able to make layouts for the bundles
[16:51] <hatch> I guess I don't understand where we are deleting the annotations on export
[16:52] <bcsaller> hatch: not on export, on draw
[16:52] <hatch> but they aren't in the export either
[16:52] <bcsaller> how could they be, they were deleted from the model on draw ^^
[16:53] <hatch> so we delete them from the model, waiting for the delta to re-populate?
[16:53] <bcsaller> I can explain it in a hangout if you'd like
[16:54] <hatch> yeah I think that's best haha
[16:54] <bcsaller> too much typing
[16:54] <bcsaller> :)
[17:01] <hatch> allll cleared up!
[17:03] <gary_poster> bcsaller, (b) is very high priority then, yeah?  Because exporting x/y is very important
[17:03] <gary_poster> sounds pretty easy?
[17:04] <bcsaller> gary_poster: it is, and its my next task, should be about an hour
[17:04] <gary_poster> mm, no, middlin
[17:04] <gary_poster> ok awesome
[17:12] <hatch> hmm the inspector no longer shows the unit count on comingsoon
[17:12] <hatch> could someone else confirm this for me?
[17:12] <hatch> deploy a service with 10 units, the inspector after deploy will show 0/0
[17:13] <rick_h_> shows 0 until I set 10 then it updates to 10 running
[17:13] <rick_h_> now I can't change it :/
[17:14] <rick_h_> the units field got disabled?
[17:14] <rick_h_> so after you set the number of units, the field gets disabled
[17:15] <rick_h_> hatch: only doing it on the first one deployed to me
[17:16] <rick_h_> hatch: once I close it and deploy a new service the count works and doesn't show 0
[17:20] <rick_h_> hatch: I'm qa'ing on juju trunk and not seeing it, but ther'es already a charm in the env (the gui charm)
[17:20] <hatch> hmm
[17:21] <hatch> this is a critical bug
[17:21] <hatch> Makyo: before release we need to fix ^
[17:21] <hatch> oh wait
[17:21] <hatch> is comingsoon running an old version?
[17:21] <rick_h_> no idea
[17:21] <hatch> nope
[17:22] <hatch> frankban: your branch landed right?
[17:22] <frankban> hatch: yes
[17:22] <hatch> the handle for the side bar is under the charm details on comingsoon
[17:22] <rick_h_> hatch: the minimize tab?
[17:22] <hatch> I wonder if comingsoon needs a 'make clean-all && make'
[17:22] <hatch> yeah
[17:22] <rick_h_> hatch: yea, ther's a bug for that
[17:23] <rick_h_> hatch: filed that one the other day
[17:23] <hatch> frankban fixed it
[17:23] <hatch> rick_h_: do you know how to log into comingsoon and re-make it?
[17:24] <rick_h_> hatch: no, bac and gary_poster have access
[17:24] <bac> hatch: what's up?
[17:24] <hatch> can you clean-all and make comingsoon ?
[17:24] <bac> hatch: sure
[17:24] <hatch> it doesn't appear to be running the latest code
[17:24] <hatch> thanks
[17:24] <rick_h_> hatch: https://bugs.launchpad.net/juju-gui/+bug/1234321
[17:24] <_mup_> Bug #1234321: the minimize tab should have a higher z-index than the inspector charm details <juju-gui:Triaged> <https://launchpad.net/bugs/1234321>
[17:25] <rick_h_> hatch: that's not what he did, is this what you mean?
[17:25] <hatch> rick_h_: yes - frankban fixed that in his last branch
[17:25] <rick_h_> hatch: oh, didn't realize that.
[17:25] <frankban> rick_h_: ah, didn't know there was a bug
[17:26] <rick_h_> frankban: all good, updating now. Thanks for the fix!
[17:26] <hatch> yeah comingsoon is very broken compared to local trunk
[17:26] <hatch> but it does disable the unit scale still
[17:26] <rick_h_> hatch: yea, I'm filing that bug as my QA bug :)
[17:26] <hatch> haha deal!
[17:27] <hatch> make a critical card too plz
[17:27] <hatch> we can't release with that
[17:27] <rick_h_> hatch: rgr
[17:27] <rick_h_> hatch: noooooo https://bugs.launchpad.net/juju-gui/+bug/1236427
[17:27] <_mup_> Bug #1236427: Scale up input stops working after units are added/removed <juju-gui:Triaged> <https://launchpad.net/bugs/1236427>
[17:27] <rick_h_> frankban: beat me to it
[17:28] <hatch> lol
[17:28] <frankban> :-)
[17:28] <rick_h_> hatch: card added though
[17:31] <gary_poster> benji, https://plus.google.com/hangouts/_/55ecf5ce6f3c3ad26992f6b8bb2db173e572ffb6 if you can
[17:31] <benji> gary_poster: coming
[17:55] <bac> jujugui: reminder, monday is a US holiday:  http://theoatmeal.com/comics/columbus_day
[17:56] <hatch> bac: lol that comic was funny
[17:56] <gary_poster> lol thanks bac
[17:58] <hatch> I don't know how much of that is true but if it is that's funny
[18:09] <hatch> bac: so which holiday are you going to enjoy? :)
[18:10] <bac> hatch: dunno, i may work and take off the friday after thanksgiving.  haven't decided.
[18:10] <hatch> our thanksgiving is monday
[18:13] <benji> gary_poster: laptop battery died; back in a second
[18:13] <gary_poster> ok benji
[18:13] <marcoceppi> rick_h_: I've updated the blueprint with the response stuff, https://blueprints.launchpad.net/charm-tools/+spec/charm-bundle-support
[18:14] <rick_h_> Makyo: do we have a bug about the canvas jumping on your while pending units are coming up?
[18:14] <hatch> bcsaller: kickin around? I have a databinding question
[18:14] <bcsaller> hatch: yeah
[18:14] <hatch> quick hangout?
[18:14] <rick_h_> marcoceppi: cool, I'd rather keep thigns lower case and spelled out so will do error, warning, information
[18:14] <Makyo> rick_h_, only new services; it should center new services.
[18:14] <marcoceppi> rick_h_: fine by me
[18:15] <rick_h_> marcoceppi: ah ok, so I' deployed a secnod service, it went into pending. I moved the canvas over to see everything, and then it jumped back to center the new one coming up still
[18:15] <rick_h_> errr Makyo ^^
[18:15] <rick_h_> Makyo: rinse/repeat
[18:15] <rick_h_> Makyo: then, once it's up and running, it seems to stop trying to force center
[18:16] <Makyo> rick_h_, okay.  File a bug please..
[18:17] <rick_h_> Makyo: will do.
[18:19] <rick_h_> Makyo: marking high but really not sure if it's really low. Low seems to be where things would go to die sometimes
[18:19] <Makyo> rick_h_, High is fine.  If it comes up I can retriage.  Still trying to sort diffs.
[18:30] <bac> hatch: i forgot to ask, did the 'make clean' on comingsoon clear up the problems you were seeing?
[18:30] <hatch> checking
[18:30] <rick_h_> bac: yep, change dto 610
[18:31] <bac> great
[18:31] <hatch> bac: yep that's working now - still have the unit issue
[18:31] <hatch> but tha'ts a separate bug
[18:31] <hatch> thanks
[18:31] <bac> np
[18:31] <hatch> wonder why it didn't rebuild the css
[18:31] <rick_h_> hatch: did you file that then? I did not as I could not dupe that in my juju-core-lxc env I'm qa'ing in
[18:31] <hatch> oh I thought it already was
[18:32] <hatch> ok will file
[18:32] <rick_h_> hatch: wait, what unit bug?
[18:32]  * rick_h_ thinks hatch and him are crossing wires
[18:32] <hatch> comingsoon > deploy mysql > inspector will show 0/0 for units
[18:32] <rick_h_> hatch: ok yea is that an existing bug then? I wasn't aware of it.
[18:32] <rick_h_> hatch: can you dbl check/file?
[18:33] <hatch> if you enter a value other than 1 in the ghost it will change to that number after the next delta
[18:33] <hatch> if it's still1 then it'll be 0
[18:33] <hatch> yep I'll file/card it
[18:34] <gary_poster> hatch, rick_h_ , sorry, known bug, I gave fix to Makyo
[18:34] <rick_h_> man this upgrade service thing is killing me
[18:34] <Makyo> hatch, rick_h_ gary_poster already has a diff I'm trying to get in there.
[18:34] <hatch> ohh ok cool
[18:34] <rick_h_> Makyo: ah ok cool
[18:34]  * hatch closes bug window
[18:34]  * rick_h_ didn't catch that was the diff in question
[18:34] <hatch> gary_poster: Makyo does this also fix the disabled unit input bug?
[18:34] <Makyo> My bad.
[18:35] <gary_poster> hatch no
[18:35] <gary_poster> hey guys I need to take off.  thanks all, and I'll see some of you with Huw.
[18:35] <hatch> alright I'll leave that one there
[18:35] <hatch> cya
[18:41] <rick_h_> Makyo: heads up, sent some more feedback to luca/-peeps on the upgrade. Let me know if any of that is nuts or doesn't make sense.
[18:48] <Makyo> rick_h_, ah, yeah.  I don't think it'd be too hard to have a [current revision] for whichever version or whatever.
[18:49] <Makyo> Another time, though
[18:59] <bac> hi rick_h_, in charmworld it looks like you made a change recently about how icons are served up.  do you have a sec to talk about it?
[19:13] <hatch> bcsaller: is this waht you had in mind? https://gist.github.com/hatched/55964a4dfae5de925e27
[19:14] <hatch> bcsaller: I ask because I now get the reported error whenever trying to open anything into that slot again
[19:16] <bac> benji, gary_poster: we currently are using the default icon for all bundles.  is that a temporary thing?
[19:17] <benji> yeah, I would think so
[19:21] <bac> benji: as is, if the bundle has an icon we substitute the default.  if it has no icon then it gets nothing, rather than the default.
[19:22] <benji> heh, that's probably not what was intended
[19:37] <hatch> lunching
[20:07] <bac> benji: would you have time to review https://code.launchpad.net/~bac/charmworld/bundle-icon-path/+merge/190470
[20:07] <benji> bac: sure
[20:09] <Makyo> jujugui Current status, two bugs in sandbox: when deploying a service, you get 1 of [0] units when the inspector opens the first time, opens to 1 of [1] units each time after.  Also the field disabled after changing unit count.  Any others?
[20:09] <Makyo> (trying these in lxc next)
[20:11] <benji> bac: the branch looks good; I saw a couple of very small things
[20:11] <bac> benji: great, thanks
[20:39] <bcsaller> hatch: I think the diff looks good, what error are you seeing?
[20:40] <bac> hey benji would you re-approve https://code.launchpad.net/~bac/charmworld/bundle-icon-path/+merge/190470 ?  it was stated early that the new lander didn't care about new revisions but it very much does.
[20:40] <hatch> bcsaller: just got back from lunch sorry
[20:40] <bac> s/early/earlier today/
[20:40] <hatch> so I fixed the issue I had mentioned - but the original issue still remains, so I'm going to be tracking on that now
[20:41] <hatch> it appears that for some reason the viewlet in updateDOM is the unitDetails viewlet and not the charmDetails one
[20:41] <hatch> so going to have to track that one back
[20:41] <hatch> I know that diff is working because the bindings length now goes up when you open the panel and then returns back to the original when closed
[20:42] <gary_poster> Makyo, sounds good.  you mean you have those two fixed?  If so, do you want to go ahead and get those landed?  I can try to get them through for you if that helps.
[20:42] <bcsaller> hatch: don't all the viewlets still update? You'd see them all
[20:42] <hatch> the unitDetails viewlet is closed
[20:42] <hatch> but for some reason updateDOM is being called on it
[20:42] <hatch> when I try and open the charmDetails viewlet
[20:42] <Makyo> gary_poster, those are left.  Checking more on a real env
[20:42] <bcsaller> hatch: close is different than a hidden tab how? cause those are kept up to date too
[20:43] <gary_poster> Makyo, I think hatch fixed your #2?
[20:44] <gary_poster> "the field disabled after changing unit count"
[20:44] <Makyo> Oh?  Maybe I'm a little out of date, then.
[20:45] <hatch> bcsaller: the left tabs we remove the content from the DOM
[20:45] <hatch> at least that's what the code shows
[20:45] <gary_poster> Makyo, could be completely confused.  wait to see if hatch confirms/denies
[20:45] <hatch> sorry reading the backlog
[20:45] <gary_poster> bug 1236427
[20:45] <_mup_> Bug #1236427: Scale up input stops working after units are added/removed <juju-gui:Triaged> <https://launchpad.net/bugs/1236427>
[20:45] <hatch> that one still exists
[20:46] <hatch> I am working on the charm details one
[20:46] <hatch> I don't know if there is a bug for mine - it's not on the card
[20:47] <Makyo> That one as well.  Had assumed it was a misbound event was all :(
[20:47] <benji> bac: I think you just need to re-mark it as approved (at the top)
[20:47] <hatch> Makyo: gary_poster on comingsoon when I deploy using the default settings there are never any units in the inspector it's always 0/0
[20:47] <benji> (I've had the same issue)
[20:47] <bac> benji: no, i think it needs a vot
[20:48] <bac> vote
[20:48] <benji> :(
[20:48] <hatch> Makyo: it's a databinding issue - so far I've found one bug and resolved it but tracking down another
[20:48] <Makyo> hatch, Have that fixed locally as we mentioned with gary_poster's changes.
[20:48] <hatch> oh ok cool
[20:48] <hatch> then it's just the scale up input bug
[20:48] <Makyo> hatch, and yours, correct?  Just those two?
[20:48] <benji> bac: will you try?  I'd like to know for sure.
[20:48] <hatch> yes, and I have no ETA on mine, sorry
[20:48] <Makyo> okay
[20:49] <bac> benji: that is what i did previously.  after your approval i made my changes, pushed them, and marked the MP approved.
[20:50] <benji> bac: done
[20:51] <bac> thanks
[20:56] <hatch> Makyo: as a status update (sometimes a good break helps break through the problem) I have solved the original issue now, another issue, and now exposed another so hopefully nearing the end
[20:57] <Makyo> hatch, alright.  I'm running into issues with coordinates and centering in a real env., will keep posted.
[21:02] <hatch> sweet fixed
[21:02] <hatch> three bug fixes all within the same 'patch' haha
[21:03] <hatch> I better comment this else noone will know what's going on
[21:09] <Makyo> Oh, good, it affects dragging services now too.  Augh.  I am really tired of solving this same thing over and over again.
[21:09] <Makyo> </scarcasm?
[21:09] <Makyo> >
[21:13] <hatch> I think you put your close tag in the wrong spot
[21:13] <hatch> ;)
[21:13] <hatch> bcsaller: I still have to write a test for this - but would like it if you could take a peek https://codereview.appspot.com/14489044/  just to make sure it's done in the proper spot
[21:14]  * bcsaller peeks
[21:22] <bcsaller> hatch: notes sent
[21:23] <hatch> thanks
[21:32] <hatch> bcsaller: re your comment on the loop - I need to loop through this model and compare with the key because it appears that there are bindings which match the model id which are associated to other areas
[21:32] <hatch> this could be another bug?
[21:32] <hatch> I can investigate further if you like
[21:32] <bcsaller> hatch: it sounds like we're conflating what that method should do in that case
[21:33] <hatch> I could split this loop out
[21:33] <hatch> but it's a nice place to put it because every time this method is called it should do this loop
[21:34] <hatch> but it could be broken out into a private utility like method
[21:34] <bcsaller> sounds like we want unbindModel and unbindViewlet that can filter the list either way
[21:35] <bcsaller> this is unbind model
[21:35] <hatch> agreed, but that's probably more work than I want to do atm
[21:35] <bcsaller> and engine.unbind is for all
[21:35] <hatch> since this is blocking release
[21:35] <bcsaller> well, its just the one new method that unbinds by viewlet name I think
[21:37] <bcsaller> I'm not sure about the semantics of needing to loop the keys when the only argument is a model, maybe an optional viewlet arg as well?
[21:38] <hatch> that sounds like an idea - so you want the viewlet.remove() method to call the original 2 then another to remove the bindings via the viewlet name?
[21:39] <bcsaller> I think that is what we're actually after, no?
[21:41] <hatch> yeah that makes sense
[21:41] <hatch> so in this case it would be the viewlet, I'm not sure when model would be required
[21:41] <hatch> or when it would be called for that matter
[21:42] <hatch> well actually unbind doesn't remove anything from the _bindings list
[21:42] <hatch> so in there would be unbindModel
[21:47] <Makyo> No luck on this positioning thing, gonna walk the dogs and see if that helps.
[21:49] <bcsaller> Makyo: I'm also looking at the position issues, happy to sync up when you get back
[22:08] <huwshimi> Morning
[22:11] <hatch> morning
[22:13] <hatch> Makyo: so is it looking like release will not be until tomorrow?
[22:20] <Makyo> hatch, correct. The locked fields and dragging causing service jumps (same issue as rick_h_'s centering bug, I think) have been show stoppers in the past, not comfortable with them today.
[22:21] <hatch> alright no problem
[22:21] <hatch> I'm about to land my fix so that won't be holding you up
[22:21] <hatch> I just have to figure out a good way to test it
[22:21] <hatch> :)
[22:26] <Makyo> bcsaller, still around? Zonked, but willing to chat.
[22:28] <Makyo> FWIW I'm running into the delayed annotations thing, where if I try to drag, the service jumps to the old position, but still moves with my cursor, however many pixels away.  Ditto centering: centers on old position.
[22:29] <bcsaller> Makyo: I'm seeing that as well
[22:29] <gary_poster> jujugui (hi huwshimi!) call in 1 or 2 for those who want to attend
[22:30] <bcsaller> Makyo: I was trying to flow diagram all the places we manipulate x/y and see if I could simplify it
[22:31] <Makyo> bcsaller, yeah, I think that's a good idea.  There's x/y attrs on services, x/y props on service_boxes, and gui-x/y annotations.  A little too organic to keep up with.


  Need some remote hands to do a server hard disk swap.
[07:25] <head_victim> blahdeblah: I know there is a semi active CQLUG that a few people hang around in linux-aus.
[07:25] <head_victim> Not sure if any of them are in Rocky exactly but the closest I can think of short of going on a road trip myself :)


[12:27] <wgrant> pitti: Hi, yesterday's hardy kernel update has bad overrides. At least l-r-m landed in universe.
[12:28] <wgrant> This makes linux-generic, linux-server uninstallable.
[12:37] <lamont> wgrant: I'm not so sure, since the install in question is done with universe enabled..
[12:38] <wgrant> lamont: What's the error?
[12:38] <wgrant> 2.6.24-30 certainly does have bad overrides, but the specific one I quoted may not be directly relevant here.
[12:38] <lamont> that nvidia-kernel-common doesn't exist
[12:39] <lamont> because it's in restricted
[12:40] <lamont> though the top level error is simply that linux-restricted-modules-generic is uninstallable
[12:42] <wgrant> lamont: Which is interesting, since linux-restricted-modules-2.6.24-29-generic also depended on nvidia-kernel-common. And nvidia-kernel-common has always been in restricted.
[12:42] <wgrant> https://launchpad.net/ubuntu/hardy/i386/nvidia-kernel-common
[12:44] <wgrant> Hmm
[12:44] <wgrant> Interesting.
[12:44] <wgrant> hardy's linux-generic was in restricted until March.
[12:45] <wgrant> April, even.
[12:53] <pitti> wgrant: usually that already gets caught in -proposed; it was fixed yesterday, is any package still wrong?
[12:54] <pitti> wgrant: there's a bug in soyuz somewhere, it randomly puts some binaries into universe
[12:54] <pitti> we haven't yet written a script to fix overrides after copying from PPA
[12:54] <wgrant> Well, it's not really a bug.
[12:55] <wgrant> For non-queued copies of new packages it uses the default overrides
[12:55] <wgrant> Which is universe.
[12:55] <pitti> well, it's not predictable
[12:55] <lamont> pitti: mdeslaur and jdstrand are also digging into this
[12:55] <pitti> as many of the kernels do land in main
[12:56] <wgrant> wgrant@lamuella:/tmp/chroot-autobuild$ rmadison linux-restricted-modules-2.6.24-29-generic
[12:56] <wgrant> linux-restricted-modules-2.6.24-29-generic | <IP_ADDRESS>-29.9 | hardy-security | amd64, i386
[12:56] <wgrant> linux-restricted-modules-2.6.24-29-generic | <IP_ADDRESS>-29.9 | hardy-updates | amd64, i386
[12:56] <wgrant> wgrant@lamuella:/tmp/chroot-autobuild$ rmadison linux-restricted-modules-2.6.24-30-generic
[12:56] <wgrant> linux-restricted-modules-2.6.24-30-generic | <IP_ADDRESS>-30.11 | hardy-security/universe | amd64, i386
[12:56] <wgrant> linux-restricted-modules-2.6.24-30-generic | <IP_ADDRESS>-30.11 | hardy-updates/universe | amd64, i386
[12:56] <wgrant> That's the not whole problem here, but it shows that something is not right.
[12:58] <mdeslaur> ok, overrides have been adjusted for yesterday's lrm
[12:58] <pitti> mdeslaur: ah, you did? I'm just running change-override
[12:58] <mdeslaur> pitti: I just got jdstrand to do it
[12:58] <wgrant> Hm, not showing up in the web UI yet.
[12:58] <pitti> right, so it needs a publisher
[12:58] <lamont> which runs in 5 min
[12:59] <wgrant> I don't see !universe pubs on https://launchpad.net/ubuntu/hardy/amd64/linux-restricted-modules-2.6.24-30-generic
[13:00] <mdeslaur> fyi, I got him to do this: http://paste.ubuntu.com/745874/
[13:01] <wgrant> Ah
[13:01] <wgrant> That's only half the trouble :/
[13:02] <pitti> mdeslaur: want me to run the same again for hardy-updates?
[13:03] <wgrant> lamont: Do we have logs from previous installs to see what it actually did?
[13:03] <lamont> we do not
[13:04] <jdstrand> pitti, mdeslaur: re updates> I just did
[13:05] <pitti> ok, great
[13:06] <wgrant> lamont: I don't see how you can install linux-generic without restricted :/
[13:06] <lamont> wgrant: given what I've seen, I believe that main/restricted are what we install with
[13:06] <lamont> which would explain the universe thing breaking things
[13:07] <wgrant> Oh!
[13:07] <wgrant> That makes more sense.
[13:07] <pitti> yes, linux-image-generic -> main only
[13:07] <pitti> linux-generic -> includes l-r-m
[13:07] <pitti> for lucid onwards that's easier, as the kernel is purely main and everything else is DKMS
[13:07] <wgrant> lamont: You said earlier that nvidia-kernel-common didn't exist.
[13:08] <wgrant> main/restricted but not universe makes a lot more sense, but then it would be that linux-restricted-modules-2.6.24-30-generic didn't exist.
[13:08] <wgrant> (because it's in universe, and won't be fixed this publisher unless someone is extremely quick)
[13:08] <lamont> nvidia-kernel-common was me walking down the uninstallable tree on an installed machine, which happened to be main/universe
[13:08] <wgrant> Ahaa
[13:09] <lamont> damn red herrings
[13:09] <wgrant> pitti, jdstrand: Could you bring linux-restricted-modules-2.6.24-30-generic back into main?
[13:09] <wgrant> -29 is there, -30 is universe
[13:09] <pitti> it certainly should be in restricted?
[13:09] <pitti> this must not be in main
[13:10] <wgrant> pitti: Well, it's been in main for a while.
[13:10] <pitti> m -s hardy -S linux-restricted-modules-2.6.24
[13:10] <wgrant> eg. linux-generic has been in main since April.
[13:10] <pitti> that's the reference
[13:10] <lamont> once we verify -30, we should maybe fix -29
[13:10] <pitti> wgrant: that was also an error thehn
[13:10] <pitti> wgrant: that was also an error then
[13:10] <wgrant> pitti: Certainly.
[13:10] <wgrant> But I think we should make things installable first.
[13:10] <wgrant> Then get a list of what's where and fix it up.
[13:10] <wgrant> Because it is a hideous mess at the moment.
[13:11] <wgrant> l-r-m and linux-generic were initially in restricted, but ended up in main a few months back.
[13:11] <lamont> wgrant: I wonder if maybe overrides shouldn't allow regexes
[13:11] <wgrant> -28 of both was in restricted
[13:11] <wgrant> Then -29 was in main
[13:11] <wgrant> And -30 is split across main and universe
[13:12] <lamont> and kittens.  I'm sure kittens were involved somehow
[13:12] <wgrant> We could send them straight back to restricted now, but I'm more interested in making things work immediately.
[13:15] <pitti> wgrant: I thought we just did send them back to restricted?
[13:15] <pitti> how would that make things not work?
[13:16] <wgrant> pitti: That didn't include everything.
[13:16] <wgrant> linux-restricted-modules-common was there, but no other l-r-m bits.
[13:27]  * wgrant sleeps.
[15:51] <Riddell> hmm, found in new queue "Description: Unity configurator This program allows one to configure and tune Unity with a pleasant and comfortable graphical interface."
[15:51] <Riddell> do we want this in the archive?
[16:10] <skaet> Riddell,  good question.
[16:11] <Riddell> it reminds me of ccsm
[16:11] <skaet> pitti, ^^  any thoughts on this?
[16:11] <skaet> what's ccsm?
[16:12] <tumbleweed> skaet: compizconfig-settings-manager
[16:12] <tumbleweed> this is at least friendlier than that. But does it expose things that it shouldn't?
[16:12] <skaet> thanks tumbleweed
[16:14] <Riddell> tumbleweed: I'm not sure how you'd define things it shouldn't
[16:14]  * skaet thinks it needs some review by the desktop and dx team before letting it in.
[16:15] <ogra_> are we talking about universe ?
[16:15] <Riddell> ogra_: yes
[16:15] <ogra_> that really shouldnt need a DX review
[16:15] <ogra_> its universe after all, as long as the package fulfills the criteria for a universe package there shouldnt be any political reason to not have it
[16:16] <skaet> ogra_, I was thinking it might be useful for the DX team to make sure that the interfaces its exposing/using are stable and likely to persist.
[16:16] <tumbleweed> eep, the code aint pretty (and is italian)
[16:17] <ogra_> (the dev could as well have someone upload it to debian and wed would get it by sync ...)
[16:17] <skaet> ogra_ ack.
[16:17] <ogra_> tumbleweed, well, that might be a reason why it doesnt fulfill the criteria ...
[16:17] <tumbleweed> yeah, if it's not harmful, I don't have any problems with it, and don't think we should in general
[16:17] <ogra_> but having a canonical entity block a universe package is a very bad idea imho
[16:18]  * skaet nods
[16:18] <tumbleweed> I'd much rather things like this went into the archive, than we had people running crazy shell scripts or enabling a bazillion PPAs
[16:18] <ogra_> true
[16:19] <ogra_> though if the code is bad or harmful it definitely doesnt qualify ...
[16:19]  * tumbleweed doesn't think it's harmful, but I don't know what's safe to change in unity
[16:19] <Riddell> tumbleweed: without reviewing the code I don't know if this is any different from a crazy shell script, it might change any random config option
[16:19] <tumbleweed> it just changes gesettings options
[16:19] <ogra_> that should be safe if it does it the right way
[16:20] <ogra_> thats something every user can do using dconf-editor
[16:20] <ogra_> (which is a horrid interface btw)
[16:23] <seb128> is there any screenshot of that utility?
[16:23] <seb128> or a list of the options it allows to tweak?
[16:25] <tumbleweed> seb128: bzr branch lp:myunity; ack-grep -a gsettings
[16:25]  * tumbleweed would post screenshots, but about to run out for dinner
[16:25] <Riddell> seb128: people.canonical.com/~jriddell/tmp/myunity.png
[16:25] <jdstrand> fyi, the overrides were still wrong for a bunch of stuff on hardy, so kernels were still uninstallable. this is hopefully fixed now
[16:26] <jdstrand> mdeslaur is investigating the other kernels, and I am applying overrides on his behalf
[16:26] <jdstrand> he is updating some documentation as well
[16:27] <jdstrand> this all seems to originate with the ppa to -proposed copy. so I have added another bullet item to ArchiveAdministration t verify the overrides, and add nag text to copy-proposed-kernel.py as well
[16:28] <seb128> tumbleweed, ogra_, Riddell: it doesn't seem to do anything "dangerous", it tweaks configs in gconf
[16:28] <seb128> we never banned stuff from the archive based on the fact that users could break their config with those
[16:28] <seb128> we wouldn't have ccsm if that was the case ;-)
[16:28] <Riddell> I thought we didn't have ccsm in the archive
[16:29] <seb128> but at the same time I'm not sure if we should recommend those to go for extras rather, that seems the sort of hackish software that will not keep working long and stay broken in universe for years
[16:29] <seb128> Riddell, we do have ccsm in the archive for as long as we have compiz
[16:30] <Riddell> so we do
[16:41] <Riddell> seb128: what about ubuntu-tweak?
[16:41] <Riddell> didn't that get rejected?
[16:41] <seb128> dunno but I would like to see it available
[16:42] <ogra_> Riddell, the predecessor was rejected, because it was really harmful
[16:42] <seb128> it would be a better tools to recommends than gnome-tweak-tools (which depends on gnome-shell, so is not very nice to recommend to unity users who want to tweak gnome settings)
[16:42] <ogra_> automatix ?
[16:42] <ogra_> was that the name ?
[16:42] <ogra_> it broke the package manager in various ways etc
[16:42] <Riddell> ogra_: right
[16:44] <Riddell> https://lists.ubuntu.com/archives/ubuntu-archive/2010-August/036627.html
[16:45] <ogra_> wow, so nice and calm ...
[16:46] <ogra_> i remember a blogpost from matthew garret about automatix where he literally commented on every line and its harmfulness
[16:46] <Riddell> jdstrand is like that, I hear he doesn't even get flustered when linux updates go into universe
[16:46] <ogra_> heh
[16:46] <ogra_> which is a common issue :)
[16:47] <Riddell> I think I'd be happier if this myunity package was clear in the description that it was unofficial
[16:47] <jdstrand> heh
[16:48] <ogra_> Riddell, tell that to the packager then :)
[16:53] <Riddell> done
[17:05] <lamont> dear archive admins... halp.
[17:05] <lamont> https://launchpad.net/ubuntu/hardy/amd64/linux-restricted-modules-generic
[17:06] <lamont> and yet cocoplum shows it in universe as of 1617 UTC
[17:11] <jdstrand> lamont: mdeslaur and I are working it out
[17:12] <lamont> and as we discovered, we are in a twisty maze of tiny passages, all different
[17:13] <jdstrand> yes, the grue is after us, but he will be denied!
[17:52] <Riddell> skaet: I hear rumours about the release images being 750MB this cycle but I can't find any information on the topic, do you know where any UDS notes or WIs would be?
[17:52] <skaet> Riddell,  just a sec and I'll hunt down the blueprint.
[17:52] <Riddell> I thought it was https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-dvd-image but there's nothing there
[17:57] <seb128> Riddell, the sabdfl acked the possibility to go 750mb if needed but consensus is that we will probably not need it this cycle
[17:58] <seb128> Riddell, in practice I don't think we will have any change this cycle
[17:58] <Riddell> ok so we should worry about our images being 10MB oversized :)
[17:58] <skaet> thanks seb128
[17:58] <seb128> well I guess kubuntu could decide to use the option to go over 700mb
[17:59] <seb128> that would be a decision in your team
[17:59] <Riddell> I'm curious to know what the reaction would be
[17:59] <seb128> it was basically decided for Ubuntu that it's better if we can keep staying on the CD for the lts
[18:45] <Riddell> seb128: if ubuntu one goes to pyqt you think you can fit that onto the ubuntu desktop CD?
[18:46] <seb128> Riddell, we need to have that discussion, the u1 team wanted to have another try at this ubuntuone-installer thing
[18:47] <slangasek> I thought pitti vetoed the installer? :)
[18:50] <seb128> slangasek, yeah, in oneiric, that's why I say they want to have another try to it ;-)
[18:51] <slangasek> heh, I didn't realize it was a temporal veto
[18:52] <slangasek> anyone know why perl-modules 5.12.4-6 is still showing up in the precise Packages files?  Seems like it should've been garbage collected already, but maybe it's sticking around for benefit of armhf?
[18:52] <micahg> slangasek: NBS rdepends
[18:53] <micahg> libperl5.12 specifically
[18:53] <slangasek> ah
[18:53]  * slangasek bides his time then
[18:53] <seb128> slangasek, I'm not sure it got vetoed, it was on the CD until beta, we reverted because not having the music store on the CD was raised as an issue
[18:53] <micahg> slangasek: the LP people made it behave more like Debian so archs that are behind aren't uninstallable
[18:54] <seb128> slangasek, they were discussing having the music store showing on the CD this cycle but still having the installer triggering when you try to use it the first time
[18:54] <slangasek> micahg: yes, I knew about that recent change, I just couldn't work out what was holding it here
[18:54] <slangasek> though I was just about to check libperl5.12 in NBS :)
[20:34] <cjwatson> slangasek: yeah, it's due to perlkde not being buildable right now
[20:34] <cjwatson> which is due to a couple of bits of KDE being an upstream version or two back for some reason
[20:35] <cjwatson> libsmokekde-dev | 4:4.7.1-0ubuntu2 | precise/universe | amd64, armel, i386, powerpc
[20:35] <cjwatson> okular-dev | 4:4.7.2-0ubuntu1 |       precise | amd64, armel, i386, powerpc
[20:35] <cjwatson> ^- specifically those two
[20:35] <cjwatson> it was quite handy that it was still there so that I could use it as a test case for debootstrap, though ;-)
[21:41] <slangasek> cjwatson: heh, right :)


[01:46] <elfy> balloons: another tracker enhancement bug 1429321
[01:46] <elfy> sorry boss ...
[20:28] <wxl> elfy: apparently you contributed to http://forum.phillw.net/viewtopic.php?f=4&t=35 phillw tells me. can i ask you a question about it?


[17:05] <cyberanger> netritious: are you a fan of A Perfect Circle?
[18:42] <Fastforward85> Hey guys. How's it going?
[18:45] <cyberanger> not bad, how about you Fastforward
[18:47] <Fastforward> Doing well, thanks. Enjoying the rain and a sandwich at the moment.
[18:57] <netritious> cyberanger: they are ok. Big fan of Tool though.
[18:58] <cyberanger> netritious: they just released a new album this week, but afaik, only one song is new
[18:58] <cyberanger> yeah, I recalled us talking about Tool, wasn't sure about A Perfect Circle though
[18:59] <netritious> Well that's weird cyberanger, but then again, Maynard is involved :)
[18:59] <netritious> ^^about the "only one song is new"
[18:59] <cyberanger> the song is "By and Down"
[18:59] <cyberanger> yeah, that is very odd
[19:00] <netritious> what are some other bands you like cyberanger?
[19:01] <cyberanger> I'm all over the map lately, David Bowie, Nina Simone, Epica, In This Moment
[19:01] <netritious> haven't heard of Epica
[19:02] <cyberanger> http://youtu.be/CXp8297gqTU
[19:05]  * wrst doesn't understand  a word
[19:05]  * wrst wishes those kids would turn that noise down
[19:05] <wrst> and get off my yard!!!!
[19:09]  * cyberanger agrees with wrst
[19:10] <cyberanger> and it might help if it wasn't for the fact Epica is a Dutch symphonic metal band
[19:10] <wrst> ha ha will yeah !
[19:10] <cyberanger> and if I used a better video
[19:11] <wrst> actually that was pretty interesting
[19:11] <wrst> that combo of things
[19:11] <cyberanger> yeah, and that's just a sampling, it gets intrestingly weirder


[02:04] <m4gnus> R2Pi2 are you *just* a Raspberry Pi?
[02:06] <pleia2> m4gnus: pretty much
[02:06] <m4gnus> Ha! Yay!
[02:06] <m4gnus> >_>
[02:06] <DonkeyHotei> of course not, it's a pi with an irc client!
[02:09] <m4gnus> Does it do any tricks?
[02:10] <DonkeyHotei> idk, it's her pi, not mine
[02:58] <pleia2> heh, no, it doesn't do any tricks, just brought it in a few times to /exec some info about the pi
[02:59] <DonkeyHotei> what client is it running? i ask because prior to typing half this line, it didn't occur to me to ctcp version
[03:00] <pleia2> irssi
[03:08] <DonkeyHotei> i installed irssi on my first coin mining rig, which was already running headless with tmux, ubuntu of course
[03:08] <DonkeyHotei> precise, though
[03:10] <ianorlin> I only have irsii in my lxqt vm
[03:11] <DonkeyHotei> second rig is not secure and i don't want to expose it to the internet
[03:11]  * ianorlin doesn't like mining crypto currency because of power
[03:13] <DonkeyHotei> odd, my eeepc 900a running trusty froze on wake from suspend and when i force rebooted, the fonts got tiny-fied
[03:14] <DonkeyHotei> i can't read the unity menu bar
[03:35] <DonkeyHotei> i know i saw a font size control somewhere before, can't find it now
[03:36] <DonkeyHotei> pleia2: you're the expert
[03:37] <ianorlin> I would have ot reboot into my unity and not lxde to find it I don't remember off the top of my head
[03:38] <DonkeyHotei> unity makes the most sense on a screen that size, plus, utopic will be touchscreen-friendly, and i've installed a resistive touchscreen on it
[04:13] <nhaines> Utopic is not planned to be toucscreen-friendly.
[04:14] <nhaines> It'll be utopic+2 that'll have Unity 8, although utopic+1 should have a preview session.
[04:14] <DonkeyHotei> i was told otherwise in #ubuntu-touch
[04:15] <DonkeyHotei> utopic+2? seriously?
[04:16] <DonkeyHotei> and until then Win8 will be the sole touch-friendly OS when half the laptops at best buy have touchscreens?
[04:29] <nhaines> Yup.
[04:30] <nhaines> Although to be honest, Unity 8 isn't planned to work any differently than Unity 7 on desktops, touchscreen or not.
[04:31] <nhaines> And in any case, no sense in breaking Unity for *everyone* just so a couple of people can have some extra touchscreen features a little earlier.
[04:32] <DonkeyHotei> then ubuntu-touch MUST be installable on x86
[04:33] <nhaines> It has been since April 17th.
[04:33] <DonkeyHotei> last i tried, it required arm libs it couldn't get
[04:33] <nhaines> In a fashion, anyway.  "Ubuntu Touch" isn't a thing that exists.
[04:34] <nhaines> You'll want to install unity8-desktop-session-mir.
[04:37] <DonkeyHotei> i might try that on the netbook, will it care that the touchscreen is resistive?
[04:37] <DonkeyHotei> and that the driver is for xorg?
[04:38] <nhaines> Resistive touchscreen shouldn't matter.  Canonical isn't doing any development for X11, so you'll have to check with the community for Xorg stuff.
[04:42] <nhaines> Oh, I misread the question.  If Mir doesn't run on your netbook, neither will Unity 8.
[04:44] <DonkeyHotei> i'm sure it will run in some fashion. i just don't know if it has the same touchscreen driver as xorg
[16:23] <Guest64755> Ooops!  I've turned into Guest64755!
[16:26] <DonkeyHotei> [Wed 2014-06-04 08:13:34 PM PDT] <DonkeyHotei> odd, my eeepc 900a running trusty froze on wake from suspend and when i force rebooted, the fonts got tiny-fied
[16:26] <DonkeyHotei> [Wed 2014-06-04 08:14:10 PM PDT] <DonkeyHotei> i can't read the unity menu bar
[16:26] <DonkeyHotei> [Wed 2014-06-04 08:35:52 PM PDT] <DonkeyHotei> i know i saw a font size control somewhere before, can't find it now


[18:50]  * vorlon waves
[18:50] <mdeslaur> hi vorlon
[19:04] <vorlon> this does not look like quorum
[19:10] <mdeslaur> vorlon: what do we need for xnox's proposal on the list...can I just +1 it?
[19:10] <vorlon> well I haven't read it yet
[19:10] <vorlon> so maybe? :)