[00:03] <tumbleweed> bdrung_: yes. no, not so mad about that
[00:05] <bdrung_> \o/ finally i can build audacity for unstable.
[00:08] <bdrung_> tumbleweed: thank you very much for the man page
[00:09] <tumbleweed> bdrung_: np
[00:11] <bdrung_> tumbleweed: what needs to be done for 'But there is a production-related bug: translate_web_api seems to require "staging" or "web" in the URL.'?
[00:13] <tumbleweed> bdrung_: I haven't looked into it properly yet, but translate_web_api looks like it expects either staging or edge, whoops not web
[00:25] <bdrung_> tumbleweed: does hugdaylist 0.101 work?
[00:29] <tumbleweed> bdrung_: yes, although it requires a .edge. URL (and only seems to support a very limited subset of lp buglist URLs)
[00:30] <bdrung_> tumbleweed: can we set edge for hugdaylist?
[00:30] <tumbleweed> bugs.e.l.n/ubuntu/+source/foo seems to work
[00:31] <tumbleweed> bdrung_: manage-credentials and massfile use that function too, so someone should probably work out what it does and fix it :)
[00:32] <bdrung_> tumbleweed: where is this function?
[00:32] <tumbleweed> ubuntutools/lp/libsupport.py
[00:33] <tumbleweed> I mean it's a simple enough function, I just haven't read everything that calls it (to find out why it does the checks it does)
[00:33] <bdrung_> tumbleweed: the fix seems trivial
[00:34] <tumbleweed> bdrung_: it should be, yes
[00:35] <bdrung_> tumbleweed: try this patch: http://pastebin.com/uSfB7F2L
[00:37] <tumbleweed> bdrung_: production URLs don't contain .production. (it doesn't work)
[00:38] <ari-tczew> if package is FTBFS and
[00:38] <ari-tczew> Debian has got a new version (includes new upstream release) and Debian package built fine, it's require a FFe?
[00:38] <ari-tczew> for sync
[00:38] <bdrung_> tumbleweed: let's ask for help in #launchpad
[00:39] <bdrung_> ari-tczew: main or universe?
[00:39] <ari-tczew> bdrung_: universe
[00:40] <bdrung_> ari-tczew: if it introduces new features, yes.
[00:43] <ScottK> ari-tczew: As bdrung_ says.  If it fixes FTBFS, then that will be a factor making it more likely to get approved.
[00:43] <ari-tczew> ok thanks ScottK and bdrung_
[00:44] <bdrung_> i should go to bed. i have closed the wrong bug in d/changelog
[00:47] <bdrung_> DktrKranz: u-d-t 0.103 is ready for upload once ubuntutools/lp/libsupport.py supports the production API in translate_web_api()
[00:47] <bdrung_> who wrote translate_web_api?
[00:52] <ari-tczew> I've uploaded a patch into bzr. do I need to run next command to build a package in maverick universe?
[00:53] <tumbleweed> bdrung_: bzr blame says jpds. This works: http://pastebin.com/vL2tUdxf
[00:56] <bdrung_> tumbleweed: what value has netloc on production?
[00:57] <tumbleweed> bdrung_: netloc = hostname (so bugs.launchpad.net)
[00:58] <bdrung_> tumbleweed: and launchpad._root_uri?
[00:58] <tumbleweed> https://api.launchpad.net/1.0/
[00:59] <bdrung_> tumbleweed: let's talk to the launchpad guys
[02:45] <kklimonda> hmm, why do some libraries add a -x.0 after name? like libgtk-x11-2.0.so or libcouchdb-glib-1.0?
[02:47] <persia> kklimonda, Hrm?  Could you be more verbose?
[02:47] <persia> My quick guess would be to allow libgtk-x11-2.1 to be installed in parallel.
[02:48] <kklimonda> persia: what is the point of adding a version of the library to its name
[02:48] <kklimonda> persia: it's what the version after .so is for, isn't it?
[02:48] <persia> Right, but different namespace.
[02:48] <kklimonda> you can have libgtk-x11.so.1 and libgtk-x11.so.2
[02:48] <persia> There's packaging namespace and filesystem namespace.
[02:48] <ajmitch> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg has some extra info in it
[02:48] <persia> (or libgtk-x11.so.2.1)
[02:49] <persia> ajmitch, Doesn't that just suggest naming the package to match upstream's SONAME choice?
[02:49] <kklimonda> persia: what namespace are you talking about?
[02:49] <ajmitch> persia: yes, in this case it is an upstream thing
[02:50] <persia> I'm unsure if it's a "bug", but yeah.
[02:50] <ajmitch> where they've decided to have some versioning in the library name
[02:50] <kklimonda> and the reason for it is.. ? :)
[02:51] <persia> kklimonda, So, lets assume we want to install libgtk-x11.  Let's further assume that we want to install two different versions.  Lastly, let's assume that for convenience sake, we want to have two different source packages (as the sources are wildly different).  How else do we manage this?
[02:51] <ajmitch> a way to show that two libraries are different in API as well as ABI?
[02:51] <persia> I think the reason upstream does this sort of thing is because upstream is thinking about packaging, rather than being normal upstream.
[02:51] <ajmitch> gtk+ 1.2 & 2.0 are quite different, so they name them differently
[02:52] <kklimonda> but from their perspective just using so.1.0 and so.2.0 would be enough - I agree that it would make it harder for package them in a sane way probably.
[02:53] <kklimonda> persia: source packages could be still gtk+2.0 and gtk+3.0 so the question would be how to name libgtk so it's clear what version they are.
[02:53] <persia> Right, so upstreams that do a lot of packaging sometimes do it the other way.  It's an upstream bug, but one we're not usually unhappy about them not fixing.
[02:54] <ajmitch> you can only have one .so symlink though
[02:54] <persia> kklimonda, true.  Feel free to fix the issues, if you have a clean solution.  Just make sure the fix works for all the downstreams of the upstream :)
[02:55] <kklimonda> persia: nah, I was just curious why is it done this way. Now I see some good reasons for doing it.
[02:55] <ajmitch> this is also a way to be able to build against multiple versions of the library on the system
[02:55] <persia> Which is critical if we wish to support multiple versions simultaneously.  We try to avoid that, but it's a massive amount of porting in some cases, and doesn't happen within a release cycle.
[02:56] <ajmitch> probably why gtk+ is the example being used
[02:56] <lifeless> did we just port the ud discussion here?:P
[02:56] <ajmitch> lifeless: not quite :)
[03:01] <persia> lifeless, The answers are similar.  The initial question was different :)
[03:02] <lifeless> 42Q
[03:02] <kklimonda> :)
[03:03]  * ajmitch hopes we haven't caused any heads to explode in here
[03:11] <ScottK> No.  Trying to figure out why you volunteered for ARB hurt my head more.
[05:59] <SpamapS> ScottK: around?
[06:03] <persia> SpamapS, timezone suggests it's getting rather late there
[06:03] <SpamapS> indeed
[06:03] <SpamapS> we're all a bit ghoulish though, aren't we?
[06:03] <persia> No.  Lots of folks who get up early and tuck in by 21:00 local around as well.
[06:20] <fabrice_sp> anyone has an idea why this FTBFS: https://launchpad.net/ubuntu/+source/fso-usaged/0.9.1.1+git20100507-1/+build/1745783 Everything is ok, and build successful....
[06:25] <kklimonda> fabrice_sp: Function `dbus_ipeer_dbus_proxy_new' implicitly converted to pointer at resource.c:1220
[06:26] <kklimonda> fabrice_sp: missing prototype probably.
[06:27] <kklimonda> it probably doesn't fail on i386 because this isn't fatal there but may be (or always is?) fatal on 64bit architecture
[06:32] <fabrice_sp> kklimonda, isn't it only a warning? What bugs me is that the build ends successfully but still appears as a FTBFS
[06:34] <persia> fabrice_sp, It's unsafe: at runtime, it may or may not crash, depending on environmental factors: You need to make sure your pointers are safe for 64-bit.
[06:34] <kklimonda> fabrice_sp: as I said, it's a potential error on amd64 and builder detects it and, as a result, fails a build
[06:35] <persia> On amd64, there's a chance it will work, but it will probably crash for most folk.  On other 64-bit architectures, it will almost certainly crash.
[06:36] <fabrice_sp> kklimonda, can you point me where in the build log it fails? I can't see it...
[06:36] <kklimonda> fabrice_sp: at the bottom of the log there is a message from builder :)
[06:36] <kklimonda> fabrice_sp: "Our automated build log filter detected the problem(s) above that will
[06:36] <kklimonda> likely cause your package to segfault on architectures where the size of
[06:36] <kklimonda> a pointer is greater than the size of an integer, such as ia64 and amd64"
[06:36] <fabrice_sp> ohhhhh
[06:36]  * fabrice_sp shouldn't work on FTBFS so early....
[06:37] <fabrice_sp> thanks! will have a look at this error later, then
[06:49] <persia> The other option is to only support i386/armel/powerpc, but some folk would be annoyed by that :)
[07:47] <Rhonda> The shadow for the headline lettering on planet ubuntu is really disturbing, frankly spoken. Whom to bug about potentially have that shadow not *that* far moved off?
[07:52] <Rhonda> 0.1em is a bit much for the bigger fonts.
[07:52] <persia> Probably email rt@ubuntu.com and hunt someone in #canonical-sysadmin
[07:53] <persia> You might find a useful tweakable in lp:~planet-ubuntu/config/main or lp:ubuntu-drupal-planet which you'd want to tweak first.
[07:54] <persia> https://launchpad.net/~ubuntu-drupal-devs/+members is a list of people to ask for commit if you have to change the latter
[10:41] <RainCT> hey dapal :)
[10:41] <dapal> RainCT: hey :)
[10:41] <dapal> RainCT: uhm, I should be sponsoring another thing from you..
[10:41] <dapal> RainCT: was that gnome-a-j ?
[10:42] <RainCT> dapal: Yup.
[10:42] <dapal> ack :)
[10:42] <dapal> fixed the 403? :P
[10:43] <RainCT> Yes
[11:21] <Riddell> tumbleweed: ping
[11:21] <Riddell> tumbleweed: why is bug 638879 reported on dgen but about ora2pg ?
[11:39] <Riddell> bdrung_: on bug 644667 you subscribed ubuntu-archive but the bug isn't confirmed
[11:40] <bdrung_> Riddell: Jonathan subscribed ubuntu-archive. you can unsubscribe ubuntu-archive until we get an ACK from ubuntu-release
[11:46] <Riddell> bdrung_: thanks done
[11:58] <tumbleweed> Riddell: wtf? no clue how that happened.
[12:00] <tumbleweed> bdrung_: I presume you saw my u-d-t fix. It's pretty much the same as the original.
[12:01] <Riddell> tumbleweed: so it's ora2pg to be removed and nothing done with dgen?
[12:02] <tumbleweed> Riddell: correct
[12:09] <Riddell> tumbleweed: done
[12:09] <bdrung_> tumbleweed: can you please check if staging still works?
[12:10] <bdrung_> tumbleweed: the if statement seems to inverted (was: if not (staging or edge), but now it's: if staging or edge)
[12:12] <tumbleweed> bdrung_: staging works. the check was to see that both URL and the launchpad instance were pointing at the same service (staging or edge) the problem with adding production is that you get hostnames like bugs.launchpad.net and edge.launchpad.net
[12:21] <micahg> if Debian has an foo-x | foo (> y) , and we don't have foo-x, we don't need to remove it from the depends list right, as long as foo (>y) will be fulfilled?
[12:21] <geser> correct
[12:21] <micahg> k, yay! I can get rid of another merge :)
[12:22] <micahg> I guess it made sense for Lucid since the upgrades might have been confused
[14:05] <ari-tczew> I'm sad due to watching it: https://launchpad.net/ubuntu/+source/libgdchart-gd2/0.11.5-7
[14:05] <ari-tczew> new MOTU member didn't test build before uploading :(
[14:06] <Laney> Also used syncpackage pointlessly.
[14:08] <ari-tczew> Laney: do we should warn Bhavani to avoid these cases in future?
[14:09] <mr_pouit> it's just a cdbs issue
[14:10] <Laney> ari-tczew: A gentle reminder might be a good idea. And this should be fixed.
[14:10] <Laney> mr_pouit: It doesn't matter what the issue is, packages should be tested before upload.
[14:10] <mr_pouit> maybe you should ask him *before* blaming him, don't you think?
[14:10] <ari-tczew> cjwatson: ^^
[14:11] <micahg> +1
[14:11] <Laney> I tested it myself :)
[14:11] <Laney> but I don't think anyone is being overly critical here
[14:11] <ari-tczew> everyone don't blaming him
[14:13] <directhex> can i blame someone? i do so enjoy blaming people for things
[14:13] <sistpoty|work> directhex: blame me, I can live with it :P
[14:14] <ari-tczew> people are too sensitive...
[14:15] <ari-tczew> please don't make a suicide in future
[14:15] <cjwatson> ari-tczew: why are you pinging me?
[14:15] <ari-tczew> cjwatson: due to Bhavani's mistake
[14:15] <cjwatson> what do you want me to do about it?
[14:16] <ari-tczew> cjwatson: only information. you approved him with a review
[14:16] <mr_pouit> sigh
[14:16] <cjwatson> ari-tczew: if you think the DMB should be aware of something, please mail our list (developer-membership-board@lists.ubuntu.com) rather than speaking to individual DMB members
[14:17] <geser> ari-tczew: please collect this kind of data if you stumble upon it (and if he improves over time or not) and let the DMB know in January when we re-evaluate his MOTUship
[14:17] <cjwatson> ari-tczew: unless you expect me to remember something until January and to be able to accurately pass on the information to the rest of the DMB
[14:18] <cjwatson> in which case you have a greatly inflated opinion of my memory ;-)
[14:18] <Laney> where are approval mails sent these days?
[14:19] <cjwatson> for developer approvals?  devel-permissions, ubuntu-devel-announce
[14:19] <Laney> I see DMB minutes but not individual approvals like there once were
[14:19] <Laney> maybe on -permissions though, didn't look there
[14:19] <geser> in theory devel-permissions, but in practice it's only mentioned in the minutes :(
[14:20] <Laney> would be nice if the meeting log were attached, too (I think mootbot does this?)
[14:20] <Laney> or a link
[14:40] <ari-tczew> Laney: http://irclogs.ubuntu.com/2010/09/14/%23ubuntu-meeting.html
[14:40] <Laney> thanks
[14:45] <wgrant> An interesting meeting.
[14:45] <wgrant> (although I was 15, not 16)
[14:58] <bdrung_> DktrKranz: u-d-t 0.103 is ready for upload to experimental (and it's lintian clean).
[15:01] <directhex> does pull-debian-source work with the new rmadison?
[15:02] <DktrKranz> bdrung_: will have a look later
[15:03] <bdrung_> directhex: i ran "pull-debian-source mozilla-devscripts" and it worked
[15:03] <bdrung_> DktrKranz: it has man pages (thanks to tumbleweed) and some more bugs fixed
[15:03] <DktrKranz> nice
[17:09] <DktrKranz> bdrung_: looking at ubuntu-dev-tools right now, final OK to upload?
[17:10] <bdrung_> DktrKranz: yes (unless you want to fix something from https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools)
[17:11] <bdrung_> DktrKranz: the requestsync bug list is quite long: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools?field.searchtext=requestsync
[17:12] <DktrKranz> I see
[17:15] <DktrKranz> bdrung_: uploading
[17:18] <bdrung_> DktrKranz: thanks
[17:19] <DktrKranz> bdrung_: from now on (well, not until projectb ACL table is updated), you can upload new revisions :)
[17:19] <bdrung_> :)
[17:21] <dandel> i have two bugs in backports that need some attention (64-bit issues)
[17:21] <DktrKranz> bdrung_: maybe FFe bug should be updated with latest changelog entry
[17:21] <dandel> also, i was redirected here from the ubuntu-bugs.
[17:25] <bdrung_> DktrKranz: done
[17:37] <geser> bdrung_: Hi, I've looked at some requestsync bugs and with some I don't have an idea what to do with them as they are not directly bugs in requestsync but only that requestsync doesn't catch the error if a LP API call fails.
[17:38] <geser> bug 531727, bug 528744 and bug 517866
[17:38] <geser> the first one could eventually be marked as duplicate of the one mentioned in my comment
[17:40] <bdrung_> geser: the fix would be to write a try...catch statement and tell the user what went wrong an give a propper formatted error message.
[17:48] <geser> yes, catching the error is easy but I'm not sure if just displaying the error message will be enough e.g. when an edited report gets lost and needs to be retyped
[17:49] <geser> and as the LP API doesn't fail often it's also hard to check if the fix realy fixes it
[17:50] <bdrung_> geser: depends on the situation where it fails. you can store the report or ask the user to retry.
[17:50] <dandel> bug 607505 and bug 585045 are in need of 64-bit testing packages (or in general updated packages)
[17:50] <bdrung_> dandel: vlc 1.1.4 is already there
[17:51] <dandel> it's not in the 64-bit repo tho
[17:51] <geser> bdrung_: will think about the bugs when I've some more free time again
[17:51] <dandel> bdrung_, anyways, these are backports requests.
[17:53] <bdrung_> dandel: i know. will ffmpeg 0.6 be backported? this would introduce new issues (for example audacity)
[17:54] <geser> bdrung_: do you know an easy way to check in python if a script is run with an UTF-8 locale? as that would allow to fix bug #553795
[17:55] <bdrung_> geser: no.
[17:55] <dandel> bdrung_, newer copies of vlc require ffmpeg 0.6 to enable hardware accelerated decoding
[17:56] <bdrung_> dandel: i have a patch at hand for backporting vlc without pulling other newer packages
[18:06] <DktrKranz> geser: something like python -c "import locale; print locale.getdefaultlocale()[1]" could be a start
[18:20] <neeraj> can I still file feature freeze exception?
[18:20] <neeraj> * for new upstream versons
[18:22] <bdrung_> neeraj: yes, but you have to provide a good reason for getting the exception
[18:23] <bdrung_> neeraj: main or universe package?
[18:23] <bdrung_> dandel: i gave my comment to the vlc backport
[18:25] <dandel> bdrung_, i use audacity and ffmpeg 0.6 and it has no issues.
[18:26] <bdrung_> dandel: try to use ffmpeg to export a file and you will see
[18:26] <bdrung_> dandel: i just fixed the problem with version 1.3.12-7 in maverick
[18:27] <neeraj> bdrung_: https://launchpad.net/ubuntu/+source/ubuntu-sugar-remix-meta (I think its main)
[18:27] <ScottK> It's not main.
[18:27] <bdrung_> neeraj: universe
[18:27] <bdrung_> neeraj: look at "Component"
[18:31] <lool> Hi folks
[18:32] <lool> Would an archive admin be so kind to look at syncing systemtap from experimental?  LP #645200 has the rationale
[18:32] <lool> basically the current version doesn't work wiht .35 kernels which is what we have in maverick; the new version is confirmed as fixed
[18:34] <sladen> if it's a case of the current functionality being non-existant (fundementally broken), but it seems a no-brainer to me since any upgrade is not going to be /worse/
[18:34] <lool> Yup
[18:35] <lool> apparently there was an incompatible change in the tracing interface of the kernel
[19:46] <jenkins> I am not able to get an answer from #ubuntu-packaging.I have a debian/copyright file but I am still getting the lithan tag "no-copyright-file" Any suggestions what could be causing it?
[20:15] <bdrung_> jenkins: can you show me the build log?
[20:16] <jenkins> bdrung_: the stuff in the terminal or is it a file that is generated?
[20:17] <bdrung_> jenkins: there will be a build log if you use debuild
[20:18] <jenkins> bdrung_: is this what you ment http://paste.ubuntu.com/498705/ ?
[20:19] <bdrung_> yes
[20:22] <bdrung_> jenkins: can you paste the content of debian/rules?
[20:23] <bdrung_> jenkins: found it: there is no dh_installdocs call
[20:23] <jenkins> thanks bdrung_ I will give that a go
[20:24] <jenkins> thats great bdrung_
[20:24] <bdrung_> you're welcome
[21:12] <micahg> SpamapS: I see you got mongodb to build :)
[22:00] <ari-tczew> micahg: does bug 645125 needs an ACK from release team?
[22:00] <micahg> ari-tczew: shouldn't, is there something in teh changelog that you think warrants an FFe?
[22:01] <ari-tczew> micahg: hmm, I'm thinking whether this sync is valuable.
[22:02] <micahg> ari-tczew: Documentation updates are valuable as they explain the past 2 updates
[22:03] <micahg> ari-tczew: translations are also valuable
[22:03] <ari-tczew> micahg: I said about release team, because I saw that bdrung_ subscribed ubuntu-release to bug 640682 where are not upstream release included, only bugfixes
[22:04] <micahg> ari-tczew: that's because it's in main
[22:05]  * ari-tczew is planning to clean up sponsors queue and start natty development with clear queue
[22:06] <micahg> ari-tczew: sponsors queue is pretty clean for universe
[22:06] <ari-tczew> micahg: I think also for main
[22:06] <micahg> ari-tczew: all main uploads require a release team ack
[22:06] <micahg> ari-tczew:  you can't do anything for main
[22:07] <ari-tczew> micahg: you don't understand me. as a member of ubuntu-sponsors, I can unsubscribe, if there are nothing to sponsor
[22:07] <micahg> ari-tczew: hmm, well, I guess you could go through then, but I don't think people are randomly subscribing -sponsors w/out something to sponsor
[22:09] <ari-tczew> micahg: ok, let's back to your request. what tests have you done with this package?
[22:09] <micahg> ari-tczew: should be a build log attached
[22:09] <micahg> ari-tczew: and it installed fine locally
[22:11] <bdrung_> ari-tczew: you are welcome to work on items that target main.
[22:12] <bdrung_> ari-tczew, micahg: there a lot that can be done. either unsubscribe if there nothing to sponsor, or make sure the patch applies, works, forward it to upstream (and after that pinging me to get it uploadad).
[22:13] <micahg> bdrung_: k, if that works, I'll can try to help with that as well
[22:13]  * micahg would also like to see and empty sponsors queue :)
[22:14] <ari-tczew> bdrung_: I would suggest you to review current syncs requests for main (fresh bugs)
[22:14] <bdrung_> micahg: yes. some bugs are there for very long. even reading them takes much time.
[22:15] <bdrung_> ari-tczew: probably most needs an ACK from ubuntu-release
[22:15] <ari-tczew> bdrung_: ah, yes. I forgot
[22:15] <micahg> bdrung_: one of my main requests won't go in until after maverick, am I better off unsubscribing -sponsors?
[22:15] <bdrung_> ari-tczew: everyone can subscribe ubuntu-release
[22:16] <bdrung_> micahg: that would be nice (and don't forget to subscribe -sponsors again once natty is open)
[22:16] <micahg> bdrung_: k, it's just a transitional package cleanup, can I assign myself or is that bad form?
[22:17] <bdrung_> micahg: you can assign yourself.
[22:17] <bdrung_> micahg: once it should be sponsored, unassign yourself
[22:18] <micahg> bdrung_: k
[22:18]  * micahg is off for now
[22:28] <Bachstelze> ari-tczew: what's the standard procedure for forwarding to Debian? For another bug, I just reported it on Debian's bug tracker and attached my Ubuntu patch, with no answer
[22:29] <bdrung_> Bachstelze: bug number?
[22:30] <Bachstelze> debian bug 594429
[22:30] <Bachstelze> oh never mind, there was an answer
[22:31] <Bachstelze> wonder why I didn't get an email
[22:31] <bdrung_> Bachstelze: because you have to subscribe to the bug to get all responses
[22:32] <bdrung_> Bachstelze: you could link the ubuntu bug to the debian bug
[22:33] <Bachstelze> I might get the same answer on the freeciv one ari-tczew said I should foward then, it's also fixed upstream
[22:34] <ari-tczew> Bachstelze: I understand, but Debian doesn't have packed latest upstream release, so you should forward changes.
[22:34] <ari-tczew> Bachstelze: also, you can request an upgrade to new upstream release
[22:35] <ari-tczew> Bachstelze: wiki: https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[22:36] <ari-tczew> saying easier: you can use script 'submittodebian' or create a new debian bug manually including your patch and information about changes.
[22:40] <ari-tczew> bdrung_: sync includes new upstream release. bug reporter wrote informations about FFe. does it still needs ACK from release team? package is in universe
[22:42] <bdrung_> ari-tczew: if (new feature) or (package in main): require ACK from release team
[22:44] <Bachstelze> okay, I'll do that tomorrow, it's almost midnight here :o
[22:47] <soren> pretto: /win 61
[22:47] <soren> Whoops
[23:03] <bdrung_> ari-tczew: here's a current sponsorship overview: http://people.ubuntu.com/~bdrung/sponsoring/
[23:03] <bdrung_> i have now an non-interactive script that updates this page
[23:06] <ari-tczew> bdrung_: I know, tumbleweed sent me yours and his page
[23:06] <bdrung_> ari-tczew: i just uploaded an update
[23:07] <bdrung_> ari-tczew: let me know when i should update the page
[23:09] <bdrung_> ari-tczew: bug #645019
[23:10] <ari-tczew> bdrung_: do you need run update manually?
[23:10] <bdrung_> ari-tczew: yes
[23:10] <bdrung_> ari-tczew: i hope that my fix will be merged soon
[23:11] <ari-tczew> bdrung_: why you ping me on this bug?
[23:11] <ari-tczew> bdrung_: hm, but dholbach's script runs update manually right?
[23:11] <ari-tczew> automatically * ^^
[23:11] <bdrung_> ari-tczew: because you processed this bug.
[23:12] <bdrung_> ari-tczew: the scripts on http://reports.qa.ubuntu.com/reports/sponsoring/ is run periodically, automatically, but due to a bug index.html is not created.
[23:13] <bdrung_> ari-tczew: i have made a fix and pushed the branch to get it merged
[23:13] <ari-tczew> bdrung_: aha I understand.
[23:26] <ari-tczew> bdrung_: for me you can now update
[23:26] <bdrung_> ari-tczew: update started
[23:27] <bdrung_> ari-tczew: there is one more reason for getting the queue empty: the sponsor-page script will be faster ;)
[23:28] <ari-tczew> :)
[23:31] <ari-tczew> bdrung_: I hope we will start natty with clean queue. I think that 30th October is at the latest deadline.
[23:32] <bdrung_> ari-tczew: do you have enough time for that? i want to reduce it to zero for over a year and you see the current situation...
[23:32] <ari-tczew> bdrung_: I have not many time, but I'll leave merging packages for take a look on sponsors queue.
[23:32] <bdrung_> ari-tczew: if you can process two or three request per day, it's doable
[23:34] <bdrung_> ari-tczew: i assume that i use 50 % of my time for sponsoring and 50 % for my packages this cycle. no time left to merge other packages...
[23:34] <bdrung_> ari-tczew: update run done
[23:36] <ari-tczew> bdrung_: coolbhavi told me that he is intersted in sponsoring for universe @natty devel cycle
[23:37] <bdrung_> ari-tczew: keeping the universe part of the queue short is not the problem.
[23:37] <bdrung_> ari-tczew: getting the backlog of main requests processed is.
[23:40] <ari-tczew> bdrung_: during natty devel I'll have less time due to last year in school.
[23:40] <bdrung_> ari-tczew: updating the sponsors list takes 5m13.325s
[23:41] <ari-tczew> bdrung_: and every update takes time and resources for still subscribed bugs
[23:42] <bdrung_> ari-tczew: yes, there is no real cache used
[23:43] <ari-tczew> bdrung_: maybe coolbhavi will help us to clean queue
[23:43] <bdrung_> ari-tczew: will you be at the UDS?
[23:44] <ari-tczew> bdrung_: unfortunately not :( and you? why ask? :)
[23:44] <bdrung_> ari-tczew: no (only remote). i think it would be useful to have a track about the sponsor queue
[23:47] <ari-tczew> aha