[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


[15:10] <ubotu> New bug: #162660 in soyuz "Allow autosync to follow experimental" [Undecided,New] https://launchpad.net/bugs/162660
[15:13] <PriceChild> I've got the option of editing other users' questions in all projects... I haven't actually tried going through with it yet but assume it'd work. About to file this as a bug unless its a "feature" in disguise?
[15:19] <Hobbsee> WTH is needing attention?
[15:19] <Hobbsee> this panel is needing attention or something?
[15:19] <Hobbsee> Questions needing your attention for Launchpad
[15:19] <Hobbsee> ah
[15:20] <Hobbsee> Launchpad has unanswered questions in the following languages: 1 in French. Can you help?
[15:20] <Hobbsee> how is it needing my attention, if it's not certain it's a question i can help with?
[15:20] <Hobbsee> and since when do i speak french?
[15:20] <r0ver> hello. Is it possible to delete a project started by myself ?
[15:25] <PriceChild> After editing the question, I can't see the original question either like you can with bugs
[15:33] <stdin> r0ver: no, you need a LP admin to do it
[15:39] <r0ver> stdin: ok, thanks
[15:46] <cprov-lunch> cprov
[15:47] <cprov> lamont: queue-mangler ?
[15:48] <lamont> er, queue-builder?
[15:48] <cprov> lamont: it runs on intervals of 30 minutes.
[15:49] <lamont> so, :00 and :30?
[15:53] <cprov> lamont: no it varies, it runs (32 min) and wait 30 minutes then runs again ... that's how the buildd-sequencer operates
[15:58] <lamont> ah, ok
[15:58] <lamont> so there's not really anyway to tell when it's running, other than by being on the machine?
[16:07] <Hobbsee> lamont: can you explain https://edge.launchpad.net/~kubuntu-members/+archive/+build/442279 ?  the binary which it's missing was built on the 29th, in that ppa.
[16:07] <Hobbsee> lamont: cprov says it's likely due to the new chroots.
[16:08] <Hobbsee> lamont: i'd guess that sbuild has stopped picking up the deps from it's own ppa for some reason, but it wasnt doing it before (see kdebase, iirc)
[16:14]  * lamont finishes screaming.
[16:14] <lamont> some days, I hateseseses my video card
[16:14] <lamont> other times, I hate the driver that crashes my machine from time to time
[16:15] <lamont> cprov: do you have the hardy tarballs where I can grab them?  that'll let me answer Hobbsee's question
[16:16] <lamont> err, actually, Hobbsee's question requires the gutsy/i386 tarball
[16:57] <Ubulette> is lpia (main) buildd broken ?
[16:57] <Ubulette> http://launchpadlibrarian.net/10366796/buildlog_ubuntu-hardy-lpia.xulrunner-1.9_1.9~b1~rc3%2Bnobinonly-0ubuntu1_CHROOTWAIT.txt.gz
[16:58] <Hobbsee> lamont: did you find the problem?
[17:35] <elmo> Ubulette: is that a PPA?
[17:35] <Ubulette> no
[17:35] <Ubulette> elmo, no
[17:35] <elmo> oh -1.9 is a separate source package
[17:35] <elmo> meh
[17:36] <elmo> ok, fixed the buildd, I think/hope, retrying the build
[17:36] <Ubulette> ok, thanks
[17:37] <Ubulette> elmo, could you force the retry for me please ?
[17:38] <elmo> Ubulette: I have done
[17:38] <Ubulette> excellent
[17:38] <Ubulette> thanks :)
[18:05] <Ubulette> elmo, it failed again, this time missing cdbs. could you save the day once more ? :)
[18:06] <elmo> I'm looking at it
[18:06] <Ubulette> http://launchpadlibrarian.net/10367122/buildlog_ubuntu-hardy-lpia.xulrunner-1.9_1.9~b1~rc3%2Bnobinonly-0ubuntu1_MANUALDEPWAIT.txt.gz
[18:06] <Ubulette> elmo, i don't get the missing + does not exist
[18:15] <ubotu> New bug: #162699 in soyuz "Add link to full build queue from Build details page" [Undecided,New] https://launchpad.net/bugs/162699
[18:21] <ubotu> New bug: #162703 in launchpad "Pre-release code notice should link to bug report page" [Undecided,New] https://launchpad.net/bugs/162703
[18:56] <ubotu> New bug: #162713 in launchpad "should complain loudly when different versions of internal services talk xml-rpc to each other" [Undecided,New] https://launchpad.net/bugs/162713
[18:56] <elmo> Ubulette: OK, I think I've found the problem.  I've set xulrunner-1.9 to rebuild... again.
[18:56] <Ubulette> thanks
[19:02] <elmo> Ubulette: aha, that seems happier now
[19:03] <Ubulette> indeed. Thanks a lot.
[19:31] <Ubulette> elmo, the i386 one has been fully built for more than 20 min but it's still stuck in the same status (Currently building), like if it was waiting for something to happen
[19:31] <elmo> Ubulette: I'll defer to cprov on that ...
[19:31] <Ubulette> ok. Thx. it's https://edge.launchpad.net/+builds/rothera
[19:32] <Ubulette> or https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/1.9~b1~rc3+nobinonly-0ubuntu1/+build/444687
[19:35] <Ubulette> cprov, could you help for ^^ ?
[19:36] <cprov> Ubulette: let me check
[19:38] <Ubulette> i've seen that many times in ppas, it eventually stops (ie timeout) after 3h doing nothing, then succeeds.
[19:41] <cprov> ubuntulog: slave-scanner was hung :(
[19:43] <Ubulette> oh, ok.
[19:44] <cprov> ubuntulog: uhm, but it's still building ...
[19:45] <Ubulette> yes
[19:46] <cprov> Ubulette: I can't be right.
[19:46] <Ubulette> hm ?
[19:48] <cprov> Ubulette: how long does it takes to build normally ?  would it be bad to lose this job result ?
[19:48] <Ubulette> 50min to 1h.
[19:49] <Ubulette> it's the main dep of firefox3, which just started so I expect it to fail
[19:49] <cprov> uhm, it is worth of some investigation then.
[19:49] <Ubulette> if you can restart it without me bumping it, fine
[19:49] <cprov> no worries, it will fail soon enough
[19:50] <cprov> no, we need to access the builder, elmo do you have time ?
[19:52] <Ubulette> ff3 is in dep wait now so i'm not worried. feel free to debug this xul build
[19:59] <Ubulette> lpia is in the same state
[21:41] <nealmcb> I'm looking at https://edge.launchpad.net/ubuntu/gutsy/+source/libvirt/ and noticing that there is no "code" tab and no project associated with it.  the project involved seems to be http://libvirt.org/ where they publish code via cvs.  I'm not quite clear on how to make that association - do I need to register a whole new project in launchpad, or is there a shortcut of some sort, or should I get the real maintainers to do it all?
[21:43] <pochu> nealmcb: try removing gutsy/ from the url
[21:44] <nealmcb> done
[21:47] <nealmcb> pochu: but I still don't see a project association or code tab.  I'm just thinking having launchpad pull their code and making it available via bzr would be handy, and remember seeing that encouraged somewhere but I don't remember the proper steps
[21:48] <ajmitch> yes, an upstream project needs to be registered in launchpad for that to happen
[21:48] <nealmcb> ajmitch: just the guy I was gonna talk to next :-)
[21:49] <ajmitch> oh dear, why?
[21:49] <nealmcb> so should I just go ahead and do that, and get a "series" and link the code base to it?
[21:49] <nealmcb> ajmitch: well, you pulled libvirt originally I guess
[21:49] <ajmitch> I believe so, yes
[21:50] <ajmitch> it's been awhile since I've looked at how to do imports & various things
[21:50] <nealmcb> that's why I came here to find the experts :-)
[21:51] <nealmcb> and should there be a super-project for virt-manager etc? or are they separate enough to remain separated?
[22:00] <mpt> Goooooooooooooooooooood morning Launchpadders!
[22:00] <ajmitch> hi mpt
[22:15] <mdke> has anyone used the gutsy installerfor a thinkpad t43? It seems to hang at the partition stage - gparted also just keeps scanning for devices continuously and I can't find /dev/hda or /dev/sda in order to try fdisk
[22:16] <mdke> gah, chan
[22:16] <mdke> sorry
[22:19] <nealmcb> so I'm at https://code.edge.launchpad.net/libvirt/+addbranch and it isn't clear where to put the cvs information for a mirrored branch
[22:20] <nealmcb> ajmitch: or is this mostly a pointless exercise?
[22:22] <thumper> nealmcb: branches are for bzr branches, not cvs
[22:23] <thumper> nealmcb: if you want to import from CVS then it isn't a mirrored branch, it is a code import
[22:23] <nealmcb> thumper: thanks
[22:23] <ajmitch> ah, you've awakened an expert that you were looking for
[22:23] <nealmcb> :-)
[22:25] <mpt> PriceChild, that you can edit any question is not a bug, the same is possible for bug reports
[22:27] <mpt> PriceChild, but that you can't get back the original question is bug 50562.
[22:27] <ubotu> Launchpad bug 50562 in launchpad-answers "Save original question when using 'Edit question'" [Medium,Confirmed] https://launchpad.net/bugs/50562
[22:27] <mpt> hi ajmitch :-)
[22:27] <thumper> nealmcb: see https://help.launchpad.net/VcsImports
[22:29] <nealmcb> ajmitch: but I am curious, is this helpful?  or will I just annoy the author Daniel Veillard?
[22:29] <thumper> nealmcb: project groups are only creatable by launchpad admins right now I believe
[22:29] <ajmitch> I don't think many authors would be annoyed, but it is useful
[22:30] <ajmitch> I believe it's necessary to register a project in order to mark a bug as affecting upstream
[22:30] <thumper> nealmcb: if you are registering a project but don't want to have much to do with it you can set the maintainer to some general registrant user, but I can't remember who exactly off the top of my head
[22:31] <ajmitch> registray administrators
[22:31]  * thumper wonders who's awake that'd know
[22:31] <ajmitch> s/ray/ry/
[22:31] <thumper> ajmitch: yeah, that's right#
[22:33] <mpt> hmmmm
[22:33] <mpt> perhaps registry administrators should be a radio button
[22:38] <nealmcb> thumper: getting close... so if the cvs command is  cvs -d :pserver:anoncvs@libvirt.org:2401/data/cvs co libvirt    is the module "libvirt"?
[22:38] <nealmcb> and is there any "branch"?
[22:40] <nealmcb> and can I specify the password somehow?
[22:45] <mwhudson> nealmcb: branch needs to be MAIN
[22:46] <mwhudson> the password can be specified in the CVSROOT
[22:51] <nealmcb> mwhudson: interesting - what is the syntax?  hints on how to do that would be helpful on https://help.launchpad.net/VcsImports
[23:01] <ubotu> New bug: #162754 in launchpad "Hard to disclaim maintainership of a project you're registering" [Undecided,New] https://launchpad.net/bugs/162754
[23:04] <nealmcb> mpt: nice feature request - thanks :-)
[23:04] <mpt> yw
[23:14] <mwhudson> nealmcb: i can't remember :)
[23:15] <nealmcb> it looks pretty clear to me that the libvirt project I've just registered was used for the gutsy libvirt package code and I assume the same is true for earlier releases.  but does it matter which release (gutsy, hardy, etc) I associate it with?
[23:18] <mwhudson> nealmcb: i _think_ it's just :pserver:user:pass@host:/root
[23:19] <mwhudson> yes, seems so
[23:20] <nealmcb> mwhudson: thanks
[23:38] <nealmcb> well, I registered the libvirt project for the hardy libvirt package.  it doesn't seem to affect gutsy, but that probably matters less
[23:38] <nealmcb> ta
[23:40] <ubotu> New bug: #162759 in malone "Source portlet says incorrectly says a package is in universe" [Undecided,New] https://launchpad.net/bugs/162759