[01:13] <maco> highvoltage: you online right now? americas rmb isnt making quorum. can we borrow you?
[01:20] <highvoltage> maco: I really wish I could but I need to leave right now
[01:50] <bitshuffler> Hi guys. I have some trouble with deps & packaging. What is the proper name for depending on e.g. libboost-filesystem1.38-dev - as in 9.10 has 1.38, 10.04 has 1.40 and so on ... What canonical name can I use to require those on all versions?
[01:52] <micahg> bitshuffler: libboost-filesystem-dev?
[01:53] <bitshuffler> micahg: thanks, I'm currently trying libboost-dev perhaps that works
[01:54] <bitshuffler> Another question is that "libboost-dev" doesn't work on debian 5.0 cause I need 1.35 but the default is 1.34 or so. Is there some %if version = 1.2.3 for packaging debs?
[01:55] <bitshuffler> So I can explicitly require libboost_1.35 on Debian 5.0 and use whatever the distro provides for the rest of the stuff?
[01:56] <micahg> bitshuffler: you might want to look at this: http://www.debian.org/doc/debian-policy/ch-relationships.html
[01:57] <bitshuffler> micahg: so I e.g. could do something like "Depends: libboost_1.35-dev | libboost-dev" and Debian would take the first while later Ubuntu version would take the later?
[01:58] <bitshuffler> (assumed that Debian 5.0 has libboost_1.35-dev and alter Ubuntu libboost-dev)
[01:58] <micahg> bitshuffler: no, "Depends: libboost-dev (>= 1.35)" would probably be better, Debian would just pull in 1.34 in your example
[01:58] <micahg> bitshuffler: oh really
[01:59] <bitshuffler> micahg: "oh really?"
[01:59] <micahg> bitshuffler: then your solution is better :)
[01:59] <micahg> bitshuffler: I didn't realize lenny had multiple 1.35 also
[01:59] <bitshuffler> micahg: ah, so I can rest assured that it will take the first if available and the other stuff only as fallback?
[02:00] <bitshuffler> micahg: cheers, thanks a lot, you helped me out of my misery ;D
[02:00] <micahg> bitshuffler: it should, yes, it should go left to right to install if none of them are installed
[02:00] <bitshuffler> it has 1.35 I'm just not sure about the package name but it was just for the sake of having an example.
[02:00] <bitshuffler> micahg: great, thanks a lot :)
[02:00] <micahg> bitshuffler: np
[02:13] <bitshuffler> Ok, hope fully the last one :D How do I add some "Prefer" for stuff like "have choice for libstdc++-dev: libstdc++6-4.1-dev libstdc++6-4.2-dev libstdc++6-4.3-dev" - as in I need libstdc++-dev and for some reason there are 3 libs providing this?
[02:14] <bitshuffler> as in does .deb know some Prefer tag or how do you deal with that?
[02:15] <micahg> bitshuffler: separate with | with the favorite on the left
[02:16] <bitshuffler> micahg: like in "Depends: libstdc++-dev | libstdc++6-4.3-dev" ?
[02:17]  * bitshuffler scratches head
[02:17] <bitshuffler> on thinking about it it makes sense
[02:17] <bitshuffler> micahg: Thanks a lot once again :)
[02:17] <micahg> bitshuffler: yeah, I think so
[02:17] <micahg> bitshuffler: np
[02:18] <bitshuffler> Comming from rpm packaging that is like having to wrap your head around nosql after you got used to relational dbs ;D
[02:18] <RAOF> bitshuffler: It looks like you're going about this the hard way - why are you manually populating the Depends field, anyway?
[02:19] <bitshuffler> RAOF: I have to. I am not running Ubuntu / Debain but using OBS to create package for 0ad and there are some version "differences" if you try to create the stuff for Debian, Fedora, Mandriva, openSUSE and Ubuntu from 2 files ;D
[02:19] <bitshuffler> so I'm used to packaging rpms but with debs I often encounter "unseen land" ;D
[02:20] <RAOF> Won't OBS rebuild the source package for each of the different targets?
[02:20] <bitshuffler> RAOF: yes, of course, but for that to succeed you have to provide proper packaging info for whatever distro version you use.
[02:20] <RAOF> I mean, we've got a nice robust infrastructure for populating the Depends field from the libraries the package actually links to.
[02:21] <RAOF> Right.  So, you Build-Depend on libstdc++-dev, the package gets built against whatever version of libstdc++ that target has, and then use ${shlibs:Depends} to automatically populate the Depends field with the appropriate dependency.
[02:22] <bitshuffler> oh, you mean something like autorequires? That works there fine too for the binary but for the source package it is a bit harder (at least if you have to satisfy every supported debian & ubuntu version)
[02:23] <bitshuffler> given for debian 4 and your old lts version (6.x or so iirc) it wont work anyways so I just target debian 5 and the latet 3 Ubuntu versions.
[02:23] <bitshuffler> s/3/2/
[02:23] <RAOF> So far you've got Build-Depends: libboost-dev (>= 1.35), libstdc++-dev
[02:23] <bitshuffler> heh, gimme a sec, I'm trying it currently locally and setting up the chroot takes ages :)
[02:24] <micahg> RAOF: mutiple libboost-devs are required since debian 5.0 has 1.34 by default
[02:25] <RAOF> micahg: Ah, so that needs to be libboost-dev (>= 1.35) | libboost1.35-dev, right.
[02:25] <micahg> RAOF: yeah
[02:27] <bitshuffler> RAOF: yes, on debian 5.0 I can use libboost-dev since that installs 1.34 but I apparently need min 1.35 and later Ubuntu versions just work with libboost-dev since that is 1.38+
[02:29] <bitshuffler> *on debian 5.0 I can _not_ use libboost-dev
[02:29] <micahg> bitshuffler: that's why you have the minimum version specified libboost-dev (>= 1.35)
[02:31] <RAOF> And have the alternative “ | libboost1.35-dev”
[02:31] <bitshuffler> micahg: yes, that prolly is the cleanest solution
[02:32] <bitshuffler> otoh I get now "unresolvable: nothing provides libboost-signals-dev, nothing provides libboost-filesystem-dev" for 10.04 (_without_ univers) Does that make sense?
[02:33] <micahg> bitshuffler: yes
[02:33] <bitshuffler> micahg: in what way?
[02:33] <micahg> bitshuffler: well, if your chroot doesn't have universe enabled, then you can't get those packages
[02:34] <bitshuffler> micahg: well, I have libboost-filesystem1.40.0_1.40.0-4ubuntu4_i386.deb on 10.04 i586 but apparently it doesn't "provide" (dunno the dep name for that) "libboost-filesystem-dev". That's correct or am I mixing something up?
[02:35] <bitshuffler> *deb name
[02:35] <bitshuffler> er, make that "libboost-filesystem1.40-dev_1.40.0-4ubuntu4_i386.deb" obviously
[02:36] <micahg> bitshuffler: yes, well, the metapackage is in universe and the versioned package is in main
[02:36]  * bitshuffler facepalms
[02:36] <bitshuffler> micahg: what is the reasoning behind that?
[02:36] <micahg> bitshuffler: the binary was probably needed for something in main
[02:37]  * micahg supposes the correct versioned package should provide the metapackage
[02:37] <bitshuffler> (on rpm packages just would do "Provide: libboost-filesystem-dev" and I could happily do "Depends: libboost-filesystem-dev". Don't you guys have something similar?
[02:38] <bitshuffler> micahg: could you look that up please with apt-get or whatever you folks use please?
[02:38] <micahg> bitshuffler: yes, I checked, it doesn't seem to do it
[02:38] <micahg> bitshuffler: we have a provides as well
[02:39] <micahg> bitshuffler: I'm going to suggest we move to #ubuntu-packaging since that channel is specifically for packaging issues
[02:39] <bitshuffler> micahg: hm, so the only way to make me happy without relying on universe (which is no option) is to make some "Depends: $libboost_ubuntu9.10 | $libboost_ubuntu10.04" line?
[02:39] <bitshuffler> micahg: sure, thanks :)
[05:22] <pitti> Good morning
[06:10] <micahg> pitti:  if a retracer bug hasn't been retraced after a month, is that an issue?
[06:21] <pitti> micahg: uh, yes; the maverick/lucid ones are working quite well
[06:21] <micahg> pitti: this is for karmic
[06:22] <pitti> ah, right; no retracers for that one
[06:22] <micahg> pitti: is there a way to let people know that when they file bugs?
[06:22] <micahg> pitti: what other supported versions are there no retracers for?
[06:22] <pitti> not currently
[06:22] <micahg> pitti: even hardy?
[06:23] <pitti> people are not really meant to file crashes on stables in the first place :)
[06:23]  * micahg should stop asking for them then
[06:23] <pitti> micahg: we do have hardy retracers still, but they are rather unstable (too old launchpadlib/apport stack)
[06:24] <pitti> micahg: I still have karmic chroots, but ATM I can't quite remember why I disabled karmic
[06:24] <pitti> I guess it was that gdb/glibc breakage again
[06:24] <micahg> pitti: well, I'd like to let the bugsquad know what the status is/should be
[06:24] <pitti> micahg: what's the particular bug #?
[06:24] <micahg> pitti: bug 596321
[06:24] <pitti> micahg: I can re-add the karmic one, and we'll see how far it gets
[06:25] <pitti> (done)
[06:25] <micahg> pitti: thanks
[07:39] <dholbach> good morning
[07:39] <pitti> hey dholbach
[07:39] <dholbach> hey pitti
[08:42] <rock> ?
[09:10] <micahg> pitti: the problem with the eclipse/xulrunner issue is actually a xulrunner/cairo issue which actually affects Seamonkey as well, but I haven't had a chance to fix it yet, where do you think the breaks should go now?
[09:11] <pitti> micahg: it seems to me that 1.9.2 should conflicts:/replaces: 1.9.1, so that the old 1.9.1 package is cleaned up for everyone (not just eclipse users); WDYT?
[09:11] <pitti> I wonder why this isn't done already
[09:11]  * micahg forgot why we didn't do that...IIRC, we did it for karmic
[09:11] <pitti> wouldn't users pile up xulrunner versions right now?
[09:12] <micahg> apparently we didn't have a transitional package in karmic...
[09:12] <micahg> pitti: yes
[09:12] <micahg> pitti: yeah, it makes sense, I'll discuss with chrisccoulson_
[09:15] <pitti> micahg: thanks; in this case we should reopen the xulrunner-1.9.2 tasks and close the eclipse ones
[09:16] <micahg> pitti: well, the actual bug was fixed in xul192
[09:16] <pitti> micahg: right; but we need a xulrunner task if we want to change/SRU that
[09:17] <micahg> pitti: k
[09:21] <dupondje> pitti: https://bugs.launchpad.net/ubuntu/+source/aegir-provision/+bug/543662 added debdiff :)
[09:22] <pitti> dupondje: please get it uploaded
[09:24] <dupondje> ah it first needs to get in maverick with ubunu1 tag ?
[09:25] <pitti> dupondje: no, upload to lucid
[09:26] <dupondje> i'll spam some motu :) don't have upload perms
[10:03] <geser> pitti: I just sponsored dupondje ; it should be now in the SRU queue
[10:03] <pitti> thanks
[11:44] <ev> anyone mind giving a spot check of this patch to sphinxsearch that packages the library and language bindings? http://paste.ubuntu.com/464472/
[11:47] <ev> http://paste.ubuntu.com/464475/ - updated; I failed to mention the build failure patch in the changelog
[13:00] <cjwatson> zul: could you merge gpib?  you're the last uploader, and it's on my list of packages not merged since karmic
[13:00] <zul> cjwatson: sure
[13:01] <cjwatson> thanks
[13:04] <cjwatson> StevenK: did you have a plan for hildon-desktop and libosso?  I seem to remember something going past on IRC
[13:05] <StevenK> cjwatson: I had no plan, no
[13:05] <seb128> cjwatson, I think pitti investigated those some days ago, he was speaking about them on IRC
[13:07] <StevenK> To be brutally honest, we can probably lose the Ubuntu changes for both and just sync them
[13:08] <cjwatson> StevenK: could you either file bugs for those or do it?
[13:08] <cjwatson> I just want them off my list :-)
[13:08] <StevenK> cjwatson: I still have privs, so I can JFDI if you wish
[13:09] <cjwatson> that's fine by me
[13:09] <cjwatson> that'll be down five today, out of 18
[13:10] <seb128> getting there ;-)
[13:13] <ScottK> cjwatson: Thanks for the stale merges initiative.  I think it's a very valuable exercise.
[13:16] <StevenK> cjwatson: Synced, thanks for the prod.
[13:17] <cjwatson> ScottK: I think we'll probably have to do it every cycle (except perhaps LTS cycles?)
[13:17] <ScottK> It might be worth investing some time in automation then.
[13:17] <seb128> cjwatson, is there so much value doing those? we have some desktop packages where we decided it's often not worh the work
[13:18] <seb128> ie hours of work to not get any value changes
[13:18] <seb128> valuable
[13:18] <cjwatson> seb128: the threshold is that they haven't been done for well over a year
[13:18] <cjwatson> seb128: I think it's reasonable enough to at least look at them by that point
[13:19] <seb128> right, my comment was rather on about doing it every cycle
[13:19] <cjwatson> well, the threshold would still be two cycles back from whenever we were doing it
[13:20] <seb128> I'm wondering if we should claim that we stop merging that few sources
[13:20] <cjwatson> something that people just don't bother with for one cycle don't register
[13:20] <cjwatson> seb128: if you read the spec, it has several alternatives other than doing the merge
[13:20] <cjwatson> I excluded anything in the sync-blacklist, for instance
[13:21] <cjwatson> all I ask is that some active decision be taken, rather than simply letting it fester
[13:21] <seb128> I've read your email, I guess I don't feel we never want to merge those again, it's just lot of work for little benefit so we tend to just not do it
[13:21] <StevenK> cjwatson: While I'm actually on cocoplum, am I okay to NBS out -7?
[13:21] <cjwatson> StevenK: leave it another day, please - CD builds failed today
[13:26]  * StevenK removes a few NBS binaries, sadly, only 4 or so
[13:30] <psurbhi> hie ! i can see in git://git.debian.org/debian-ha/redhat-cluster.git references to upstream? what is upstream location for this git?
[13:30] <psurbhi> the ubuntu redhat-cluster package needs to be updated. The git patch for this update is huge
[13:31] <psurbhi> so wanted to look at a possible smaller patch.
[14:09] <didrocks> dholbach: "the audience even forgave him to try to make French the official language of Ubuntu Development." <- ahah :)
[14:10] <dholbach> "ahah" :)
[14:10]  * dholbach hugs didrocks
[14:10]  * didrocks hugs dholbach back
[14:11] <lool> pitti: Hey
[14:11] <lool> pitti: Do you know why armel apparenlty misses .ddebs?
[14:11] <pitti> lool: no, they're supposed to be there
[14:15] <lool> pitti: For some reason, eglibc for instance is missing
[14:15] <lool> pitti: How would I dive into the issue?
[14:15] <pitti> hmm; /me looks
[14:17] <pitti> lool: hm, not sure; everythign seems alright with ddeb-retriever, it does collect for armel
[14:19] <pitti> http://ddebs.ubuntu.com/dists/maverick/main/binary-armel/Packages
[14:19] <pitti> that seems quite complete
[14:19] <pitti> ddebs@macquarie:/srv/ddebs.ubuntu.com/public_html/pool$ find -name '*_armel.ddeb'|wc -l
[14:19] <pitti> 12845
[14:19] <pitti> lool: so, not sure; must be bad luck with eglibc
[14:19] <pitti> this stuff isn't very reliable
[14:20] <lool> pitti: Hmm ok
[14:20] <pitti> sometimes apache on the buildds hangs forever, and thus blocks the retriever for hours or days
[14:20] <lool> Ah
[14:20] <pitti> I guess the ultimate answer is "wait until we enable ddeb support in soyuz" :/
[14:51] <asac> mterry_: poke bug 592640
[14:54] <mterry_> asac, getting to it.  I noticed it got removed from debian testing because of python2.6 issues...  i know we worked around them in ubuntu, but still
[14:54] <asac> mterry_: so that one is stuck not because you are overloaded? e.g. does it mean you have slots for two or three more?
[14:54] <asac> mterry_: i guess you like cloud stuff?
[14:55] <mterry_> asac, heh.  I just worked through most of my mir queue.  I don't like this reward  :)
[14:55] <mterry_> asac, I'm still working on avogadro, just wanted to finish investigation
[14:55] <mterry_> asac, I could take more, if you're willing to suffer a delay to review
[14:55] <asac> mterry_: ok. i will give you one more for today ;) ... and leave you alone for a week to give you air to breath ;)
[14:56] <asac> mterry_: i think 1-2 weeks is ok (unless its blocking alpha3)
[14:57] <JontheEchidna> avogadro is an optional build dep, but we shipped with avogadro support in the past when the library was part of kdeedu. So it won't block alpha 3 for it to not be in main, but is a priority to us to get in before final as to prevent a feature regression
[15:00] <asac> JontheEchidna: lets not remove pressure from that MIR then ... just fix whatever mterry_ wants you to fix
[15:00] <asac> :)
[15:00] <JontheEchidna> :)
[15:04] <mterry_> JontheEchidna, plus, I believe it was already promoted and the review is an after-the-fact deal
[15:17]  * ogra wonders why calling reboot from an init-bottom initramfs script doesnt do anything
[15:31] <LucidFox> Gah, so many magic numbers in Murrine
[15:34] <cjwatson> chrisccoulson_: could you look at bug 601009?  I see you were the last uploader
[15:38] <chrisccoulson> cjwatson, yeah, will try and look at that later
[15:43] <cjwatson> chrisccoulson: thanks, can I assign it to you?
[15:43] <chrisccoulson> cjwatson, yeah, feel free to
[15:44] <cjwatson> done, thanks
[16:03] <bvleur> Anyone know where I can learn more about btrfsck output? I've got lots of lines ending in "errors 400", but I can't seem to find what that means
[16:12] <cjwatson> bvleur: #btrfs is more likely to be able to give a good answer than here, I think
[16:13] <bvleur> cjwatson: Thanks!
[16:27] <dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 33 minutes in #ubuntu-classroom
[16:28] <dholbach> warp10, BlackZ: ready? :)
[16:33] <BlackZ> dholbach: of course! \o
[16:33] <dholbach> excellent
[18:42] <jdstrand> cjwatson: hi! so, micahg just asked me to handle bug #605453
[18:43] <jdstrand> cjwatson: he was told that AAs would be able to do this, but I don't know how and there isn't anything in ArchiveAdministration that I can see that deals with this
[18:43] <jdstrand> cjwatson: a) is this something AAs should be doing and b) is there a wiki page describing the process?
[18:43] <cjwatson> jdstrand: if they all look mozilla-ish to you, then that's fine; use an up-to-date lp:ubuntu-archive-tools, and ./edit_acl.py -P mozilla -S maverick -s foo -s bar -s baz ... add
[18:43] <cjwatson> no docs for this that I'm aware of, sorry
[18:43] <jdstrand> cjwatson: do you mind if I add it to the wiki?
[18:44] <cjwatson> that's OK - just don't add permissions for *people* using that tool without the approval of the TB/DMB as appropriate
[18:44] <cjwatson> in general assigning packages to package sets is much like assigning them to components in terms of privilege level, i.e. yes it's something AAs can and should be doing
[18:44] <jdstrand> cjwatson: I'll be sure to mention that this is for established teams
[18:45] <cjwatson> that wasn't quite what I meant
[18:45] <cjwatson> but yes, I guess that's close enough :)
[18:45] <jdstrand> yeah, I guess there could be individuals that already have access
[18:45] <cjwatson> edit_acl.py can also grant a person access to a package set, and that sort of thing
[18:45] <jdstrand> anyway, I'll add something about being careful
[18:46] <jdstrand> k
[18:46] <cjwatson> and there are also some permissions for individuals that it's OK to extend; for instance till-kamppeter has general approval to upload printing packages, although at present there's no package set for that since it's just him
[18:46] <jdstrand> cjwatson: are these permissions that the TB has approved listed somewhere?
[18:47] <jdstrand> I could refer to that
[18:50] <cjwatson> jdstrand: probably not :-/
[18:51] <jdstrand> k
[18:51] <jdstrand> cjwatson: thanks for the info
[19:12] <geser> jdstrand: I guess you should ask for a link to the minutes where it was approved if you want to be sure
[19:16] <jdstrand> cjwatson: I added https://wiki.ubuntu.com/ArchiveAdministration#Adjusting%20Launchpad%20ACLs
[19:17] <jdstrand> cjwatson: though, the command doesn't work for me:
[19:17] <jdstrand> $ ./edit_acl.py -P mozilla -S maverick -s instantbird  addThere was an error:
[19:17] <jdstrand> (<lp.soyuz.model.packageset.Packageset object at 0x2aaab6a60b10>, 'addSources', 'launchpad.Edit')
[19:17] <jdstrand> that didn't paste right
[19:17] <jdstrand> ./edit_acl.py -P mozilla -S maverick -s instantbird  add
[19:17] <jdstrand> There was an error:
[19:17] <jdstrand> (<lp.soyuz.model.packageset.Packageset object at 0x2aaab6a60b10>, 'addSources', 'launchpad.Edit')
[19:19] <geser> IIRC only TB members can do it
[19:22] <geser> bug #562451
[19:23] <jdstrand> a
[19:23] <jdstrand> h
[19:23] <jdstrand> geser: ok, thanks
[19:25] <jdstrand> wiki adjusted
[19:40] <geser> jdstrand: I looked at the LP code and *if* I understood it correctly, then LP admins and the owner of a packageset can edit it. The owner of all (except two) package sets it the TB (the owner of the remaining two is DMB).
[19:42] <jdstrand> interesting
[20:06] <micahg> cjwatson: jdstrand was stopped by bug 562451, what should I do (if anything)?
[20:10] <dieki> If a screenshot in the software center is out of date or incorrect, where do I report a bug? Against the package? Against the software center?
[20:14] <JontheEchidna> dieki: submit a new one at screenshots.debian.net
[20:15] <JontheEchidna> (this is where the screenshots come from)
[20:17] <dieki> JontheEchindna: I did. Months ago. Nothing ever happened with it.
[20:19] <dieki> It was for the package gimp, so I'm sure other people have submitted screenshots as well. However, the current screenshot still shows GIMP 2.4.
[20:25] <dieki> JontheEchidna: Since that failed, what should I do next?
[20:26] <JontheEchidna> wait, I guess
[20:27] <JontheEchidna> filing a bug report won't really help, since we have just about as much controll over screenshots.debian.net as you do
[20:27] <dieki> Okay.
[20:27] <dieki> I wish Canonical/Ubuntu would handle screenshots themselves...
[20:31] <maxwellian> Does anybody have a link to a good explanation of how fakeroot works?  I've read the part about wrapping standard library functions, but how does it keep track of the changes it's pretending to make?  Why do other utilities believe these changes took place?
[20:32] <maxwellian> It seems like black magic to me.
[20:33] <geser> jdstrand: if you agree that the request from bug 605453 is valid, I could try if being the owner of the package set is enough to edit it add those packages (the mozilla package set is owned by DMB)
[20:41] <jdstrand> geser: I was fine with instantbird, nspluginwrapper and weave. the other three are all in universe, but it wasn't clear why they should be in the package set (gxine and mongodb build depends on xul, but mediatomb is unclear)
[20:41] <chrisccoulson> jdstrand, mediatomb is using spidermonkey
[20:41] <chrisccoulson> as are gxine and mongodb
[20:42] <micahg> jdstrand: sorry, I should have specified more about those
[20:42] <chrisccoulson> instantbird looks pretty neat
[20:42] <jdstrand> does just using those packages mean that they should be in the mozilla package set? forgive me, but I am new to these acls
[20:43] <hdon> hi all. i am using jaunty on x86_64 platform. apparently the glibc has gnu ifunc but the gdb does not. is there a repo somewhere that has the correct gdb? i cannot do simple things in gdb like: call strlen("test")
[20:43] <micahg> jdstrand: I was trying to add stuff that I'd be likely to maintain
[20:43] <chrisccoulson> jdstrand, that was the idea for this packageset (it would contain the packages that the mozillateam regularly touches)
[20:44] <jdstrand> well, I can't actually do anything about it. geser can make the call on those, but I imagine he would like an email/wiki reference
[20:45] <geser> micahg, jdstrand: Added weave, instantbird, nspluginwrapper (being owner of the package set works)
[20:47] <micahg> geser: thanks, but what about the other ones ( the mozjs packages)?
[20:48] <geser> checking what exactly got approved by the DMB and if those package match it
[20:49] <jdstrand> geser: thanks for working on this :)
[20:49] <micahg> geser: here's the package set if it helps: http://qa.ubuntuwire.com/multidistrotools/mozilla.html
[20:49] <chrisccoulson> geser - things like gnome-shell and gjs have been approved (as an example of other spidermonkey applications)
[20:57] <geser> micahg, chrisccoulson: sorry for being extra cautious, it's the first time I edit a package set. mongodb and gxine have a xulrunner-dev build-dependency => so they are ok (xulrunner rdepends). But where is the connection from mediatomb to xulrunner?
[20:58] <micahg> geser: no problem, mediatomb js was disabled, but I was going to add it back since people wanted it
[21:01] <geser> chrisccoulson, micahg: added the three other too
[21:01] <micahg> geser: awesome :) thank you very much
[21:02] <chrisccoulson> thanks geser :)
[21:02] <micahg> jdstrand: thanks to you too
[21:03] <jdstrand> geser: thanks
[21:03] <geser> cjwatson: adding packages to the mozilla package set is done
[21:04] <micahg> geser: how should I go about these requests in the future?
[21:07] <geser> micahg: good question, I don't think there is process for it yet. But filing a bug looks good, subscribe the DMB to it (as the DMB is owner of the Mozilla package set and can edit it) and poke a DMB member (I don't believe the DMB looks at bugs regularly yet)
[21:08] <micahg> geser: ok
[21:09] <micahg> geser: I was also wondering if the package set could be allowed for Lucid
[21:14] <geser> micahg: don't know, perhaps cjwatson can answer that
[21:14] <cjwatson> jdstrand: hm, drat, I thought you had access but obviously not
[21:14] <geser> in any case, the owner of a package set can edit it, but only TB members can create them
[21:15] <cjwatson> geser: thanks for handling that
[21:16] <micahg> cjwatson: I was wondering if the package set could be allowed for Lucid
[21:16] <cjwatson> micahg: I haven't generally been doing them for stable releases, no, because it takes ages to sync everything up and stable uploads require special approval anyway
[21:16] <micahg> cjwatson: ok, thanks
[21:17] <cjwatson> each series has a different instance of the package set ... this is necessary, but it does mean things are painful to do retroactively
[21:44]  * achiang can't seem to wrap his head around GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT
[21:46] <achiang> if the former=10, and the latter=10, my impression was that the menu is supposed to be hidden for 10 seconds, and then we boot into whatever the default menu option was
[21:47] <achiang> other documentation makes it seem like the only way to turn off the menu is to set GRUB_TIMEOUT=0
[23:19]  * ccheney forgot the syntax to push a branched bzr repo to his own area on lp
[23:19] <ccheney> anyone happen to know where to point me?
[23:21] <ccheney> i thought it was something like: bzr push lp:~ccheney/+branches/uec-provisioning  but that appears to not be quite right
[23:23] <ccheney> ah managed to get bzr to tell me
[23:23] <ccheney> bzr push lp:~ccheney/uec-provisioning/branch