[00:20] <ramiro> hello
[00:22] <ramiro> how would I go about the following issue?: a cross-compiler depends on pre-compiled runtime libraries. with them, I build the compiler. then I can build the runtime libraries again. So the runtime libraries depend on themselves.
[00:23] <RAOF> That sounds like a typical bootstrapping problem; I'd guess off the top of my head that gcc does that, and I'm fairly sure mono does, too.
[00:25] <ramiro> it is possible to build them in many steps, but then I'd have to bundle the runtime source with gcc and have a somewhat complex debian/rules.
[00:26] <RAOF> You're bootstrapping; you're going to have a somewhat complex debian/rules *regardless*.
[00:27] <ramiro> heh, makes sense.
[00:27] <RAOF> You can bundle binaries in the source package as long as they get rebuilt during the build - ie: patching some source and then rebuilding should Do The Right Thing™
[01:46] <crimsun> poor chris.
[01:51] <RAOF> I wonder what's bouncing me.
[01:51] <StevenK> RAOF: "Excess Flood"
[01:52] <RAOF> That seems odd, given I wasn't actually doing anything at all.
[01:52] <StevenK> Indeed
[01:52] <RAOF> Perhaps a bug against smuxi is in order.
[01:55] <micahg> RAOF: there was a huge netsplit a little while ago
[01:56] <RAOF> Ah.  Maybe that triggers it?  Was that when I started bouncing?
[01:57] <micahg> RAOF: yes
[02:12] <stochastic> what's the program that's similar to 'apt-get source package' but instead pulls the latest code from launchpad?
[02:13] <micahg> stochastic: pull-lp-source
[02:13] <stochastic> thanks micahg
[02:13] <dhillon-v10> hi all, can anyone look here: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995 and tell me why the patch I provided doesn't work?
[02:42] <StevenK> wgrant: O hai -- how long does it take qa.uw.com/ftbfs to notice something does now build?
[02:43] <wgrant> StevenK: It makes a *lot* of requests to Launchpad, so it only runs every six hours.
[02:43] <wgrant> That frequency is arbitrary.
[02:45] <StevenK> wgrant: Yeah, sounds reasonable
[02:56] <ajmitch> wgrant: so the next step is to get some batching happening in the API?
[03:12] <RAOF> Oh, poot.  I misspelled “Requires.private” as “Requires.Private”.
[03:15] <hakaishi> Hey folks! Anyone up to advocate/review qt-shutdown-p? It is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
[03:50] <rhpot1991> anyone know if there is a way to tell pbuilder-dist to save changes?  I can't seem to get the pbuilder --save-after-login flag to work with it
[03:52] <crimsun> depends on the type(s) of changes, but generally, --save-after-exec --override-config
[03:52] <rhpot1991> crimsun: I just need to add my ppa to my apt sources
[03:53] <rhpot1991> normally I'd login and do --save-after-login, add the ppa exit and all would be good
[03:53] <rhpot1991> but with pbuilder-dist it doesn't seem to honor that flag (or I'm doing something silly)
[03:55] <RAOF> It does (or should) honour that flag, but it also overrides a bunch of your config with each invocation.  Say, for example, that you don't want mirror.kernel.org as your mirror?  Currently, you're out of luck with pbuilder-dist.
[03:56] <RAOF> That might also cause it to kill your added entries in sources.list; I'm unsure.
[03:59] <rhpot1991> RAOF: well I used pbuilder and pointed at the resulting .tzr file and it seems to have saved it, but oddly enough when I logged in with pbuilder-dist it didn't show me the saved data
[03:59] <rhpot1991> I'll go ahead and build and see if it works
[03:59] <rhpot1991> I need my PPA to match a dependency that isn't pushed yet
[04:03] <dhillon-v10> crimsun: hi there, can you have a look here: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995 if you have a minute or so
[04:05] <dhillon-v10> crimsun: why is the patch not applying? I did it using bzr
[04:14] <micahg> if something is marked won't fix, if it's released with a proper changelog entry, will the status change to Fix Released?
[04:15] <rhpot1991> RAOF: well, I went in with pbuilder added them, updated, everthing is ok.  Then I run pbuilder-dist and it doesn't seem to obey :(
[04:15] <rhpot1991> guess I'll have to go straight up pbuilder for now
[04:16] <RAOF> micahg: You mean: there's a changelog entry * foo, bar: fixes (LP: #123456), where bug 123456 is currently set to “won't fix”?  I think that'll set it to fix released.
[04:16] <micahg> RAOF: that's my question :)
[04:17] <RAOF> I'm fairly sure it'll set it to fixed released.  Do you not want it to?
[04:17] <micahg> RAOF: no, I want it to so I don't have to make more bug noise ;)
[04:18] <ScottK> micahg: Although I have to wonder why something that's marked wontfix is getting fixed.
[04:19] <micahg> ScottK: source package change
[04:19] <ScottK> Generally we're pretty conservative about putting that on a bug.
[04:19] <micahg> firefox 3.6 will return to the firefox source package which was formerly firefox 2
[04:20]  * micahg put it there in a lot of cases
[04:21] <micahg> it was correct at the time
[04:33] <persia> IF it was correct at the time, why isn't it still correct?  "Won't Fix" should be reserved for stuff we really aren't expecting to fix.  Notabug and the like.
[04:38] <micahg> persia: it was firefox 2 which was won't fix, now it's firefox 3.6 which will be fix released
[04:38] <micahg> we intended to stick with versioned source packages until upstream decided to do rapid releases
[04:38] <persia> I still think it oughtn't have been won'tfix.  That should only be used where we specifically intend not to fix something.
[04:39] <persia> Getting it fixed later, even by accident, makes us look indecisive.
[04:40] <micahg> persia: so, you're saying I should comment anyways and explain?
[04:40] <persia> Leaving a comment in the bug explaining why circumstances have changed would mak sense, and changing the bug from "wontfix" to "triaged" or something with the comment.
[04:41] <persia> Then you go from "Triaged" to "Fix Released" with the upload.
[04:41] <micahg> persia: ok, I'll do that, it's only 3 bugs in this case
[04:41] <persia> But try to avoid these :)
[04:41] <micahg> yep, it's unfortunate, but necessary
[05:26] <ScottK> persia: Sometimes circumstances change and so wontfix should change too.
[05:27] <persia> ScottK: Agreed.  I just think that 1) it deserves explanation when it happens, and 2) we should try not to do that.
[05:27] <ScottK> Certainly.
[05:28] <ScottK> I'd rather look indecisive than make present virtue out of past necessity.
[05:30] <persia> I'd rather avoid both, but given the choice I have to agree.
[07:11] <dholbach> good morning
[07:12] <SevenMachines> morning
[09:42] <dholbach> BlackZ: so does autotrash use a setup.py based installation?
[09:42] <BlackZ> dholbach, yes
[09:43] <dholbach> you could try just using /usr/share/doc/debhelper/examples/rules.tiny (with debhelper 7)
[09:43] <dholbach> DktrKranz: do you have a good example for an python app using dh7?
[09:44] <POX> dholbach: gaupol :)
[09:44] <johe|work> hi there, i submited an new package version to an bug report https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/509495 what does i nedd to do now, to get it replaced in repositry
[09:45] <dholbach> thanks POX
[09:45] <dholbach> BlackZ: apt-get source --diff-only gaupol; less gaupol*.diff.gz
[09:45] <dholbach> BlackZ: that'll give you an idea how to do it
[09:46] <BlackZ> dholbach, thx
[09:46] <dholbach> BlackZ: and if you get stuck, just ask in here, somebody will be able to help you :)
[09:55] <POX> dholbach: zless, I guess (and gaupol has to be >= 0.14-1)
[09:55] <dholbach> POX: less works too
[09:58] <POX> not here (I don't have LESSOPEN defined)
[10:02] <dholbach> POX: ah ok
[10:04] <randomaction> johe|work: you need to provide a debdiff (modification to the *source* package), and see https://wiki.ubuntu.com/SponsorshipProcess
[10:04] <johe|work> randomaction, thx
[10:04] <randomaction> johe|work: see also https://wiki.ubuntu.com/Bugs/HowToFix (it tells you how to produce a debdiff)
[10:27] <jariq> Could someone please review package ipwatchd ? http://revu.ubuntuwire.com/p/ipwatchd
[12:30] <hyperair> dholbach: ping. regarding the whole MC losing quorum thing, how should i go about applying as a MOTU, if i can't make the next meeting? (it's 3AM local time)
[12:33] <persia> hyperair: You could try an email application, but otherwise, you'd do best to wait until the 2nd February DMB meeting, at which we can hope some direction is provided.
[12:33] <persia> Note that we haven't had any successful email applications in a while, and getting it complete in the next six days would be tricky.
[12:35] <ScottK> Althernatively, suck it up and get up in the middle of the night ...
[12:36]  * persia expects some MC members to be attending in the middle of the (local) night.
[13:20] <DktrKranz> dholbach: I finished my job journey and I'm back town, so I can regularly take my session tonight :)
[13:47] <Quintasan> Hello
[13:48] <slytherin> Quintasan: hi
[13:48] <Quintasan> slytherin: \o
[13:48] <slytherin> Why do we have two links pointing to different FTBFS pages in topic?
[13:52] <ScottK> Because one if packages that failed to build in the archive and the other is ones that failed to build in a rebuild test.
[13:53] <slytherin> ScottK: So is the second url relevant all the time?
[13:54] <ScottK> slytherin: Yes.  lucas has been doing regular rebuild tests for us this cycle.
[13:54] <slytherin> Then it is fine.
[15:33] <ramiro> I'm using reprepro to manage a repository. When I included a new version of a package, the old one was deleted because it was unreferenced. How do I make it so that all packages always remain in the repository, and it's the user's job to select which one he wants? (and by default he gets the latest version)
[15:55] <nigel_nb> maco, around?
[15:55] <persia> ramiro: You'll need to either use less smart repository software, or very custom solution.
[15:57] <ramiro> ugh, a less smart repository software means I'll have to be less dumb =). which one do you suggest?
[15:57] <persia> I'm not the right person to suggest any: I don't manage repositories (but we don't much generally here).  apt-ftparchive is probably the least fancy of the options.
[16:06] <freeflying> ramiro: dak maybe :)
[16:09] <persia> freeflying: Doesn't dak autoexpire superceded stuff?  Anyway, I can't imagine it being useful for less than 10,000 packages.
[16:10] <ScottK> persia: Depends on the pain to package ratio you find acceptable.
[16:10] <persia> heh.  I suppose :)
[16:11] <freeflying> persia: mini-dak then  :)
[16:16] <dholbach> ajmitch_: if you have a bit of time - do you think you could help out with reviewing the zope* packages on REVU?
[16:18] <ScottK> Considering there's an active Zope team in Debian, wouldn't they better go there?
[16:22] <persia> The moreso because they describe themselves as the "Debian/Ubuntu Zope Team"
[16:28] <benste>  hi, if I'd like to have a package merged from debian - what can I do? -https://bugs.launchpad.net/ubuntu/+source/tiemu/+bug/221332
[16:31] <benste> ?
[16:31] <ScottK> benste: First step would be to look at the changes Ubuntu has from Debian in the package and see if they are still needed/relevant.
[16:31] <persia> benste: There are outstanding Ubuntu changes that need to be investigated before the package is synched.
[16:32] <persia> benste: From a quick glance, I believe it does need a merge, to deal with iceweasel/firefox differences between Debian and Ubuntu.
[16:32] <benste> why should tiemu use FF ?
[16:32] <benste> - where does i have to look for it ?
[16:33] <persia> benste: In Debian, in tiemu 3.02-1, there is a dependency declared on "iceweasel | www-browser".
[16:33] <benste> and whom does I have to propose to include the new version even if it's ok - so already build a ubuntu version
[16:33] <benste> k
[16:33] <persia> This dependency needs to be modified to be "firefox | www-browser"
[16:34] <benste> persia: only changing depency is simple isn't it - simply download source, change config and rebuild deb right ?
[16:34] <persia> Err, sorry.  Needs to be "firefox | abrowser | www-browser"
[16:34] <benste> what about the already build Ubuntu package
[16:34] <persia> benste: Don't even bother rebuilding.  We work exclusively with source packages.
[16:34] <benste> inlcuded in the PPA of one poster
[16:35] <ScottK> persia: Why?
[16:35] <benste> persia: changing depency is all - if so I'll do right away
[16:35] <persia> Download the Debian and Ubuntu package sources.  Merge the changelogs.  modify debian/control to have the right dependency and use "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as the Maintainer.
[16:35] <ScottK> I think the odds of anyone having no package that provides www-browser installed is effectively nil
[16:35] <persia> Put the previous maintainer in XSBC-Maintainer
[16:36] <persia> Update the changelog, and attach a debdiff to the bug.
[16:36] <benste> persia: would be kind of you to explain me how to do this - or give some simple resources which will guide me through this process
[16:36] <persia> ScottK: Because that's what the mozilla team declared should be the dependency.  See bug #272772
[16:37] <persia> !merge
[16:37] <persia> benste: That URL should give some guidance.  Ask here if you get stuck.
[16:37] <ScottK> persia: since it currently Depends/Recommends neither, it's not applicable
[16:37] <benste> I'll
[16:37] <benste> fo
[16:38] <persia> ScottK: Hrm?  Are you looking at the same tiemu I'm seeing?
[16:38] <persia> Depends: libatk1.0-0 (>= 1.20.0), libc6 (>= 2.7), libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.3.5), libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.14.1), libpango1.0-0 (>= 1.21.6), libticables3 (>= 3.9.6-1), libticalcs4 (>= 4.6.1-1), libtifiles0 (>= 0.6.6-1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.1.4), firefox | abrowser | www-browser
[16:38] <ScottK> persia: I'm looking at you having said it depends iceweasel | www-browser
[16:39] <persia> My sid apt-cache says it does.  Am I out of date?
[16:39] <ScottK> No.  I'm saying I think that's sufficient.
[16:39] <persia> I thought that one of the changes we maintained was all the s/iceweasel/firefox/ changes in package relationships.
[16:39] <persia> Do we have a solution for that now?
[16:39] <ScottK> Changing iceweasel | www-browser to firefox | abrowser | www-browser has zero practical effect on user experience
[16:40] <ScottK> The only time that would matter is if the user had no package installed that provided www-browser and that would be hard to accomplish
[16:40] <persia> Well, that removes a whole heap of diffs.
[16:40] <ScottK> I'm just saying I think it's not worth the effort to maintain that diff.
[16:40] <ScottK> It does.
[16:41] <ScottK> Consider it.
[16:41] <persia> I can see the argument, I just thought that there was some intent behind that.
[16:41] <ScottK> I realize it's a change in procedure, but I think it makes sense.
[16:41] <ScottK> If there's some other diff, go ahead and do firefox | abrowser | www-browser too, but if that's it, I'd sync it.
[16:41] <persia> I don't disagree, but I also think that procedure is best changed in combination with interested parties, such as TIL or mozillateam.
[16:42] <persia> fta: Do you have any opinion about tiemu and iceweasel/firefox ?
[16:43] <persia> ScottK: If there wasn't some reason to fiddle the names, the simplest solution to the entire mess would be to have firefox Provide: iceweasel.
[16:43] <ScottK> persia: I agree with that.
[16:43] <persia> So, because we didn't do it the easy way, I presume there's some reason.
[16:43] <ScottK> That would solve an even large set of problems.
[16:44] <ScottK> In theory, changing to firefox | abrowser | www-browser is more correct, but I think it's not worth the trouble.
[16:44] <persia> I don't pretend to understand that reason, but I'll go along as long as others feel it's better to do it the hard way.
[16:45] <ScottK> I don't know that it's been seriously examined in some time.
[16:45] <persia> That's why I asked TIL :)
[17:08] <benste> persia: what if I can't find my package in https://merges.ubuntu.com/universe but in https://merges.ubuntu.com/t/tiemu/
[17:08] <benste> ?
[17:09] <persia> benste: then that would mean the wiki page was out of date :)
[17:09] <benste> lol
[17:09] <benste> persia: the wiki(how to merge) or the list of merges ?
[17:09] <persia> The wiki of how to merge.
[17:09] <benste> so you're using a different site today ?
[17:10] <persia>  /topic says http://people.ubuntuwire.com/~lucas/merges.html , but this may be temporary.
[17:10] <persia> We've been having a lot of discussion about merges this cycle, and I'm not sure we have a final solution yet.
[17:15] <bddebian> Heya gang
[17:16] <benste> persia: thx for this temp info found the last uploader and Scott  replied to the bug too
[17:19] <ScottK> persia: His package is in Multiverse.  That's why he couldn't find it in Universe.
[17:19] <benste> :-9
[17:20] <ScottK> Interesting.  Per architecture support time: "add case were a architecture is supported (armel) but not for the full LTS time" in https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-support-timeframe-information
[17:20] <persia> ScottK: Is MoM generally up again, or are we still unsure of a final solution?
[17:22] <persia> ScottK: Separately, that sense of "supported" probably means "labeled as supported", rather than anything else.  Same as hardy lpia in that sense.
[17:23] <ScottK> persia: MoM is unmaintained.
[17:23] <ScottK> Oh, I didn't realize that obtained for Hardy lpia.
[17:23] <persia> That was my understanding.  As a result, I believe the wiki page on merging to be out of date.
[17:23] <ScottK> OTOH, the alternative via bzr is not really mature enough for general use.
[17:24] <persia> I'm not sure it does for all flavours, but I know that because of the way some of the mobile stuff was done on lpia, lpia desktop didn't work reliably anyway because of library issues.
[17:24] <persia> So when the (non-LTS) mobile flavour ended support (18 months), I *think* lpia kinda lost support.
[17:25] <persia> I have no idea about lpia server.
[17:25] <persia> On merging: right.  I don't think we have a good replacement for the merging documentation right now.
[17:27] <ScottK> There are some useful hint in the UDD wiki pages.
[17:27] <ScottK> hint/hints
[17:27] <persia> Yes.  They haven't worked for me yet, but I'm sure that's only a matter of time.
[17:28] <ScottK> Also in the replies to my recent thread on the topic on the UDD mail list.
[17:28] <ScottK> It would be useful for someone to work on a page that was the union of those two resources.
[19:04] <fabrice_sp> lutin, about bug 510693
[19:05] <fabrice_sp> why do you need an ack from u-u-s? IMHO you should be able to push that by yourself
[19:06] <fabrice_sp> (package is still in universe, it seems)
[19:06] <Lutin> fabrice_sp: heh, thought it had been promoted to main already.
[19:06] <Lutin> sorry
[19:07] <fabrice_sp> np: I'll unsubscribe u-u-s then ;-)
[19:08] <fabrice_sp> may I subscribe archive admin also? Or you will take care of it?
[19:09] <Lutin> fabrice_sp: I'll take care of it, thanks
[19:09] <fabrice_sp> ok
[19:42] <pucko-> I have a few packaging problems I was hoping someone could help me with. I want to include a udev-file in my package (which is built with cdbs). but I can't get debhelper to add my udev rule to the package. Supposedly, specifying DEB_INSTALLUDEV_ARGS in debian/rules should take care of it. but it doesn't seen to work. it's just ignored.
[19:42] <fta> persia, ScottK: wrt tiemu, feel free to do whatever you want with it, i just touched it once as part of a massive firefox meta package update
[19:43] <persia> fta: More generally, do you know the reason that we fuss with changing all the package dependencies rather than just having firefox and abrowser Provide: iceweasel?
[19:43] <persia> pucko-: Is this a new package, or a change to an existing package?
[19:44] <pucko-> a new package
[19:44] <pucko-> dh_installudev is actually run, but I can't get it to take the correct arguments.
[19:45] <fta> persia, a lot of debian users are using our firefox packages (because they are fresher), as they also have iceweasel, it's best to keep things separate
[19:46] <persia> fta: So it's worth changing the dependencies of all these packages every cycle?  I just thought that by using Provides: we could sync more packages from Debian.
[19:46] <fta> persia, but you may want to talk to asac about that, those days, i'm mostly focusing on chromium
[19:46] <persia> OK.  I just picked on you because you touched tiemu last :)
[19:47] <persia> pucko-: You need DEB_DH_INSTALLUDEV_ARGS instead of  DEB_INSTALLUDEV_ARGS, but figuring this out is frustrating and tricky.  Might I recommend using /usr/share/doc/debhelper/examples/rules.tiny as the base of your debian/rules?
[19:47] <pucko-> oh. thanks!
[19:49] <pucko-> um.. that file is just 3 lines :-/
[19:50] <persia> Yep.  Saves lots of messing about.
[19:52] <persia> You can pass arguments to dh_installudev either by passing them to the dh call (but this passes the same arguments (likely usually ignored) to dh_*), or you can add an override_dh_installudev: rule, and put the complete dh_installudev call in that.
[19:52] <persia> (Well, there's lots of other ways to do it too, but those might be easiest)
[19:52] <pucko-> sounds easier to just use the env variable. now that I know it :-)
[19:53] <persia> What's your environment variable setting?
[19:53] <pucko-> I mean that DEB_DH... thing
[19:53] <persia> Right.  What value are you using?
[19:54] <pucko-> oh it worked. DEB_DH_INSTALLDEV_ARGS = --priority=85
[19:55] <persia> pucko-: Here's the two different rules.tiny debian/rules files that do that: http://paste.ubuntu.com/360227/
[19:55] <persia> (and no hunting around for special secret variable names)
[19:55] <pucko-> now I only have this postinst-has-useless-call-to-ldconfig warning. it is added by debhelper for some reason. can I tell it to ignore it?
[19:55] <persia> Are you installing any shared libraries?
[19:56] <pucko-> well. sort of. it's a smart card reader driver. one .so-file that should go into /usr/lib/pcsc/ somewhere.
[19:57] <pucko-> so tha path shouldn't be added to ld.so.conf
[19:57] <pucko-> the
[19:57] <persia> You need to pass arguments to dh_makeshlibs to ignore that.
[19:57] <pucko-> ok.
[20:16] <feuloren> hi, is there packages for gegl 0.1 somewhere ?
[20:18] <randomaction> feuloren: looks like no, Debian has an open request for it
[20:35] <statik> hey Daviey, i just reviewed your django-openid-auth branch. got one minor request for you, and i'll be happy to merge it
[20:50] <hotellina> hi people, do you know how make ubuntu able to show volume levels for all sound peripherals ( usb also) ?
[21:03] <jibel> fabrice_sp, just seen you've sponsored bug 464422. Thank you !
[21:04] <fabrice_sp> jibel, you're welcome: you did all the job ;-)
[21:09] <randomaction> jibel: well done, this was a bug with an enormous amount of duplicates
[21:10] <jibel> randomaction, thanks
[21:11] <randomaction> two such bugs, actually :)
[21:12] <jibel> if anyone knows how to reach the debian maintainer please ping him. It would be great to fix it upstream too.
[21:13] <fabrice_sp> jibel, I saw you reported it there, but no answer :-/
[21:28] <menesis> could someone review/sponsor my zope.* packages on REVU? http://revu.ubuntuwire.com/u/menesis
[21:32] <pucko-> can anyone tell me why there is both a libusb-0.1-4 and libusb-1.0-0? very confusing..
[21:33] <pucko-> in ubuntu karmic
[21:36] <randomaction> pucko-: it's commonplace to have different versions of libraries in distribution (or installed on the same machine), as different applications may require different versions
[21:37] <pucko-> hm..
[21:40] <pucko-> it seems very specific. why not just libusb0 and libusb1?
[21:44] <tsimpson> because the files are libusb-0.1.so.4 and libusb-1.0.so.0
[21:45]  * Quintasan goes to bed, school etc.
[22:05] <jariq> how long does it take to the package to show up in the ppa after upload?
[22:06] <persia> jariq: ask in #launchpad.
[22:06] <jariq> thx
[22:32] <hggdh> about 5 minutes, anyway
[23:49] <superm1> RainCT, could you ack ~ubuntu-dev-without-bugmail into ~mythbuntu?
[23:50] <RainCT> superm1: sure
[23:50] <superm1> thanks
[23:52] <RainCT> superm1: Uhm, what has changed since the original proposal when we created that team?
[23:52] <superm1> RainCT, it looks like there is a gateway to catch all the extraneous email now isn't there?
[23:53] <superm1> or was there still some other deficiency?
[23:53] <RainCT> superm1: I'm not sure, I'm reading the old mails right now
[23:56] <RainCT> superm1: There was no agreement that ubuntu-dev needed access to such branches: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026207.html
[23:57] <RainCT> superm1: Also, problems with the ~ubuntu-dev-without-bugmail approach were that e-mails other than bugmail were still send to everyone (for example, notifications of new mailing list creations) and that all developers had the Mythbuntu logo on their profile
[23:57] <superm1> Oh right
[23:57] <superm1> well then i guess not worth the troubles still
[23:58] <superm1> once more ~mythbuntu folks are more packaging proficient on their own should just have them apply for per package upload rights and move those branches to ~mythbuntu-dev at that time
[23:58] <superm1> for now it's convenient as it stands
[23:58] <superm1> sorry for the churn, i should have dug that mail up myself and reviewed it