[00:07] <ebroder> Whooo python 2.7!
[00:07] <Pici> woo
[02:50] <IdleOne> thank you marienz
[02:50] <hyperair> marienz: thanks.
[02:50] <IdleOne> can you just delete that topic
[02:50] <marienz> does someone still have... ah, there we go
[02:51] <IdleOne> thank you again
[02:51] <tsimpson> thanks marienz
[02:51]  * hyperair thinks someone deserves a ban though
[02:51] <elky> hyperair, he'll move on to another channel now and earn a k-line
[02:51] <marienz> the reset wasn't me :)
[02:51] <hyperair> marienz: hmm who did it?
[02:52] <IdleOne> question I have is why was the topic not locked
[02:52] <micahg> thanks Pici
[02:52] <elky> IdleOne, because numerous people here who are not ops need to change it
[02:52] <hyperair> thanks Pici
[02:52] <hyperair> what we need are topic acls!
[02:52] <IdleOne> elky: then a bot should be set up and access given to the non-ops for topic change
[02:52] <tsimpson> marienz: you may want to watch #kde too
[02:52] <hyperair> so who's up to creating a topicbot
[02:53] <micahg> Pici: maybe this channel should be +t?
[02:53] <tsimpson> IdleOne: the channel was -t before the bot needed to change the topc
[02:53] <IdleOne> tsimpson: in light of the new trend of looking for channels that are -t and setting racist topics I think it's time to revisit that policy
[02:54] <tsimpson> IdleOne: there is no policy on channel modes
[02:54] <wgrant> The number of inappropriate topic change incidents is tiny.
[02:54] <IdleOne> ok. just trying to offer a sane solution
[02:55] <Pici> Nevertheless, perhaps we should use +t and give the same flag to ubuntu/member/*
[02:55] <hyperair> well then, if that's the case, shall we set it back to -t again until the next bot comes along?
[02:55] <IdleOne> Pici: +1
[02:55] <hyperair> Pici: yeah i think that's a good idea.
[02:55] <micahg> Pici: +1 only ubuntu people should be changing the topic
[02:56] <Pici> Let me bounce it off the rest of the IRCC just to make sure we're all in agreement first.
[02:58] <ScottK> Pici: This isn't an IRCC controlled channel.
[02:58] <ScottK> (yes, IRCC has ops, but it's my understanding that ubuntu-dev controls the policies for #ubuntu-devel)
[02:59] <IdleOne> ScottK: not about who controls it, should be about security and IMHO -t is a security risk
[03:00] <IdleOne> in any *buntu channel
[03:00]  * ScottK is unclear on the relationship between a channel topic and security?
[03:00] <ScottK> If there is a link, it would be safest if no one could set the topic.
[03:01] <spm> well yes. everything is a security risk. as wgrant mentioned, the number of unauth changes is tiny. you're trying to spend $100,000 in securit ymeasures to proect something worth $1000. not worth it.
[03:01] <Pici> ScottK: I didn't say we'd change it, but I think that the IRCC should be in agreement before we propose the idea to the tech board, or whomever claims control nowadays.
[03:01] <wgrant> It takes about 30 seconds to fix the incidents that happen once every few months.
[03:01] <hyperair> it's unnecessary annoyance
[03:01] <ScottK> Yep.
[03:01] <wgrant> It takes a lot longer than that to grant someone permissions if they need them.
[03:02] <IdleOne> spm:  setting +t and leaving it is a one time thing. really isn't hard to do
[03:02] <micahg> wgrant: it seems like requiring an ubuntu cloak for changes to topic is simple enough, no?
[03:02] <hyperair> wgrant: how often does someone without an ubuntu member cloak need to set the topic?
[03:02] <hyperair> wgrant: i've never changed the topic of any #ubuntu- channels even once.
[03:02] <spm> every losa every month, sometimes more often.
[03:03] <ScottK> micahg: We've already spent more effort on dealing with a tiny problem than it's worth.
[03:03] <wgrant> Well, the LOSAs are canonical/*-cloaked, so they should probably be whitelisted too.
[03:03] <micahg> ScottK: this is twice in 24 hours
[03:03] <hyperair> well yes, so whitelist canonical and ubuntu cloaked people.
[03:03] <spm> wgrant: I'm not
[03:03] <ScottK> wgrant: I object to priviledges in an Ubuntu channel based on place of employment.
[03:03] <wgrant> ScottK: True.
[03:04] <wgrant> spm: Hm, I may indeed be mistaken.
[03:04] <micahg> why do LOSAs need to change topic in ubuntu-devel?
[03:04] <wgrant> LP downtime, among other things.
[03:04] <ScottK> That's how they keep us informed (quite appreciated too)
[03:04] <micahg> ah, ok
[03:04] <hyperair> here's an idea, let's have a launchpad bot.
[03:04] <wgrant> So, we've spent longer arguing about this than it has taken to resolve all of the inappropriate topic changes since the channel was started in 2004.
[03:05] <micahg> wgrant: right, but as I pointed out this is the second time in 24 hours this has happened
[03:05] <ScottK> Pici: I can't stop you and the IRCC from formulating a solution, but I would suggest there are more productive ways to spend your time.
[03:05] <micahg> so, I guess we wait to see if it gets worse :)
[03:06] <hyperair> i wonder how long it would take to give cloaked people access to the topic.
[03:08] <IdleOne> I think part of the IRCC mandate is worrying about IRC namespace and its proper functioning.
[03:09] <IdleOne> anyway, have a good night folks. +t is a good solution
[03:10] <aroman> hey all, I'm working on a new app that is currently in alpha right now, but I could really use bugs/support in improving the app's experience. What is the best way to get people interested in this project? It's on launchpad with a PPA right now.
[03:11] <ssj6akshat> aroman, name?
[03:12] <aroman> ssj6akshat, It's called purple.
[06:11] <hyperair> i wouldn't call it purple if i were you
[06:11] <hyperair> it promotes confusion with libpurple, which is part of pidgin
[06:42] <pitti> Good morning
[06:42] <pitti> tkamppeter: hi
[06:42] <pitti> hallyn_: I have no idea at all about multipath-tools, I'm afraid
[07:08] <ebroder> udienz: There's no need to both submit a merge proposal and subscribe ~ubuntu-sponsors to a bug. Either one is sufficient
[07:08] <ebroder> (Just FYI)
[07:24] <didrocks> good morning
[07:30] <tkamppeter> pitti, hi
[07:35] <tkamppeter> pitti, it is about bug 680628, I have applied also the Cairo patch. Can you upload the new Cairo package? Thanks.
[07:36] <pitti> tkamppeter: yes, can do
[07:37] <pitti> tkamppeter: is there an upstream bug for the cairo patch? when sponsoing, I'd like to add a proper patch header
[07:42] <tkamppeter> pitti, the Cairo patch is taken from the upstream VCS repo, so it is already upstream.
[07:42] <pitti> tkamppeter: ah, thanks
[07:42] <tkamppeter> pitti, the link is in the LP bug report.
[07:43] <tkamppeter> pitti, another thing is CUPS and Samba, it still does not seem to work for everyone, see bug 494141 for example.
[07:50] <soren> Laney: I'm not so much concerned about the EULA itself. It's a multiverse package after all, so it's not entirely unexpected. It's just that packages from -updates generally shouldn't need to prompt the user unless there's a functional change that the user needs to be aware of.
[08:03] <dholbach> good morning!
[08:11] <didrocks> hey dholbach
[08:11] <dholbach> hi didrocks
[08:12] <didrocks> hey dholbach (not sure if you see my first message, as I was just disconnected :))
[08:14] <dholbach> didrocks, j'ai seulement vu "hey dholbach" :)
[08:14] <didrocks> dholbach: oh ok, the lag showing in my weechat before I just disconnected was false then :)
[08:15]  * dholbach hugs didrocks :)
[08:15]  * didrocks hugs dholbach back
[09:22] <soren> pitti: I have a server written in Python. When something inside it throws exceptions, they're caught and logged and then it moves on with its life. I'd like to use apport to report bugs about these exceptions. Are there other projects doing something like that that I can learn from?
[09:24] <pitti> soren: not off the top of my head, but it's not too difficult
[09:25] <pitti> soren: you have to set sys.excepthook to your own crash handler, and inside that, you can import apport_python_hook and call apport_excepthook() with the exception
[09:25] <ebroder> pitti: I don't think you can recover if you make it to sys.excepthook
[09:25] <pitti> well, you can call it from any exception handler
[09:26] <pitti> but I thought the point of this was to have a fallback for uncaught exceptions
[09:26] <pitti> if you are there, you can at least go back to a defined state
[09:26] <soren> pitti: Cool, thanks. I'll see how that works out.
[09:26] <ebroder> soren: I think you could just call apport_python_hook.apport_excepthook(sys.exc_type, sys.exc_value, sys.exc_traceback) from any exception handling block
[09:27] <pitti> soren: note that apport_excepthook() calls sys.__excepthook__ in the end (to have the default handler), so you need to take care not to end up in an endless recursion
[09:27] <soren> Hm... Ok.
[10:00] <brendand> Hi
[10:00] <brendand> I have a question about update-manager
[10:01] <brendand> Trying to write a test which triggers an update
[10:01] <brendand> but the initial update that happens at the start is getting in the way
[10:01] <brendand> i'm trying to add an options which disables this
[10:01] <brendand> option
[10:02] <brendand> is there any straightforward way to do this, first of all?
[10:02] <brendand> otherwise I have some more specific questions
[10:03] <mvo> brendand: you can disable the daily update by modifying /etc/apt/apt.conf.d/10periodic
[10:03] <brendand> thanks
[10:04] <brendand> let me see if that does the trick
[10:05] <mvo> brendand: what kind of test is this (out of curisoty) automatic or manual?
[10:07] <brendand> automatic
[10:07] <brendand> basically
[10:07] <brendand> start update-manager
[10:07] <brendand> connect to d-bus
[10:07] <brendand> call (new) update() method
[10:07] <brendand> check return code
[10:07] <brendand> fail if return code is wrong or can't connect to dbus
[10:08] <mvo> nice, is that part of a broader testing approach?
[10:08] <brendand> the problem is i need to introduce a delay because it always does an initial update
[10:08] <brendand> it's part of SRU testing
[10:08] <brendand> to check that if an SRU borks your machine at least update-manager works to recover it
[10:09] <brendand> having arbitrary delays in test scripts is not my idea of maintainability
[10:09] <brendand> i already have one to 'make sure' that update-manager started enough to expose the dbus interface
[10:09] <brendand> don't want another if i can avoid it
[10:18] <mvo> brendand: sure, that is reasonable. let me know if I can help in any way, this sounds like a great project
[10:26] <janimo> what exactly does the suffix nobinonly stand for in mozilla package version names?
[10:31] <soren> pitti: Is there any way I can use apport to report bugs about packages in a PPA? Right now it complains it's not an Ubuntu package.
[10:32] <pitti> soren: yes, you can, ubuntuone-client does that; /usr/share/doc/apport/crashdb-conf.txt and /usr/share/doc/apport/package-hooks.txt.gz have the details
[10:32] <soren> pitti: ta
[10:33] <pitti> soren: /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf defines an "upstream project" crash database
[10:33] <pitti> soren: and /usr/share/apport/package-hooks/source_ubuntuone-client.py shows how to use it
[10:33] <pitti>     if not apport.packaging.is_distro_package(report['Package'].split()[0]):
[10:33] <pitti>         report['CrashDB'] = 'ubuntuone'
[10:33] <pitti> soren: that means "if this isn't a native package, then use the upstream crash DB"
[10:33] <soren> And that just makes it report it against ubuntuone rather than ubuntu/ubuntone?
[10:34] <pitti> soren: (you can also set it unconditionally if you always want to report against the upstream project, or set any other condition)
[10:34] <soren> Or is crash DB an actual thing I need to set up?
[10:34] <soren> Coolness.
[10:34] <pitti> soren: no, the "ubuntone" is the name of the crashdb that is defined in /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf
[10:34] <soren> Ah, right. I see it now.
[10:34] <soren> Thanks, I'll look into that.
[10:35]  * pitti smells tight OpenStack apport integration :)
[10:35] <soren> :)
[10:35] <soren> Does dh-apport deal with crashdb.conf?
[10:36] <pitti> I don't think it does
[10:36] <soren> ok.
[10:36] <pitti> just debian/package.apport
[10:36] <soren> np
[10:36] <pitti> soren: patches accepted :)
[10:36] <soren> pitti: Thanks a lot!
[10:36] <pitti> soren: (I don't use dh_apport myself, I'm not that familiar with it)
[10:37]  * soren shakes his fist at launchpad for being read-only right now
[10:38] <pitti> ogra_ac: is there an ogra_battery as well?
[10:39] <ogra_ac> pitti, lol
[10:39] <ogra_ac> i'm just redoing my home network during my vacation, an IRC proxy is part of the plan
[10:41]  * ogra_ac hugs mvo for enabling a flawless gutsy->hardy->lucid upgrade of my firewall
[10:42] <mvo> ha! thanks ogra_ac, nice to hear
[10:42] <ogra_ac> finally i can use ufw :)
[10:53] <janimo> micahg: hello, what does nobinonly mean in the mozilla package version strings?
[11:13] <janimo> ChrisCoulson: hello. Is it possible to use xulrunner in firefox and thunderbird builds? I know this comes up from time to time but I can't find a recent writeup of why this is not done
[11:14] <janimo> chrisccoulson: planned to be done on tbird or stopped by upstream issues?
[11:15] <chrisccoulson> janimo, oh, sorry, i didn't see your message here
[11:15] <janimo> chrisccoulson: my fault, I asked in private first by mistake
[11:15] <chrisccoulson> that's ok
[11:16] <chrisccoulson> OOI, why do you ask?
[11:16] <janimo> ARM FTBFS fix needs to be done in both xulrunner and tbird
[11:16] <janimo> it is the same xpcom code
[11:16] <chrisccoulson> ah, ok. yeah, that's a bit of a pain
[11:16] <janimo> but I guess it is a common maintenance problem with the duplication
[11:16] <chrisccoulson> which xulrunner version isn't building? if it's 1.9.2, don't invest any time fixing that
[11:17] <chrisccoulson> we'll drop that from the archive before release
[11:17] <janimo> yes, it is that one
[11:17] <janimo> ok
[11:18] <janimo> chrisccoulson: what does nobinonly mean in the mozilla package names? I did not see that in other contexts
[11:18] <chrisccoulson> it means we've stripped out some binary files from the source tarball
[11:19] <janimo> thanks
[11:59] <phlax> hi can anyone tell me what the right way to overwrite an upstart .conf script is? If I use "alternatives" it seems the job is not recognised as the script is a symlink
[13:35] <pitti> sconklin: I published lucid/karmic kernels as well now; is there an update how to publish the pure security hardy/dapper updates?
[13:37] <pitti> sconklin: btw, the hardy kernel was misbuilt -- ERROR   linux 2.6.24-28.82 in hardy (linux_2.6.24.orig.tar.gz already exists in destination archive with different contents.)
[13:43] <Keybuk> jhunt: so, I've had an epic idea of epic epicness
[13:44] <jhunt> Keybuk: I'm all ears... err eyes!
[13:44] <Keybuk> it should help with the visualization part of the spec quite a bit
[13:45] <Keybuk> but it also helps massively with the event bridges
[13:45] <jhunt> gr8
[13:45] <jhunt> intrigued!
[13:45] <Keybuk> simply the idea is to export the start_on and stop_on trees as properties
[13:45] <Keybuk> using reverse polish notation, they'd be an array of variants, that would basically end up looking something like
[13:45] <Keybuk> start on = [ "AND", ["started", "dbus"], ["started", "apache"]]
[13:46] <jhunt> I like.
[13:46] <jhunt> :)
[13:46] <Keybuk> so for viz, you can just pull that array, and quickly see everything the job "depends" on
[13:46] <Keybuk> now, for bridges, this makes a big win too
[13:46] <Keybuk> bridge starts, walks the jobs and gets their start_on propeties
[13:46] <soren> That's not RPN.
[13:46] <soren> RRPN, perhaps :)
[13:47] <Keybuk> err, sorry, Polish
[13:47] <Keybuk> though RPN is what I mean to do, since that's easier to push back out to a tree
[13:47] <Keybuk> annnywayy
[13:47] <Keybuk> so let's say you wanted to do an inotify bridge
[13:48] <Keybuk> you need to know what filenames to look for, right?
[13:48]  * soren apologises for the interruption :)
[13:48] <Keybuk> but they're all tied up in the job configs
[13:48] <Keybuk> e.g. start on file-created /foo/bar
[13:48] <Keybuk> now the bridge just needs to make a D-Bus call to fetch all the stat_on properties
[13:49] <Keybuk> and it can trivially extract the events it's going to generate and know what files to listen for
[13:49] <ion> Nice
[13:49] <jhunt> +1!
[13:49] <Keybuk> so this does most of the "event match" stuff from 0.10, but in 0.6 :p
[13:51] <apw> cjwatson, could you remind me which bit of the installer does the 'if we have too little ram enable ram swap support'
[14:07] <mdz> cjwatson, pitti, the brainstorm review deadline is today, and I have all of them except amitk's
[14:07] <mdz> I haven't been able to track him down
[14:08] <mdz> kiko is trying to help put something together, but it would be great if you could help
[14:09] <kirkland> @pilot in
[14:10] <ScottK> doko: No need to worry about boost1.40 for the Python transition.  We should be ready to remove it be the end of the week.
[14:10] <pitti> mdz: what was his question?
[14:10] <mdz> pitti: power management in Linux :-/
[14:11] <mdz> a complex one
[14:11] <kirkland> dholbach: hmm, i did "@pilot in" but nothing happened
[14:11] <kirkland> dholbach: topic still the same
[14:17] <mterry> kirkland, odd, worked yesterday
[14:17] <kirkland> @pilot in
[14:17] <kirkland> mterry: ^
[14:17]  * mterry shrugs
[14:17] <pitti> !hello | pitti
[14:17] <pitti> at least ubottu seems to be alive
[14:17] <pitti> (got a /msg)
[14:18] <pitti> !pilot | pitti
[14:18] <pitti> !ask | pitti
[14:19] <Keybuk> jhunt: https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickFinishUpstart?action=diff&rev2=8&rev1=7
[14:19] <Keybuk> jhunt: I've added the "manual" stanza as an explicit extra work item to the spec because it deserves a unique definition outside of the disabling of jobs
[14:20] <Pici> kirkland: try again
[14:20] <Keybuk> jhunt: and I've added the start_on/stop_on bits as a dep of the visualization bits
[14:22] <Keybuk> do you want to check over what I've put to make sure it's right?
[14:27] <pitti> chrisccoulson: you said the other day that we want to drop xulrunner somehow?
[14:27] <pitti> chrisccoulson: I just tried to build OO.o in current natty, and it dies with
[14:27] <pitti> Please recompile Libxul with --enable-ldap or use --with-openldap.
[14:28] <pitti> chrisccoulson: do you know anything about that? was that changed recently?
[14:28] <chrisccoulson> hmmmm :/
[14:28] <chrisccoulson> i thought openoffice was just using the npapi headers
[14:28] <chrisccoulson> that sounds suspicious
[14:28] <chrisccoulson> do you know what openoffice is doing with it? i downloaded the source the othe day, but decided it would be too painful to even unpack it ;)
[14:29] <pitti> chrisccoulson: http://paste.ubuntu.com/541008/
[14:29] <pitti> chrisccoulson: not really, I'm afraid; it already took me over an hour to even get that far :)
[14:30] <kirkland> !pilot | kirkland
[14:30] <kirkland> !pilot
[14:30] <doko> chrisccoulson: openoffice.org-officebean, should be possible to disabled that
[14:31] <kirkland> @pilot in
[14:31] <kirkland> Pici: thanks, that worked
[14:31] <chrisccoulson> pitti - hmmm, i'm not sure how that ever worked then. --enable-ldap is tbird-specific, and firefox has no ldap code in it :/
[14:35] <pitti> doko, chrisccoulson: ok, I'll try --disable-ldap
[14:36] <chrisccoulson> thanks
[14:36] <chrisccoulson> if it needs ldap, then it needs to use thunderbird-dev instead
[14:36] <chrisccoulson> but that doesn't even have any pkg-config files, so it might be difficult to use that
[14:37] <ScottK> doko: Any idea about http://launchpadlibrarian.net/60320546/buildlog_ubuntu-natty-i386.python-dns_2.3.4-4build2_FAILEDTOBUILD.txt.gz
[14:44] <jhunt> Keybuk: thanks! looks good to me.
[14:45] <Keybuk> ok, coo
[14:45] <Keybuk> will add my other bits next then
[14:46] <chrisccoulson> pitti - oh, i really don't envy you today :)
[14:46] <chrisccoulson> i just unpacked OOo
[14:46] <chrisccoulson> ;)
[14:47] <pitti> chrisccoulson: if you want to build it, pull from lp:~pitti/openoffice/3.2.1-natty to get around the first few stumbling blocks
[14:49] <doko> ScottK: no, builds locally
[14:50] <ScottK> OK.
[14:50] <sconklin> pitti: thanks for publishing those, we'll take a look at Hardy. We're currently in discussion about how the pure security kernels will be handled - they'll get the same testing that security kernels in the past have gotten. It's not well documented, and we'll fix that. I'll keep you informed. In the past, the security team has published those.
[14:52] <chrisccoulson> pitti - are you sure you're not just missing a build-depends btw?
[14:52] <pitti> chrisccoulson: none that debian/control demands
[14:52] <chrisccoulson> "checking which LDAP SDK to use... Netscape/Mozilla" versus "checking which LDAP SDK to use... OpenLDAP" on the last build
[14:52] <pitti> chrisccoulson: I might have additional b-deps installed, of course
[14:52] <pitti> chrisccoulson: right, indeed
[14:53] <chrisccoulson> so, it just looks like it picks the wrong one, but i've got no idea how it works that out ;)
[14:54] <ScottK> doko: That package built on Debian Experimental with the most recent dh_python2 changes, so I'm really in doubt about where to look.
[15:00] <doko> pitti: http://launchpadlibrarian.net/60320147/buildlog_ubuntu-natty-i386.python-hildon_0.8.8-1ubuntu8_FAILEDTOBUILD.txt.gz
[15:00] <doko> which -dev package should have the dependency on libgdk-pixbuf2.0-dev ?
[15:00] <pitti> hildon? I think we should just remove that
[15:00] <pitti> nobody touched or cared about the hildon stack for ages
[15:00] <seb128> kklimonda was asking about that to mvo before
[15:00] <pitti> unless our mobile team still is intersted in it
[15:00] <seb128> I think they agree on dropping the only rdepends
[15:00] <seb128> which was udpate-manager-hildon
[15:00] <kklimonda> doko: it wont build, even after you add /usr/include/gdk-pixbuf-2.0 to setup.py, I've already tried and failed :)
[15:00] <kklimonda> yes
[15:01] <pitti> StevenK, lool, persia: ^ should we just remove the hildon bits?
[15:01] <kklimonda> I have reported bug 687353 and will subscribe archive admins when udpate-manager-hildon is gone
[15:01] <doko> kklimonda: thanks!
[15:01] <kklimonda> I've written some more rationale there
[15:01] <pitti> doko, chrisccoulson: ah, apparently my local --disable-ldap workaround at least got me to actually compiling bits \o/
[15:02] <pitti> (I won't upload it like that; seems I just have some additional package installed which made it want to use the wrong backend)
[15:05] <Keybuk> jhunt: the only thing I'm not sure about is the config name for the override files ;-)
[15:05] <Keybuk> I vaguely like the idea of naming them /etc/default/*.conf ;-)
[15:05] <Keybuk> ie. for /etc/init/apache.conf you could create /etc/default/apache.conf
[15:06] <Keybuk> or perhaps better, /etc/override/apache.conf
[15:06] <jhunt> Keybuk: or maybe even /etc/init/override/apache.conf?
[15:07] <Keybuk> the only problem with that latter is that an existing path of that name is already supported
[15:07] <Keybuk> it'd create a job called "override/apache.conf"
[15:07] <ion> /etc/init/apache.conf.override
[15:09] <jhunt> Keybuk, ion: yes - I had just assumed ".override": by having a different extension we might avoid confusion as it is very clear they are not (standard) .conf files purely from the name.
[15:09] <Keybuk> we appeared to have hit the second unsolved problem of computing
[15:09] <Keybuk> jhunt: yeah, I think that's probably best
[15:10] <Keybuk> and they are alphabetically greater than ".conf"
[15:10] <Keybuk> so they appear afterwards
[15:10] <Keybuk> ok, let's just go with that
[15:10] <Keybuk> I'm persuaded by the alphabeticalness
[15:10] <Keybuk> apache.conf
[15:10] <Keybuk> apache.override
[15:10] <Keybuk> dbus.conf
[15:10] <Keybuk> squid.conf
[15:10] <Keybuk> it looks ok
[15:12] <ion> aye
[15:14] <jhunt> cute. I guess if, when updating a package that supports upstart we detect that the .conf file on disk is different to the new .conf file in the package we're updating, assuming no existing .override, we could rename the .conf to .override to get the best of both worlds: keep the (new) .conf file, but retain the admins current behaviour? Or would that just be too crazy/weird?
[15:14]  * jhunt takes deep breath to recover.
[15:14] <mvo> I will kill update-manager-hildon with the next upload
[15:14] <Keybuk> a bit weird I think :p
[15:17] <ogra_ac> mvo, but how will i upgrade my ubuntu wrist watch then ?
[15:30] <doko> kklimonda: http://launchpadlibrarian.net/60320774/buildlog_ubuntu-natty-i386.python-visual_1%3A5.12-1.1build2_FAILEDTOBUILD.txt.gz
[15:30] <doko> in atkmm1.6 you didn't package the .la file. by intent?
[15:31] <tumbleweed> ScottK: re python-dns, the problem is that it doesn't BD on python-all (like dh_python2 packages should), and we have python2.6-minimal in our chroots
[15:31] <kklimonda> doko: once bug 662572 is fixed (there is a branch waiting for a sponsor) it can be rebuild
[15:31] <kklimonda> doko: yes, missing .la file is by design, we just have to rebuild gtkglextmm so it doesn't use it
[15:32] <doko> kklimonda: could you do that?
[15:32] <kklimonda> doko: I don't have upload rights yet :)
[15:32] <kklimonda> the branch is linked in the bug
[15:33] <kklimonda> and python-visual doesn't have to be changed in any way - it just have to be rebuild once new gtkglextmm is ready
[15:33] <ScottK> tumbleweed: Thanks.
[15:33] <doko> Riddell: thanks so much for your kdebindigs upload :-(
[15:34] <kklimonda> doko: you remind me of http://dilbert.com/2010-12-06/ ;)
[15:35] <doko> heh ...
[15:35] <doko> kklimonda: could you prepare a debdiff?
[15:36] <kklimonda> doko: sure
[15:41] <kklimonda> doko: attached to the bug
[15:55] <cdbs> doko, barry: Anyone of you working on bug #685177 ? I have a patch, can I go ahead and upload it?
[15:55] <barry> cdbs: i haven't gotten to it yet.  please upload a patch.  i'll review and test, but i cannot upload
[15:55] <barry> cdbs: thanks!
[15:56] <cdbs> barry: okay, I meant to say I can upload directly
[15:56] <barry> cdbs: ah cool.  if you're confident about the fix, jfdi :)
[15:56] <cdbs> barry: Testing via a test build, though it should work
[15:57] <doko> cdbs: yes, please go ahead
[15:57] <barry> cdbs: is it a patch upstream should be interested in?
[15:57] <xperia> hello to all. i am trying to build "swftools" on ubuntu but i get allways this error message here.
[15:57] <cdbs> barry: will forward
[15:57] <xperia> *** No rule to make target `xpdf-*tar.gz', needed by `xpdf/Gfx.cc'. Stop.
[15:57] <xperia> http://paste-bin.com/view/94604b8a
[15:57] <xperia> looks like maybe i a missing here some dev lib. can anybody help me resolving this problem.
[15:57] <cdbs> barry: yes, its a must-needed change
[15:59] <barry> cdbs: cool, thanks
[16:25] <Keybuk> jhunt: added the other bits now, have a read through
[16:25] <jhunt> Keybuk: thx, will do.
[16:25] <Keybuk> cjwatson just needs to add the plymouth stuff :p
[16:36] <micahg> janimo: it means that the binary components are removed
[16:36] <janimo> micahg: thanks, chris has answered that a while ago too :)
[16:37] <janimo> micahg: do you prefer getting patches for tb or shall I make an upload if I have changes?
[16:37] <janimo> there's an ARM FTBFS I am fixing
[16:37] <micahg> janimo: patches please
[16:37] <janimo> also I think libhal may not be needed as a dep
[16:37] <ScottK> pitti: Would you please rescore kde4libs.  I'd like to get it started on the slow archs asap to minimize failures due to archive skew.
[16:38] <janimo> micahg: simple diff or debdiff with changelog?
[16:38] <micahg> janimo: debdiff with changelog, or merge proposal into lp:thunderbird if you like
[16:39] <janimo> micahg: ok, thanks
[16:40] <didrocks> barry: hey
[16:40] <pitti> ScottK: done
[16:40] <didrocks> barry: I have an issue with dh_python/dh7 not taking care of what's needed when you have some python + autotools
[16:40] <ScottK> pitti: Thanks.
[16:41] <barry> didrocks: hi
[16:41] <didrocks> barry: I workarounded it badly and was looking for you to get a proper fix :)
[16:41] <ScottK> didrocks: Did you look at the new update that just hit today.
[16:41] <ScottK> There's some new capabilities in dh_python2 now.
[16:41] <didrocks> ScottK: oh really? No I didn't
[16:42] <barry> didrocks: what package?  but yeah, as ScottK says, the new dh_python2 could improve things
[16:42] <ScottK> didrocks: Now if you get your file into /pyshared, dh_python2 will automatically do the symlinking.
[16:42] <ScottK> That should simplify things.
[16:42] <didrocks> barry: it was compizconfig-python, branch is at lp:~compiz/compizconfig-python/ubuntu/
[16:43] <didrocks> I have already talked with ScottK about the override I had to do in debian/rules
[16:43] <didrocks> ScottK: hum, it's not related to the symlink in fact
[16:43] <ScottK> OK.
[16:43] <didrocks> but that's nice :)
[16:43] <ScottK> It was long enough ago I forgot what it was
[16:43] <didrocks> ScottK: so no more trigger for the symlinking? it was already doing that, isn't it?
[16:44] <didrocks> (as a postinst IIRC)
[16:44] <ScottK> No, it makes the symlinks at build time.
[16:44] <ScottK> postinst just does pycompile
[16:44] <barry> right, which is it's huge advantage
[16:45] <didrocks> oh, symlinks at build time now, nice! Did you check it didn't break my --prefix patches btw? :)
[16:46] <doko> --prefix patches?
[16:46] <ScottK> pitti: It still says kde4libs is build score is 2505.  Doesn't look rescored?
[16:46] <pitti> ScottK: oh, seems ubuntu-build didn't pick the latest version
[16:46] <didrocks> doko: yeah, for installing with python-support using cdbs in other path, like the /opt/extras.ubuntu.com/…
[16:47] <ScottK> pitti: I guess because the source isn't published yet?
[16:47] <doko> ScottK: rescored
[16:47] <ScottK> doko: Thanks.
[16:48] <didrocks> barry: so, I think my issue is still valid, I have to do that to avoid dh_auto_install to become confuse: http://bazaar.launchpad.net/~compiz/compizconfig-python/ubuntu/annotate/head:/debian/rules
[16:50] <barry> didrocks: sorry, i don't understand why you have to make this override?
[16:50] <pitti> ScottK: done now
[16:51] <ScottK> Thanks.
[16:51] <didrocks> barry: without it: http://paste.ubuntu.com/541058/
[16:55] <doko> is there even one kde package which does *not* fail to build?
[16:55] <barry> didrocks: huh.  weird
[16:56] <ScottK> doko: It's because they were all uploaded at once.  once kde4libs is built we'll retry them in order and they should be fine.
[16:56] <barry> didrocks: my stack is a bit deep at the moment, but if you want me to look at it, please make sure there's a bug open with a `python27` tag
[16:56] <didrocks> barry: ok, doing it right now, thanks :)
[16:57] <didrocks> barry: subscribing you as well?
[16:57] <barry> didrocks: yep, though i'll see it either way :)
[16:57] <didrocks> barry: ok ;)
[16:58] <doko> didrocks: what is the complete setup call?
[17:00] <barry> so, i guess my nipy local build is failing because, even though i'm using natty-i386, the host is still amd64, so the chroot is not a true i386 architecture?
[17:01] <barry> er, my nipy local build is *succeeding* where it fails on the buildds
[17:01] <doko> barry: do you use schroot?
[17:01] <barry> doko: yes
[17:01] <didrocks> doko: seems it tries to make install (it calls make -j1 install DESTDIR=/home/didrocks/work/compiz/compiz-config-python/build-area/compizconfig-python-0.9.2.1/debian/python-compizconfig)
[17:02] <doko> barry: add personality = linux32 to the config
[17:02] <doko> didrocks: and then?
[17:02] <barry> doko: it's got that already
[17:03] <didrocks> doko: well, the rest is the trace you got: http://paste.ubuntu.com/541064/
[17:03] <doko> didrocks: what is the call for the error message from line 8?
[17:04] <barry> but something is very strange because i can see it installing the i386 packages, even though the build log claims it's an amd64 build: nipy 0.1.2+20100526-2build1 (amd64)
[17:04] <BlackZ> kirkland: bug #685860: I'm not sure how kenvandine applied my debdiff but it has not any conflict (please review the attached debdiff instead)
[17:04] <didrocks> doko: you want me add some debug in setup.py? like print sys.args?
[17:05] <barry> maybe i need to blow away that chroot and rebuild it...
[17:05] <kenvandine> BlackZ, conflict?  i applied it to the bzr branch
[17:05] <BlackZ> kenvandine: as I said you yesterday it should be applied to the latest package available in Debian unstable
[17:06] <doko> kenvandine: any news about bug #684949?
[17:06] <doko> didrocks: no I would like to see the call itself (python setup.py --install ....)
[17:07] <janimo> stgraber: hello, mind if I take your build lightspark for armel WI ?
[17:08] <kenvandine> doko, i have it fixed in bzr, but it is blocked on a new dbusmenu
[17:08] <kenvandine> BlackZ, that is what i did, i just pushed the result to the source package branch
[17:08] <didrocks> doko: is there a way with dh7 to get you that?
[17:08] <BlackZ> kenvandine: well, I can cleanly apply the debdiff without any conflict to the Debian package
[17:09] <doko> pitti: ^^^ dh7
[17:09] <kenvandine> BlackZ, yeah, it applied cleanly for me too
[17:09] <kenvandine> and i pushed the result to bzr
[17:09] <BlackZ> kenvandine: I rarely use bzr to merge packages :)
[17:09] <kenvandine> built it in pbuilder and everything looked good
[17:09] <doko> kenvandine: who can I poke about dbusmenu?
[17:09] <kenvandine> me :)
[17:10] <kenvandine> doko, i am blocked on tedg though
[17:10] <kenvandine> but he is working on it as fast as he can
[17:10] <doko> kenvandine: desktop installability is now blocked on you ;)
[17:10] <kenvandine> doko, indeed :)
[17:10] <kenvandine> fun times
[17:11] <kenvandine> i like how tedg drops off after i mention him
[17:11] <janimo> micahg: any plans to change tbird packaging format to (quilt 3.0) sometime?
[17:11]  * barry -> lunch
[17:14] <BlackZ> kenvandine: do you mind if I remove the proposed bzr branch link from the bug report and ask the sponsors to review the debdiff, instead?
[17:14] <kenvandine> BlackZ, i guess
[17:14] <kenvandine> BlackZ, is there something wrong with it?
[17:16] <BlackZ> kenvandine: like I said up, I rarely use bzr to merge packages; I usually attach a debdiff (ubuntu -> debian) containing the merge, instead
[17:17] <kenvandine> sure, ok
[17:17] <kenvandine> either way works
[17:18] <kenvandine> i reviewed it and it looked good to me, just would rather someone more familiar with nfs actually upload it
[17:18] <BlackZ> kenvandine: yes, I see. Thanks a lot for your work, though :)
[17:19] <kklimonda> doko: gtkglextmm on powerpc has failed because gtkmm 2.22.0 still waits on atkmm1.6 to build - just saying so you don't waste time investigating it :)
[17:26] <GrueMaster> pitti: Ping - When will linux-image-2.6.35-903.19-omap4 be moved from proposed to maverick-updates & natty?  I did the testing for it 2 weeks ago now.
[17:26] <GrueMaster> Bug 673504
[17:33] <CarlFK> barry: does this look like a python 2.7 issue: /usr/lib/python2.6/dist-packages/GnomeCodecInstall/PackageWorker.py line 16: from aptdaemon.defer import inline_callbacks - there currently is no aptdaemon.defer in Natty.
[17:34] <pitti> GrueMaster: sorry, sconklin asked me to remove the remaining flavours in -proposed yesterday, as we are in a new round
[17:34] <CarlFK> issue = https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032224.html  " Some parts of the archive will be uninstallable or not upgradeable for a few days; please wait with upgrades until the rebuilds are done, and for the next two days, also avoid bug reports about upgrade problems. "
[17:34] <GrueMaster> Does this mean I have to retest yet again?  Come on.
[17:38] <pitti> GrueMaster: no, we don't; but the kernel team needs to reupload it
[17:39]  * GrueMaster is getting seriously frustrated with the inefficiency of the kernel sru processes.
[17:39] <GrueMaster> If this were an isolated incedent, we'd fix and move on.  This has happened to me now for going on 4 cycles.
[17:42] <SpamapS> Keybuk: + [scott] socket activation: TODO  .. .DONE yet? ;)
[17:43] <Keybuk> actually yes
[17:44] <Keybuk> it's been done for months, I just couldn't persuade the author to sign copyright assignment
[17:47] <GrueMaster> pitti: sconklin:  Could you guys figure out why the current process is broken?  I really don't like having to retest patches that should have been released (even if you say this one won't need retesting - inevitably it will).
[17:58] <smoser> smb, are you around ?
[18:04] <seb128> cjwatson, should libcanberra be in the desktop set?
[18:04] <SpamapS> Is there any way to get apt-cache rdepends to only show you Depends: and not Recommends: ?
[18:05] <seb128> SpamapS, --show-recommend=no?
[18:05] <ebroder> SpamapS: aptitude search ~D^my-package$ ? :)
[18:05] <seb128> SpamapS, --show--recommends
[18:05] <seb128> rather
[18:05] <doko> seb128: he's sick today
[18:05] <seb128> doko, ok thanks
[18:07]  * SpamapS should have rtfm'd .. oops ;)
[18:07] <SpamapS> thanks guys
[18:09] <seb128> cjwatson, same question for gobject-introspection
[18:10] <seb128> cjwatson, (just letting in the backlog, no hurry)
[18:19] <barry> sbuild is really confusing me.  i'm not sure if i've set something up wrong or this is the normal way it should work.  i rebuilt my natty i386 chroot it definitely has personality=linux32.  when it updates it pulls the i386 packages, but when it builds it claims the architecture is amd64.  why is that?
[18:21] <Keybuk> barry: dpkg doesn't check that kind of thing
[18:22] <Keybuk> it uses either dpkg --print-architecture
[18:22] <Keybuk> or gcc -dumpmachine
[18:22] <Keybuk> so if you have an amd64 chroot, you always get amd64 out, no matter what personality
[18:23] <barry> Keybuk: dpkg --p-a says i386; gcc -dumpmachine says i686-linux-gnu
[18:23] <Keybuk> oh, then no idea what sbuild is doing ;)
[18:23] <doko> barry: do you start sbuild with linux32?
[18:23] <ebroder> barry: What's uname -m?
[18:23] <Keybuk> dpkg will certainly build i386 things
[18:23] <ebroder> doko: You shouldn't have to if you set the personality right in the sbuild config file
[18:23] <barry> ebroder: uname -m says i686
[18:24] <ebroder> barry: Fascinating
[18:24] <barry> doko: [natty-i386] definitely has personality=linux32
[18:25] <barry> yes, if "fascinating" means damn perplexing ;)  let me try forcing sbuild -arch=i386
[18:26] <barry> well, that does make the sbuild log claim it's i386.  so maybe it's just ignoring the personality=linux32 in the conf file
[18:26] <barry> i suppose it could be a bug in sbuild
[18:27]  * barry files a bug
[18:27] <ebroder> barry: Were you using the -c argument to sbuild?
[18:27] <barry> ebroder: yep
[18:27] <ebroder> barry: Don't do that :-P. You want -d natty --arch i386
[18:27] <ebroder> And let sbuild figure out which chroot to use
[18:31] <barry> ebroder: okay!  thanks, that does seem to work.  command line options could be better (esp. with schroot -c ;)
[18:31] <ebroder> barry: Yeah, I don't know where I learned to use -d, but it wasn't from the manpage
[18:32] <barry> ebroder: yeah ;)
[18:44] <Keybuk> I know this is hyretical within Ubuntu
[18:44] <Keybuk> but I really prefer the GiT-style of branch submission where you clean up the branch first
[18:44] <Keybuk> and submit it in the form of nice atomic patches
[18:45] <Keybuk> rather than "here's a mess of commit logs"
[18:45] <ebroder> Keybuk: Agreed. Somebody should write bzr rebase -i
[18:46]  * apw prefers to think of that as 'every commit is sacred/history should be understandable' rather than bzr/git issue
[18:46] <ebroder> apw: Sure, except that bzr doesn't seem to have the tools to let me choose my philosophy
[18:47] <Keybuk> apw: I think the problem is that I can't see any benefit to history reflecting development process
[18:47] <Keybuk> six months later, it doesn't *matter* that you had three abortive attempts to get the patch to work, and eight paper bag commits to fix typos, missing ;s, build errors, etc.
[18:48] <apw> Keybuk, indeed i can't say i can see any point to thinking of all of history as sacred at all, but i am also not allowed to commit things which don't build ... so i have to think that way
[18:57] <Keybuk> hmm
[18:57] <Keybuk> I hate test suite failures
[18:58] <Keybuk> oh, I remember this one
[18:58] <Keybuk> this is a D-Bus regresson
[19:00] <Keybuk> doko: you realise the test you commented out was an actual BAD FAILURE right?
[19:00] <Keybuk> ie. rather than fix a bug that can cause kernel panics, you simply commented out the test case?
[19:00] <Keybuk> Missing The Point Of Test Suites
[19:09] <RoAkSoAx> mterry: howdy!! Ok, so talked to upstream and he said that only the libs are intended to be LGPL. So I'm presumming that some of the headers that say 2.1 should also be changed to 2
[19:20] <Keybuk> oh
[19:20] <Keybuk> guess who changed this code
[19:20] <Keybuk> fortunately the person who didn't bother to actually test their change didn't write an init daemon or something
[19:25] <mterry> RoAkSoAx, OK, so sounds like some bits need the 2.1 to be changed to 2 and some bits need the word Lesser inserted?  Those seem like important details to clear up
[19:30] <RoAkSoAx> mterry: yes! I'm currently waiting for upstream's response on how to move forward with this
[19:39] <doko> ScottK: I assume you will take care of obmenu yourself (control file still mentions 2.6)
[20:07] <RoAkSoAx> mterry: alright, figured it out. Upstream will review my patch
[20:07] <mterry> RoAkSoAx, nice
[20:07] <RoAkSoAx> mterry: will let you know when it's applied in Ubuntu ;)
[20:07] <mterry> k
[20:59] <ScottK> doko: Then it's unlikely to get fixed.
[20:59] <doko> ?
[21:06] <ScottK> doko: I'm not sure why you assume I'll do anything with it.
[21:07] <doko> ScottK: well, you're the maintainer?
[21:07] <ScottK> No.
[21:08] <doko> ahh, ok
[21:08] <ScottK> I fixed it for the 2.6 transition, but that was a LONG time ago.
[21:12] <ScottK> Currently my time for Python stuff is very limited.  My Ubuntu time is focused on trying to figure out how to get stable symbols for C++ packages with gcc4.5.  Unfortunately the only advice I got from the gcc maintainer was a pointer to a man page, so it's likely to be awhile before I get that sorted (if at all).
[21:21] <seb128> kirkland, hey
[21:21] <kirkland> seb128: howdy
[21:21] <kirkland> seb128: just about to step out to a meeting, what's up?
[21:22] <seb128> kirkland, I just wanted to comment on this indicator sponsoring you did
[21:22] <seb128> that's something that should be discussed with design
[21:22] <kirkland> seb128: oh?  hmm...
[21:22] <seb128> we don't usually change the default because one user disagrees with what has been selected for Ubuntu
[21:22] <seb128> I've asked ted to get some design input on this bug
[21:23] <kirkland> seb128: sorry, seemed like a sensible change;  shall i revert it, or would you like to?
[21:23] <seb128> but just for next time, you might want try to check with people working on the project, especially for canoncial projects
[21:23] <kirkland> seb128: okay, no problem
[21:23] <seb128> kirkland, let's say what dx people say
[21:23] <ScottK> Why especially for Canonical projects?
[21:24] <kirkland> seb128: what should I do with that upload?  revert the change?  leave as is?
[21:24] <seb128> ScottK, because we know we have responsive people on those
[21:24] <ScottK> Seems to me that's good advice for any packages with people regularly working on them.
[21:24] <seb128> kirkland, let it for now
[21:24] <ScottK> seb128: Those aren't the only ones for which that's true however.
[21:24] <seb128> kirkland, ted mentioned that showing the real name can be an issue in some countries when people don't like having their name displayed
[21:24] <seb128> ScottK, the wording I used was maybe not adapted sorry
[21:25] <kirkland> seb128: sure;  presumably those people wouldn't want their login/nickname displayed either?
[21:25] <seb128> ScottK, I meant "you can find easily somebody to check since it's coming from dx"
[21:25] <kirkland> seb128: in any case, sorry, I didn't realize this was controversial
[21:25] <seb128> kirkland, not sure but we probably want some discussions before changing defaults in any case
[21:25] <kirkland> seb128: i suppose we might talk to dholbach and figure out how we can filter controversial/design bugs out of the patch pilot queue
[21:26] <seb128> kirkland, nothing to be sorry about, thanks for review the patch ;-)
[21:26] <seb128> kirkland, well, they should still be in the queue
[21:26] <ebroder> seb128: I've noticed a handful of dx-sensitive issues in the queue. If you guys want to hoard those bugs (which I have no problem with, as long as they're actually going to get dealt with), it would be helpful for the DX team to comment *early*
[21:27] <seb128> kirkland, the pilot is there to let the contributor know that someone has been considering the work done so it's fine to subscribe the designers and to say that we need design input
[21:27] <kirkland> seb128: okay, no problem, i did test it here, and i wondered myself why my login was being used instead of my real name, so i really honestly thought it was perfectly straightforward
[21:28] <ebroder> https://code.launchpad.net/~udienz/ubuntu/maverick/light-themes/light-themes.fix549365/+merge/42840 is another good example
[21:28] <seb128> we could probably use a wiki note on what to do for design issues
[21:28] <seb128> like add an ayatana task
[21:28] <kirkland> seb128: yeah
[21:28] <seb128> I will check that with dholback and dx tomorrow
[21:28] <seb128> ebroder, indeed
[21:28] <ebroder> seb128: I think this issue is probably more generic than DX, but I'm not entirely sure how I think the net should be cast
[21:28] <seb128> we need to have a defined way to deal with those
[21:29] <seb128> right
[21:29] <ebroder> And I am a little bit worried about obstructing work to shrink the sponsorship queue
[21:29] <seb128> the goal is not to shring the queue
[21:29] <seb128> is to let people know their work is being considered
[21:30] <seb128> or that we care
[21:30] <seb128> it's fine to tell them the change needs design thinking
[21:30] <kirkland> seb128: agreed;  i just sent my results to the list, noting that
[21:30] <seb128> kirkland, thanks
[21:30]  * micahg thinks sponsors should be able to recognize something as controversial and ask the appropriate team
[21:31] <seb128> kirkland, thanks was an useful controversial upload ;-)
[21:31] <kirkland> seb128: np;  thanks for ping me in a friendly manner ;-)
[21:31] <seb128> we need to hit some of those cases to affine the rules
[21:31] <ebroder> seb128: Yes, but it's important that we don't switch from "ignoring patches" to "thanking people then ignoring patches". There's a balance out there somewhere
[21:31] <seb128> or at least document what to do in those cases
[21:31] <seb128> ebroder, indeed
[21:31] <micahg> ebroder: patch pilot is supposed to guide patches to the right place as well, not just sponsor
[21:31] <seb128> well it means we need a way to ask for design input
[21:32] <seb128> or for other people input
[21:32] <seb128> not only design
[21:32] <seb128> then to make sure the input comes in a timelined way
[21:32] <ebroder> Yeah, I think that's key
[21:36] <CarlFK> natty alt instller % done bar is jumping backwards
[21:36] <CarlFK> In whatever comes before "Select and install softwre" step.
[21:37] <CarlFK> i think it was "retrieving packages"
[21:39] <CarlFK> even if no one cares much about the graph (i don't), it might be a symptom of a real problem.  any suggestions on how I can get more details?
[21:40] <ebroder> CarlFK: I think what you're seeing is multiple stages of the installer, although I'm not sure
[21:46] <CarlFK> welp, whatever i was seeing, i don't see it on a 2nd run.
[21:58] <CarlFK> ah - it was "configure apt"  and it did it again, around 20 - 25%.
[22:07] <CarlFK> it jumped from 71% to 65%.
[22:10] <doko> seb128: any idea about the uninstallability of the thythmbox build dependencies?
[22:11] <seb128> doko, let me check
[22:24] <doko> must be something which went into the archive within the two last hours
[22:26] <seb128> doko, it's building on armel so not sure
[22:27] <doko> seb128: armel still has a backlog
[22:27] <doko> setting up a new chroot
[22:29] <seb128> doko, <robert_ancell> seb128,   libgirepository-1.0-1: Conflicts: libgirepository1.0-1 but 0.9.12+git20101124-0ubuntu2 is to be installed.
[22:30] <seb128> doko, python-gobject needs a rebuild
[22:30] <seb128> doing it
[22:40] <SpamapS> james_w: around?
[22:40] <james_w> hi SpamapS
[22:42] <SpamapS> james_w: looking at your bp api merge for the wi tracker
[22:43] <SpamapS> james_w: fails on bp's that don't have bugs associated
[22:43] <SpamapS> james_w: but I think thats easily solved
[22:43] <james_w> SpamapS, fails how?
[22:43] <james_w> ah, forgot to mention in the merge proposal
[22:44] <james_w> the bug links aren't exported on production yet
[22:44] <SpamapS> james_w: *ahh*
[22:44] <james_w> you can test by changing it to service_root=EDGE_SERVICE_ROOT.replace("qastaging", "")
[22:44] <SpamapS> james_w: I just did if lp and hasattr(bp, 'bugs'):
[22:44] <james_w> replace("edge", "qastaging") I mean
[22:44] <james_w> that's fine by me
[22:45] <doko> seb128: version too? libgirepository1.0-1 (>= 0.9.3)
[22:45] <james_w> it would obviously mean that bug links weren't counted as workitems until that change is deployed to production
[22:45] <SpamapS> james_w: ahh, that would be important. ;)
[22:45] <SpamapS> james_w: so thats coming very soon though, right?
[22:45] <seb128> doko, the naming changing to match the debian one
[22:45] <seb128> doko, which is -1.0
[22:46] <seb128> it has a provide
[22:46] <seb128> but provides are not versioned
[22:46] <james_w> SpamapS, the code is in trunk, it just needs a rollout, which can happen without downtime
[22:46] <james_w> SpamapS, I'm agitating to get it done sone
[22:46] <doko> ahh, ok
[22:47] <SpamapS> james_w: awesome. :) I'll note that in my review of the MP. Otherwise it seems to be working fine
[22:49] <james_w> SpamapS, great, thanks for the review
[22:51] <hallyn_> cjwatson: for a low priority ssh bug which was also filed against debian and has a trivial patch - should i bother to do a bzr merge proposal, or will you get that through the debian bug if/when it patches anyway?
[22:51] <hallyn_> (sorry, I still get confused about exactly how syncs from dbian generally happen for ubuntu-patched packages)
[22:59] <SpamapS> james_w: set it to Work in Progress.. we should review again when the LP change lands.
[22:59] <james_w> SpamapS, yes
[23:00] <james_w> SpamapS, could you look at my other branch? It is rather urgent for Linaro
[23:01] <SpamapS> james_w: oh right the alt project one. Totally forgot that
[23:02] <james_w> SpamapS, I assume you are in ~platform?
[23:02] <james_w> (on people.canonical.com)
[23:03] <SpamapS> james_w: yes
[23:03] <SpamapS> james_w: doing test run on natty right now.. then will try the new stuff. ;)
[23:03] <james_w> SpamapS, could you get me a crontab -l from there?
[23:03] <SpamapS> james_w: sure, standby
[23:09] <SpamapS> james_w: something's broken there
[23:10] <james_w> SpamapS, with my branch?
[23:10] <SpamapS> james_w: yes, I posted the error I got in the MP
[23:11] <SpamapS> james_w: looks fairly simple to resolve
[23:16] <barry> python-gobject is broken: http://launchpadlibrarian.net/60345542/buildlog_ubuntu-natty-i386.nipy_0.1.2%2B20100526-2build1ppa1_FAILEDTOBUILD.txt.gz
[23:19] <micahg> barry: a new version was just uploaded
[23:19] <james_w> SpamapS, please pull and try again
[23:19] <james_w> that'll teach me not to test fully after each merge
[23:20] <barry> micahg: cool, thanks
[23:36] <GrueMaster> pitti: sconklin:  I have tested linux-image-2.6.35-24-omap for bug 673509 and it passed.  I have updated the bug accordingly.  Please see that this gets into -updates so I don't have to test it again, thanks.
[23:50] <SpamapS> james_w: alright, merged and pushed
[23:50] <james_w> SpamapS, woop, thanks
[23:50] <SpamapS> james_w: did you need extra projects added to the configs for linaro too?
[23:50] <james_w> SpamapS, yes, but I'm just testing to make sure I request the right ones
[23:51] <SpamapS> james_w: alright. I think we need to put the configs in their own branch and let people edit those more readily than the code itself.
[23:51] <james_w> that would make sense