[00:04] <squarebracket> so the wacom kernel module is old... is there any way i can update it, or is that reserved for special people like core devs?
[00:05] <micahg> squarebracket: talk to the kernel team, I think someone else was trying to get that updated as well
[00:06] <squarebracket> no one is listening in -kernel :(
[00:06] <squarebracket> i will try to get in touch though, thanks.
[00:06] <micahg> squarebracket: it's off hours, maybe read the kernel ML threads (not sure if there are, but my guess is there would be)
[00:08] <squarebracket> micahg, what's not off hours? I will check for a ml, it would be sweet if it could be merged before the .1 release
[00:08] <micahg> j3su: https://wiki.ubuntu.com/UbuntuDevelopers <-- requirements for developers
[00:09] <micahg> squarebracket: I don't know if they're planning another release before .1, but I would think UTC 12:00 - UTC 18:00 is probably when someone would be available (overlap of US/EU timezones)
[00:11] <squarebracket> micahg, ah, thanks for the tip :) and i meant if it could be done -for- the .1 release. it seems like as good a time as any
[00:13] <micahg> squarebracket: UTC 09:00 - UTC 20:00 based on today's activity :)
[00:14] <squarebracket> micahg, thanks!
[06:26] <bilalakhtar> fabrice_sp: You there? I want to tell you something about that uswsusp merge
[06:27] <fabrice_sp> bilalakhtar, hmm, I only have 5 minutes
[06:28] <micahg> hi fabrice_sp, did you try doctrine on amd64?
[06:28] <fabrice_sp> micahg, my system is amd64, so yes
[06:28] <fabrice_sp> it FTBFS, right?
[06:29] <micahg> fabrice_sp: k, it works on i386 but not due to amd64 because of the badly written test
[06:29] <bilalakhtar> fabrice_sp: I want to tell you, the bugs you quoted in debian, exist in current version as well
[06:29] <fabrice_sp> micahg, is it fizable?
[06:29] <bilalakhtar> fabrice_sp: and, we need a merge and a few changes,because current version depends on splashy, which is NOT in maverick
[06:29] <micahg> fabrice_sp: not really, but it builds fine on i386
[06:30] <fabrice_sp> bilalakhtar, the debian tracker marked them as linked to the new version. Did you tried the actual version?
[06:30] <bilalakhtar> fabrice_sp: but there is a very small change between debian -1.1 and -1.2
[06:30] <fabrice_sp> bilalakhtar,explain that and resubscribe sponsors
[06:30] <fabrice_sp> another way could be fix the actual package
[06:30] <bilalakhtar> fabrice_sp: that would be feasable as well
[06:31] <fabrice_sp> actual package depends on usplash
[06:31] <fabrice_sp> no?
[06:31] <fabrice_sp> micahg, is it possible to disable tests on amd64?
[06:31] <bilalakhtar> fabrice_sp: debian package depends on splashy and so does (current) ubuntu
[06:31] <bilalakhtar> NO package depends on usplash
[06:31] <micahg> fabrice_sp: it's arch all
[06:32] <fabrice_sp> bilalakhtar, it's a suggest, so it's ok to keep it
[06:32] <bilalakhtar> fabrice_sp: after all, the new debian version fixes a bug in debian BTS
[06:32]  * bilalakhtar confirms fabrice_sp 's comment
[06:32] <fabrice_sp> micahg, really?
[06:32]  * fabrice_sp checks what happened in last build
[06:32] <micahg> fabrice_sp: yeah, it's just a collection of PHP livs
[06:32] <micahg> *libs
[06:33] <fabrice_sp> ok: I sjhould have build them in my i386 chroot then
[06:33] <micahg> fabrice_sp: I'll try to talk to upstream more about it so that it's actually fixed, the reason for the test was >32 bit integer stored in a 64bit db shouldn't fail
[06:33] <bilalakhtar> fabrice_sp: Even though debian package doesn't 'Depend' on splashy, in debian/rules, it is configured with --enable-splashy
[06:34] <bilalakhtar> fabrice_sp: ok, I will resubscribe sponsors
[06:34] <fabrice_sp> bilalakhtar, actual Ubuntu package don't do that
[06:34] <fabrice_sp> so first, try to justify why we need the Debian pacakge, and after, see what we can do
[06:34] <micahg> bilalakhtar: have you seen bug 568193
[06:34] <ubottu> Launchpad bug 568193 in splashy (Ubuntu) "[removal request] Splashy is uninstallable and incompatible with Lucid." [Undecided,Fix released] https://launchpad.net/bugs/568193
[06:34] <fabrice_sp> I'm still not sure we need something that corrupt ext4 partitions :-/
[06:35] <bilalakhtar> micahg: of course, I saw that long ago. That bug is the reason why this merge is a big halabaloo
[06:36] <fabrice_sp> we will shortly go into the FF period, so new versions has to be justified
[06:36] <fabrice_sp> (one week?)
[06:36] <micahg> 2 weeks
[06:36] <fabrice_sp> ok. not so short, then
[06:37] <fabrice_sp> about doctrine: not sure it's worth it, as the buildd will build it on i386...
[06:37] <micahg> fabrice_sp: right, at least as far as Ubuntu is concerned
[06:37] <fabrice_sp> yeah, exactly
[06:38] <micahg> fabrice_sp: k, will you be syncing or just acking?
[06:39] <fabrice_sp> right now, I'll fly to my work place :-)
[06:39] <fabrice_sp> I'll have a look this night
[06:39] <micahg> fabrice_sp: awesome :), thanks, no rush
[06:39] <fabrice_sp> (fly = I'm very late)
[06:39] <fabrice_sp> :-D
[06:39] <fabrice_sp> CU guys
[06:39] <micahg> fabrice_sp: sorry :-/
[06:39] <fabrice_sp> np ;-)
[06:43] <doctormo> I'm trying to work out how ubuntu manages to install dependencies at run-time, things like mp3 codec support in rythembox. I thought it was packagekit, but research seems to suggest not.
[06:43] <doctormo> Does anyone here have the answer?
[06:44] <RAOF> gnome-codec-install, IIRC.
[06:44] <persia> doctormo: You may find better fodder in -devel, but check the gnome-codec-install package
[06:44] <persia> I think gstreamer0.10-packagekit does the actual magic bits
[06:45] <doctormo> Hey persia, great to hear from you.
[06:45] <doctormo> Thanks RAOF, downloading the sources now.
[06:48] <doctormo> Looks like it's all running commands via popen. Not as elegant as I thought it would be though.
[06:49] <doctormo> Perhaps they're just waiting for packagekit to get there.
[06:53] <RAOF> It's not using aptdaemon?
[06:58] <persia> Not the codec bit: the rest of the default install stuff seems to do so.
[06:58] <bilalakhtar> persia: freeeeee ?
[06:59] <persia> bilalakhtar: How do you mean?  Certainly some of the codecs would fail to be free by some definitions.
[06:59] <bilalakhtar> persia: I mean, are you free (the opposite of busy) ?
[07:00] <persia> I've not cleared my TODO list in longer than I can remember, but I'm not opposed to accepting new items or reprioritising.  That said, I suspect you ask more of my time asking me this question, rather than a more general sort of request for assistance (or a directed one, if it requires me).
[07:01] <bilalakhtar> persia: go ahead with your task, you are a member of DMB, so I suppose my tasks will steal your time :)
[07:03] <persia> bilalakhtar: What do you seek to have done?  If something is blocking on me (or on a DMB member), I'd rather sort it sooner, in hopes you'll do something else on my list by coincidence.  If you need something from a class of folks, you'll surely do better to just request it, rather than hunting down each member of the class individually, and trying to find a time when they are subjectively unbusy.
[07:05] <bilalakhtar> persia: I wanted a bugfix sponsor, for package .... well...gwibber
[07:05] <bilalakhtar> leave it persia
[07:05] <bilalakhtar> I will seek it later
[07:05] <persia> bilalakhtar: I'm not even someone who can help with that :)  I'd recommend asking (generally, not a specific person) in #ubuntu-desktop
[07:06] <bilalakhtar> persia: ok, well, leave it
[07:06]  * bilalakhtar asskigns that task for 'later' in gtg
[07:07] <persia> Why?  Most of the -desktop crowd who can sponsor probably read backscroll.  Better to just leave a note there, and wait.  "later" might bring you back here, or you might ask me again :)
[07:08] <bilalakhtar> k
[07:35] <doctormo> bilalakhtar: http://doctormo.org/2010/07/26/how-to-ask-for-translations/ <- As the wise man said, don't ask to ask or risk being axed.
[07:38] <dholbach> good morning
[08:12] <Rhonda> doctormo: Did you hear anything from Paul Jaros with respect to my German translation of the howtoask? He sent me a mail excusing for criticising me but I have no clue what for or anything? :)
[08:13] <doctormo> Rhonda: I forwarded you that email
[08:13] <doctormo> Unless it was an email you didn't get, but he did.
[08:15] <doctormo> Rhonda: Basically he sent me an email with some corrections and fixes. I think mostly he thought you were too formal. But then again, I didn't want to get into it, I figured you would sort it out yourselves.
[08:23] <Rhonda> Hmm, must have missed that mail …
[08:25] <Rhonda> doctormo: I looked into my mail log, didn't reach my server, so it wasn't an accidental removal of the mail. Can you please forward it again?
[08:26] <doctormo> Rhonda: I just sent it again
[08:26] <Rhonda> I have to update the translation a bit anyway. For a start, need to get the beta font to see something, and I already found a string that is too long. :)
[08:26] <Rhonda> Right, got it this time. :)
[08:27] <doctormo> Heh I just added a depends feature to the next version of ground control, so when you press the Make PDF button, it prompts you to install inkscape, pdftk, gnome-doc-utils and the ubuntu font.
[08:28] <Rhonda> "press the Make PDF button"??!  :)
[08:28] <Rhonda> I don't see any "button" in my filesystem. ;)
[08:31] <RAOF> doctormo: Ah, if that's what you were after, you might want to look at sessiondaemon - it's an aptdaemon client that runs in the user's session and provides a PackageKit-session compatible dbus interface.
[08:32] <doctormo> RAOF: I had a look at the dbus interface, it seemed like a lot of work for the simple side feature I wanted to do.
[08:33] <doctormo> Rhonda: Yea it's a ground control thing, you'll notice that in the howtoask branch there is a .gcfunctions file, it tells the nautilus plugin what extra things can be done. Useful for "Build this" and "Make Release"
[08:33] <RAOF> Reasonable
[08:33] <doctormo> Because you can't be lazy without build scripts doing all your work for you :-D
[08:42] <Rhonda> doctormo: Oh, will open the directory with nautilus then :)
[08:42] <Rhonda> Hmm, maybe my nautilus is too old, I still don't find any button.
[08:47] <Rhonda> Anyway, doctormo? How to submit an update now properly? :)=
[08:53] <Rhonda> And I don't get the instructions on how to install the beta font. %-/
[08:57] <dholbach> who can I persuade to give a packaging training session on 12th Aug 12:00 UTC or 19th Aug 18:00 UTC or 26th Aug 0:00 UTC?
[09:01] <dholbach> maybe something about NBS, packaging from scratch, dh7, using bzr, finding stuff that needs to get done, etc?
[09:02]  * Rhonda would throw in "git" ;)
[09:03] <dholbach> Rhonda: for when can I sign you up?
[09:09] <ajmitch> Rhonda: you should know not to bite so easily :)
[09:10] <Rhonda> ajmitch: Hey, when sabdfl responses to that suggestion with "yes, it's so much more peaceful when you don't have to put up with all those collaborators. a few barriers go a long way!" I see that as a challenge. ;)
[09:10] <ajmitch> hehe
[09:11] <Rhonda> dholbach: If noone comes up with something more interesting I could do th 19th at 18:00
[09:12] <dholbach> Rhonda: about using git?
[09:12] <Rhonda> Yep.
[09:12] <dholbach> alright
[09:12] <ajmitch> pity none of those times are really good for me - midnight, lunchtime or 6AM
[09:12] <dholbach> I'll add it to the Packaging/Training wiki pgae for now, but will comment it out
[09:12] <dholbach> ajmitch: 0, 6, 12, 18 utc - none of them good for you?
[09:13] <dholbach> ajmitch: if you want 6 utc, I'm happy to take 12 utc instead
[09:13] <dholbach> ajmitch: what would you like to talk about?
[09:14] <ajmitch> 6 UTC is best, but I wouldn't have anything ready on by next week
[09:14] <dholbach> ok, september then :)
[09:14] <dholbach> ajmitch: what would you like to talk about? :-D
[09:15] <ajmitch> *maybe* using bzr if I'm familiar enough with it ;)
[09:15] <dholbach> ok cool
[09:16] <dholbach> there's been a few sessions about it already, so you can check what happened there
[09:16] <ajmitch> yeah, which is why I'm thinking that it's probably not needed to have yet another person trying to talk about it
[09:16] <dholbach> ajmitch, Rhonda: added both of you to https://wiki.ubuntu.com/Packaging/Training (but commented both out until you confirmed)
[09:16] <dholbach> ajmitch: I think it is
[09:16] <ajmitch> ok, thanks
[09:17] <dholbach> ajmitch: I think we could have weekly sessions about how to find and fix small bugs - we'd still have a lot of people who are interested and learn something new
[09:17] <dholbach> so it's no shame to not talk about something brand new
[09:17] <dholbach> ajmitch, Rhonda: thanks muchly!
[09:18]  * ajmitch would love to find out some actual details about using looms
[09:19] <Laney> wgrant: sorry to bug you again, but will you be able to fix that multidistrotools page? :)
[09:19]  * ajmitch was using the bzr brnches of ubuntu packages to get them ready for upload to debian today, looms may come in handy for keeping the changes separate
[09:24] <ajmitch> Laney: what's broken with it?
[09:24] <Rhonda> dholbach: Will have to look up git-buildpackage first, am absolutely not using it and it might make sense to also cover topgit, which I neither use. %-/
[09:25] <Laney> the sid information isn't correct
[09:25] <ajmitch> outdated?
[09:25] <Laney> possibly
[09:25] <dholbach> Rhonda: good luck :)
[09:26] <Rhonda> dholbach: I always can chicken out and just cover basic git usage, though. :P
[09:26] <carstenh> Rhonda: topgit packaging as it is used currently is broken by design
[09:26] <Rhonda> … and show off how good http://git.deb.at/ looks. :P
[09:26] <ajmitch> Rhonda: teach me how to use git-buildpackage properly & I'll be happy ;)
[09:28] <Rhonda> ajmitch: I am a bit in conflict with git-buildpackage because it only really works with upstream in the repository too, which doesn't work with upstream sources like wormux or wesnoth. :)
[09:28] <ajmitch> they're just too big to carry in git?
[09:29] <Rhonda> Absolutely unhandy to give people the chance for a "quick" clone to contribute.
[09:29] <ajmitch> agreed
[09:31] <Rhonda> It was tried with wormux for quite some time (which is smaller than wesnoth) and was abandoned again.
[09:32] <Rhonda> And given that I need the upstream tarball locally anyway for building I don't see any benefit of storing it in the repository also. It just explodes disk space and transfer rates.
[09:33] <ajmitch> iirc it took me about 3 hours to grab a bzr branch of a package once, when I was wanting to make a simple fix
[09:33] <carstenh> pristine-tar solves the "I need the upstream tarball locally anyway" problem
[09:35] <Rhonda> carstenh: With the (IMHO huge) drawback of have the diskspace exploded and the network filled with transfers for quick contributions.
[09:38] <Rhonda> I mean, for upstream projects like t-prot and beep I also did the complete upstream + pristine-tar approach. But it's just unhandy for anything bigger than a perl library.
[09:38] <carstenh> Rhonda: .git becomes bigger, but I don't see why it should cause more network traffic in cases where you need to build the package locally anyway and thus need to download the tar.gz or recreate it from git anyway
[09:38] <Rhonda> Sometimes one doesn't want/need to build the package locally.
[09:39] <Rhonda> dedicated build system with much more power than locally available. And vim's netrw isn't as convenient as being able to work locally, too.
[09:39] <carstenh> yes, but I did exclude this case in my argumentation and agree to your point ;)
[09:39] <Rhonda> pffft :)
=== nobawk- is now known as [nobawk]
=== menesis1 is now known as menesis
=== yofel_ is now known as yofel
[14:29] <Milanium> is http://revu.ubuntuwire.com/ still in use, because no one takes a look at my packages for >3 months
[14:30] <Rhonda> I'm not sure if it's meant to work that way, putting something up there, sit and wait.
[14:31] <Milanium> I also posted reports at launchpad.
[14:31] <Rhonda> It helps to get a bit more active like that. :)
[14:31] <geser> Milanium: we have a massive lack of reviewers, it's faster to get the package into Debian (and then sync to Ubuntu) than to find reviewers for your package on REVU
[14:32] <Rhonda> Milanium: And it also helps to have a more direct link instead of just the main page. :)
[14:32] <Milanium> http://revu.ubuntuwire.com/p/ignuit
[14:33] <Milanium> http://revu.ubuntuwire.com/p/gnocky
[14:33] <Milanium> are they okay to send to debian?
[14:34] <Rhonda> Hmm, those are new packages, so they need deeper checking.
[14:35] <RainCT> Milanium: http://revu.ubuntuwire.com/revu1-incoming/gnocky-1007281521/gnocky-0.0.7/debian/README.Debian uhm?
[14:36] <Rhonda> Milanium: Why a "+nmu" version for an "Initial release" upload?
[14:37] <Milanium> lintian told me to
[14:37] <Rhonda> Told you to what?
[14:37] <Milanium> just remove +nmu?
[14:37] <Milanium> it said +nmu is missing
[14:38] <bdrung> porthose: please don't forget to unsubscribe ubuntu-sponsors
[14:38] <Rhonda> Milanium: Rather you can put yourself into the Uploaders field, me thinks.
[14:39] <Rhonda> Milanium: Also, do not put the package name into the short description.
[14:39] <Rhonda> That might look like "gnocky - Gnocky - mobile phone manager" in the end.
[14:39] <Milanium> ok
[14:39] <Rhonda> … which for sure isn't what you intend it to be. ;)
[14:40] <juli_> geser, Hi!  what about Debian import freeze? how the new packages can be imported if import is frozen?
[14:43] <juli_> Rhonda, if you have a bit time could you please also take a look at http://revu.ubuntuwire.com/p/felix-osgi-obr and http://revu.ubuntuwire.com/p/felix-framework
[14:46] <Rhonda> Milanium: And I won't look at ignuit because it's source format 3.0, sorry. :P
[14:47] <Rhonda> Milanium: comment left in gnocky
[14:47] <Milanium> yes, linthian told me to...
[14:47] <Milanium> how do I revert source format 3.0?
[14:47] <Rhonda> told you what?
[14:48] <Rhonda> Maybe you misinterpreted lintian output. Please try to apply reasoning to lintian messages. It might be buggy or report on things that might be totally valid, and hint you in the wrong direction.
[14:48] <Rhonda> juli_: Sorry, I don't look at source format 3.0 packages.
[14:49] <juli_> Rhonda, I understood already but why? I can use 1.0 but 3.0 is more progressive as I read
[14:51] <Milanium> how do I switch from 3.0 to 1.0?
[14:52] <Rhonda> It's a bit of nuisance IMHO, like the forcing applying patches automaticly, which makes it a bit impractical for VCSes where one has to store the patches not twice, once in the files (if orig source is imported) and once in debian/patches/*
[14:53] <Rhonda> It isn't much more progressive to 1.0 + quilt, to be honest, and this is rather a reason why I stick with 1.0 + quilt when possible.
[14:53] <Rhonda> Milanium: quilt pop -a && rm -r .pc debian/source
[14:54] <Rhonda> But you shouldn't convert back to 1.0 just because I doesn't like it. :)
[14:54]  * Rhonda . o O ( especially not if that would mean more things to review for me.  %-/ )
[14:55] <juli_> Rhonda, thank for explanation.
[14:56] <juli_> Actually I have to upload about 4 new packages in Ubuntu to be able to update NetBeans to 6.9
[14:57] <juli_> Would someone help me with this? I really don't know how to do that because of lack of reviewers:(
[15:03] <juli_> will it really be easier to upload to debian and ask debian import freeze exception for sync?
[15:04] <Rhonda> It will be easier in the long run.
[15:05] <juli_> People want to see new NetBeans in Maverick: https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/595000
[15:05] <ubottu> Launchpad bug 595000 in netbeans (Ubuntu) "Netbeans 6.9 released" [Undecided,New]
[15:06] <juli_> so I have to be in hurry
[15:06] <Milanium> Warning! This package could not be extracted; there's no browsable directory for it on REVU. at http://revu.ubuntuwire.com/p/gnocky
[15:06] <Milanium> what have I done wrongly?
[15:07] <Rhonda> Used source format 3  :)
[15:07] <juli_> geser, dholbach, ttx If you have a minute, please, take a look  at http://revu.ubuntuwire.com/p/felix-osgi-obr and http://revu.ubuntuwire.com/p/felix-framework
[15:07] <Rhonda> From that point of view revu really looks pretty unmaintained, if you ask me.
[15:07] <geser> juli_: before Feature Freeze a sync can be easily requested, DebianImportFreeze stops only the automatic import
[15:08] <Rhonda> But hey, having a recent enough dpkg-dev on the system really requires magic so that dpkg-source -x works  %-)
[15:09] <juli_> geser, thanks. But I'm not sure it is easier to find uploaders in Debian:( and then ask for sync. If it really is I will try this way.
[15:09] <dholbach> geser: are you handling juli_'s request right now? I'm quite busy right now :-(
[15:11] <geser> Rhonda: if you manage to have a working dpkg backport for hardy on sparc then probably REVU would support v3 source packages properly
[15:11] <dholbach> sorry, misread
[15:15] <Rhonda> geser: Why not upgrade revu to lucid now that's the new LTS?
[15:16] <geser> does lucid run stable on sparc?
[15:16]  * Rhonda . o O ( maybe it's time to switch to Debian stable … )
[15:17] <geser> does Debian stable run stable on sparc?
[15:17] <Milanium> http://revu.ubuntuwire.com/p/ignuit is now ready
[15:18] <Rhonda> geser: AIUI yes, it does.
[15:19] <geser> if I remember correctly kernel stability issues on sparc prevented the upgrade to a more recent Ubuntu release. But I'm not involved with REVU administration so don't the details.
[15:19] <Milanium> http://revu.ubuntuwire.com/p/gnocky has been corrected, too
[15:19] <Rhonda> geser: Hmm, alright. Thanks for the update. But rmadison -u ubuntu dpkg tells me that hardy has amd64 and i386 only?
[15:21] <geser> rmadison lists only architectures on archive.u.c and not from ports.u.c
[15:21] <geser> I don't remember when sparc moved to ports
[15:22] <geser> looks like hardy on sparc was already on ports
[15:25] <Rhonda> geser: packages.ubuntu.com doesn't list them neither.
[15:26] <Rhonda> Hmm.
[15:26] <Rhonda> geser: I'd like to have that list adjusted and fixed. Like for http://packages.ubuntu.com/dpkg
[15:27] <Rhonda> If you can get me authoritative information on which architectures to list there, please let me know.
[15:27] <Rhonda> … though this would (again) involve pestering cjwatson to pester elmo to get a diff applied.
[15:27] <Rhonda> Because djpig is still a blackhole for me and hasn't reacted to repeated pings. But then, maybe I should stop caring like everyone else. :/
[15:29] <geser> I don't know either if ports should be included on packages.u.c or not
[15:29] <geser> I wish rmadison would also list ports architectures for Ubuntu (which would make it even more useful)
[15:31] <Rhonda> Hmm, rmadison doesn't that for Debian neither.
[15:31] <Rhonda> So I guess it's just along the same lines. But packages.u.c can list ports just like packages.d.o does.
[15:32] <Rhonda> geser: See e.g. http://packages.debian.org/irssi with respect to m58k
[15:32] <Rhonda> m68k
[15:36] <bdrung> geser: import-bug-from-debian lacks an man page
[15:36] <geser> bdrung: I know. Didn't found time yet to write one.
[15:37] <bdrung> geser: maybe ask Andrew?
[15:39] <geser> why not
[15:41] <bdrung> currently he is not here
[15:41] <jpds> Rhonda: sparc is not listed anywhere as it's not a supported arch.
[15:41] <jpds> sparc hasn't been supported since dapper.
[15:43] <Rhonda> Since packages.u.c seems to be such an abandoned service, I don't think that it would have any influence anyway.
[15:44] <jpds> Well, it uses Perl and Berkley DB, so yeah.
[15:44] <jpds> ;-)
[15:45] <geser> Rhonda: how much traffic/load does the software for packages.{u.c,d.o} consume/create? perhaps it could be moved somewhere else where an admin is easier reachable
[15:56] <geser> bdrung: re your r672 commit to u-d-t: why not use the Version class from python-debian (Version.upstream_version gives you what you want)
[15:57] <Rhonda> geser: I have no clue, to be honest, but I can ask the debian admins wether they have packages.d.o in their munin.
[15:57] <bdrung> geser: i wasn't aware of the existence. feel free to change it.
[15:57] <Rhonda> geser: And about "an admin is easier reachable" - I don't see that to change by moving the service to some other box, to be honest.
[15:58] <Rhonda> geser: Frank won't be easier reachable by moving the service. Adding additional responsible people (read: forming a team) would make them easier reachable.
[16:02] <geser> Rhonda: I had the idea to move it perhaps to ubuntuwire.com if we want to continue this service (and if you ask wgrant perhaps you could get even access to it)
=== asac_ is now known as asac
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
[18:39] <ari-tczew> geser: qa.ubuntu.com shows that you're core developer
[18:42] <geser> ari-tczew: I'm not; it's probably it's because I'm a member of DMB and the DMB is an admin of other teams which makes me an indirect member of those teams
[18:42] <ari-tczew> geser: hmm... so we got a bug
[18:42] <geser> ari-tczew: have you an link to a page where I'm listed as core-dev?
[18:43] <ari-tczew> geser: http://qa.ubuntu.com/reports/sponsoring/ last row right now
[18:46] <geser> git is not only in main, it's seems to be also in the ubuntu-desktop package set and as the DMB is an admin of ~ubuntu-desktop that makes me an indirect member of ~ubuntu-desktop and LP would let me upload it
[18:48] <geser> I'm aware of this problem (this only affects MOTUs in the DMB) and have to check that I don't use those privileges
[18:49] <ari-tczew> geser: I think you should report this issue to dholbach
[18:50] <tyarusso> Say, what file should contain commands to be run on a dpkg-reconfigure?  (I need to restart a service after reconfiguration.)
[18:51] <geser> ari-tczew: I doubt dholbach can do anything about it. This is how LP permissions get applied as team admins are also team members (this doesn't apply to team owners)
[18:52] <ari-tczew> aha
[18:56] <geser> tyarusso: postinst is run as part of dpkg-reconfigure
[18:56] <tyarusso> geser: okay, ty
[18:56] <tyarusso> ah, right - I redirected that the /dev/null so couldn't tell
[18:56]  * tyarusso tries to remember why
[18:57] <geser> tyarusso: add a comment when you remember for the next time
[18:58] <tyarusso> geser: I think it was something about not being noisy when using debconf, but I'm not really convinced it's actually necessary.
=== fta_ is now known as fta
[19:21] <ari-tczew> main component is crying due to lack of merges sponsoring
=== fta_ is now known as fta
[19:54] <ScottK> tyarusso: Redirecting to /dev/null is almost certainly working around another problem that ought to be solved.
[20:00] <tyarusso> ScottK: mmk, noted
[20:48] <ari-tczew> ttx: ping
[21:11] <ari-tczew> bdrung: could you check this? I need this very quick for merging and sync by archive admins is not going to game. bug 611034
[21:11] <ubottu> Launchpad bug 611034 in maven-repo-helper (Ubuntu) "Sync maven-repo-helper 1.2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/611034
[21:14] <bdrung> ari-tczew: i am on it
[21:16] <bdrung> ari-tczew: done
[21:16] <ari-tczew> bdrung: thanks! but I need second package synced. I'll give a bug number in 5 minutes, could you process it also?
[21:17] <bdrung> yes
[21:21] <ari-tczew> bdrung: ahh, your sponsored package needs to be build, so propably I'll request next sync tomorrow.
[21:22] <bdrung> ari-tczew: yes :)
[21:24] <BlackZ> bdrung: could you look at bug #554823 ?
[21:24] <ubottu> Launchpad bug 554823 in logrotate (Ubuntu) "Please merge logrotate 3.7.8-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/554823
[21:30] <bdrung> BlackZ: can i sponsor it tomorrow?
[21:32] <bdrung> BlackZ: i have to write a script that pulls a patch from launchpad and applies it. your bug could be a good test bug
[21:32] <BlackZ> bdrung: sure, when you have time. Will you remember that tomorrow or will I have to ping you?
[21:32] <bdrung> BlackZ: i'll assign myself to it
[21:40] <Sarvatt> bdrung: thanks for all of the sync sponsors by the way!
[21:41] <bdrung> Sarvatt: you are welcome
[21:41] <BlackZ> bdrung: it would be a nice script, feel free to try it with my bug
[21:42] <bdrung> BlackZ: it should be part of the review script collection
[21:42] <BlackZ> bdrung: agreed
[21:42] <bdrung> s/should/will/
[21:43] <bdrung> i am fighting against launchpad currently
[21:44] <BlackZ> bdrung: huh.. why?
[21:44] <bdrung> BlackZ: more specific: launchpadlib
[21:44] <BlackZ> bdrung: what's the problem?
[21:45] <bdrung> BlackZ: i try to improve the sponsoring overview, but it still throws errors at me and is totally slow
[21:46] <geser> bdrung: timeouts or other errors?
[21:46] <bdrung> geser: other errors
[21:46] <bdrung> geser: but in the worst case i have to wait 10 mins for the error
[21:46] <bdrung> it starts getting on my nerves
[21:48] <geser> does it happen at different places or always at the same package or bug?
[21:49] <ajmitch> launchpad people do like to hear about timeouts so that they can be fixed
[21:54] <bdrung> geser: that's my programming error, but to debug it, i have to wait to long. start it, wait, getting an error, fixing it, starting again, waiting, getting another error, ...
=== fta_ is now known as fta
[22:20] <bdrung> geser: now i have a restfulclient bug: http://paste.debian.net/81689/
=== fta_ is now known as fta
[22:24] <wgrant> bdrung: How's that a restfulclient bug?
[22:24] <wgrant> bdrung: 'ubuntu' isn't a series.
[22:24] <bdrung> wgrant: ok, then it's a launchpadlib issue
[22:24] <wgrant> bdrung: Howso?
[22:25] <wgrant> You're asking for something that doesn't exist, and it's giving you an error to tell you that.
[22:25] <bdrung> couldn't launchpadlib throw his own error?
[22:26] <wgrant> What do you mean?
[22:27] <ajmitch> do you mnean raising a useful exception rather than 400 bad request?
[22:27] <wgrant> It throws an exception with the error from Launchpad as content.
[22:27] <bdrung> ajmitch: yes
[22:27] <ajmitch> it'd require a bit of work in launchpadlib to create those extra exceptions to be raised, but I think it'd be possible
[22:28] <wgrant> Possible, perhaps.
[22:28] <wgrant> But to what end?
[22:28] <bdrung> wgrant: then i could catch the exception better
[22:29] <wgrant> That would require that all the possible exception classes were created upfront on every launchpadlib startup.
[22:29] <wgrant> That sound slow.
[22:30] <ajmitch> either that, or created when an exception is raised, which sounds messy
[22:30] <wgrant> ajmitch: But then you can't catch it.
[22:30] <ajmitch> true, that's a small problem :)
[22:32] <ajmitch> I imagine there could be quite a lot of possible exceptions to raise?
[22:34] <wgrant> Um, yes, just a few.
[23:53] <plars> I'm looking at a merge for a package, and it looks like everything that was in the ubuntu version has been picked up in some form or fashion by either the debian version of the package, or upstream, except for one minor change in the control file
[23:54] <Laney> what is the change?
[23:54] <plars> the version of the package for suggests and replaces is newer in the ubuntu version of the package than the debian version, and the changelog entry for it said that it was to facilitate a smoother update from intrepid
[23:54] <plars> I'm not sure I understand the reasoning for that, and whether it's really needed
[23:54] <plars> s/suggests/conflicts
[23:55] <Laney> no, kill it
[23:55] <plars> -Conflicts: xnee (<< 3)
[23:55] <plars> +Conflicts: xnee (<< 3.02-1)
[23:55] <Laney> there is no supported upgrade path from intrepid to maverick
[23:55] <plars> right, but was wondering if that needed to be updated to a newer version, such as the lucid version
[23:55] <plars> I was trying to understand how that helped with the update from intrepid
[23:59] <Laney> << 3 wouldn't have conflicted with the version in intrepid