[02:22] <nhandler> Who should I talk to about an issue with lists.ubuntu.com?
[02:25] <ScottK> nhandler: Probably #canonical-sysadmin, but probably not this time of day.
[02:26] <nhandler> ScottK: What time would you suggest trying?
[02:26] <ScottK> European work day.
[02:28] <nhandler> Thanks for your help ScottK. I'll try and ask tomorrow before I leave the house for the day.
[03:09] <Hobbsee> anyone feel like doing some ISO testing?
[03:26] <ScottK-laptop> NCommander: wireshark uploaded.  Thank you for your contribution to Ubuntu.  Please send the Debian maintainer an appropriate note via BTS.
[03:27] <NCommander> ScottK-laptop: it FTBFS on Debian?
[03:27] <ScottK-laptop> NCommander: Dunno.
[05:08] <iulian> Good morning.
[05:15] <ScottK-laptop> Anyone noticed any changes in Launchpad since the updated it?
[05:15] <ScottK-laptop> I'm still waiting for the promised post on what's new.
[05:17] <nxvl> ScottK-laptop: there is already a post
[05:17] <ScottK-laptop> nxvl: Where?  The karma for code reviews one?
[05:18] <nxvl> and the where is everyone one
[05:18] <ScottK-laptop> That's it?
[05:18] <nxvl> ScottK-laptop: but, are you using edge?
[05:18] <ScottK-laptop> Not generally
[05:18] <nxvl> i mean, as in now that you don't find anything new
[05:19] <ScottK-laptop> I do sometimes, but the new fonts and stuff have been leaking onto regular pages for a while.
[05:19] <ScottK-laptop> I use edge if someone gives me an edge url, but that's it.
[05:20] <ScottK-laptop> Mind you, I consider the roll out a new version and I don't notice anything good news.
[05:20] <ScottK-laptop> It's pretty unusual for me to like the changes they do make.
[05:22] <slangasek> ScottK-laptop: the fonts are smaller now
[05:22] <slangasek> that's all I've noticed :)
[05:23] <nxvl> and you have a map on your profile (i have it long ago)
[05:23] <ScottK-laptop> Yes, the one that they thought it would be a good idea if everyone could move you around.
[05:23] <nxvl> heh
[05:24] <nxvl> yes
[05:24] <nxvl> :D
[05:24] <nxvl> it's horrible that other people can add your location
[05:24] <ScottK-laptop> OK, so we're they day before a significant release milestone and they take our major system development tool down to give us the essential new features of:
[05:24] <ScottK-laptop> 1.  New font
[05:24] <nxvl> but it's nice to see a map with the info of the people in each team's page
[05:24] <ScottK-laptop> 2.  Karma for functions rarely used in distro development
[05:24] <ScottK-laptop> 3.  A map.
[05:25] <ScottK-laptop> Glad to see all the important stuff's already fixed.
[05:26] <StevenK> ScottK-laptop: So they'll get more sarcastic remarks from you if they implement other new stuff rather than say, signed PPAs?
[05:28] <ScottK-laptop> Right.  Because we all know having maps in people's profiles is WAY more important than basic security.
[05:29] <ScottK-laptop> Fortunately parody and criticism are generally protected actions.
[05:29]  * ScottK-laptop just registered launchpadsucks.net
[05:29] <ScottK-laptop> So now the question is will I do anything with it.
[05:30] <jml> Incidentally, https://edge.launchpad.net/launchpad-project/+milestone/2.1.9 might give you a better picture of what's changed in this release.
[05:33] <ScottK-laptop> Well we have been repeatedly promised better notification of what's planned for Launchpad.  It continues not to happen.
[05:33] <ScottK-laptop> jml: What on that list has actually been implemented?  That's milestoned, not done.
[05:33] <jml> ScottK-laptop: everything with fix-committed was released today.
[05:34] <persia> jml: "Fix Released" as well?
[05:34] <ScottK-laptop> How are non-Launchpad people supposed to know that?
[05:34] <jml> ScottK-laptop: maybe some of the others too (and maybe there were unforeseen problems that mean some fix-committed's weren't released)
[05:34] <ScottK-laptop> So the page is inaccurate and irrelavant
[05:34] <jml> ScottK-laptop: we'll be updating them to fix released over the next couple of days.
[05:34] <jml> ScottK-laptop: ok. I was just trying to help.
[05:35] <jml> persia: sure, those too.
[05:35] <ScottK-laptop> jml: I understand that and it's not something personal towards you, but MOTU have been complaining for the two years I've been involved in the project that we are always suprised about what changes.
[05:35] <jml> persia: "Fix Committed" means 'in trunk' and "Fix Released" means on launchpad.net.
[05:36] <ScottK-laptop> jml: We get promises of advanced notice so we'll know what's coming, but with very few exceptions, it doesn't happen.
[05:36] <persia> jml: And the current skew related to release is the lack of automatic hooks to transition states with release?
[05:36] <jml> persia: partly.
[05:36] <persia> jml: I don't have enough information to file the bug that would fix that.  When you have some time, could you file it and subscribe me?
[05:36] <jml> persia: also, some of us like to make extra extra sure that a thing actually works before we mark it as 'fix released'
[05:37] <jml> persia: I think I might have sometime in my first week at Canonical :)
[05:37] <persia> Which bug?
[05:37]  * jml looks
[05:37] <jml> maybe I just complained about it :)
[05:37] <ScottK-laptop> Also some of those that are marked fix committed have been released for quite some time.
[05:37] <persia> Also, I think it'd be better to set "Fix Released", and then unset it to show that it was a regression in the Activity log, as a better means of communication.
[05:38] <ScottK-laptop> Bug 252469 was released last week if not the week before.
[05:40] <jml> ScottK-laptop: I find that difficult to believe -- maybe it was released on edge?
[05:40] <jml> persia: there's bug 41702, 163694 and 163696
[05:40] <ScottK-laptop> jml: I don't use edge except if someone gives me an edge url (not relevant for PPA use)
[05:41] <jml> ScottK-laptop: sure, but we didn't rollout two weeks ago :)
[05:41] <ScottK-laptop> Well I did a bunch of PPA test uploads over the weekend and that bug was fixed.
[05:42]  * jml shrugs
[05:43] <jml> persia: none of those are quite it. (except maybe 163694)
[05:43] <persia> jml: I think the distinction in 163694 is useful, but not used well for either LP or Ubuntu.  41702 would help with release, but it's more a need for a hook.  163696 is more about the milestone thing.
[05:44] <ScottK-laptop> OTOH, only a small fraction of the activity in this release appears to have a significant relationship with distro development anyway.
[05:44] <persia> jml: In Ubuntu, when someone uploads a patch, there is a means to mark it as fixing a bug.  When it is accepted and pushed to the public archives, Malone automatically marks the bug Fix Committed.  I'd like to see something similar for LP, but tuned to your workflow in some way.
[05:45] <persia> Note that the patch doesn't always actually fix the bug, in which case the bug is reopened.
[05:45] <jml> persia: all, well we have got bug 232429
[05:45] <jml> s/all/ahh/
[05:46] <persia> jml: Hrm.  That's close, but wouldn't that close them on VCS-commit, rather than on push to either edge or lpnet?
[05:47] <jml> persia: well, 'fix committed' when landed on trunk is already what we do, so this would automate it.
[05:47] <jml> persia: but then there needs to be a 'fix released' transition, probably when the revision appears in a series.
[05:47] <ScottK-laptop> jml: Which piece of Launchpad is responsible for the map and talking to Google about it?  i have a bug I want to make sure I get in the right place.
[05:48] <jml> ScottK-laptop: couldn't say. filing on 'launchpad' is a safe bet: it'll get triaged swiftly.
[05:48] <persia> jml: Yep, which is a combination of 163696 and 41702.
[05:48] <ScottK-laptop> OK.  That's what I'll do.
[05:49] <jml> persia: in general, that sort of stuff (although I would love it so much) is not currently a high priority for the code team.
[05:50] <persia> jml: Bugs are bugs.  Once there are bugs, priorities can be discussed.  Let's not dissuade bugs because of previously existing priorities.
[05:50] <jml> right :)
[05:50] <jml> persia: just giving you a heads up :)
[05:52] <ScottK-laptop> Looks like they managed to break the map thing when they released it somehow anyway.
[05:53] <ScottK-laptop> http://launchpadlibrarian.net/17714878/googleapi.png
[06:06] <fabrice_sp> Hi. Do I need a FFe if a package sync  fix a FTBFS in Intrepid? (Bug #258667)
[06:07] <slangasek> you need a FFe for things that break the freeze on features
[06:08] <slangasek> which may or may not be the case for a given sync
[06:09] <ScottK> fabrice_sp: How does syncing from Debian fix that problem?
[06:09] <ScottK> fabrice_sp: Also does the new upstream release have any new features in it?
[06:10] <ScottK> If the answer to the 2nd question is yes, then you need an FFe.
[06:10] <fabrice_sp> ScottK: Debian changed the dependencies in control file, so the package now builds successfully
[06:10] <ScottK> OK.
[06:11] <ScottK> So if it's just a bugfix release, then no, but if it has new features, then yes.
[06:11] <fabrice_sp> ScottK: OK: I'll have a look to upstream changelog, to check if there are new features
[06:47] <wgrant> I don't need to request a FFe for a release that has only one new feature that only affects BSDs, do I?
[06:49] <RAOF> I'm not really sure of the answer to that.  I'd lean towards 'yes', but not by much.
[06:50] <wgrant> It consists of adding '#if(n)def __FreeBSD__', basically.
[06:50] <persia> I'd say "no", as it doesn't include any user-visible features.
[06:50] <wgrant> The binary change for us will be zero.
[06:50] <RAOF> In which case, I'd say "no" :)
[06:51] <wgrant> Right, thanks.
[06:51] <RAOF> persia: Is FeatureFreeze about user visible features, or about minimising bugs (on the basis that new features are likely to be buggier)?
[06:51] <persia> RAOF: Yes.
[06:52] <persia> In this case, we're not even going to compile the code path with the new feature, so I don't see it being relevant.
[06:52] <RAOF> Right.  But in another case, if there was an extensive new feature which only applied to BSD, a FFe may be appropriate?
[06:52] <persia> I suppose it depends on the definition of "feature".
[06:53] <persia> To me, it means something the user is able to do with the software that they were previously unable to do, or did in a significantly different way.
[06:53] <persia> So, anything that doesn't change the behaviour of the application doesn't count as a feature to me.  That said, I'm not one of the people responsible for the official definition.
[07:03] <asomething> Hey, all. I've got a question on versioning. The package was synced from debian (0.5.6-1) then rebuilt due to a lib transition (0.5.6-1build1). What would be the correct version for a new ubuntu specific change. 0.5.6-1ubuntu1? dch -i suggests 0.5.6-1build2, but as it's not just another rebuild, that can't be right
[07:06] <ajmitch> -1ubuntu1
[07:06] <asomething> ajmitch:  thanks
[07:47] <Laibsch> good morning!
[07:47] <Laibsch> Why is it that dpkg-source on ubuntu includes .git and on debian it does not?  How can I get the debian command to include the .git directory?
[07:48] <persia> Laibsch: Does this apply to the same exact .dsc file?
[07:50] <Laibsch> persia: no .dsc file
[07:50] <Laibsch> I am trying to create those
[07:51] <Laibsch> "dpkg-source -b gnucash.git/"
[07:51] <Laibsch> On debian gnucash.git/.git/ will not be included in the orig.tar.gz that is being created by dpkg-source
[07:51] <Laibsch> on ubuntu it is included
[07:52] <persia> Oh.  Probably just a missing patch in Ubuntu then.  .git isn't supposed to be in there.
[07:52] <persia> Try using the -i -I options to make it go away.
[07:53] <\sh> crimsun: already in I just need to test
[07:55] <AnAnt> Hello, I'm almost done with the new version for sl-modem, but I dunno if it fixes all the bugs in Debian/Ubuntu or not
[07:56] <persia> AnAnt: While fixing *all* the bugs is always a goal, fixing many of the bugs is also good.
[07:57] <AnAnt> persia: well, I dunno if it fixes any of the bugs or not, I only know that it fixes the bug I encountered and the bugs saying please package the new upstream
[07:57] <AnAnt> but I think that I put it in good shape, it uses quilt now , making patch management easier
[07:58] <persia> You might try to get some users with the affected hardware to test the result.
[07:59] <Laibsch> persia: Actually, in my case, it is the other way round.  I want .git to be included
[07:59] <Laibsch> Although I understand that generally it should be excluded
[07:59] <AnAnt> great idea
[07:59] <AnAnt> how do I adopt a package in Debian ?
[08:00] <persia> Laibsch: Why?  Generally, if you want to track a VCS, you want to have a packaging VCS listed in debian/control, and if that is linked to an upstream VCS, that belongs in the packaging VCS, not in the orig.tar.gz.
[08:00] <persia> AnAnt: File an ITO bug against it.
[08:00] <persia> Err.  ITA.
[08:01] <Laibsch> persia: OK, let's see if that would work
[08:01] <Laibsch> do you have an example package config?
[08:01] <AnAnt> persia: I mean, to file an ITA bug, it should be filed against an existing (orphaning) bug or so, isn't it ?
[08:02] <persia> AnAnt: I'm not sure if you retitle the orphaning bug or if you file a new bug.  You probably want to ask in a Debian channel on OFTC.
[08:02] <AnAnt> ok
[08:02] <AnAnt> persia: do you know how I can find the orphaning bug ?
[08:03] <persia> AnAnt: I don't remember exactly.  I think it's a wnpp bug, but I'm not sure.
[08:24] <karooga> morning all.
[09:18] <Laibsch> persia: Unfortunately, I don't think that works
[09:18] <Laibsch> because of peculiarities in gnucash's build system
[09:18] <Laibsch> Without a .git or .svn directory, the build system goes into "tarball-mode", but tarball mode presumes a couple of files to present which are only created by "make dist".  make dist depends on ./configure having run.  ./configure is the file doing the switching between tarball mode and svn mode.  a vicious circle.
[09:18]  * persia has long ago lost any refrent for "that"
[09:19] <persia> Oh.  Can't you just patch that away, or have debian/rules call things in the right order?
[09:19] <Laibsch> I'd rather not reinvent the wheel
[09:19] <Laibsch> If all I need is just to get dpkg-source include a simple directory
[09:20] <Laibsch> This is not so much for release stuff as for regular testing of trunk
[09:20] <Laibsch> I'd rather have that packaged
[09:24] <persia> Yeah, but it's considered poor practice to have a VCS directory in the orig.tar.gz.
[09:24] <persia> You could always generate your orig.tar.gz by hand, with tar.  No restrictions there.
[09:25] <persia> Mind you, you'll probably get complaints about it if you ask anyone for review.
[09:34] <Laibsch> I'm probably not going to put this up for review
[09:34] <Laibsch> and yes, I could build the tar by hand
[09:34] <Laibsch> But I want to eliminate manual steps as much as possible
[09:34] <persia> Then script the manual tar creation :)
[09:34] <Laibsch> "git svn fetch;pdebuild" is really what I want to do
[09:36] <Laibsch> persia: Actually, creating the tar won't help
[09:36] <persia> Well, you could set debian/rules to work around the upstream broken build system, and then it's just `git svn fetch; debuild -S`
[09:36] <Laibsch> reason?  see above under vicious circle
[09:37] <persia> Yes.  This can be fixed.
[09:37] <Laibsch> how? please help
[09:37] <persia> Change ./configure to not do that.
[09:38] <Laibsch> well, eventually, I'll end up rewriting all of gnucash
[09:38] <persia> Certainly, but start with the bits that are causing you pain :)
[09:38] <Laibsch> which is not something I'm skilled enough to do although there are tons of things bothering me
[09:38] <Laibsch> persia: there is lots of things bothering me
[09:39] <Laibsch> and believe me, dpkg-source refusing to include a dir I absolutely want is causing me pain
[09:39] <Laibsch> and it would likely be much faster to fix than messing with gnucash
[09:39] <persia> Personally, if I just wanted to play with an upstream snapshot, I'd pull upstream VCS, and run make dist, and then build the source package.
[09:39] <Laibsch> persia: I'll want to do this regularly
[09:39] <persia> Yes, but you're not supposed to want that directory :p
[09:39] <Laibsch> Otherwise, I'd just not package stuff at all
[09:39] <Laibsch> which is also an option
[09:39] <persia> Sure.  ~/bin/update-gnucash:
[09:39] <persia> #! /bin/sh
[09:40] <persia> git svn fetch
[09:40] <persia> make dist
[09:40] <persia> debuild -S
[09:40] <Laibsch> nice thought
[09:40] <persia> ^D
[09:40] <Laibsch> your are missing something
[09:40] <Laibsch> that requires all build time deps
[09:40] <Laibsch> and I don't necessarily want that or can ensure that
[09:40] <persia> Then patch the build system to be sane.
[09:40] <Laibsch> on boxes I use for compiling but where I don't have root
[09:41] <persia> (and apt-get build-dep gnucash ought ensure that)
[09:41] <Laibsch> if you are root
[09:41] <persia> Sure, but how can you compile something if you aren't root?  For that matter, how can you run pbuilder if you aren't root?
[09:41] <Laibsch> sudo
[09:42] <persia> If you just need a chroot in which you have root, and you have access to pbuilder, use pbuilder --login or something.
[09:42] <persia> Then in the chroot, you can run apt-get build-dep gnucash.
[09:42] <persia> And do anything else you like.  At the end, you have a source package.
[09:42] <persia> You can even script the whole thing.
[09:42] <Laibsch> I still think it would be alot easier to get the dir included even if that is not good practice
[09:42] <Laibsch> and as far as broken is concerned
[09:43] <Laibsch> I guess ti is
[09:43] <Laibsch> but I cannot judge
[09:43] <Laibsch> and I don't think I can fix it
[09:43] <persia> Perhaps.  dpkg-source -b is *not* a recommended way to build source packages anyway.  While it sometimes works, it's prone to cause issues with unclean source.
[09:43] <Laibsch> the reason is to include only the minimal necessary information in the repo and autogenerate stuff
[09:44] <Laibsch> but quite likely their stuff is just plain weird and broken
[09:44] <Laibsch> they have too much of an ego and blurred vision to accept it oftentimes
[09:44] <Laibsch> unfortunately, I am without an alternative mostly
[09:45] <Laibsch> I have been trying to get this into usable shape for over a year now
[09:45] <persia> Right.  On the other hand, you now have root access to intrepid chroots on your build boxes, so you can work around them.
[09:45] <Laibsch> which is also the reason I want frequent builds from trunk
[09:47] <Laibsch> working inside pbuilder chroots is going to be major pain, too, I think
[09:47] <Laibsch> I don't mean to sound like a dork
[09:47] <Laibsch> But consider the following scenario
[09:47] <Laibsch> no root access whatsoever, not even via sudo pbuilder
[09:48]  * persia works almost exclusively within chroots, so may not be inclined to agree
[09:48] <Laibsch> but a launchpad account
[09:48] <Laibsch> if the build system where sane (or dpkg-source could be made to work the way I want it) the following would be possible
[09:49] <Laibsch> "git svn fetch;debuild -S"
[09:49] <Laibsch> upload the result to the launchpad autobuilders and be happy
[09:49] <Laibsch> with the stuff you are suggesting this will not work
[09:49] <Laibsch> which is why I don't consider it the proper thing
[09:50] <persia> I guess.  You could always abuse a PPA.  Create a fake source package that generates the source package you want.
[09:50] <persia> Essentially, you'd create a source package that contained the tarball from svn export.
[09:50] <persia> The debian/rules would unpack this source, debuild -S, grab the results, and install it in /usr/src.
[09:51] <persia> The resulting binary package would contain the source package you wanted, and you could upload that to your PPA.
[09:51] <persia> Just remember that your helper package needs to build-depend on everything required to build your source package.
[09:52] <persia> You also add a stanza to your helper package that automates the pull from svn, and creation of the upstream tarball to be put in a source package.
[09:52] <Laibsch> uff
[09:52] <Laibsch> sounds complicated
[09:52] <Laibsch> but possibly a solution
[09:52] <Laibsch> although I have not yet fully understood it
[09:52]  * RAOF is coming in late here.
[09:52] <RAOF> You want to build git snapshot packages, yes?
[09:53] <Laibsch> welcome ROAF
[09:53] <Laibsch> RAOF: sort of, but the situation is a bit complicated
[09:53]  * RAOF presses his one-button "update the nouveau ppa" script.
[09:53] <Laibsch> ROAF: I regularly want to package gnucash for personal use
[09:53]  * persia defers to RAOF, who tends to have better workarounds for this sort of thing
[09:54] <Laibsch> thanks, persia
[09:54] <Laibsch> ROAF: Without a .git or .svn directory, the build system goes into "tarball-mode", but tarball mode presumes a couple of files to present which are only created by "make dist".  make dist depends on ./configure having run.  ./configure is the file doing the switching between tarball mode and svn mode.  a vicious circle.
[09:54] <Laibsch> that is essentially the problem
[09:54] <RAOF> Urgh.
[09:55] <Laibsch> various solutions have been proposed, but they either plain don't work or don't do what I need
[09:55] <Laibsch> RAOF: exactly
[09:55] <RAOF> So, you can just keep the .git directory around.  Alternatively, you can work out what it looks for in the git directory, and fake it.
[09:55] <Laibsch> RAOF: I'd like to keep the git directory
[09:55] <RAOF> And possibly complain bitterly to upstream :)
[09:56] <Laibsch> They're deaf when it comes to complains
[09:56] <Laibsch> t
[09:56] <Laibsch> They've heard it for years
[09:56] <RAOF> Then keep the git directory.  It'll trigger at least one lintian warning, but your objective isn't an archive-ready package.
[09:56] <Laibsch> They believe it's right
[09:56] <Laibsch> ROAF: exactly
[09:56] <Laibsch> The problem is that I have two build machines
[09:57] <Laibsch> One is VERY slow and running ubuntu ;-)
[09:57] <Laibsch> dpkg-source apparently keeps the .git directory on that machine
[09:57] <Laibsch> I have another build machine, very fast and running debian
[09:58] <Laibsch> dpkg-source will not keep the .git directory, no matter what I do
[09:59] <Laibsch> on debian
[09:59] <persia> Laibsch: It's not safe to depend on the Ubuntu behaviour.  That will be patched away soon enough.
[09:59] <Laibsch> yes
[10:00] <RAOF> So, that appears to be the behaviour of "dpkg-source -i" - is that being passed?
[10:00] <Laibsch> which is why I'd be happy if ROAF knew about a way to force inclusion of the .git dir
[10:00] <Laibsch> RAOF: I tried with and without -i switch, no change
[10:00] <Laibsch> dpkg-source -iblahdeblah -b gnucash.git
[10:01] <Laibsch> .git not included
[10:01] <RAOF> What version source package is it?  1.0?  3.0?
[10:02] <Laibsch> there is some mention of 1.0, I believe
[10:02] <Laibsch> How do I check or change?
[10:02] <Laibsch> dpkg-source: info: using source format `1.0'
[10:03] <RAOF> Right.  So... dunno.
[10:03] <Laibsch> dpkg-source on ubuntu says nothing
[10:04] <RAOF> You could always hack around it by moving .git to reallygit and then moving it back at the start of the build.
[10:29] <pythonic> hi.. i'm filing a Needs Packaging bug.. how do i answer "in what package did you find this bug?"
[10:31] <persia> pythonic: Leave it blank.
[10:32] <pythonic> k. and just the package description in the "further information" field?
[10:33] <persia> And license and upstream link, and what not.  There's a good example on the wiki.
[10:37] <Hobbsee> \sh: is 271392 fixed for f-nonfree now too?
[10:37] <\sh> bug 271392
[10:37] <\sh> Hobbsee: yes...
[10:37] <\sh> bah...I missed that
[10:37] <Hobbsee> \sh: cool :)
[10:38] <\sh> bah the flashplugin...that wasn't the problem...and now I have to close them manually
[10:39] <Hobbsee> \sh: only some of them are that issue
[10:39]  * Hobbsee marks one invalid, due to using a non-ubuntu package.
[10:40] <\sh> Hobbsee: na...
[10:40] <\sh> Hobbsee: if it's the new flashplayer-plugin with the list of libs...just mark them fix released...new flashplayer10 will come in time
[10:40] <Hobbsee> \sh: there's a debconf thing for others.
[10:41]  * Hobbsee dupes a few.
[10:42] <elky> Hobbsee, see -devel plzkthx
[10:43] <stdin> ^ was just about to poke Hobbsee about that ^
[10:43] <Hobbsee> elky: the lawyer questions?
[10:43] <Hobbsee> oh
[10:43] <elky> no, the idiot
[10:43] <Hobbsee> helps when i scroll down
[10:43] <elky> yep
[10:46] <Hobbsee> \sh: out of general curiosity, why didn't you use libxcb-render-util0?  it contains the library it's whining about.
[10:46] <\sh> Hobbsee: I used it
[10:46] <\sh> Hobbsee: it's in ubuntu13 now
[10:47] <Hobbsee> \sh: ah right.  For some reason, I only checked what I currently had installed.
[10:47]  * Hobbsee is still trying to delve through this list of bugs, which really should be on the iso tracker.
[10:48] <\sh> Hobbsee: ubuntu13 just reached the buildds imho..and should be available soon on the mirrors
[10:48] <Hobbsee> \sh: great :)
[10:48] <\sh> it's really a beast
[10:50] <\sh> Hobbsee: bug #270358 is a nice one
[10:57] <Laibsch> OK, I was actually successful in making the gnucash build system believe it was being compiled from svn
[10:57] <Laibsch> now I hit the next bug
[10:57] <Laibsch> http://rafb.net/p/gs728n29.html
[10:58] <Laibsch> How come pbuilder gets a permission denied for "mkdir -p /usr/share/gnucash"?  It should be running inside its chroot with full root privs?
[11:01] <Laibsch> line 26f
[11:02] <azeem> Laibsch: it shouldn't
[11:02] <azeem> I wonder why gnucash would want to create that directory during configure-stamp
[11:02] <\sh> shouldn't be  the right dir : $DESTDIR/usr/share/gnucash when building through debian/rules?
[11:02] <Laibsch> well, the build system of gnucash is strange
[11:03] <Laibsch> \sh: I thought of that
[11:03] <\sh> Laibsch: can you pastebin the debian/rules?
[11:03] <Laibsch> sure
[11:04] <Laibsch> it is a variation of the official debian debian/rules
[11:04] <Laibsch> \sh: http://rafb.net/p/dTngIM26.html
[11:06] <azeem>  mkdir -p /usr/share/gnucash
[11:06] <\sh> Laibsch: try: mkdir -p `pwd`/debian/temp/usr/share/gnucash :) in line 29 of your paste
[11:06] <azeem> that is wrong
[11:06] <\sh> Laibsch: try: mkdir -p `pwd`/debian/tmp/usr/share/gnucash :) in line 29 of your paste
[11:06] <azeem> Laibsch: why did you need to add it at that point anyway?
[11:06] <\sh> that's better
[11:10] <Hobbsee> \sh: that's been reopened, too :-\
[11:11] <\sh> Hobbsee: you mean this lib32cap1 thingy?
[11:11] <Hobbsee> \sh: yeah
[11:11] <Laibsch> actually, that was a left-over from previous troubleshooting :-)
[11:11] <\sh> Hobbsee: I set it to invalid yesterday...and I wrote also now something to him, for explanation...
[11:12] <verwilst> hi emgent
[11:12] <verwilst> i will send you the email ;)
[12:44] <Laney> What the
[12:44] <Laney> Someone is marking needs-packaging bugs as affecting feisty/gutsy-backports
[12:44] <Hobbsee> Laney: ....interesting.
[12:47] <wgrant> What's wrong with that?
[12:52] <persia> While I don't see any issue with having a needs-packaging bug affect backports, I'd think the best path forward was to get the packaging done before trying to test a backport.
[12:56] <Laney> There's nothing to backport - he reported the n-p bugs yesterday and made them affect backports too
[12:56] <Laney> It's spammed me with a lot of bugmail
[12:58] <persia> Yeah, if there's nothing to backport, it's probably premature.
[12:59] <Laney> http://img168.imageshack.us/img168/6177/bmhp9.png
[13:07] <therealjosh> Hello, I have recently created an application, its in GTK and its a budgeting program. I was thinking of trying to get it into jaunty as i knew intrepid was frozen. I was told to ask here.
[13:11] <\sh> motu-release: please take a peak on ubuntu-devel...pls...and say what you think about a UVE for flashplugin-nonfree :)
[13:12] <Hobbsee> \sh: erk.
[13:12] <\sh> Hobbsee: erk=no, erk=I don't care, erk=yes? ,)
[13:13] <Hobbsee> \sh: how much does it fix, vs how much does it break?
[13:14] <\sh> Hobbsee: with ia32-libs in place...it works...the new version is rc2 ... so we need to get the final through -updates after intrepid release
[13:14] <\sh> Hobbsee: but for now...we should push rc2 to intrepid...
[13:15] <Hobbsee> \sh: i think that would be reasonable + would agree in principle to the final in -updates - although I have little (read:  no) control there.
[13:21] <\sh> hobbsee: I'll do some UVE magic on LP ;) should -release decide :)
[13:48] <pochu> is there any script to know if any/what dependencies of a package are in multiverse?
[13:50] <Laney> My god, a whole page of emails from that guy
[14:01] <persia> pochu: You may find the debcheck output useful for some packages, although not all.
[14:01] <persia> pochu: The other trick is to set up an apt-cache without multiverse, and try to install the package.
[14:01] <psyke83> hi, I converted bug #257403 into a FFe request, can someone let me know if I need to provide additional information in the report?
[14:04] <pochu> persia: I've done an 'apt-cache madison `list of packages` | grep -v main | grep -v universe. Thanks for your suggestion anyway
[14:04] <persia> pochu: That works too :)
[14:06] <ScottK-laptop> pochu: That won't get build-deps.
[14:13] <persia> ScottK-laptop: It depends on how `list of packages` is generated.
[14:13] <ScottK-laptop> True.
[15:12] <pochu> ScottK-laptop: unless `list of packages` contains both depends and build-depends ;)
[15:13] <ScottK-laptop> Right.
[15:26] <norsetto> pochu: re. bug 268914: if the whole purpose is to move this (and other stuff) to universe just patch it so, no need to update it
[15:31] <Laibsch> In what variable is the topdir of the source code to be ompiled stored in pbuilder?
[15:32] <Laibsch> I need to "cd $topdir;$do_something;cd -"
[15:32] <Laibsch> looking for the right string for $topdir
[15:34] <RainCT> Laibsch: $(CURDIR)
[15:35] <RainCT> (not sure if that's what you mean)
[15:35] <RainCT> s/mean/ask for
[15:38] <Laibsch> thanks
[15:40] <Laibsch> RainCT: Is $CURDIR exported to called processes such as a batch script?
[15:47] <persia> pochu: Also, we're trying not to have any more Java MoveToMain bugs for intrepid.  There's still 10 in the pipeline, and the release team is likely to start having more critical things to chase.
[15:54] <slytherin> persia: pochu: norsetto: I will patch the ubuntu version itself. I haven't got enough time in last few days. Should find some time on weekend.
[15:55] <persia> slytherin: Sorry.  Didn't know it was one of the listed bugs (I should check the list next time)
[15:56] <slytherin> no issues.
[15:57] <norsetto> slytherin: thx
[15:58] <pochu> btw I have no interest in them, I just ACK'd a sync request which changelog entry said it was moved to main in Debian, so I checked if it could be moved in Ubuntu too but it was blocked by 268914, so I left a comment there for completeness
[15:59] <pochu> s/which/whose/ ?
[16:01] <RainCT> Laibsch: $(CURDIR) is available in debian/rules, if you call scripts from there then no, unless you pass it to them or include them into the current environment (by prepeding a ". " to the call)
[16:06] <ScottK-laptop> persia: I've read the Java multiverse -> universe bugs and support them, but have very limited time before I leave on vacation tomorrow.  Feel free to copy/paste this into each of them as my motu-release ack for those bugs.
[16:06] <persia> ScottK: I'll review which of the MoveToMain bugs were also FFe bugs, and paste.  Thanks!
[16:07] <persia> ScottK: Also, as I'll likely be asleep when you go: have a good vacation.
[16:08] <ScottK-laptop> Thanks.
[16:09] <Lamba> where is the correct place to request the motu team look into making a deb of some code ?
[16:10] <Lamba> i see there's debs for ebox and 3-4 of its modules, but the ebox cvs has code for several others. one in particular, the soap module, would be handy in the ubuntu repos
[16:11] <ScottK-laptop> Lamba: For Ebox, #ubuntu-server is probably the best place to discuss it.
[16:11] <Lamba> rgr.
[17:54] <iulian> Hmm, why don't you guys delete the revu-uploaders team from launchpad if it's not useful anymore?
[17:55] <persia> Well, it could conceivably become useful again.  Let's wait until LP OpenID is working cleanly for everything before we drop it.
[17:58] <iulian> Yea... that's an idea.
[17:58] <Laibsch> maybe some of you remember my previous trouble with "mkdir -p /usr/share/gnucash/doc" in pbuilder?  I am trying to build gnucash from svn in pbuilder which is a bitch because of some of gnucash's peculiarities in the build system.
[17:58] <Laibsch> I got a couple of steps further, but now I am back at the point I was trying to troubleshoot before wrt mkdir
[17:59] <Laibsch> http://rafb.net/p/jsPLbs44.html is the diff for my rules file to the one from the debian maintainer
[18:00] <Laibsch> http://oss.leggewie.org/wip/pbuilder.log is the output from pbuilder
[18:01] <Laibsch> And there it is again
[18:01] <Laibsch> test -z "/usr/share/gnucash/doc" || /bin/mkdir -p "/usr/share/gnucash/doc" /bin/mkdir: cannot create directory `/usr/share/gnucash': Permission denied
[18:01] <Laibsch> How can that happen?  Isn't pbuilder running as root?
[18:03] <Laibsch> why isn't the released package running into that problem (I tried that one with pbuilder and it completed fine as expected)?
[18:04] <Laibsch> I grepped through the svn source but found no reference to install-exec-am
[18:04] <azeem> Laibsch: I told you, it isn't running as root
[18:04] <Laibsch> Oh, it isn't?
[18:04] <azeem> eh
[18:04] <azeem> 19:02 < azeem> Laibsch: I told you, it isn't running as root
[18:04] <Laibsch> OK, sorry I missed that
[18:04] <azeem> you're not allowed to create any files outside the directory where your source is
[18:05] <stdin> isn't $DESTDIR set?
[18:05] <Laibsch> I'm not sure
[18:05] <Laibsch> I'd like to inspect the unpacked and configured source
[18:06] <stdin> for the install rule, it should run "make install DESTDIR=<path to debian/package-name>"
[18:06] <azeem> suspend the pbuilder process so you got time to investigate, maybe
[18:23] <Laibsch> http://rafb.net/p/6Ccsjn41.html is the Makefile.  line 501 looks OK to me.
[18:23] <Laibsch> So I wonder if DESTDIR is correctly set
[18:23] <azeem> you have to set it
[18:23] <Laibsch> Where?
[18:23] <azeem> Laibsch: in debian/rules
[18:24] <azeem> Laibsch: did you read the packaging guide?
[18:24] <Laibsch> and why is that not necessary for the released package?
[18:24] <Laibsch> azeem: Did you ever read it completely?
[18:24] <Laibsch> To answer your question
[18:24] <Laibsch> I never sat down to read it from a to z
[18:24] <Laibsch> But I have looked things up frequently
[18:24] <Laibsch> but I am no makefile guru
[18:24] <azeem> +       LIBRARY_PATH=`pwd`/debian/tmp/usr/lib/gnucash:`pwd`/debian/tmp/usr/lib/gnucash/gnucash make install DESTDIR=`pwd`/debian/tmp
[18:25] <azeem> that is in the Debian diff at least
[18:25] <azeem> not sure which source you were basing on
[18:25] <Laibsch> I was taking the debian directory from the released package and made some changes to it to make it compile from svn
[18:26] <azeem> Laibsch: make a debdiff between your version and the released package
[18:26] <Laibsch> as stated, http://rafb.net/p/jsPLbs44.html is the diff between my rules file and the one from Thomas Buschnell
[18:27] <azeem> do you still have the build log?
[18:32] <tuxmaniac> heya gang
[18:32]  * tuxmaniac reports back after a really long time.
[18:47] <persia> tuxmaniac: How is the new timezone?
[18:47] <tuxmaniac> persia: cool. its switzerland :-) getting settled in the univ and the place
[18:49] <tuxmaniac> i will be back with a bang again shortly. /me has met several gnu/linux folks here. In fact right on the first day there were these bunch of guys calling themselves gnu generation handing out ubuntu cds :-)
[18:50] <persia> Excellent news indeed :)
[18:51] <tuxmaniac> so expect a Swiss Bug jam shortly. :-)
[18:52] <directhex> i'd prefer a swiss roll
[18:54] <\sh> tuxmaniac: if you have time, just visit germany and especially karlsruhe ;) only a couple of hours by car away from you now in .ch ;)
[18:55] <tuxmaniac> \sh: sure. I will be visiting folks at Hildesheim (close to Hanover) in a couple of months. will buzz you then ;-)
[18:55] <\sh> tuxmaniac: hannover is just 4.5 hours away from me, far more north ;) you could stop at karlsruhe first ;)
[19:04] <fabrice_sp> Hi. Can someone check Bug #271630, to see if I missed something for a FFe request? Thanks.
[19:05] <Laibsch> azeem: does http://oss.leggewie.org/wip/pbuilder.log have what you are looking for?
[19:07] <directhex> when is the time to start worrying, w.r.t. missing intrepid, if a package hasn't been updated?
[19:08] <\sh> directhex: on release day
[19:08] <directhex> O_o
[19:12] <geser> fabrice_sp: you missed the diff of the (upstream) CHANGES, the build log, install log and a summary of the testing you have done
[19:13] <geser> fabrice_sp: I'm not sure if KDE3 will stay in intrepid, so will the package build and work with KDE4 too?
[19:13] <fabrice_sp> geser: The upgraded one, yes. The older one, no
[19:14] <fabrice_sp> But There is another bug (bug #258667) that prevent installation because of missing kcontrol
[19:15] <geser> fabrice_sp: I'm asking because the new Debian changelog for 0.7.11-1 mentions a build-dependency on kdelib4-dev which is KDE3 stuff
[19:16] <Laibsch> azeem: I don't think the debdiff makes much sense.  It is 91M in size, mostly due to the underlying source.  Can I make a debdiff of just the debian directory?
[19:16] <fabrice_sp> geser: I successfully built the new package in Intrepid (not the old one)
[19:16] <fabrice_sp> geser: So I should try with dependencies on kdelibs5-dev?
[19:16] <\sh> NCommander: did you succeed with a fix for ggz-grubby?
[19:16] <geser> fabrice_sp: I believe you, some KDE3 packages are still available but I don't know for how long
[19:17] <fabrice_sp> geser: (in case KDE3 doesn't stay in Intrepid)?
[19:17] <geser> fabrice_sp: I don't know if it's that easy
[19:17] <\sh> fabrice_sp: there is only a small portion of kde3 in intrepid...
[19:18] <geser> \sh: do you know the plans for KDE3 in interpid? will it get removed completely?
[19:18] <\sh> fabrice_sp: and I wonder if kwave can live with this small portion...I wouldn't think so...does kwave has some kde4 source available?
[19:18] <\sh> geser: no...some packages like kdelibs4 are still used for (guessing knetwork manager?)
[19:19] <NCommander> \sh: no, sorry
[19:19] <NCommander> I'll look onto attacking that at some point this weekend
[19:19] <fabrice_sp> geser & \sh: it seems that upstream is not available anymore (this is the last available version from upstream)
[19:19] <fabrice_sp> (no answer since 6 month according to Debian log)
[19:20] <\sh> fabrice_sp: talk to riddell about a removal of that stuff then...if they come back, we can include the package again...but we should get rid of this stuff (using kde3) ;()
[19:21] <Laibsch> http://oss.leggewie.org/wip/debdiff-debian.txt is the 91M debdiff filtered down to what applies to debian/ with filterdiff.  azeem, looks unsuspicious to me
[19:21] <\sh> NCommander: no worries...
[19:22] <\sh> 91M debdiff?
[19:22] <fabrice_sp> \sh: I'll just try a build  against kdelibs5, just in case. If no luck, I'll go for a source removal
[19:22] <NCommander> 91MB?
[19:22] <\sh> fabrice_sp: have fun :) I think it will fail because of a changed sound architecture...but we could be lucky :)
[19:22] <NCommander> OW
[19:22] <Laibsch> \sh: The debdiff between the 2.2.6 debian release and the stuff I am compiling from gnucash trunk.  55K due to changes in debian, 91M changes in the source
[19:23] <fabrice_sp> \sh: glupsss
[19:23] <Laibsch> the source changes are about the same size as the source itself
[19:23] <\sh> Laibsch: that's a whole new upstream version ,-> or a complete rewrite ...whatever too much
[19:24] <Laibsch> yes, too much for a debdiff
[19:24] <Laibsch> but of course the packaging information is still valid
[19:24] <Laibsch> mostly
[19:25]  * directhex disagreed with debdiff where upstream changes are involved
[19:25] <directhex> debdiff is fine from a previous ubuntu version or debian version, but it's a silly thing to mandate to say "look at the diff between 1.0.1beta3 and 8.76pro"
[19:25] <directhex> completely useless metric
[19:26] <Laibsch> yes
[19:26] <Laibsch> agreed
[19:26] <Laibsch> but it was requested here ;-)
[19:26] <Laibsch> so I provided it
[19:45] <sebner> DktrKranz: \o7
[19:45] <sebner> DktrKranz: lag ,.. P
[19:46] <DktrKranz> sebner, your script is buggy... -ETOOLAG and bogus "7"
[19:46]  * sebner is now afk. fixing the script xD
[19:47]  * DktrKranz is now afk, preventing sebner from fixing it
[19:47]  * sebner is now afk from afk and preventing DktrKranz to prevent sebner from fixing it xD
[20:11] <fabrice_sp> \sh: there is a version of kwave compatible with KDE 4 in kwave subversion repository, with a lot of changes, so I'll wait. How do I put on hold the sync request? I'm not able to unsuscribe "Ubuntu Sponsors for universe "
[20:12] <fabrice_sp> (Bug #271630)
[20:15] <geser> fabrice_sp: u-u-s is unsubcribed from that bug now
[20:16] <fabrice_sp> geser: thanks
[20:17] <verwilst> emgent: ping
[20:30] <azeem> Laibsch: this is the problem:
[20:30] <azeem> -	make all
[20:30] <azeem> -	make install
[20:30] <azeem> +	make
[20:30] <azeem> you run make install without further arguments, that is bound to fail
[20:31] <azeem> Laibsch: the earlier diff of debian/rules you showed did not have this change
[20:48] <handschuh> hi; how do I add file and directory-permissions via dh_install ?
[20:48] <azeem> handschuh: I don't think you can, you'll have to run chmod afterwards I think
[20:48] <azeem> or fix the upstream Makefile if they are wrong
[20:50] <handschuh> ok, thanks
[21:16] <Nutzebahn> Helo.
[22:33] <mrbichel> Hello, i am interested in getting involved in ubuntu as a developer.
[22:34] <pochu> hi mrbichel, check this page: https://wiki.ubuntu.com/MOTU/Contributing
[22:36] <mrbichel> thanks
[22:38] <persia> mrbichel: Welcome :)
[22:38] <persia> mrbichel: Please also ask any questions here as you contribute.
[22:41] <mrbichel> thanks
[22:43] <mrbichel> i signed up on launchpad. How much experience should i get myself before signing up for mentoring?
[22:43] <persia> mrbichel: It depends on how you work best, and with what you seek mentoring.
[22:43] <verwilst> hm
[22:43] <verwilst> Subject: 	zabbix_1.6~ppa1_source.changes rejected
[22:43] <verwilst> any help? :)
[22:44] <verwilst> Rejected: Signer has no upload rights at all to this distribution. Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
[22:44] <persia> If you are the sort of person who works best with a one-on-one relationship, mentoring might be something you want sooner.  If you are the sort of person who works best with documentation and discussion with the community-at-large, you may not need mentoring at all.
[22:44] <verwilst> i think i was still root when i started dput
[22:44] <verwilst> and my .dput.cfg is under my normal user
[22:44] <verwilst> could that be it?
[22:45] <persia> verwilst: Could be.  Looks like you tried to upload to Ubuntu rather than a PPA.
[22:45] <verwilst> "Already uploaded to upload.ubuntu.com"
[22:45] <verwilst> i can't re-upload :(
[22:45] <persia> You need to delete the .upload file.
[22:45] <verwilst> persia: yeah.. how do i remove it?
[22:45] <persia> You don't need to remove it: it was rejected already.
[22:46] <persia> (where "it" means the upload to upload.ubuntu.com)
[22:46] <verwilst> attempt 2 :P
[22:47] <mrbichel> So generally you spot a bug you would like to fix and sign up yourself for it or sign up for mentoring on a specific project in order to get started developing?
[22:48] <verwilst> should you see it appear right away on your ppa?
[22:49] <verwilst> hm, i feel another rejection coming up
[22:49] <verwilst> :P
[22:50] <verwilst> rah!
[22:50] <verwilst> again :(
[22:50] <verwilst> same error message
[22:50] <verwilst> grr i wanted to do a quick upload and go to bed
[22:52] <verwilst> hm yes, it takes upload.ubuntu.com instead of ppa.launchpad.net
[22:53] <verwilst> http://pastebin.ca/1205342
[22:54] <verwilst> any ideas pretty please?
[22:54] <ceekay> sorry i know this is a newbie question- there is a new version of a package upstream (makedumpfile) that i created a package for because i need it right away. seems like the nice thing to do would be to contribute that packaging to ubuntu for potential use... what is the best channel for doing do? contact the package maintainer?
[22:55] <verwilst> rah!
[22:55] <verwilst> forgot to add my ppa name
[23:02] <persia> ceekay: The current practice is to file a bug against the package, requesting an update to the new upstream.  Add the "upgrade" tag to the bug, and attach the updated diff.gz.
[23:03] <persia> For packages in main, you want to subscribe the "ubuntu-main-sponsors" team to request someone to review the changes and possibly upload.
[23:03] <persia> Note that Ubuntu is currently in FeatureFreeze, so it may well be that this upgrade will not be accepted right now, or even for Ubuntu 8.10.
[23:09] <Nutzebahn> Hello.
[23:10] <Sneaky> Hello. :)
[23:10] <Nutzebahn> Can anyone here make a deb package of megatunix or help me to? ./configure doesn't work.
[23:11] <directhex> people are generally quite stretched. they won't do packaging for you without a very very good reason
[23:11] <directhex> teaching you is another matter
[23:11] <directhex> give a man a fish, etc etc etc
[23:11] <Nutzebahn> :'(
[23:11] <Nutzebahn> megatunix.sourceforge.net
[23:11] <Nutzebahn> That program is worth creating a debian package for.
[23:13] <Laney> If it's that worth it, then it's worth your time to learn how to do it ;)
[23:14] <handschuh> Nutzebahn: did you follow http://www.msextra.com/viewtopic.php?p=151941  ?
[23:14] <directhex> Lamba, strangely, people seem ever so busy when you say "patches plz" to their own suggestions
[23:16] <pochu> Nutzebahn: if you don't want to package it yourself, you can report a 'needs-packaging' bug at Launchpad and/or a RFP bug in bugs.debian.org. Hopefully somebody will see it and package it
[23:16] <Nutzebahn> Ok.
[23:36] <nxvl> nellery: how is your jurney going?
[23:37] <nellery> nxvl, hi, I submitted a package upgrade a few days ago and the release team was subscribed
[23:38] <nellery> still not sure if it will be uploaded
[23:38] <nxvl> :D
[23:38] <nxvl> if not, at least you will learn something
[23:38] <nellery> they asked for the upstream .diff, but no reply yet
[23:39] <nxvl> i was more happy when someone rejects a patch or bug report from
[23:40] <nellery> nxvl, yup, I certainly did learn lots with that
[23:40] <nellery> any thoughts on what I should work on now?
[23:41] <nxvl> since he pointed to my errors and learn something from that
[23:41]  * persia recommends looking for unloved packages (no uploads in a while), and trying to patch bugs filed in launchpad.
[23:42] <nxvl> nellery: still not a week, so keep up with the FTBFS
[23:42] <nxvl> :D
[23:43] <persia> Oh.  Those are good too :)
[23:43] <nxvl> yep
[23:43] <nxvl> it's on the ones you more learn
[23:43] <nxvl> :D
[23:43] <nxvl> nellery: secret tip, if you find a really hard one, ping NCommander
[23:43]  * nxvl hides
[23:43]  * NCommander smashs nxvl with the bookcase of doom
[23:44] <nxvl> ouch
[23:44]  * NCommander adds mono ontop
[23:44] <nxvl> :(

[23:45]  * nxvl HUGS NCommander 
[23:45] <orly_owl> ow mono
[23:45] <orly_owl> please not that
[23:45] <orly_owl> ill do whatever you want
[23:46] <persia> orly_owl: Fix all the outstanding bugs :p
[23:46] <orly_owl> ok, bring on the mono
[23:46] <persia> heh
[23:47] <NCommander> So nxvl is a mindreader
[23:47]  * DktrKranz suggest to remove mono, gnome, the whole archive and leave with bash only
[23:47] <NCommander> or in a drunk suber, I chmodded my mind 777
[23:47] <NCommander> Ah
[23:47] <NCommander> DktrKranz,
[23:47] <NCommander> :-)
[23:47]  * NCommander has a bug for you
[23:47] <DktrKranz> \o/
[23:48] <NCommander> DktrKranz, please upload Ada fixes to -proposed
[23:48] <DktrKranz> NCommander, which one was the first?
[23:48] <NCommander> Ugh
[23:48] <NCommander> Link to bug please so I can remember
[23:48] <DktrKranz> IIRC, they have a specific order
[23:49] <DktrKranz> bug 268260
[23:49] <orly_owl> bug 1
[23:49] <orly_owl> darn
[23:51] <DktrKranz> NCommander, highly libaws
[23:52] <nxvl> did anyone know how backports work?
[23:52] <nxvl> can i (as a MOTU) do universe-backports?
[23:52] <NCommander> nxvl, MOTU can ack backports if they don't require source level changes, but only core-dev can do an actual backport (i.e., needs source changes)
[23:52] <nxvl> or do i need core-dev status?
[23:52]  * directhex coughs
[23:53] <nxvl> well, in that sense only archive-admins can do backports
[23:53] <NCommander> (and for an MOTU to ack a backport, they need to be a member of ubuntu-backports)
[23:53] <directhex> mono's not hard, just misunderstood
[23:53] <nxvl> DktrKranz: can you confirm that?
[23:53] <nxvl> persia: or you?
[23:53] <slangasek> mono is the kissing disease
[23:53] <nxvl> NCommander: not that i don't belive you, but i still don't buy that
[23:53] <nxvl> \o/
[23:53] <nxvl> our release manager
[23:54] <persia> I'm not a member of the backports team.
[23:54] <DktrKranz> nxvl, I'm not in backporters, but I think you need ACK from ubuntu-backports
[23:54] <nxvl> slangasek: you can confirm that
[23:54] <NCommander> nxvl, https://help.ubuntu.com/community/UbuntuBackports#Technical%20Information%20for%20Ubuntu%20Developers
[23:54] <directhex> slangasek, you don't like kissing? :o
[23:54]  * persia tries to be a member of as few teams as possible
[23:54] <slangasek> directhex: I don't like diseases
[23:54]  * NCommander hides the mono cannon
[23:54] <directhex> slangasek, pfft, that which doesn't kill us makes us stronger
[23:54] <directhex> well, except for multiple sclerosis. and aids.
[23:54] <persia> Note that there have occasionally been non-MOTU members of the backporters team, but proven experts at backports testing and review.
[23:54] <directhex> and a hurty knee
[23:55] <slangasek> nxvl: I don't think that's correct; I don't see why the universe/backports would have an ACL that allowed only ubuntu-core-dev to upload to it
[23:55] <NCommander> persia, I was told it is MOTU only now
[23:55] <NCommander> directhex, I believe whatever doesn't kill us make us stranger
[23:55] <persia> NCommander: I could believe that.  I suspect the policy became sane when jdong became MOTU.
[23:55] <directhex> NCommander, fneeb fneeb moopleboop?
[23:55] <slangasek> nxvl: but I have no first-hand knowledge
[23:55] <persia> (he was the last non-MOTU backporter
[23:55] <nxvl> slangasek: yep, i think the same
[23:55] <NCommander> persia, I'm a backport tester, but I can't ack backports, which is reserved for ubuntu-backporters
[23:56] <NCommander> Source level changes can only be uploaded by a core-dev unless the rules of changed
[23:56]  * slangasek starts ubuntu-backpackers
[23:56] <NCommander> s/of/has
[23:56] <slangasek> NCommander: what's the source on that rule?
[23:56] <NCommander> slangasek, wiki
[23:56] <persia> slangasek: Is that those who carry, or those who engage in activities during which one usually carries?
[23:57] <slangasek> oh, there was a second paragraph
[23:57] <slangasek> persia: I was thinking of the cocktail
[23:57] <persia> slangasek: Part of the way that the backports repos were constructed enforces that.
[23:57] <slangasek> ok, I stand corrected
[23:58] <persia> slangasek: Oh my.  That's an interesting blend.  I'm not sure why one adds orange juice though.
[23:58] <slangasek> :-)
[23:59] <directhex> for the interested and/or infected, the current plans in debian to shrink mono good 'n' proper are now written down, at http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
[23:59] <NCommander> persia, I believe sanity is overrated