[00:09] <robert_ancell> TheMuso: hi
[00:09] <TheMuso> robert_ancell: Hey there.
[00:11] <robert_ancell> TheMuso: I have a BZR question... I've made a branch lp:~robert-ancell/gdl/ubuntu which I was trying some packaging ideas.  Now I don't want these changes anymore.  How do I a) mege with lp:~ubuntu-desktop/gdl/ubuntu or b) delete this branch?  Which is more correct?
[00:11] <TheMuso> robert_ancell: If you want to delete the branch, you want to go to http://launchpad.net/gdl/+branches and delete the branch from there.
[00:13] <robert_ancell> TheMuso: thanks, I assume I can do that from the command-line too?
[00:14] <TheMuso> robert_ancell: Not that I know of.
[00:14] <TheMuso> Sure you can delete the branch locally, but I am not sure about deleting it from LP on the command line.
[00:14] <rickspencer3> hi TheMuso
[00:15] <rickspencer3> thanks for your awesome interview feedback
[00:15] <TheMuso> Hey rickspencer3.
[00:15] <TheMuso> rickspencer3: np
[00:15] <rickspencer3> I would like to put it on the wiki as an example of good quality interview feedback
[00:15] <rickspencer3> would that be ok with you?
[00:15] <TheMuso> rickspencer3: BTW, I have a spec that I need approved. Its in the review stage, but hasn't yet been looked at. Do I need to do anything special?
[00:15] <TheMuso> rickspencer3: Sure, go ahead./
[00:15] <rickspencer3> in terms of the spec, who is the approver?
[00:16] <TheMuso> rickspencer3: It was foundations/Robbie, but the approver was changed to you. let me double check that.
[00:16] <rickspencer3> TheMuso: send me a link
[00:16] <rickspencer3> the approver should probably be pitti
[00:16] <TheMuso> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnome-speech-replacement
[00:18] <rickspencer3> TheMuso: I set pitti as approver, and set it to "pending approval" which will trigger pitti to review it
[00:18] <TheMuso> rickspencer3: Thanks a lot.
[00:18] <rickspencer3> he'll set it to approved, or make comments and send it back to "drafting"
[00:18] <rickspencer3> n/p
[00:18] <TheMuso> Gotcha, I know the process.
[00:38] <kalon33> good night !
[02:17] <Rammler1983> hallo, i can't log in after installing the latest ati driver
[02:20] <TheMuso> Rammler1983: What version of Ubuntu are you using?
[02:21] <Rammler1983> 9.04
[02:21] <TheMuso> Rammler1983: Are you talking about the fglrx proprietary driver, or the free driver?
[02:22] <Rammler1983> after updating with update manager in ubuntu and i restart the laptop the system freezes
[02:23] <TheMuso> How does it freeze? DO you get a login screen?
[02:23] <Rammler1983> no
[02:23] <Rammler1983> after choosing
[02:23] <Rammler1983> ubuntu 9.04
[02:24] <Rammler1983> i get the logo
[02:24] <TheMuso> Rammler1983: Ok. Do you still have the 2.6.28-7 kernel installed, and if so, can you boot that ok?
[02:24] <Rammler1983> but it not sharp
[02:24] <Rammler1983> no
[02:24] <Rammler1983> i cant
[02:25] <Rammler1983> i tried the alle the recovery options
[02:25] <Rammler1983> and still not
[02:26] <TheMuso> Hmm. If you boot with recovery mode, do you get any error messages at the time of the freeze?
[02:26] <Rammler1983> no
[02:26] <Rammler1983> it just freezes
[02:26] <Rammler1983> with out updating everything is fine
[02:26] <Rammler1983> but i can't use the effects
[02:29] <TheMuso> Rammler1983: ok, so you can't boot at all. What kernel are you trying to boot?
[02:30] <Rammler1983> the latest one
[02:30] <Rammler1983> just a sec.
[02:31] <Rammler1983> http://wiki.cchtml.com/index.php/Ubuntu_Gutsy_Installation_Guide
[02:32] <Rammler1983> i used method 1
[02:33] <Rammler1983> 2.6.28-11-generic kernel
[02:35] <TheMuso> hrm ok
[02:35] <TheMuso> Sorry I'm not sure whats going on then.
[07:28] <didrocks> good morning
[08:26]  * robert_ancell has made lots of enemies with his bug triaging in compiz.  Apparently LP stupidly is happily spamming everyone who is subscribed with duplicate reports (there are >200 of them)
[09:03] <pitti> Good morning
[09:16] <seb128> pitti: guten tag!
[10:00] <Ampelbein> seb128: good morning. I am unsure about your comment on bug 345727. I can't find a change done outside debian/* and apparently the patch still gets applied in the latest ubuntu-package. If I look at the diff introducing the fix (http://launchpadlibrarian.net/24141917/seahorse-plugins_2.26.0-0ubuntu1_2.26.0-0ubuntu2.diff.gz) I see that it is properly made as a patch and in revision 6 of the bzr branch this change was applied.
[10:01] <seb128> Ampelbein: the changelog entry is misleading then
[10:01] <seb128> "  * libseahorse/seahorse-gpg-options.c:
[10:02] <seb128>     - Copy gpg.conf skel instead of creating blank file
[10:02] <seb128> "
[10:02] <seb128> I've not looked into the source
[10:02] <Ampelbein> seb128: right, got confused by that at first too.
[10:02] <seb128> not sure why they claim the change is not in the current version then
[10:02] <seb128> anyway that should be sent upstream in any case
[10:05] <Ampelbein> seb128: I will do that.
[10:08] <Ampelbein> seb128: and i can confirm that this works correctly in karmic: "mv ~/.gnupg/gpg.conf .." ; seahorse-agent produces a correctly copied skeleton gpg.conf
[10:25] <seb128> grrrr at karmic
[10:25] <seb128> so running away from my laptop for half an hour means I've a system I need to powerdown using the power button when coming back now
[10:26] <Ampelbein> why is that?
[10:26] <seb128> because the box does nothing
[10:26] <seb128> blank screen doesn't react to vt changes, etc
[10:27] <Ampelbein> hm, i have no problems at all, nvidia graphics. can leave for hours, still working after.
[10:39] <pitti> ugh, I hope Robert used a script to fix the duplicates and didn't do this by hand
[10:39] <seb128> which ones?
[10:40] <pitti> all the compiz ones
[10:40] <pitti> got some 100 mails
[10:40] <seb128> we discussed duplicates of duplicates at uds and listed a tool to do the magic for that if that's what you are talking about
[11:28] <Laney> what's the point of all this de- and re-duping of that compiz bug?
[11:28] <Laney> it will be flooding lots of peoples inboxes
[11:35] <seb128> Laney: not keeping a duplicate open I guess
[11:36] <seb128> launchpad doesn't let you mark duplicate a bug which has duplicate
[11:36] <Laney> I just wonder if the gain is worth the pain
[11:37] <seb128> it didn't cost a lot either
[12:09] <seiflotfy1> hey guys
[12:09] <seiflotfy1> dunno where to bing this topic up
[12:10] <seiflotfy1> but at UDS i talked to Bono
[12:10] <seiflotfy1> i mean jono
[12:10] <seiflotfy1> he had the idea of writing an application that teaches people who cant read and write to do so
[12:38] <jpds> Haha, Bono :)
[12:41] <seiflotfy1> sorry
[12:41] <seiflotfy1> :P
[12:47] <kalon33> ^^
[12:53]  * seb128_ kicks karmic
[12:54] <seb128_> if somebody talked to me recently please say whatever you said again, karmic just crash my laptop when I'm away for a while
[12:55] <kalon33> it's karmic, just logical it is not yet quite stable ^^
[12:55] <kalon33> but it doesn't work so bad here :)
[13:13] <kalon33> hello crevette
[13:13] <crevette> hello
[13:14] <crevette> hey kalon33
[13:38] <Nafallo> kenvandine: confirmed that there will be a gajim 0.12.3 soon.
[13:38] <kenvandine> Nafallo: cool
[13:38] <kenvandine> Nafallo: did you get a chance to see why notifications aren't called?
[13:38] <Nafallo> kenvandine: nope
[13:38] <Nafallo> kenvandine: I did however get a chance to package 0.12.2 :-D
[13:38] <kenvandine> :)
[13:39] <kenvandine> still broken though?
[13:39] <Nafallo> kenvandine: yes.
[13:39] <Nafallo> kenvandine: are you sure it ever worked? ;-)
[13:39] <kenvandine> yes... positive... i have screenshots somewhere :)
[13:40] <kenvandine> in it's current state, at least last i tried, it doesn't even show the libnotify notifications
[13:40] <Nafallo> ehrm. does for me.
[13:40] <Nafallo> if you mean notify-osd stuff.
[13:40] <kenvandine> yes
[13:41] <kenvandine> well then it should work with the indicator
[13:41] <kenvandine> that had stopped working for me
[13:41] <kenvandine> the method that does that wasn't even getting called
[13:41] <Nafallo> the only part that works with the indicator is that I can see gajim in the list :-)
[13:41] <kenvandine> i even tried in a guest session, so no local config
[13:41] <Nafallo> hmm. weird.
[13:46] <asac> Nafallo: can you please upload latest gajim crack now?
[13:47] <asac> i am still suffering bugs i haveing filed a report for ;)
[13:47] <asac> havent
[13:47] <Nafallo> asac: I have it in my PPA. what's the bug?
[13:47] <Nafallo> asac: also... I have it in the wrong ppa. let me fix that :-)
[13:48] <asac> Nafallo: error dialogs jumping in my face whenever you (in particular) send a message
[13:48] <asac> Nafallo: why not push to karmic?
[13:48] <asac> i dont want to add yet another PPA ;)
[13:48] <asac> unless you have snapshots in there or something similar sexy
[13:49] <Nafallo> asac: oki. fair enough.
[13:51] <asac> Nafallo: so why didnt you upload to karmic ;)?
[13:52] <Nafallo> asac: because the publisher haven't ran yet?
[13:52] <asac> Nafallo: ah so you already uploaded to real archive? nice.
[13:53] <Nafallo> and ppa
[14:09] <seb128> pitti: what do we do if our specs don't fit well with having a list of tasks?
[14:10] <crevette_> hey seb128
[14:10] <pitti> seb128: as I wrote, just split them up as sensible
[14:10] <seb128> lut crevette_
[14:11] <seb128> pitti: hum, I'm not sure how to split the GNOME3 one, that's virtually an hundred small tasks ... should I spend a day listing all those?
[14:11] <pitti> seb128: e. g. the banshee one could be "package new version", "measure memory requirements", "write MIRs", "change seeds"
[14:11] <pitti> seb128: no, of course not
[14:11] <seb128> ie gnome-vfs has 37 rdepends in main
[14:12] <seb128> libglade around 60
[14:12] <seb128> etc
[14:12] <pitti> seb128: packaging gnome/zeitgeist are obvious ones
[14:12] <pitti> seb128: I guess you can't work on all 97 anyway? :-)
[14:13] <seb128> no, but I'm not sure what are realistic or not so I'm having difficulties putting a metric on that
[14:13] <seb128> that's why I'm asking ;-)
[14:13] <seb128> I was going to go on the best effort metric
[14:13] <pitti> seb128: yeah, this spec is very blurry
[14:14] <pitti> seb128: you could just split it up by "drop gnome-vfs" and "drop libglade", together with the two packaging ones
[14:14] <seb128> I can add "reduce gnome-vfs use"
[14:14] <seb128> but that will not be DONE 100% in karmic
[14:14] <pitti> seb128: just ignore them for now, I think, and just add zeitgeist/gshell
[14:14] <seb128> ok
[14:14] <seb128> thanks!
[14:15] <seb128> I will add those as goal with a comment saying having a precise metric will not be easy
[14:15] <pitti> well, since we don't have a precise goal, you can't have a precise metric :)
[14:15] <pitti> but let's not worry about this too much
[14:16] <pitti> having the "must have" facts in work items will suffice for the purpose
[14:16] <pitti> WI don't cover all of our work anyway
[14:16] <pitti> (bugs, mail, SRU, and whatnot)
[14:50] <pitti> rickspencer3-afk: ping
[14:50] <fta> anyone familiar with the nautilus internals?
[14:51] <fta> i need to know which part is responsible for the smtp dialogue
[14:51] <asac> i guess seb128 ^^
[14:52] <fta> -nautilus+evolution
[14:52] <crevette_> nautilus and smtp?
[14:52] <fta> oops
[14:52] <crevette_> ha
[14:52] <seb128> what dialog?
[14:52] <fta> SMTP
[14:52] <seb128> smtp is what you use to send emails
[14:52] <fta> between the client and the server
[14:52] <seb128> do you speak about the sent bar? the preference dialog?
[14:52] <seb128> the account details?
[14:52] <asac> or the protocol impl?
[14:53] <pitti> rickspencer3-afk: I got my work items parsing/CSV generation script ready
[14:53] <seb128> anyway better to ask on #evolution on irc.gnome.org
[14:53] <pitti> rickspencer3-afk: but it seems that the trend line in burndown.py is utterly hardcoded?
[14:53] <seb128> they are responsive and probably know the code better, I'm hanging there too
[14:53] <fta> seb128, asac: the protocol implementation, the headers sent by evolution are not good enough to use in my corporate environment
[14:54] <rickspencer3> pitti: yes, totally hard coded
[14:54] <pitti> rickspencer3: good morning
[14:54] <rickspencer3> I couldn't figure out how to access x,y coords of elements in the chart
[14:54] <rickspencer3> seems pychart just burns off the image, and then forgets about it
[14:54] <seb128> fta: the communication is in evolution-data-server
[14:54] <asac> fta: yeah the word dialog is then confusing because this usually refers to UI.
[14:54] <pitti> rickspencer3: this is line.draw([(0,380),(725, 0)])
[14:54] <pitti> ?
[14:55] <rickspencer3> pitti: right
[14:55] <rickspencer3> and line is actually an arrow :)
[14:56] <fta> seb128, thanks. looking into that now.
[15:05] <fta> ok, found it.. camel/providers/smtp/camel-smtp-transport.c  1520 lines, yeah! oh, joy!
[15:14] <glatzor> Riddell, mvo: hello. I would like to push packagekit 0.4.8 to karmic.
[15:15] <glatzor> Riddell, mvo: Unfortunately it contains an api break in the qt libs without a so name change
[15:17] <glatzor> Riddell, so kpackagekit 0.4.1 has to be uploaded too
[15:56] <ahe> is there a graphical frontend for x redirection, already?
[15:57] <ahe> i'm looking for something that allows to explore the gnome menu of a remote machine and select and start programs for execution with display on my local screen
[15:58] <ahe> another cool feature would be to start a remote desktop session with display in a xnest on the local machine
[16:01] <ahe> if nobody knows such a tool i create a blueprint
[16:05] <kenvandine> pitti: putting a blueprint into "review" sends it to the approver for review?
[16:13] <pitti> kenvandine: yes
[16:17] <seb128> what is the recommended python way to read a txt file on a http location?
[16:17] <crevette> urllib2??
[16:18] <crevette> urllib2.urlopen('http://www.google.com').read()
[16:19] <crevette> I would say that, it is included in the default python install, but perhaps there is better?
[16:19] <james_w> that's pretty good
[16:20] <james_w> you need more if you want specific things with redirects, etags etc., but that'll work fine
[16:20] <seb128> I don't need to read a web page, just a txt file on a people location
[16:21] <crevette> urllib2.urlopen('http://www.google.com/anyfile.txt').read() would work too I guess seb128
[16:21] <seb128> I was pondering copying it locally and checking the timestamp before downloading again
[16:25] <calc> pitti: do you happen to know why bip seems to prepend + to every message?
[16:26] <pitti> calc: I'm not using bip, I don't know
[16:26] <calc> pitti: ok
[16:26] <pitti> seb128: I was typing that 5 mins ago, but I got disconnected
[16:27] <pitti> for line-by-line this is most convenient:
[16:27] <pitti> for line in urllib.urlopen('http://foo'):
[16:27] <pitti>     print line
[16:27] <seb128> pitti: thanks
[16:29] <kenvandine> pitti: new release of telepathy-glib do out and uploaded to debian within the hour
[16:29] <kenvandine> :)
[16:29] <pitti> \o/
[16:29] <kenvandine> with this bug fixed of course
[16:29] <kenvandine> pitti: tp upstream is great :)
[16:31] <jcastro> seb128: any word on tomboy 14.2 for jaunty? upstream fixed jaunty bugs and they are keen on getting it out to people
[16:33] <seb128> jcastro: go for it?
[16:33] <seb128> jcastro: I'm not working on tomboy but I'm fine having a new version sru
[16:34] <jcastro> seb128: is anyone available to work on it? it kind of sucks when an upstream fixes our bugs and they don't end up back in the distro. (understand that everyone is busy)
[16:34] <seb128> dunno but I'm sure we can find somebody easily next week
[16:34] <jcastro> k
[16:34] <seb128> it's just almost 6pm on a friday there
[16:35]  * jcastro nods
[16:35] <jcastro> I didn't mean right now. :D
[16:35] <seb128> I will find somebody to do the update and do the sponsoring next week
[16:35] <seb128> so we already have an updated and a reviewed in the loop and we just need sru verification
[16:35] <seb128> which pedro can easily do ;-)
[16:37] <jcastro> yeah it can just get frustrating for an upstream when they ship fixes and there's a lag there.
[16:37] <jcastro> and then the users are bugging them about bugs they fixed already
[16:39] <seb128> well we don't do stable version updates in stable for non lts versions
[16:40] <seb128> if nobody comes to bug us about the update that's it
[16:40] <pitti> jcastro: fine if someone from community wants to do the packaging and put it into jaunty-backports or so
[16:45] <didrocks> seb128: gnome-python-destkop had a bugbuddy binding without depending on bugbuddy package (as it's in universe). With the package split (there is one package for gnome-python-bugbuddy), do I achieve the same thing? Having this package with the binding, but not depending to the universe bugbuddy package?
[16:46] <pitti> didrocks: I think it'd make sense for gnome-python-bugbuddy to depend on bugbuddy
[16:46] <seb128> didrocks: yes
[16:46] <jcastro> seb128: don't we cherry pick fixes from stable gnome point releases?
[16:46] <pitti> jcastro: only if they match our SRU criteria and someone requests them
[16:46] <didrocks> pitti: but bugbuddy is in universe, gnome-python-desktop in main
[16:46] <jcastro> ok
[16:46] <seb128> jcastro: we do when we have issues which seem worth doing that, not sure if there is one on tomboy right now
[16:46] <pitti> didrocks: right, but if there's a split out g-p-bugbuddy, this particular package could be in universe; I suppose we don't need it in main?
[16:47] <seb128> pitti: packages that "import bugbuddy" will likely need patching need ...
[16:47] <seb128> pitti: it's easy to install the binding and make it handle the case where bug-buddy is not installed
[16:47] <pitti> seb128: for the g-p-d -> g-p-b dependency change?
[16:47] <seb128> if you want to move the binary to universe
[16:48] <seb128> g-p-bugbuddy that is
[16:48] <didrocks> pitti: is it possible in Ubuntu policy? Having a source package providing bin packages in both main and universe?
[16:48] <seb128> I think app importing it should depend on it
[16:48] <pitti> didrocks: yes
[16:48] <didrocks> ok, so, I can remove the patch, adding the b-d and put the splitted package in universe
[16:48] <seb128> well, will pychess start if pybugbuddy is not installed?
[16:49] <seb128> or will it bail on the import bugbuddy which is not in a try statement?
[16:49] <didrocks> seb128: I will try this
[17:26] <hggdh> pitti, ping
[17:26] <pitti> hi hggdh
[17:27] <hggdh> hi pitti. I am writing an apport hook for Evolution; the main objective is to sanitise the BTs so that private data is masked. So... is there a way of reconstructing the crash file from a bug?
[17:27] <hggdh> this will allow me to locally run the hook under apport-retrace, and check it
[17:33] <pitti> hggdh: there's no CLI for it, but it's not particularly hard
[17:33] <pitti> hang on
[17:34] <pitti> hggdh: but if you just want to test a hook, why bother with uploading it first at all?
[17:34] <pitti> you could just use the details expander to see what it would send, and then cancel?
[17:35] <pitti> hggdh: problem is, there is a function to download a report, but it doesn't grab all attachments; just the ones needed for retracing and duplication
[17:35] <pitti> but for your purpose you probably want all attachments
[17:40] <pitti> rickspencer3: fixed the "work items" syntax on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bug-workflow FYI
[17:40] <hggdh> pitti, yes. The problem is that I have to test it against bugs that do have the fields I need to mask out; on the other hand, I do not really need all attachments, just the BT and StackBT, so the function you have might be a good start point
[17:40] <hggdh> if, of course, you do not mind sharing it
[17:41] <rickspencer3> pitti: oops, I just stomped on your changes, I think
[17:41] <pitti> hggdh: right, the curent function does fetch those
[17:41] <pitti> hggdh: look at sr/lib/python2.6/dist-packages/apport/crashdb_impl/launchpad.py, APPORT_FILES
[17:42] <pitti> hggdh: are those enough for you?
[17:42] <hggdh> looking
[17:43] <seb128> http://people.ubuntu.com/~seb128/versions.html
[17:43] <seb128> ^ first version, I've to make that clear and nicer now
[17:43] <pitti> seb128: nice!
[17:44] <seb128> but that list debian, ubuntu, upstream versions
[17:44] <hggdh> pitti, yes, thank you
[17:44] <seb128> and color lines for merges and updates required
[17:44] <pitti> hggdh: python -c 'from apport.crashdb import get_crashdb; c=get_crashdb(None); r=c.download(338478); r.write(open("/tmp/report.crash", "w"))'
[17:44] <pitti> hggdh: sorry, I know it's not nice, but perhaps throw it in a small shell script and call it apport-download?
[17:44] <pitti> I guess I should add that to the apport package itself
[17:44] <hggdh> :-)
[17:45] <hggdh> If what I am trying to do succeeds, we might consider adding it to the hooks-utils
[17:45] <pitti> seb128: what's the color key right now?
[17:45] <seb128> red = new upstream version
[17:45] <seb128> orange = newer upstream and in debian
[17:46] <seb128> yellow = current upstream version but newer revision in debian
[17:46] <pitti> great
[17:46] <seb128> so yellow = to merge
[17:46] <seb128> red = to upgrade
[17:46] <seb128> orange is to merge and upgrade
[17:46] <pitti> rickspencer3: np
[17:47] <pitti> rickspencer3: fixed again
[17:47] <pitti> ugh, today I got 7 new specs to review
[17:48] <rickspencer3> I see, doesn't like my moin :)
[17:48] <rickspencer3> pitti: I'm not much with the regex, but doesn;t the i in "items" need to be lower?
[17:49] <pitti> rickspencer3: //i -> case independent
[17:49] <pitti> rickspencer3: wOrk iTEMs will work as well
[17:49] <pitti> rickspencer3: but *shrug* I can just extend it to digest = .. =
[17:50] <rickspencer3> don't bother
[17:51] <rickspencer3> thanks though
[17:52] <rickspencer3> pitti: in terms of quickly, .quickly file is bad? no hidden files?
[17:53] <pitti> rickspencer3: why would you want hidden files? that's confusing
[17:53] <rickspencer3> that's fair feedback
[17:53] <pitti> and I'm not even sure whether Debian Policy allows shipping hidden files in packages
[17:53] <rickspencer3> what should w call it?
[17:53] <rickspencer3> this would *create* a hidden file, not ship one
[17:53] <pitti> quickly.conf
[17:53] <pitti> ?
[17:53] <rickspencer3> it would make "magic"
[17:54] <pitti> rickspencer3: what does that file do?
[17:54] <rickspencer3> this would be a per *instantiated* file
[17:54] <rickspencer3> it is a container for information about a particular project
[17:54] <rickspencer3> so if I do:
[17:54] <rickspencer3> $quickly new ubuntu-project birds
[17:54] <rickspencer3> this would create a project called "birds"
[17:55] <rickspencer3> in that directory called "birds" is a file that contains information that quickly needs, most importantly the template that created it
[17:55] <rickspencer3> so it would have:
[17:55] <rickspencer3> template = ubuntu-project
[17:55] <rickspencer3> but you could imagine extended it
[17:55] <rickspencer3> currently this file is .quickly
[17:56] <rickspencer3> but perhaps naming it something more descriptive and making it visible makes sense
[17:56] <rickspencer3> didrocks: ^^^^
[17:56] <rickspencer3> proj
[17:56] <rickspencer3> proj.conf
[17:56] <rickspencer3> quickly.proj
[17:56] <rickspencer3> birds.proj
[17:56] <rickspencer3> ???
[17:56] <rickspencer3> birds.quickly
[17:58] <pitti> rickspencer3: I wouldn't make the name project specific
[17:58] <didrocks> rickspencer3: yes ? :)
[17:58] <pitti> quickly.conf is easy to find, and similarly static than "Makefile"
[17:58] <rickspencer3> why not (out of curiousity?)
[17:58] <pitti> (IMHO)
[17:58] <didrocks> (backlogging)
[17:58] <rickspencer3> didrocks: discussing the naming of ".quickly"
[17:59] <pitti> rickspencer3: well, you could parse *.conf and decide which ones are for quickly, but what happens if you have several?
[17:59] <rickspencer3> does quickly.conf not suggest that you are configuring quickly itself, rather than the app you are creating?
[17:59] <pitti> well, "Makefile" doesn't configure make itself, just how to use make
[17:59] <rickspencer3> if it's birds.quickly, it would be quite easy to find, and the meaning of the file may be quite clear to users
[17:59] <dobey> is '.quickly' a desktop file?
[17:59] <didrocks> pitti: the new spec revision is more verbose about this .quickly file
[17:59] <rickspencer3> right, but this is a different user (not that I'm disagreeing)
[18:00] <pitti> rickspencer3: does it make sense to have several?
[18:00] <rickspencer3> pitti: not really
[18:00] <rickspencer3> I guess RoR names all their files the same, not per project
[18:00] <pitti> rickspencer3: that's what I thought, too
[18:01] <didrocks> so, .quickly file seems good, no? :)
[18:01] <pitti> so why not call it "quickly.conf" then? then you can't have two
[18:01] <rickspencer3> didrocks: I think making it hidden is not optimal
[18:01] <didrocks> pitti: I think this is an internal quickly function. The user doesn't have to change it
[18:01] <didrocks> rickspencer3: see above :)
[18:02] <didrocks> my purpose is to manipulate it by quickly commands
[18:02] <didrocks> so, no user direct interaction. (like .bzr folder in bzr branch)
[18:02] <pitti> well, it's your baby, but personally I find hidden files very confusing
[18:02] <pitti> it's way too easy to miss them when producing tarballs, backups, packages, etc.
[18:02] <rickspencer3> pitti: may we leave it .quickly until we get some user feedback?
[18:02] <kenvandine> rickspencer3: i agree with pitti
[18:02] <rickspencer3> I think didrocks gets to decide
[18:02] <rickspencer3> :)
[18:03] <pitti> didrocks: you don't tar up .bzr/ and mail it to a friend
[18:03] <rickspencer3> you should rather quickly deb
[18:03] <rickspencer3> :)
[18:03] <didrocks> no, I just wait for "professional feedback", so we can make it quickly.conf
[18:03] <rickspencer3> pitti: will you approve the spec if I leave this an open issue?
[18:03] <didrocks> I'm juste afraid quickly user won't understand it and remove it
[18:04] <didrocks> just*
[18:04] <pitti> rickspencer3: sure, but I wanted to mention it and point out the potential traps
[18:04] <rickspencer3> yes
[18:04] <pitti> and be aware that it's hard to change afterwards
[18:04] <rickspencer3> I don't think we need to block on it now though
[18:04] <pitti> and it'd be the first build system which relies on hidden files
[18:05] <rickspencer3> I'm tending to agree with pitti at this point, and am wondering whether having a simple to edit configuration file might be a good thing
[18:05] <rickspencer3> though I still like birds.quickly
[18:05] <didrocks> pitti: I don't see really any difference with .quickly and .bzr-builddeb
[18:07] <pitti> didrocks: *shrug* okay; when I wrote that, I didn't know what .quickly was (that was another point that I mentioned which needed clarification)
[18:07] <pitti> if the user should never touch it, fine for me
[18:07] <didrocks> pitti: is the new spec version more clear?
[18:07] <pitti> didrocks: didn't have a look at the newer version (-EOVERLOAD)
[18:08] <didrocks> pitti: ok, that's why I didn't understand :)
[18:08] <rickspencer3> didrocks: I am extracting work items and putting them on the whiteboard so we can track during Karmic
[18:08] <rickspencer3> could you review those when I am done?
[18:08] <didrocks> so, having an hidden file makes sense?
[18:09] <didrocks> rickspencer3: sure, but I hadn't the time to follow the meeting about work items handling, are they just opened bug?
[18:09] <rickspencer3> didrocks: no, we're tracking on the whitebaord
[18:09] <rickspencer3> it will be rather obvious I think
[18:09] <rickspencer3> check it out in like 1 minute
[18:09] <didrocks> rickspencer3: ok, just drop me the link and I will review them :)
[18:10] <didrocks> (still fighting with gnome-python-desktop stuff ^^)
[18:11] <rickspencer3> didrocks: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-quickly
[18:11] <rickspencer3> when you get the chance
[18:11] <rickspencer3> please add ones that are missing
[18:11] <rickspencer3> and if you feel some are done, change TODO to DONE
[18:11] <rickspencer3> Thanks!
[18:12] <didrocks> rickspencer3: I will do this during the week-end. Having my dinner now :)
[18:12] <rickspencer3> :)
[18:12] <rickspencer3> didrocks: great
[18:12] <rickspencer3> I think this is going to be one of the sleeper hits of Karmic!
[18:13] <rickspencer3> pitti: I've added work items to both my blueprints
[18:13] <didrocks> rickspencer3: I will do everything so that it will be :)
[18:13] <didrocks> so you later!
[18:13] <rickspencer3> bye bye
[18:13] <rickspencer3> have a good weekend didrocks
[18:13] <pitti> bye didrocks
[18:13] <didrocks> thanks, you too :)
[18:15] <pitti> rickspencer3: \o/
[18:15] <pitti> ArneGoetje just added work items as well
[18:15] <pitti> tomorrow's db dump should have some more data
[18:18] <ArneGoetje> pitti: it's okay if the work items get added over time? I mean if it turns out that there is more to be done?
[18:18] <pitti> ArneGoetje: yes, that works
[18:18] <ArneGoetje> pitti: ok
[18:18] <pitti> the total height of the bar will increase, but that's fine
[18:21] <rickspencer3> ArneGoetje: pitti: ideally, the churn will be minimal after next week
[18:21] <rickspencer3> but increased scope can be measured by increases in the height of the bar
[18:32]  * pitti plays the whack-a-spec game harder
[18:33]  * pitti chuckles at https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/SocialFromTheStart release note: "Gwiber does blabla. It is mandatory"
[18:33] <pitti> kenvandine: ^ :-)
[18:33] <pitti> MUST ... TWITTER!
[18:37] <kenvandine> :)
[18:53] <crevette> nobody experienced black flash of the display while running karmic? I think it comes from g-p-m...
[18:53] <maxb> ah, yes I think I've seen that from time to time
[18:54] <crevette> hmmm, g-p-m applet seems also to reset the "luminosity" of the display
[18:54] <crevette> brightness is the right word I guess
[18:55] <crevette> my exprience is: being on battery, set a defined brightness to make brighter, right click on the g-p-m applet and the brightness is instantly reset
[18:56] <crevette> s/ight click on the g-p-m applet and/ight click on the g-p-m applet, click "preferences" and/
[19:20] <pitti> seb128, asac, bryce: could you please take a look at https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bug-workflow and check if the functinoality/approach suits you? please just comment in the whiteboard
[19:31] <pitti> good night everyone, and have a nice weekend!
[19:34] <SiDi> pitti: you too then
[20:02] <seb128> re
[20:02] <seb128> pitti: sorry you were saying about the spec? karmic keep crashing the box while I'm away
[20:02]  * seb128 notes to not upgrade to unstable so early next cycle
[20:05] <SiDi> seb128: i think hes gone
[20:05] <seb128> SiDi: he will be back on monday or something and read backlog
[20:05] <SiDi> will he actually read so far ? :/
[20:06] <seb128> "so far"?
[20:06] <seb128> usually people read lines where they have been highlighted
[20:06] <seb128> I don't expect he will be pinged a thousand time during the weekend
[20:06] <SiDi> if he lets his PC idle all weekend, that'll still be a lot of lines to check. even with Ctrl+F. I personally never check my irc logs :)
[20:07] <seb128> anyway thanks but I work with pitti for years and I will manage, no need to discuss how we are working
[20:07] <seb128> I will talk to him on monday that's ok
[20:08] <SiDi> i didnt mean to be offensive :p
[20:12] <seb128> that was not offensive just not really an useful discussion
[20:16] <rickspencer3-afk> SiDi
[20:16] <rickspencer3-afk> heh
[20:16] <rickspencer3-afk> oops