[02:28] <Dannny> hey guys
[02:28] <Dannny> anybody here?
[02:42]  * ajmitch thinks he may have been in the wrong place if he was seeking quick answers or support
[03:33] <calc> bryce_: is alberto alberto milone?
[03:35] <nhandler> calc: Alberto Milone is tseliot on IRC
[03:35] <calc> ok
[03:59] <bryce> calc: yes
[06:54] <pitti> Good morning
[06:56] <mpontillo> mornin'! (well, will be in an hour or so for me.)
[06:57] <mpontillo> hey, so I took a stab at a TODO item: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/332253 ... attached a script that I think will fix the problem if packaged, but I'm not sure what to do next (or if I should have even changed the "assigned to" field)
[06:57] <mpontillo> thanks ubottu ;)
[07:24] <didrocks> morning mpontillo pitti
[07:25] <pitti> hey didrocks
[07:28] <didrocks> pitti: I was wondering about a patch in gnome-volume-manager
[07:28] <didrocks> debian/gnome-volume-manager.links: Add gnome-volume-manager-gthumb.sh symlink to /usr/share/gnome-volume-manager/, where it had been shipped in old Ubuntu releases. Since this cannot be changed on system upgrades, this needs to be kept indefinitely.
[07:29] <didrocks> why providing still this symlink?
[07:29] <pitti> didrocks: it's pretty obsolete now, since g-v-m isn't being used for handling photos etc. any more
[07:29] <pitti> and we don't use it at all
[07:29] <didrocks> yes, I know. Just want to understand the remark :)
[07:29] <pitti> didrocks: the problem was that the path got stored in the user's gconf db
[07:30] <pitti> which we can't change on upgrades
[07:30] <didrocks> pitti: we can't use g2conf-tools to update it?
[07:30] <didrocks> in some kind of postinst script?
[07:30] <didrocks> gconf2-tools*
[07:30] <pitti> no, we mustn't touch /home in maintainer scripts
[07:31] <didrocks> pitti: ok, thanks. I understand now :)
[08:00] <mpontillo> mornin' didrocks. really morning now ;)
[09:10] <didrocks> hey seb128. We have to get ready for GNOME 2.27.1, right? :)
[09:10] <pitti> seb128: bonjour! had a good weekend?
[09:10] <seb128> didrocks: you can, I'm still catching up on jaunty bugs and doing merges for my part today
[09:11] <seb128> pitti: hello, excellent thanks! you?
[09:11] <didrocks> seb128: great, I will follow them :)
[09:11] <seb128> didrocks: I see no reason to hurry in broken versions so early in the cycle, almost nobody is running karmic yet anyway
[09:11] <didrocks> ok seb128, I will not hurry too, so :)
[09:11] <pitti> seb128: it was great; we did the traditional camping/hiking on May 1, and I helped my parents in the garden (oh, my back!), and we did a barbecue party
[09:11] <seb128> didrocks: I prefer to get merges sorted first and bugs on shape and start with .2 or .3 for the updates
[09:11] <pitti> karmic!
[09:12] <pitti> but I agree that merges are first prio now
[09:12] <seb128> pitti: I did some gardening too ;-)
[09:12] <didrocks> seb128: I still have few merges to do, so, ok. I put some priority on this
[09:12] <seb128> didrocks: gnome-python-extras for example? ;-) debian fixed your build issue
[09:12]  * pitti also waits for NEW and buildds to catch up, so that he can upload the new gnome devkit crack
[09:12] <didrocks> seb128: well... I will do gnome-python-extras :p
[09:12] <seb128> ;-)
[09:13] <seb128> pitti: how busy are buildds still?
[09:13] <pitti> very
[09:13] <pitti> https://launchpad.net/builders/
[09:13] <pitti> except lpia
[09:16] <didrocks> thoses queues are quite crazy :)
[09:24] <seb128> didrocks: yeah, some thousand packages synced from debian
[10:02] <robert_ancell> seb128: pitti:  I have an email regarding how to make progress in the compiz bugflood.  What mailing list do you guys recommend I send it to for feedback?  How wide is the distribution of the desktop mailing list?
[10:02] <pitti> robert_ancell: I'd post to u-devel@, it's of general interest
[10:03] <seb128> robert_ancell: is that a call for bug triagers?
[10:03] <seb128> robert_ancell: you might want to Cc ubuntu-bugsquad
[10:03] <seb128> robert_ancell: otherwise ubuntu-devel sounds good
[10:04] <robert_ancell> seb128: pitti: It's more of taking a divide and conquer approach to compiz and being ruthless to maximise our effort.  I'll email both of you and see what you think
[10:07] <seb128> ok
[10:07] <seb128> I think that first we should autoclose all crash bugs which didn't get any activity since hardy or something
[10:07] <seb128> bugsquad might have code ready for that sort of things
[10:08] <seb128> bryce_ also has quite some scripts to add stock replies, needinfo bugs, etc
[10:08] <seb128> don't spend hours on every bug trying to understand it in any case
[10:08] <robert_ancell> seb128: that's exactly what I'm trying to avoid :)
[10:08] <seb128> success in bug triage is to triage quickly issues which don't seem worth stopping
[10:08] <pitti> right, it should suffice to go through and decide which are the really bad ones which affect many people
[10:08] <seb128> ie set those low importance and switch to the next one
[10:09] <seb128> then you can mostly ignore =< low
[10:09] <robert_ancell> I think we have to reduce the number of bugs though - just triaging them will still leave too many bugs visible that no-one will ever get back to looking at.  They may as well be closed or merged
[10:10] <asac> pitti: hmm. commented on xmlrpc-c MIR ... its not the same source as the cmake - e.g. it adds a new set of libs for xmlrpc server stuff
[10:11] <seb128> right
[10:11] <seb128> that's why I suggest agressive closing of bugs which have not changed since hardy
[10:11] <seb128> and perhaps stock reply for bugs which seem rather video driver issues
[10:11] <asac> pitti: do we care and open a bug for splitting up the binary packages?
[10:11] <seb128> and perhaps reply for "we don't have the manpower to work on that, please open an upstream bug"
[10:12] <pitti> asac: it's already split, only the base packages are in main, rest is universe
[10:12] <asac> pitti: hmm. let me check
[10:12] <robert_ancell> seb128: but that's passing the problem on.  I think there's value in acknowledging that there are a lot of issues like this instead of closing them which sends the message "not our problem"
[10:12] <asac> pitti: i thought the server libs are in the base package
[10:13] <pitti> robert_ancell: they can stay open
[10:13] <asac> pitti: yeah so the server libs and the abyss libs are in the base package
[10:13] <pitti> robert_ancell: our goal can't be to have zero bugs on the package, I think
[10:13] <asac> libxmlrpc-c3
[10:13] <asac> that package
[10:14] <pitti> asac: that's in universe
[10:14] <pitti> we just have the -c3-core package in main
[10:14] <seb128> hello rodrigo_
[10:14] <rodrigo_> hi :)
[10:15] <robert_ancell> pitti: But then you can't see the forest for the trees.  There needs to be a balance between having enough bugs that fixing them is accessible (ideally by third parties) but not loosing all the information that hundreds of bugs gives
[10:15] <asac> pitti: hmm. so someone did the split up. nice. good
[10:15] <pitti> robert_ancell: indeed, but then there's also priorities and assignees
[10:15] <pitti> a bug which is triaged/low/unassigned is basically "shelve"
[10:15] <pitti> and a "high/triaged/assigned" bugs is on somebody's work list
[10:16] <asac> pitti: great. so riddell did the split after i talked to him on friday
[10:16] <pitti> right, he mentioned it in the MIR
[10:17] <asac> nevermind then
[10:17] <pitti> asac: the new package isn't published yet, I just NEWed it
[10:17] <robert_ancell> pitti: so, to follow that strategy on compiz.  If we close the bugs that are "too hard" (e.g. video drivers) and triage everything else (probably to low priority) we will still have 400 bugs with vague descriptions that will just continue to grow.  Anyone not familiar with compiz will not want to put any effort into it - it will just look too hard
[10:18] <pitti> robert_ancell: video driver bugs should be reassigned, not closed
[10:18] <pitti> robert_ancell: using priorities more could help there (and being really conservative about "high")
[10:19] <mnemo> robert_ancell: maybe you can write a spider that checks all the compiz bugs for attached xorg.log that has stacks in them and then bulk assign those to the appropriate video driver...
[10:20] <pitti> bryce has such scripts like those
[10:22] <robert_ancell> seb128, pitti: ok, I'll talk to bryce about scripts.  Do
[10:22] <mnemo> asking people to re-test with compiz off is probably also a good thing that could transfer some bugs to xorg... not that xorg has too few bugs but :) :)
[10:22] <seb128> robert_ancell: "description not good enough to understand the bug = needinfo + low priority if that doesn't seem a high importance issue"
[10:23] <seb128> and get some autoclosing going on for all needinfo which didn't get updated for 6 weeks or something
[10:23] <seb128> then you can get a bookmark listing only open bugs "ie confirmed triaged"
[10:23] <seb128> and sorted by importance
[10:24] <seb128> that should give you a reasonable list
[10:24] <seb128> that give the "NEW" bugs which are too triage
[10:25] <seb128> and somebody need to go over the needinfo every now and then to close or reopen according to the new comments
[10:25] <robert_ancell> I just feel it might be hiding the issues rather than than us getting valuable information on how to improve the stability of compiz (and so reduce the number of incoming bugs)
[10:25] <seb128> I've cleaned a bit pidgin this way
[10:25] <robert_ancell> seb128: ok, will look at pidgin for ideas
[10:26] <seb128> half of "old bugs" got submitter replying that jaunty was fixing the issue for them
[10:26] <seb128> there is not too much to look at, I've been going through bugs not touched recently asking to try on jaunty
[10:26] <seb128> I got quite a lot of "that has been fixed in recent versions"
[10:26] <robert_ancell> seb128: particularly in the case of compiz the bugs are not reproducable anyway - they're just random crashes
[10:27] <seb128> I tend to close one time crashers with no recent duplicates
[10:27] <seb128> we can still reopen if somebody else runs into the issue again
[10:27] <seb128> we need to do some statistical work anyway
[10:27] <seb128> ie we could ignore all bugs which didn't get at least confirmed by 3 users
[10:28] <seb128> we can't spend hours on every issue which one user got once
[10:28] <seb128> we have to go for things annoying a lot of users or being important issues
[10:29] <robert_ancell> and in the case of compiz we have hundreds of reports, and almost none of them having reproducable conditions or likely to be reproduced
[10:29] <robert_ancell> anyway, I have to go.  Thanks for the feedback
[10:29] <seb128> you're welcome
[10:30] <seb128> just set those low importance
[10:30] <seb128> and don't bother looking to low bugs
[10:30] <seb128> and get them raised if there is several duplicates
[10:30] <seb128> we can continue chatting about that tomorrow
[10:31] <robert_ancell> seb128: yup,  please email me some Karmic work/pointers for tomorrow as I'm not too sure what to do / what others are currently doing
[10:32] <seb128> robert_ancell: ok will do
[11:12] <crevette> Hello
[11:14] <seb128> lut crevette
[11:14] <crevette> salut seb128
[11:38] <pitti> seb128: gconf merge uploaded; so you'll take rarian in exchange?
[11:39] <seb128> pitti: yes
[11:39] <pitti> splendid; 6 merges to go then..
[13:26] <seb128> mvo: any reason you let bug #318268 on avahi?
[13:26] <seb128> mvo: that doesn't seem to be an avahi issue ...
[13:28] <mvo> seb128: let me have a look
[13:28] <seb128> mvo: thanks
[13:28] <mvo> no reason
[13:29] <mvo> I reassigned to dpkg for now, this short read on buffer copy message needs some love
[13:29] <seb128> mvo: ok thanks
[13:52] <exoeoeoeoe> http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck
[13:53] <mnemo> did anyone else get dependency problems / broken package for compiz when upgrading to karmic? I need working compiz to test a -ati patch for karmic
[13:54] <mnemo> this is the concrete problem I have on karmic --> http://pastebin.com/m4d9ee54a
[14:00] <asac> mnemo: well. while auto synchs are on its easy< to have dependency problems temporarily
[14:01] <mnemo> asac: the reason i want this patch into karmic is because I need some bake time there so I can request a SRU for jaunty
[14:01] <mnemo> asac: how long will the auto syncers be on?
[14:02] <asac> mnemo: till debian import freeze
[14:02] <asac> mnemo: https://wiki.ubuntu.com/KarmicReleaseSchedule
[14:03] <mnemo> aah thats quite long
[14:03] <asac> mnemo: well. a) i dont know if your problem is something else ;) ... b) if its a temporary issue because of lots of updates going on, you might be able to upgrade in a few hours a few days or so
[14:03] <asac> mnemo: how do you upgrade?
[14:04] <mnemo> asac: i had this problem for two days now.. I upgraded by "sed -i s/jaunty/karmic/ sources.list"
[14:04] <asac> mnemo: and then?
[14:04] <asac> what command are you using?
[14:04] <mnemo> sudo apt-get update followed by "sudo aptitude dist-upgrade"
[14:04] <asac> try apt-get dist-upgrade
[14:05] <asac> aptitude can be lame ;)
[14:05] <mnemo> ok
[14:05] <asac> but look carefully if things get removed you dont want go away ;)
[14:06] <mnemo> are you on karmic with working compiz btw? if so, then I might have some config issue related to my upgrade
[14:06] <asac> i havent upgraded yet. want to do some SRU stuff first
[14:06] <mnemo> k
[14:07] <mnemo> asac: so, is it possible to SRU without adding patch to karmic first?
[14:07] <mnemo> my patch causes frequent -ati crashes, its merged upstream and fix has been confirmed by a handful of people
[14:08] <asac> well. this early in cycle making the SRU and uploading to karmic without using karmic makes sense
[14:09] <mnemo> aah ok
[14:09] <asac> baking in karmic is not really useful because a) its not really stable and b) not many use karmic anyway
[14:09] <mnemo> right
[14:09] <asac> mnemo: anyway, its important that the same fix goes to karmic
[14:09] <asac> we want to prevent that there are regressions because the patch was forgotten to add there
[14:10] <mnemo> its already merged to upstream mesa so it will go in there for sure
[14:11] <asac> mnemo: well. unless its things like gnome which release time based, you cannot be sure that the next upstream will be ready or in karmic imo
[14:11] <asac> if bryce said he will do that then just -proposed should be ok
[14:11] <asac> but talk to him i would say
[14:11] <asac> he should be responsible to help you get this patch in ... or tjaalton
[14:12] <mnemo> yea im just waiting for bryce to wake up basically :)
[14:12] <asac> hehe
[14:12] <seb128> hello rickspencer3
[14:12] <rickspencer3> hey seb128
[14:12] <asac> mnemo: so i cant speak for bryce, but i would think that you shouldnt be required to upgrade to karmic at this point ;)
[14:13] <pitti> hey rickspencer3, good morning
[14:13] <asac> hi rickspencer3
[14:13] <rickspencer3> good afternoon pitti, asac
[14:13] <rickspencer3> how was the (long) weekend?
[14:13] <asac> precious
[14:13] <pitti> awesome
[14:13] <asac> even the weather was superb friday and sat
[14:14] <asac> which is kind of a lottery thing here ;)
[14:14] <seb128> excellent there too
[14:14] <seb128> and next weekend is 3 days again ;-)
[14:14] <rickspencer3> oh?
[14:14] <asac> typical french ;)
[14:14] <rickspencer3> sweet
[14:14] <rickspencer3> seb128: Friday or Monday off?
[14:15] <seb128> friday
[14:15] <seb128> it's the end of second war day
[14:15] <rickspencer3> mmm
[14:16] <seb128> rickspencer3: I will not be there for our weekly call and the meeting tomorrow btw
[14:16] <seb128> rickspencer3: travelling to london to join the dxteam sprint
[14:16] <rickspencer3> seb128: ok
[14:16] <rickspencer3> ok
[14:42] <seb128> ok, so I've a todolist for the team contributors, what are the preferences to track those? wiki, bugs, txt list stored in some bzr?
[14:52] <ktenney> howdy, since 8.10->9.04, gdm hangs, /var/log/auth fills with pam_nogin(gdm:auth): cannot determine username
[14:52] <ktenney> suggestions?
[14:53] <mnemo> ktenney: can you boot the 9.04 live CD?
[14:55] <ktenney> haven't tried, don't have one. Should
[14:55] <ktenney> I make one and get back?
[14:55] <mnemo> well
[14:55] <mnemo> ,try that, and if its boots... also try logging out from the live CD
[14:56] <mnemo> if you log out, then you should see a gdm screen and you should be automatically logged in again
[14:56] <mnemo> as user "ubuntu"
[14:56] <mnemo> if gdm hangs on the live CD please open a bug using the terminal command "ubuntu-bug gdm"
[14:56] <mnemo> and describe what you said about the with logs etc
[14:57] <ktenney> mnemo: I'll be back, thanks
[15:27] <mpontillo> morning all
[15:40] <pitti> rickspencer3: FYI, I updated my specs: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-symptom-based-bug-reporting and https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-automagic-python-build-system
[15:40] <rickspencer3> pitti: sweet
[15:40] <pitti> rickspencer3: I didn't see any other which I'm drafting, but please let me know if I forgot one
[15:40] <rickspencer3> I have a lot of work to do regarding those :(
[15:41] <pitti> rickspencer3: I dropped the webdav debug symbols from the apport one; it's a completely separate topic
[15:41] <pitti> and probably not feasible time-wise in karmic anyway
[15:41] <rickspencer3> ok
[15:41] <pitti> rickspencer3: lot of work> wrt. scheduling?
[15:41] <pitti> every drafter should be responsible for his own summary etc., you shouldn't do those
[15:41] <rickspencer3> I have content for many bps that I haven't put in yet
[15:42]  * pitti proposes desktop-karmic-double-daytime, to be able to cover everything
[15:42] <rickspencer3> pitti: does automagic build system include an application template
[15:42] <rickspencer3> ?
[15:43] <pitti> rickspencer3: it shouldn't, I think
[15:43] <pitti> it's outside of the scope of a build system
[15:43] <pitti> rickspencer3: also, I had a quick discussion with this about Seb
[15:43] <rickspencer3> is it?
[15:43] <pitti> sorry, "about this with seb"
[15:43] <pitti> rickspencer3: templates should be in a layer on top of this, IMHO
[15:43] <rickspencer3> I think we need to create the starting place for developers
[15:44] <rickspencer3> right, so a seperate blueprint then
[15:44] <rickspencer3> ?
[15:44] <pitti> rickspencer3: that would fit into something like your "quickie"
[15:44] <rickspencer3> right, but quickie needs to assume that it will feed into the automagic build system
[15:44] <rickspencer3> they go hand in hand
[15:44] <pitti> rickspencer3: the python build system is on the same level like cdbs or automake
[15:44] <rickspencer3> I'll go ahead and create another blueprint for desktop-karmic-project-templates
[15:45] <pitti> it doesn't have an interface for dialogs, GTK GUI, or template  creation
[15:45] <rickspencer3> pitti: but there needs to a be unified interface for developers
[15:45] <pitti> rickspencer3: yes, absolutely
[15:45] <pitti> rickspencer3: and these templates should use that automatic build system
[15:45] <rickspencer3> so that they can create the projects and publish them from the same set of commands
[15:46] <pitti> but I wouldn't like it to be one big project blob, since the build system has usages outside quicke, and we shouldn't restrict the templating system to python/that build system
[15:46] <rickspencer3> ok
[15:46] <rickspencer3> so there should be a quickie command that invokes it
[15:46] <rickspencer3> but it should be loosely coupled
[15:46] <pitti> rickspencer3: quickie would write the minimal setup.py
[15:47] <rickspencer3> you should also be able to go $quickie publish
[15:47] <pitti> and the build system is clever enough to "do what I mean" with just a very small setup.py
[15:47] <rickspencer3> and it uses the automagic system
[15:47] <pitti> right
[15:47] <rickspencer3> ok
[15:47] <rickspencer3> then the other blueprint will be useful
[15:47] <pitti> rickspencer3: so, wrt. the discussion with seb128, he mentioned that something like this was discussed before
[15:47] <pitti> rickspencer3: the question was, AFAIR, which scope this project should have
[15:48] <pitti> rickspencer3: "big": build system, .debs, packaging, PPAs
[15:48] <pitti> rickspencer3: "small": run from source tree, no build system/packages/PPAs
[15:48] <rickspencer3> what are your thoughts?
[15:48] <pitti> "small" would basically operate on a tarball, with the usual limitations you get from not having packages (no i18n, no package updates, no menu entries, etc.)
[15:48] <seb128> the discussion 6 months ago got people agreeing that it should be an easy way to run prototype
[15:48] <rickspencer3> I think it should create a deb and/or a ppa
[15:49] <pitti> and the last time this was discussed it was the "small" one
[15:49] <seb128> ie just one click on a server, download, run
[15:49] <seb128> deb and ppa is high barrier to start
[15:49] <rickspencer3> preferably a ppa
[15:49] <rickspencer3> I think from the uses point of view, the system starts from creating a project from a template
[15:49] <rickspencer3> and ends with publishing to a PPA
[15:50] <rickspencer3> if ppa is too much for a single release, that's fine
[15:50] <seb128> well, when it's good enough to be properly package you can as well get it in ubuntu
[15:50] <seb128> what are you trying to solve?
[15:50] <seb128> make easy for people to get users trying their code quickly?
[15:50] <rickspencer3> seb128: that's a deep question, and I have a deep answer
[15:50] <seb128> or having a robust way to distribute code?
[15:50] <pitti> we can provide solutions for both use cases
[15:50] <rickspencer3> but essentially, discovering *how* to write an app on Ubuntu is next to impossible
[15:50] <seb128> we already have a pretty good way to distribute code ... ;-)
[15:50] <rickspencer3> and then how to distribute it is insanely complicated
[15:51] <seb128> rickspencer3: and by using ppa you will not make it any simpler
[15:51] <rickspencer3> seb128: making a PPA is far from simple
[15:51] <seb128> the previous discussion we had turned around the "you should just have to write some python code and be able to distribute it in one click"
[15:51] <seb128> right, that's why we were against using deb packaging or ppa when we discussed that
[15:52] <rickspencer3> but if we define conventions for how to write your python code, then creating a PPA could be simple
[15:52] <seb128> you still have to deal with the packaging
[15:52] <pitti> creating a source package from standard-shape python project is doable
[15:52] <rickspencer3> convention over configuration
[15:53] <pitti> PPA is a little more than one click, because you need to register an LP account etc.
[15:53] <seb128> and then users need to add a deb src etc
[15:53] <rickspencer3> if you follow the conventions, than a program can be written that creates a PPA for you (given that you have an account)
[15:53] <pitti> we can script that as well, but it's not just one click (because of authentication etc.)
[15:53] <rickspencer3> if you deviate from the conventions, that's fine, but you are on your own regarding distribution
[15:53] <seb128> the previous discussion was "go on some website, spot something you want try, click to download, double click to try"
[15:53] <pitti> seb128: that part should be apt:// URLs, no?
[15:54] <rickspencer3> seb128: that's on the end user side
[15:54] <rickspencer3> right?
[15:54] <seb128> yes
[15:54] <rickspencer3> I'm talking about opportunistic developers as users
[15:54] <pitti> making that work involves some changes in apturl itself, automatic fetching of PPA GPG keys, etc.
[15:54] <seb128> on the writter side it was "write some python, upload in one click"
[15:54] <rickspencer3> right
[15:54] <pitti> I think it comes down to what we expect from this
[15:54] <rickspencer3> but it's "write some python code following some defined conventions, then upload easily"
[15:54] <pitti> if the limitations (no i18n, no menu entries, no automatic updates) are okay, then distributing tarballs and running from source would work
[15:55] <seb128> I've the feeling that the while packaging, ppa thing is over-engineered
[15:55] <pitti> it's just not how we do things in Ubuntu
[15:55] <seb128> well, that's why I asked what you want to do
[15:55] <rickspencer3> there are two things that we answer:
[15:55] <seb128> make easy to distribute and run prototype
[15:55] <seb128> or distribute anything this way?
[15:55] <rickspencer3> 1. How the heck do a write a program that runs on Ubuntu? (quickee-like system is the answer)
[15:55] <mvo_> fetching the ppa gpg key sounds a bit scary
[15:55] <rickspencer3> 2. How they heck do I get this to my users?
[15:55] <seb128> we opted for the first one saying that you can turn to real packaging when it's ready to be distributed
[15:56] <pitti> mvo_: really?
[15:56] <asac> imo anyone who figures how to package, will figure that there are PPAs ;)
[15:56] <pitti> mvo_: (we discussed that some days ago already)
[15:56] <rickspencer3> hmmm
[15:56] <rickspencer3> this sounds like a good topic for a longer discussion
[15:56] <asac> rickspencer3: i agree that improving documentation for developers is important
[15:56] <seb128> mvo_: do you know if there was some notes from the previous uds discussion?
[15:57] <mvo_> pitti: well, its auto-adding repositories to apturl, something we decided against some time ago
[15:57] <asac> we should provide the very best to ensure that developers always end up using ubuntu
[15:57] <seb128> rickspencer3: we already had a full room 2 hours discussion about that at previous uds
[15:57] <mvo_> seb128: about the download and try thing?
[15:57] <seb128> mvo_: yes
[15:57] <pitti> rickspencer3: so, even in the event that it turns out to be the "small" one-click tarball solution, the distutils thing has been one of my pet peeves for a long time, so I'll probably work on it anyway (in my CFT)
[15:57] <seb128> mvo_: the one where desrt wrote the server and you were supposed to write the client
[15:57] <pitti> mvo_: no, I meant auto-fetching a PPA's gpg key once you added it
[15:58] <mvo_> pitti: once you added it manually?
[15:58] <mvo_> (or via software-properties?)
[15:58] <seb128> rickspencer3: I'm not really convince that we should make easier for people to distribute debs
[15:58] <mvo_> seb128: I wrote bits of that :)
[15:58] <pitti> mvo_: shouldn't matter how it got added; once it's there, we should verify the signature
[15:58] <seb128> rickspencer3: we already have tons of those and difficulties to figure what is good or not
[15:58] <mvo_> seb128: gritty, I think desrt even came up with something working even
[15:58] <pitti> mvo_: "auto-fetch and fail on non-match" -> much better than "always complain about missing key"
[15:59] <seb128> rickspencer3: I would keep deb as a way to distribute proper software and not random quick hacks
[15:59] <mvo_> pitti: right, this discussion. yes, we can add this
[15:59] <seb128> otherwise that's the door open to lot of issues
[15:59] <pitti> seb128: well, .debs would make sure that you can integrate into the menu, can upgrade and uninstall cleanly
[15:59] <seb128> one other issue is that deb packaging will require sudo rights
[15:59] <mvo_> pitti: I thought you said "apturl should be able to add PPAs automatically (with keys)"
[15:59] <seb128> and it's an open door to any abuse
[15:59] <seb128> where the small tarball solution is user land
[16:00] <seb128> an no risk for the system
[16:00] <pitti> mvo_: perhaps, somehow; but I'm not so sure about that
[16:00] <pitti> seb128: agreed
[16:00] <seb128> re rickspencer3
[16:00] <rickspencer3> heh
[16:00] <rickspencer3> someone disconnected me?
[16:01] <rickspencer3> :)
[16:01] <dobey> mvo_: btw, where is that apturl update? i haven't seen anything in proposed for it
[16:01] <seb128> too many informations? ;-)
[16:01] <rickspencer3> I didn't realize I was being that controversial ;)
[16:02] <seb128> rickspencer3: to summarize my opinion I think debs should stay a way to distribute officially supported software, we should not encourage people to install random crap this way
[16:02] <seb128> rickspencer3: especially that deb are system components, ie the postinst can do anything to the install
[16:02] <rickspencer3> seb128: what's wrong with PPA?
[16:02] <rickspencer3> it seems to me that the single point of update is of strong value to users
[16:03] <seb128> too much informations makes difficult to figure where to find quality softwares
[16:03] <seb128> I think we should not mix proper software and quick hacks
[16:03] <seb128> it's already difficult enough to find a software in the current list we have
[16:03] <rickspencer3> are PPAs "proper" or "quick" hacks?
[16:03] <seb128> proper
[16:03] <seb128> as said it depends what you want to distribute
[16:03] <mvo_> dobey: I uploaded it to -proposed, the masters-of-the-sru queue will have to check and approve
[16:04] <mvo_> dobey: uploaded Wed, 29 Apr 2009
[16:04] <seb128> do you want a quick way for people to distribute new cool stuff they work on
[16:04] <seb128> ie prototypes
[16:04] <seb128> or do you want it a way to distribute any software?
[16:04] <calc> rickspencer3: call sounds fine to me... i hit accept but not sure if it went through
[16:04] <dobey> mvo_: how does a mere mortal such as myself test it then?
[16:04] <rickspencer3> calc: ack
[16:05] <rickspencer3> seb128: if I wrote a pencil ordering app for my office, having a single point to update to would be most useful
[16:05] <seb128> I would say the tarball approch is safer (nothing require sudo, nothing running at the system level) and makes easier to try things without risk of polluting your install
[16:05] <rickspencer3> but such a ppa shouldn't show up for general usage
[16:05] <mvo_> dobey: it should appear in -proposed once approved, I think the current ubuntu-sru team (that does the review/approval) is just pitti and slangasek, not sure how often they review the queue
[16:05] <mvo_> dobey: and of course there was a long weekend now
[16:06] <seb128> rickspencer3: right, if that's a proper application you recommend to our lambda users
[16:06] <seb128> which brings we back at what we want to distribute this way
[16:06] <dobey> mvo_: right. i was hoping to test it and verify that it fixes the bug for my use case :)
[16:06] <mvo_> dobey: sure, I understand :)
[16:07] <rickspencer3> seb128: we need a way for application developers to get their apps to their users
[16:07] <seb128> rickspencer3: the tarball thing was meant as a "here is the cool python thing I started on work on a week ago, it's not really useful yet but you can try it quickly and comment by clicking there"
[16:07] <dobey> pitti: care to approve the apturl sru then? :)
[16:07] <rickspencer3> PPA seem good for this
[16:08] <pitti> mvo_: I spent 1.5 hours on SRU this morning, unfortunately I didn't completely empty the queue yet
[16:08] <seb128> rickspencer3: one thing I don't like about ppa is that deb are system components, ie how do you make sure the postinst don't format the disk or anything?
[16:08] <seb128> rickspencer3: who is going to review all those to make sure they don't do anything they should not be doing?
[16:08] <mvo_> pitti: thanks, I know that its a hard task, especially so shortly after the release, no blame on you
[16:08] <pitti> seb128: well, how do you make sure that the tarball doesn't wipe your home dir?
[16:09] <rickspencer3> seb128: right
[16:09] <seb128> pitti: we limit the access to some jail?
[16:09] <rickspencer3> that will be a problem when the PPAs are generally discoverable
[16:09] <dobey> speaking of horribly broken deb packages... adobe is on my stab-in-the-face-list :)
[16:09] <pitti> seb128: oh, we do?
[16:09] <seb128> pitti: well that's a way no?
[16:10] <mvo_> if the package runs in the jail and can't access my data, its most likely not very useful :)
[16:10] <pitti> seb128: not sure that this is generally effective, since many apps will want to work with your files
[16:10] <mvo_> i.e. if I want to test a photo app, then it needs to be able to access my photos
[16:10] <seb128> rickspencer3: my opinion is that we already have to much crap listed
[16:10] <seb128> ie search for a text editor
[16:10] <rickspencer3> seb128: listed where?
[16:10] <rickspencer3> in Add/Remove?
[16:10] <seb128> see a zillion being listed
[16:10] <seb128> yes, or synaptic
[16:10] <rickspencer3> do PPAs show up in synaptic?
[16:11] <seb128> yes
[16:11] <mvo_> after they got added, yes
[16:11] <rickspencer3> I thought you had to subscribe to them for them to show up
[16:11] <seb128> all the available deb are listed there
[16:11] <seb128> right, but if you want to install some random demo from a ppa you will get it auto-added
[16:11] <pitti> rickspencer3: well, once an user decides to use a PPA, we shouldn't have him do the decision a second time
[16:11] <seb128> and then everything in the ppa will show in synaptic
[16:12] <rickspencer3> but discovering a PPA is non-trivial
[16:12] <pitti> right
[16:12] <rickspencer3> it's not like we're exactly pushing htem
[16:12] <dobey> well it is right now
[16:12] <seb128> pitti suggests to make it one click away in a transparent way
[16:12] <rickspencer3> there's no way to search, etc...
[16:12] <pitti> seb128: ah, no
[16:12] <dobey> but i haven't transformed the code in my brain, into actual python scripts yet
[16:12] <pitti> seb128: I was talking about auto-fetching GPG keys for PPAs which the user added somehow
[16:13] <seb128> pitti: you suggested using an apt: URI though
[16:13] <seb128> doesn't that do the add ppa, etc magic for you?
[16:13] <dobey> otherwise installing something from a PPA would be a 2-step process
[16:13] <pitti> seb128: yeah, it would be one possibility
[16:13] <pitti> seb128: but right now, the author has to give instructions how to install the software anyway
[16:13] <pitti> so as an intermediate step, pointing to a PPA would make it more consistent
[16:14] <seb128> mvo_: do you have those gritty notes somewhere?
[16:15] <mvo_> seb128: let me search, but I think I was not part of the discussion, only later when desrt approached me about it
[16:15] <seb128> ok
[16:15] <dobey> although adding the stuff to apturl could make it one-step i guess
[16:15] <rickspencer3> also, don't forget that we are designing for a user here, and that user is not us
[16:15] <seb128> pitti: I guess my concern is that I want deb to stay a proper way to distribute software we can recommend
[16:15] <rickspencer3> tools for opportunistic application developers
[16:16] <seb128> I would encourage random crack to be "download, run, delete" things
[16:16] <mvo_> dobey: we even have code in it for one-step, but it might turn into a huge support/security issue
[16:16] <seb128> rather than proper installs
[16:16] <mvo_> dobey: (in apturl)
[16:16] <rickspencer3> I don't see much difference to the end user in terms of danger and such between getting a deb and getting a PPA
[16:16] <seb128> rickspencer3: who is your user target?
[16:16] <seb128> rickspencer3: ppa == deb
[16:17] <pitti> seb128: this is tricky; for apps which stick around, and for which the user wants updates, PPAs are much better
[16:17] <seb128> rickspencer3: the first draft we had was "download one py file and run it", no system install, etc
[16:17] <pitti> but they are more sticky, it's nontrivial to get rid of them
[16:17] <rickspencer3> seb128: right, except the PPA provides a single update point, you don't have to push new debs out to users
[16:17] <seb128> pitti: I feel that first prototype should use the light crappy software system
[16:17] <dobey> mvo_: the security issue seems rather bogus to me
[16:17] <rickspencer3> this is why so many people build web apps, the single point of updating is hugely valuab;e
[16:17] <seb128> pitti: and you can turn to proper ppa use when your application is recommended for lusers
[16:18] <pitti> seb128: right; well, we could support both modes
[16:18] <rickspencer3> agreed, I think a deb is appropriate sometimes
[16:18] <seb128> I totally agree with that
[16:18] <rickspencer3> but PPAs are extremely useful for deploying software
[16:18] <pitti> "spit out a runme blob" vs. "upload to PPA"
[16:18] <seb128> and we distribute all of ubuntu using debs right now
[16:18] <rickspencer3> I would think:
[16:18] <rickspencer3> quickee ebd
[16:18] <seb128> but we control quality what we distribute
[16:18] <rickspencer3> I mean quickee deb
[16:18] <rickspencer3> or quickee ppa
[16:18] <rickspencer3> two different commands
[16:19] <pitti> "quickee blob"
[16:19] <rickspencer3> seb128: this isn't about what *we* distrubute
[16:19] <pitti> for the "./runme" thing?
[16:19] <rickspencer3> it's about application developers distributing to their users
[16:20] <seb128> rickspencer3: right, same difference, the "we" being a motu or whoever upload to a ppa
[16:20] <rickspencer3> seb128: can't anyone upload to a ppa?
[16:20] <seb128> right
[16:20] <rickspencer3> I'm not a motu, but surely I could distribute my software that way, right?
[16:21] <seb128> I'm a bit concerned about distributing random crack as deb format
[16:21] <seb128> or rather going further this way
[16:21] <rickspencer3> I don't think it's random to the developers or their users
[16:21] <rickspencer3> it's just not generally useful
[16:21] <seb128> making it too easy will mean you will get thousand of cracks added daily
[16:21] <rickspencer3> but how do users discover that crack?
[16:21] <seb128> which makes impossible after some time to triage the good information
[16:21] <pitti> seb128: well, people will install crack they want no matter in which format :)
[16:21] <rickspencer3> they would have to get pointed to the PPA, and add the sources, etc...
[16:22] <pitti> if the web site says "do wget | sudo bash", they'll do it
[16:22] <seb128> pitti: right, but I would prefer to have "get crack" website than having cracks in synaptic
[16:22] <pitti> heh
[16:22] <pitti> seb128: I see what you mean
[16:22] <rickspencer3> we should categorically *not* mix in PPAs with main/universe, etc...
[16:22] <seb128> so you know that synaptic being the official way you can use that to get software you need to get work done
[16:23] <rickspencer3> seb128: yes, that is an important distinction
[16:23] <seb128> and you can get cracks on "crackland.ubuntu.com"
[16:23] <dobey> well if people stick their crack in PPAs on launchpad, and we use it, we can provide useful feedback to them
[16:23] <rickspencer3> or you could go to Add/Remove, and somehow turn on "crack mode"
[16:23] <rickspencer3> but every app in their is clearly labelled with a crack pipe
[16:24] <dobey> if they stick random tarballs or whatever on their own sites, then there is much less chance we have of helping them improve the things we actaully use ourselves
[16:24] <seb128> still you add crack to the system, ie apt database gets slower
[16:24] <seb128> indexes take longer to download
[16:24] <rickspencer3> and maybe has a certain number of dead junkies to show rating
[16:24] <seb128> I'm already annoyed by the number of packages we have right now
[16:24] <dobey> eh, we install plenty of crack by default :)
[16:24] <seb128> I'm not wanting to pay an extra 30 seconds of index download every time I do apt-get update
[16:25] <rickspencer3> seb128: We need to encourage Ubuntu as an application development platform, not discourage it
[16:25] <seb128> and by installing and removing lot of debs the system gets slower over time
[16:25] <dobey> seb128: then don't add a million PPAs to your system. most users won't really care, because that happens in the background anyway
[16:25] <rickspencer3> but I agree that we need to differentiate what is part of Ubuntu, and what is delivered by an independent developer
[16:25] <seb128> rickspencer3: there is a difference between writting softwares and distributing those
[16:25] <rickspencer3> seb128: not really
[16:25] <rickspencer3> if you can't distribute it, there's no point in writing it, and if you can't write it, you can't distribute it
[16:25] <dobey> if the removing makes the system slower, then perhpas apt/dpkg could use some fixes to make it clean up after itself better
[16:26] <seb128> for one things people writting software usually want those to work on any distro or system
[16:26] <rickspencer3> that's why most platforms include deployment as part of their sdk
[16:26] <seb128> and not just ubuntu jaunty or whatever ppa is on
[16:26] <rickspencer3> seb128: again, this is an opportunistic application developer
[16:26] <seb128> dobey: yes, dpkg could use some work no discussion
[16:27] <rickspencer3> if you're writing a pencil ordering app for your office, you really don't care about other distros
[16:27] <seb128> rickspencer3: I might be over-conservative but I can see the things getting out of control quickly
[16:27] <rickspencer3> having too many cool applications being created for Ubuntu is a problem I would love to have
[16:27] <seb128> lol
[16:27] <seb128> the issue is right there
[16:27] <seb128> "cool" is what I would like to get
[16:28] <seb128> but you will get 90% crappy applications
[16:28] <rickspencer3> but users can just ignore the crap
[16:28] <seb128> crappy or disappointing
[16:28] <rickspencer3> it's not like 100% of the apps on the web are great
[16:28] <seb128> how can they know what is crap or not in those thousand items?
[16:28] <rickspencer3> how do they discover them in the first place?
[16:29] <rickspencer3> they won't be showing up in Add/Remove or anything, they'll have to know about the PPA somehow in order to discover it
[16:29] <seb128> that's a good question ;-)
[16:29] <seb128> the issue I've with a ppa is that you don't add a specific software
[16:29] <pitti> seb128: discovery is entirely separate from the mechanics of distributing them, I think
[16:29] <rickspencer3> pitti: agreed
[16:29] <seb128> but a source which might have one good software and 800 craps next to it
[16:29] <seb128> and those will be listed as well in synaptic, apt, etc
[16:29] <rickspencer3> and we can defer solving that problem until we have the problem of too many apps :)
[16:29] <dobey> don't PPAs have disk quotas?
[16:30] <seb128> a crappy pygtk application takes few space
[16:30] <seb128> you can probably ship hundred of those in the quota limit
[16:30] <dobey> yes, but how many people are really going to write 800 crappy pygtk apps in their one PPA?
[16:31] <seb128> I've seen people storing lot of random things in their ppa already
[16:31] <dobey> although, i think all pygtk apps are crappy :)
[16:31] <seb128> including hacked version of component shipped by ubuntu
[16:31] <dobey> even mine
[16:31] <rickspencer3> so crappy PPA set up would be between a developer and their users, would it not?
[16:31] <seb128> you could end up installing a random linux git version which is there too
[16:32] <seb128> rickspencer3: well, users don't realize what they do, they will click to try gwibber, the ppa get added
[16:32] <seb128> rickspencer3: and next time they "upgrade" they get this git GNOME build which is also in the ppa
[16:32] <seb128> and nautilus doesn't start
[16:32] <rickspencer3> this problem exists today though
[16:32] <seb128> and users are screwed, ubuntu reputation gets damaged in the way because "ubuntu broke"
[16:33] <seb128> yes
[16:33] <seb128> and that's why I would not encourage extra ppa use until we solve it
[16:33] <rickspencer3> I don't think we solve it by keeping it hard to make and deploy apps
[16:33] <seb128> or we need a app-specific-ppa
[16:33] <seb128> ie one ppa = one software
[16:33] <rickspencer3> right
[16:33] <seb128> why does it have to be hard?
[16:33] <seb128> I was not suggesting to not deploy app
[16:33] <rickspencer3> seb128: it *is* hard
[16:34] <dobey> what we need is for launchpad to have PPAs on projects
[16:34] <seb128> what they discussed 6 months ago was simpler than your ppa approch
[16:34] <seb128> it was a website 1 click solution
[16:34] <dobey> instead of having to create a team to own PPAs
[16:34] <asac> hmm
[16:34] <rickspencer3> seb128: I'm open to that
[16:34] <dobey> so that you have a direct connection between a PPA and a specific app
[16:34] <rickspencer3> whatever is the deployment mechanism
[16:34] <dobey> or project anyway... a project might have multiple apps
[16:34] <seb128> I think I would be happy with the 1 software by sources.list entry
[16:35] <seb128> ie if you could say "I want to get nautilus-launchpad from rick's ppa"
[16:35] <pitti> seb128: what was the gut of that, tar'ing it up and add a runme.sh which sets up PYTHONPATH=. etc.?
[16:35] <seb128> pitti: right, it was designed for easy run of prototypes
[16:36] <seb128> pitti: the rational was that softwares good to be distributed to any user should be properly deb packaged then
[16:36] <rickspencer3> so the developer basically hosts a web page where they drop their app, and users add that page to their sources list by clicking on a link?
[16:36] <asac> rickspencer3: that was the idea of apturl
[16:36] <seb128> the frontend is a bit orthogonal but yet
[16:36] <asac> rickspencer3: we have the third party repository requirements
[16:36] <pitti> I understood it as they'd directly download an executable big script which unpacks and runs itself
[16:36] <seb128> we could have a portal for all those apps
[16:36] <rickspencer3> asac: that's what I was getting at
[16:36] <rickspencer3> okay, good discussion
[16:36] <asac> rickspencer3: otherwise we explicitly didnt want to make all ppa available that easily
[16:36] <asac> because of quality concerns
[16:37] <rickspencer3> it's clear that we have some good options for end users actually getting the applications
[16:37] <asac> if we wanted that we could make a tiny PPA searcher app or something
[16:37] <asac> but i wouldnt wnat to have that in apturl ... because thats really too easy to trigger from websites
[16:37] <rickspencer3> and that we are in agreement that we can put into place a developer workflow that goes from creating a project from a template to deploying it to users getting it
[16:38] <rickspencer3> quickie -> automatic python -> PPA/apturl/foo
[16:38] <asac> yeah.
[16:39] <pitti> rickspencer3: if we don't produce packages, we don't really need a build system either
[16:39] <seb128> we need a portal to list those applications and let user do rating etc
[16:39] <rickspencer3> pitti: would we not produce packages?
[16:39] <rickspencer3> I assumed that debs would be at the heart of whatever we do
[16:39] <pitti> rickspencer3: we would for PPA, we wouldn't for the "small scale" approach that was discussed half a year ago (which Seb explained)
[16:39] <rickspencer3> I would think users might want to create a deb, burn it to a disc, and distribute that way (or put it on an ftp server or whatever)
[16:39] <seb128> then you need to know about build requirements, etc
[16:40] <pitti> seb128: we can automate those
[16:40] <seb128> which again raise the entrance level
[16:40] <asac> pitti: so the idea is something like small python extensions that are just pulled from bzr?
[16:40] <pitti> but "deb" without "ppa" is possible as well
[16:40] <seb128> pitti: for python yes, for C... how?
[16:40] <rickspencer3> right
[16:40] <pitti> seb128: I don't even start thinking about small GUI development in C :)
[16:40] <pitti> that's far away from the target audience, I think
[16:40] <asac> please lets not start doing a source distro ;) ... arch-all python snippets might make sense to maintain like extensions out of package
[16:41] <asac> but binary stuff shoudl still be packaged properly imo
[16:41] <asac> gives you all the auto-depends and so on
[16:41] <rickspencer3> I would think that the "small" way would put a deb on a server someomen
[16:41] <seb128> pitti: making python packaging is something which would benefit anyone
[16:41] <seb128> +easier
[16:41] <hggdh> even python -- how you check for dependencies?
[16:41] <pitti> asac: for python the main task of the build system is to merge translations, put the .desktop file into the right place, etc., all of which isn't necessary if you don't build a package at all
[16:41] <pitti> seb128: right, which is why I want to do that anyway
[16:41] <seb128> hggdh: look for all the "import" and look what packages ship those?
[16:42] <pitti> writing setup.py is mostly a redundant and boring task
[16:42] <pitti> ask dobey :)
[16:42] <asac> pitti: yeah. so even for python we need packages
[16:42] <asac> and packages are not really hard to do imo with cdbs
[16:42] <pitti> asac: "we need" -> "I need it for apport and jockey", but not "Joe developer needs it for his pencil ordering app"
[16:43] <pitti> asac: it should be possible to run pretty much any python app right out of the source tree, without messing with setup.py etc.
[16:43] <asac> pitti: right. thats what i said above.
[16:43] <asac> but i dont get what needs to be improved?
[16:44] <pitti> asac: did you ever use python's distutils?
[16:45] <asac> i never ran a serious python projects in the last years ;)
[16:45] <pitti> asac: I want this to be 5 lines (description, license, author) http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/annotate/head%3A/setup.py
[16:45] <pitti> asac: and this to go away entirely: http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/annotate/head%3A/setup.cfg
[16:46] <asac> heh. yeah. i never understood why python build system is such a mess
[16:46] <seb128> which is somewhat orthogonal from the distribution discussion
[16:46] <asac> right. that sounds like a upstream build system problem
[16:47] <seb128> making python packaging easier would benefit everybody
[16:47] <asac> besides from that a package should imo be trivial enough. if users dont like that they can still use bzr branches directly. if we think thats important we can start to maintain a "ubuntu-python-tinyapps-central" repository
[16:47] <seb128> no discussion about that
[16:47] <asac> and build a UI/cmdline to search/checkout those apps
[16:47] <seb128> then there is the discussion on how we push softwares to users
[16:48] <pitti> asac: a mess? ever looked at automake/autoconf? :-)
[16:48] <asac> seb128: yeah. if its packages, its PPA ... if its just bzr branches its the frontend for the "ubuntu-python-tinyapps-central"
[16:48] <asac> repostiroy
[16:48] <asac> pitti: yes. thats well understood ;)
[16:48] <mvo_> seb128: python-packaging-easier++
[16:48] <asac> pitti: problem is that python world introduces new build systems every month and all dont bring much benefit over auto tools
[16:48] <pitti> that's what I meant with "pet peeve of mine"
[16:49] <pitti> asac: oh? distutils is around for ages, and so is setuptools
[16:49] <pitti> I don't know another one, actually
[16:49] <asac> yeah. then there is scons
[16:49] <asac> which is used by chromium
[16:49] <pitti> scons isn't a Python build system
[16:49] <asac> absolutely wasted energy to learn that imo
[16:49] <pitti> well, it's written _in_ python
[16:49] <asac> its not better than any autotools stuff
[16:49] <pitti> but I never saw a python project using scons to build itself
[16:49] <pitti> asac: it's better design-wise, but clumsy indeed
[16:50] <asac> yeah. i might mix things up ;). i retract the claim ;)
[16:50] <pitti> I tried it once, too, I was curious
[16:50] <asac> its good if its trivial
[16:50] <pitti> I haven't looked at cmake yet
[16:50] <asac> if you want to do things non-trivial its like banging your head against the wall ;)
[16:51] <pitti> sounds like autobreak :)
[16:51] <asac> problem is that with all this new stuff there are no established best practices and users choosing minority build systems without having a damn good reason just cause higher entry barriers
[16:51]  * pitti has fought with the gthumb merge for half an hour and still didn't figure out WTF broke in the autotools build system
[16:52] <asac> yeah. but autotools is so old and knowledge has completely diffused in the free software community ;)
[16:52] <asac> meaning: you will always find someone in your neighbourhood to help you fix autotools stuff ;)
[16:52] <pitti> yeah, autotools being old and crappy is the only advantage to the "new and less crappy" build system s;)
[16:52] <pitti> anyway, /flamewar, need to get some things done
[16:53] <asac> you are right. i just say that the improvements are too incremental that those dont make sense
[16:53] <asac> and thats why there is no clear winner ;)
[16:53] <asac> yeah. better working ;)
[16:54] <james_w> pitti: paver, zc.buildout, pip
[16:54] <pitti> james_w: never heard about them
[16:55] <james_w> zc.buildout is what the LP stuff now uses, so I'm going to have to learn it soon :-/
[16:55] <pitti> none of them are packaged, are they?
[16:56] <james_w> seems not
[16:57] <james_w> ah, pip isn't a build system, my bad
[17:11] <asac> lool: does the mobile team any demands for karmic wrt browser stuff?
[17:16] <seb128> chrisccoulson: are you still working on the gnome-session update
[17:16] <seb128> ?
[17:16] <lool> asac: Good question
[17:16] <chrisccoulson> hey seb128 - yes, i did start doing that
[17:16] <seb128> chrisccoulson: ok good thanks
[17:16] <lool> asac: I can think of the clutter-mozilla thing as being relatively hot for moblin 2
[17:17] <seb128> chrisccoulson: you will rebase on debian right?
[17:17] <lool> But I don't think it's in a reviewable shape ATM
[17:17] <chrisccoulson> seb128 - i've done that already. we've still got quite a delta to debian though
[17:17] <seb128> Ampelbein: let me know if you are available for some extra merges on debian
[17:17] <lool> Otherwise, keeping an eye on Fennec would be nice, that's all I can think of
[17:17] <asac> lool: moblin 2 timeline?
[17:17] <seb128> chrisccoulson: ok
[17:17] <Laney> seb128: toss some merges over here if you want
[17:18] <seb128> didrocks: what do you have on your merge list?
[17:18] <lool> asac: It's due real soon now, and we will integrate it in karmic, probably in june or so
[17:18] <Laney> where is the GNOME component work assignment list?
[17:18] <asac> lool: oh moblin 2 is what we talked about already. thought it was the NEXT ;)
[17:19] <seb128> Laney: alacarte gnome-settings-daemon
[17:19] <Laney> okey dokey
[17:19] <asac> lool: ok thanks. so keeping up with fennec is the only task mobile wise. on top probably just connman for network management.
[17:19] <asac> lool: oh i forgot, probably not only mobile, but NM UI still isnt small screen ready, right?
[17:19] <asac> lool: maybe we should tackle that this cycle too somehow
[17:20] <lool> asac: I'm sure OEM and UNR folks would be delighted by such a proposal  :)
[17:20] <asac> lool: mobile has no issues with that?
[17:20] <lool> asac: For the moblin spin, we'll probably use connman, even if not ready, but for UNR: yes definitely
[17:20] <lool> asac: We're integrating UNR, so yes, we have issues
[17:20] <asac> lool: heh ok. will that moblin spin be based on jaunty?
[17:21] <lool> in MID it's horrible, but then MID is not really at the top of our priorities :-/
[17:21] <lool> asac: Correct, but I guess we'll prepare it in karmic first, and then do some PPA backports
[17:21] <seb128> Laney: https://wiki.ubuntu.com/DesktopTeam/TODO is sort of the list but I'm pondering moving that to bugs or bzr storage
[17:21] <asac> yeah. ok. so we need backports for those and for latest connman
[17:21] <asac> those == small screen changes
[17:22] <lool> That would be nice
[17:24] <asac> btw, chromium dailies look really promissing i have to admit
[17:25] <lool> Really?  would have thought it would take much longer
[17:25] <asac> lool: you can do browsing and tabs also work
[17:25] <asac> the preferences dialog and so on doesnt exist that
[17:25] <asac> but i guess thats the easier part of it
[17:26] <asac> of course its 32bit only ... but the ia32build also works almost as good as i386
[17:26] <lool> What about flash and a11y?
[17:26] <asac> good point ... i would think that doesnt work ;)
[17:26] <asac> https://edge.launchpad.net/~chromium-team/+archive
[17:26] <lool> Thanks
[17:26] <asac> wrong
[17:26] <asac> https://edge.launchpad.net/~chromium-daily/+archive
[17:26] <asac> lool: ^^
[17:26] <lool> ah
[17:26] <asac> karmic builds arent there yet
[17:27] <lool> You could have a /ppa and /chromium-daily now  ;)
[17:27] <asac> lool: yes. but those were created before
[17:27] <asac> lool: i have to talk to ppa folks about a migation strategy
[17:27] <asac> we have other PPAs that could be consolidated now
[17:27] <asac> but just moving isnt nice ;)
[17:28] <lool> Anyway, lots of exciting stuff :)   /me returns to holidays mode and cleaning stuff around   ;)
[17:28] <asac> lool: oh. holiday. sorry for the noise. enjoy!
[17:29] <lool> Oh np, I'm on IRC so it's fine :)
[17:37] <asac> stupid question, where are the "default" groups a user gets configured?
[17:37] <asac> adduser.conf seems to not be it
[17:38] <chrisccoulson> asac - when added with users-admin?
[17:39] <asac> *shrug* ... whatever the ubuntu "default" way is i guess
[17:40] <chrisccoulson> if you add a user with users-admin, it gets it from /etc/gnome-system-tools/users/profiles
[17:40] <asac> yeah
[17:40] <asac> found it
[17:40] <asac> great
[17:40] <asac> hmm. user claims that it dip is not there by default
[17:41] <asac> seems to be wrong
[17:46] <calc> yipee it looks like OOo might actually be going towards real modularization upstream :)
[17:46]  * calc is reading a thread from late last week about it
[17:47] <vuntz> jcastro: dudie. Just want to apologize, it seems I didn't reply to your last mail in our mail discussion. But I'll reply :-)
[17:51] <bryce> mnemo: asac is right that we should put this into karmic too.  Even though we will have a new mesa there before too long, it's worthwhile for the extra testing if nothing else
[17:52] <bryce> mnemo: however I can take care of that, so no worries
[17:52] <mnemo> bryce: i managed to screw up my karmic box it seems
[17:52] <mnemo> ah great
[17:52] <pitti> hey bryce, good morning
[17:53] <pitti> hello calc
[17:56] <jcastro> vuntz: no worries, it's a busy time for everyone. :)
[17:58] <vuntz> jcastro: but I want to be sure that you don't think I stopped loving you ;-)
[17:58] <bryce> pitti: heya, hope you had a decent weekend
[17:59] <pitti> bryce: it was great indeed, lots of exercise; how about you?
[18:01] <bryce> pitti: it was ok, although I've been emailed rants about the intel perf issue that kinda bums me out
[18:03] <didrocks> seb128: gnome-python-extras (:p), keepalived, tracker, and no GNOME component, apparently!
[18:03] <seb128> didrocks: want to do gnome-python and gnome-python-desktop too?
[18:04] <pitti> bryce: *shrug* we can't do much more than pointing to workarounds, I'm afraid
[18:04] <didrocks> seb128: ok, not for tonight, but it will be ok tomorrow :)
[18:04] <seb128> ok good, thanks
[18:04] <pitti> bryce: the 965 issue worries me more; there was a comment saying that the patch overwrites the xorg.conf setting instead of just changing the default
[18:04] <didrocks> seb128: once again, just say thanks when it's done :p
[18:04] <seb128> ;-)
[18:05] <bryce> pitti: yep, they're just pissy we didn't stay back on 2.4.
[18:06] <pitti> *shrug* it's there for them to install
[18:06] <bryce> pitti: yeah I saw that bug report and plan to look at it today.  The patch should not do that though (it checks for existing virtual settings), but maybe the check isn't complete enough.
[18:07] <pitti> bryce: btw, what's the magic command to show the current virtualsize setting?
[18:07] <pitti> bryce: Keith used one in his demo, but I didn't see the actual command
[18:08] <bryce> xrandr | grep maximum
[18:08] <pitti> aah
[18:08] <pitti> thanks
[18:21] <nikkiclau> Hi.
[18:23] <nikkiclau> Anyone here ever had the issue, or knows how to resolve when one is wanting localization settings such as punctuation and date settings while having the default translation?
[18:27] <pitti> you could set LC_TIME to a different locale than LANG (or LC_MESSAGES); please see "man locale" for more information
[18:29] <ktenney> mnemo: help with gdm hanging?
[18:29] <mnemo> ktenney: did you get a chance to try the live CD yet?
[18:30] <ktenney> liveCD is fine
[18:30] <mnemo> ktenney: you got back to gdm when you logged out and then it logged you in again?
[18:30] <ktenney> yes
[18:30] <mnemo> right, okay... so you have some config issue on your machine then ;/
[18:30] <ktenney> right
[18:30] <ktenney> seems pam related
[18:31] <ktenney> pam_nologin(gdm:auth): cannot determine username
[18:31] <ktenney> possible to disable pam?
[18:32] <ktenney> or ... what config files should I look at?
[18:32] <mnemo> not sure actually..
[18:32] <pitti> good night everyone, Taekwondo time
[18:33] <mnemo> pitti: gl hf
[18:33] <ktenney> there was a forum post, another fellow, same issue, no answers yet
[18:33] <mnemo> ktenney: when you said "gdm issue" I was thinking maybe gdm failed because of some xorg related issue, in that case maybe I would have been of more help...
[18:33] <mnemo> ktenney: try asking in #ubuntu maybe
[18:33] <ktenney> no, get X, timer icon on blue field
[18:34] <ktenney> ok, though it's like the birdhouse at the zoo there, was hoping for a quiet solution here.
[18:35] <bryce> mnemo: uploaded
[18:35] <mnemo> bryce: excellent.. thanks a lot
[18:35] <ktenney> hoping a gdm/pam guru would be around
[18:46] <nikkiclau> damn .. went afk and pitti's gone
[18:46] <nikkiclau> But actually I was wondering about a user-friendly way.
[19:03] <calc> rickspencer3: ping
[19:03] <rickspencer3> calc: callling in?
[19:03] <calc> oh oops i didn't realize it was a callin one
[19:03] <calc> doing so now
[19:03] <rickspencer3> k
[19:04] <rickspencer3> awe: hi!
[19:05] <rickspencer3> calc: 2455480861
[19:05] <calc> ok in the conf now
[19:14] <calc> my phone cut out
[19:15] <rickspencer3> awe: welcome to the desktop team for Karmic!
[19:21] <rickspencer3> calc: I assume we're skipping our weekly call this week?
[19:21] <calc> rickspencer3: yea sounds fine to me
[19:21] <calc> rickspencer3: we already covered most of what we would talk about
[19:21] <rickspencer3> calc: don't forget, we've got your back
[19:22] <rickspencer3> if you need anything, just let me know right away
[19:23] <calc> ok
[19:23] <calc> i'll try to get an email written up for the group about what to do as far as triage later today so that if there are any questions it can be discussed during tomorrow's meeting
[19:24] <calc> i already described it in the wiki but i can give more details about my specific work flow than what really is appropriate for the wiki bug page
[19:25] <asac> calc: is that about "how to build/update" openoffice?
[19:26] <calc> asac: how to bug triage OOo :)
[19:26] <asac> ah ;)
[19:26] <calc> asac: i think i should be able to handle packaging OOo in 20%
[19:27] <calc> but i can also add the build/update for if someone wants to try out patches, etc
[19:27] <asac> ah so you are sliced ;)
[19:27] <asac> a piece of calc please :)
[19:27] <calc> heh yea
[19:30] <asac> whats the status of the "intel" performance bug?
[19:30] <asac> was there any news i missed?
[19:34] <rickspencer3> asac: yes
[19:34] <rickspencer3> bryce has identified a mitigation for i965
[19:35] <rickspencer3> essentially, setting virtual screen size mitigates the crash and boosts perf
[19:35] <rickspencer3> there is a patch in proposed to do just that
[19:37] <asac> rickspencer3: great. i have a firefox performance regression bug. i will ask them to test -proposed. which package is that? xserver-xorg-video-intel or more?
[19:37] <rickspencer3> as well as compiz (to unblacklist i965)
[19:38] <asac> hmm.
[19:38] <asac> is that a hard blacklist? or just a default?
[19:38] <asac> e.g. can affected users still enable compiz manually?
[19:44] <crdlb> hard
[19:45] <crdlb> it can be overridden by the user, but not with the gui
[19:45] <rickspencer3> asac: there are lots of instructions for enabling compiz
[19:45] <rickspencer3> attached to the bug and such
[19:54] <asac> crdlb: ok thanks. they only talked about appearence dialog i guess. so probably not their bug
[19:56] <Ampelbein> seb128: hi, just got back home. i updated the debdiff to bug 369395 and am ready for another merge.
[20:11] <rickspencer3-afk> should be an interesting thread to watch: http://www.reddit.com/r/technology/comments/8hsbo/how_do_you_pronounce_ubuntu/
[20:12] <rickspencer3-afk> funny anyway
[20:38] <seb128> Ampelbein: hello, ok I will have a look after dinner, you can look on rebase seahorse on debian and updating it to 2.27 too for karmic if you want
[20:38] <Ampelbein> seb128: ok, will do.
[20:38] <seb128> good
[20:38]  * seb128 dinner, bbl
[20:58]  * awe heading home...back online in an hour or so...
[20:59] <calc> pitti: ping
[21:01] <artir> OOBOONTOO
[21:07]  * asac out for a bit
[21:14] <Ampelbein> seb128: one question about seahorse. you say "rebase on debian" but debian still has 2.24.1, not 2.26.1 according to packages.debian.org. so i just update to 2.27.1, right?
[21:14] <seb128> Ampelbein: no
[21:15] <calc> Ampelbein: probably look in experimental
[21:15] <calc> hmm nm its not there either
[21:15] <calc> i guess in the pkg-gnome (or whatever then)
[21:15] <seb128> no
[21:15] <Ampelbein> calc: i searched for all distributions
[21:16] <seb128> but we have 2.26.0-0ubuntu and we synced on 2.20.1-2 previous time
[21:16] <seb128> so use debian 2.24.1
[21:16] <seb128> and apply ubuntu changes and update using that
[21:16] <Ampelbein> ah, ok.
[21:16] <seb128> ie we want all the debian changes between 2.20.1-2 and 2.24.1
[21:16] <calc> ok that makes more sense :)
[21:18] <seb128> seahorse is something where we should not have too much changes in ubuntu
[21:20] <Ampelbein> seb128: but won't we always be ahead of debian with gnome?
[21:20] <seb128> right
[21:20] <seb128> we still aim at giving back there things which could be useful and lower the differences
[21:21] <seb128> that benefit debian and that makes our job easier
[21:21] <Ampelbein> seb128: ok, understood.
[21:23] <Ampelbein> seb128: but the changes-file i generate is still based on 2.26.1 in ubuntu? so that only the files in debian/ represent the state of 2.24. in debian plus ubuntu-changes?
[21:26] <seb128> hum?
[21:26] <seb128> I usually don't merge changelog entries
[21:26] <seb128> what I do is take the debian source
[21:26] <seb128> dch -v 2.27.0-0ubuntu1
[21:26] <seb128> Then write "new upstream version"
[21:27] <seb128> and then I summarize the ubuntu changes
[21:27] <seb128> and I apply those to the source by looking at the previous changelog and diff to see what is still revelant
[21:27] <seb128> ie you want to add again the ubuntu keyring change
[21:27] <seb128> so you write that in the changelog and copy the patch over there
[21:28] <seb128> and you continue going through the diff until there is no ubuntu change that need to be applied
[21:28] <seb128> then you can look if there is some new requirement in 2.27 and do those changes too
[21:28] <seb128> that makes sense?
[21:31] <Ampelbein> seb128: ok, so i just drop the changelog-entries?
[21:31] <seb128> right
[21:31] <seb128> just summarize all the changes in the current one
[21:31] <seb128> don't copy the "lp: #nnnn" or change the format though
[21:31] <seb128> to not spam the same bugs number again
[21:32] <Ampelbein> ok.
[21:35] <james_w> that's fixed in LP, it won't keep trying to close bugs from changelog entries if they are already closed
[21:37] <seb128> james_w: it will not add the comment either?
[21:37] <james_w> correct
[21:54] <Ampelbein> seb128: we have a seahorse.preinst to remove the conffiles obsoleted by version 2.23.5, debian has not. do we keep such a change?
[21:55] <seb128> Ampelbein: if 2.23.5 was after hardy yes
[21:57] <Ampelbein> seb128: oh, just noticed. debian has a changelog-entry that it took the change from ubuntu, but they do not ship the .preinst file mentioned. i'll file a bug with debian?
[21:57] <seb128> look to the next ones if they dropped it by mistake perhaps if not open a bug
[22:02] <Ampelbein> seb128: no further mention so i guess it's a bug. another question: the watch file should also look for unstable version in ubuntu?
[22:13] <chrisccoulson> seb128 - any idea why gnome-session has a build-depends on xtrans-dev in ubuntu but not in debian?
[22:13] <chrisccoulson> i can't find anything in the changelog which explains it
[22:34] <mpontillo> Anyone know if there is an easy way to do the equivalent of "apt-get source <package>" from the command line, but grab the corresponding Debian source package instead of the Ubuntu version? (Modify sources.list maybe?)
[22:35] <dobey> you can just download the source off packages.debian.org's web site too
[22:35] <dobey> although that's not command line
[22:35] <mpontillo> Hm. Maybe I'll hack up a quick deb-src-get script then
[22:36] <Laney> mpontillo: there is pull-debian-source in the ubuntu-dev-tools package
[22:36] <mpontillo> Laney: thanks, I'll check it out
[22:37] <seb128> you can add a debian source
[22:38] <seb128> and apt-get source binary=version
[22:44] <mpontillo> thanks for the tips - pull-debian-source did exactly what I wanted. I like that you can also specify the release, as well. (adding the debian source directly could be handy at times, might have bad side effects if I'm not careful - like if I forget it's there, no?)
[22:48] <seb128> well not really bad, you can download a debian source where you want an ubuntu one if it's newer in debian yes
[22:59] <Ampelbein> seb128: i get a "dh_desktop" is deprecated for seahorse (http://paste.ubuntu.com/164503/). apparently this comes from gnome.mk, included in the rules-file. should I care for this?
[22:59] <seb128> Ampelbein: no, don't bother
[22:59] <Ampelbein> seb128: ok, bug 371871 ready for review
[23:00] <seb128> Ampelbein: I've it locally already thanks ;-)
[23:00] <seb128> the bug emails have been quicker than IRC ;-)
[23:01] <Ampelbein> seb128: ok, but i changed something to the diff.gz recently, made a mistake in debian/control.in, missing ',' after gnome-pkg-tools
[23:01] <seb128> you can summarize NEWS changes when you do new version updates btw, some users like to read those
[23:01] <seb128> right, I got the new version
[23:07] <Ampelbein> seb128: should i add new version with NEWS-changes?
[23:08] <seb128> Ampelbein: what do you mean?
[23:08] <seb128> I usually write
[23:08] <seb128> * New upstream version:
[23:08] <seb128>  -
[23:08] <seb128>  -
[23:08] <seb128>  -
[23:09] <seb128> where the enumerations are the NEWS items
[23:09] <seb128> without the translation changes which are not that interesting
[23:09] <Ampelbein> seb128: yeah. should i change the update to include this? it's only two changes. (one, if you don't count translations)
[23:09] <seb128> no don't bother
[23:09] <seb128> there is nothing too interesting to list in this one ;-)
[23:10] <seb128> that's handy when you want to close bugs in launchpad too
[23:10] <Ampelbein> seb128: i usually do this, when there is important change. but adding old changelogs does not seem to be.
[23:11] <seb128> right, there was only the context menu thing which was worth listing
[23:12] <seb128> hum
[23:12] <seb128> there is a mistake in the update
[23:13] <Ampelbein> seb128: what's the issue?
[23:13] <seb128> Ampelbein: the html documentation is already shipped in seahorse binary
[23:13] <bryce> pitti: fix for virtual override uploaded
[23:13] <seb128> there is a reason why the .install had the zillion lines
[23:13] <seb128> rather than just the share directory as debian do ;-)
[23:14] <seb128> Ampelbein: already -> also, ie you have the .html in 2 binaries
[23:14] <bryce> pitti: fix was pretty obvious and easy; in fact someone else came up with it independently (bug 371544), so I gave him the credit
[23:18] <Ampelbein> seb128: ah, i see. didn't check that one, thought the "most specific" entry in *.install "wins".
[23:18] <seb128> no, it just copy everything listed
[23:19] <Ampelbein> seb128: i'll fix that and will list the NEWS in a new upload.
[23:19] <seb128> ok thanks
[23:19] <seb128> it's time to go to bed there but I will review it tomorrow
[23:20] <seb128> if you are looking for other things to do you can have a look to do the same thing for gnome-media too
[23:20] <seb128> ie rebase on debian if required and update to 2.27
[23:21] <seb128> see you tomorrow