=== bjf is now known as bjf-afk === asac_ is now known as asac [00:36] hi folks [00:36] needing a hand with custom install cd and ubuntu installer.. [00:36] it's freezing when loading bash package. [00:36] no sure but looks like libncurses is not being loaded for some reason... [00:37] anyone? === mrooney1 is now known as mrooney [01:10] Can somebody help move Empathy dependencies to main and change the desktop seed? https://bugs.launchpad.net/ubuntu/+source/telepathy-farsight/+bug/388898 [01:10] Ubuntu bug 388898 in telepathy-farsight "Move Empathy Dependencies to Main and Update Desktop Seed" [High,Fix released] [01:13] dtchen: ping? [01:13] Why did you mark bug 192590 as "Fix Released"? [01:13] Launchpad bug 192590 in graphviz "dotty hangs" [Low,Fix released] https://launchpad.net/bugs/192590 [01:13] I see no evidence of this being the case for Hardy [01:17] Caesar: it is "Fix Released" because it is fixed in the development version, karmic koala. See https://wiki.ubuntu.com/StableReleaseUpdates for info on how to request an update for previous versions of ubuntu. [01:18] Ampelbein: did you look at the bug in question? [01:19] Caesar: What bug it is doesn't change the fact that Hardy isn't relevant for marking a bug fix released. [01:19] ScottK: I suspect we're in violent agreement here [01:20] Basically it looks like someone was preparing an SRU, possibly went dark, and then in the meantime someone marked the bug as Fixed [01:20] Meanwhile, down on the Hardy ranch, the bug is still very much alive and well === dyfet_ is now known as dyfet [01:25] Caesar: the debdiff was submitted when hardy was still in development, there were some problems with it and the patch submitter didn't bother to do the changes requested. So now it's still broken in hardy, there you are right. If you want it fixed, I'm afraid you'll have to request a SRU. [01:26] Right then [01:26] * Caesar digs out his SRU-making pants [01:27] Caesar: you can check with one of the team members on irc first to see If they are likely to approve it: https://edge.launchpad.net/~ubuntu-sru/+members [01:28] does anyone know why the nvidia module won't build in dkms? i compiled the daily kernel from linus's tree...and installed the headers, source, and image, but dkms won't build the nvidia module [01:28] billybigrig: any error message? [01:28] yeah [01:28] billybigrig: care to share it? [01:28] sudo dkms add -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13 [01:29] err whoops [01:29] sorry [01:29] :(\ [01:29] ;-) [01:29] ya i care to share gimme a sec :P [01:29] Error! Bad return status for module build on kernel: 2.6.31-rc2-billybigrigger-07.13 (x86_64) [01:29] and then says consult make.log [01:29] so it says... [01:30] *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1 [01:30] sudo dkms build -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13 [01:30] that is the command i tried [01:30] billybigrig: How did you install the kernel headers, and where did you put them? [01:31] linux-headers-2.6.31-rc2-billybigrigger-07.13_2.6.31-rc2-billybigrigger-07.13-10.00.Custom_amd64.deb [01:31] billybigrig: How did you build the kernel? [01:31] CONCURRENCY_LEVEL=3 time fakeroot make-kpkg --initrd -append-to-version=-billybigrigger-07.13 kernel_image kernel_headers kernel_source > ~/make.log 2>&1 && git reset --hard origin/master && git clean -xdf && git pull [01:32] from a git clone of linus's tree [01:32] And you only had one headers package get built? Did that package create a build symbolic link in /lib/modules/kernelversion? [01:33] billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13/build$ ls [01:34] you want to see the list? [01:34] Is there a symbolic link called build there? [01:35] If not, create a symbolic link called build, which links back to the headers directory for the kernel in /usr/src [01:35] im in build [01:36] billybigrigger@cabo:/lib/modules/2.6.31-rc2-billybigrigger-07.13$ ls [01:36] build is cyan colored when i ls [01:36] im pretty sure thats a symlink isn't it? [01:36] lrwxrwxrwx 1 root root 30 2009-07-13 16:40 build -> /home/billybigrigger/linux-2.6 [01:36] yeah so thats right [01:37] Ok. Where did the headers package install the header files? In /usr/src? [01:38] yes [01:38] I suggest changing the build symlink to point to that directory where the headers are instead. [01:45] sudo rm build && sudo ln -s /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/ build [01:45] ? [01:45] or is it build /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/ [01:46] and i guess it would be build/ right? [01:46] no the former is correct [01:46] The / is not needed [01:48] so /usr/src/xxxxx build [01:48] yep [01:48] lrwxrwxrwx 1 root root 55 2009-07-13 18:48 build -> /usr/src/linux-headers-2.6.31-rc2-billybigrigger-07.13/ [01:48] man ln for more info [01:48] k [01:48] yep that looks fine [01:48] now try and run the dkms command again [01:53] nice [01:53] thanks TheMuso [01:53] nvidia, 185.18.14, 2.6.31-rc2-billybigrigger-07.13, x86_64: installed [01:53] is there a way to re-build all dkms modules? [01:53] i have a few and would rather not do them manually [01:54] a bunch of vbox stuff [01:54] like how dkms does its post-inst stuff after a kernel image install, where is that script located? [01:54] can't i just run that? [02:00] billybigrig: I don't know how thats done sorry. [02:00] man dkms may tell you however. [02:01] still cant boot that kernel [02:02] billybigrig: ah "sudo /etc/init.d/dkms_autoinstaller start kernelversion" [02:03] should do it [03:50] I just need a kernel with CONFIG_HZ = 1000... I am using ubuntu server and the default kernel is set to CONFIG_HZ = 100... is there a pre-built kernel I could use with this option? [03:51] or is there a way to use ubuntu server with the desktop kernel installed? [03:51] You can install the desktop kernel and use it, but that's a support question and not a development question. [03:53] ScottK: ah.. okaythanks [04:06] Lovely. Reliable and repeatable OOo crash in a document that has business sensitive stuff in it so I can't use it for a bug report .... [04:07] \o/ [04:09] ScottK: But that's how it always happens ... [04:10] Right. It's not like I'm suprised. [04:11] It's one of these fill-in the form and you can't change all these parts and it must be just so work document that is exactly the kind of thing that would be bugged. [04:11] work/word [04:11] morale of the story, don't use Oo. for anything you care about? [04:11] What's your alternative that handles MS Office file formats? [04:12] Everything else I know of sucks even more. [04:12] I didn't think abiword or gnumeric handled the embedded stuff? [04:12] I don't think so. [04:13] Kwrite neither. [04:13] hi [04:18] For a while I tried including an ODF copy with the MS Office copy of stuff I sent to customers to raise awareness. Then $LARGE_CORPORATION's spam filter decided ODF was dangerous and must be blocked. [04:19] ouch [04:19] I had a nice chat with their mail admins, but their spam filtering software was proprietary so all they could do is file a bug with the vendor. [04:19] So then I decided not getting fired for not sending stuff was more important than raising awareness. [04:51] <\sh> moins [05:30] Does anyone know where is the official ISO build described? I need to test some changes to isolinux (assuming the karmic iso uses karmic's isolinux). [06:49] good morning [06:51] dholbach: good morning :) [06:51] hey JonDoe297 [07:07] Good morning [07:07] NCommander: retracer> just launchpadlib crashing with HTTP 500 errors a lot [07:08] pitti: UNR (and Ubuntu) livefs builds are broken due to brasero and nautilus-cd-burner Conflict'ing, halp? [07:11] slangasek: re-added; hm [07:12] StevenK: hm, drop n-c-d? [07:13] StevenK: I think it was done as an upgrade cleanup [07:14] pitti: We don't seed n-c-d [07:15] piA nautilus Recommends nautilus-cd-burner | brasero (>= 2.26) [07:15] And I think germinate will always jump for the first [07:16] StevenK: ah, I guess the ubuntu desktop seeds seed brasero earlier than nautilus or so [07:17] StevenK: where did you see this, BTW? [07:17] http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090713-i386.out is differntly broken [07:17] 0714 [07:17] http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090714-armel.out is an evolution thingy [07:18] any/all desync, as it looks? [07:18] interesting, _all_ arches have a different failure [07:18] Yeah, Ubuntu i386 hasn't tried yet [07:18] Anyway: [07:18] pi ubuntu-netbook-remix Recommends rhythmbox [07:18] pi rhythmbox Depends libbrasero-media0 (>= 0.9.1) [07:18] piA libbrasero-media0 Recommends brasero [07:18] so is this since yesterday then? [07:19] brasero was added ages ago [07:19] Right, so UNR should seed brasero, too? [07:19] I don't think that makes sense. [07:20] StevenK: oh, did you already NBS out libsgutils{1,2}? [07:20] pitti: I've not done NBS in a week or so [07:20] I did the transition yesterday, but no NBSing yet [07:20] StevenK: we could just flip around the nautilus dep [07:21] pitti: That works [07:21] * pitti uploads === tkamppeter_ is now known as tkamppeter [07:39] * \sh should write a rant about klibc's ipconfig dhcp crap inside initramfs while using real network switches and not soho cheap table switches from netgear [07:47] kirkland: thanks muchly, this is so much better now [07:51] * mneptok is about to fly to Armonk and set IBM on fire [07:52] question: if i have a debdiff for a package waiting for sponsorship to close one bug and i have another bug in that package that i want to fix, should i do the debdiff for this bug against the currently-in-karmic version or against the one that's waiting for sponsorship? [07:52] and not happy, warming Yule log fire. ANGRY BALROG MOUTH FIRE! [07:53] or just put one debdiff to do both? [07:55] <\sh> maco: do one debdiff to do both...add both (LP: #) to the changelog in the debdiff [07:55] ok. ive been told before one bug per upload so wasnt sure [07:57] <\sh> maco: TBH i don't think there is a policy or rule...but could be wrong.. [07:58] im gonna guess it was just a housekeeping thing. and with quilt, youve got plenty of housekeeping [07:59] :( lp timing out [07:59] <\sh> maco: btw...I added some links about the cult of virgin mary to mdzs blog .. just waiting until he moderates his comment area [08:00] robert_ancell: you writing a gdm replacement? pitti said so! :) [08:01] ... configuration :) [08:01] that's going to be headline news tomorrow [08:01] * robert_ancell feels thrown to the wolves :) [08:02] <\sh> it's all about marketing ;) [08:02] I've got the GUI mocked up and know the config to change. The difficulty is navigating the policykit/dbus/... in between [08:06] i didnt break quilt this time :D [08:09] * TheMuso kicks speech-dispatcher's autotools files where it hurts most, and leaves it for tomorrow. :) [08:10] maco: Are you sure? [08:11] StevenK, yes. quilt informed me that my patch level was wrong (forgot to add little a/ and b/ to --- and +++ lines) and then i push -a'd and it was happy [08:11] i even remembered the QUILT_PATCHES env var [08:11] quilt always curls up into a little ball when I mistreat it [08:13] ive been actively using quilt for the last 2 weeks, so its soaking in [08:14] though ive only got the routine down for quilt import so far. havent tried the start quilt, edit things, stop quilt thing yet [08:14] All this mentioning of quilt is making me want to sob [08:14] what if its the kind little amish women sew? [08:15] i can go grab my needlecraft stuff to trick your brain... [08:15] maco: I wasn't aware you were Amish [08:15] * StevenK hides [08:15] my facebook profile used to list Amish as my religion [08:16] Hah [08:16] a scarily large number of folks believed it [08:16] amish...facebook...amish...facebook... [08:19] <\sh> twitter, facebook, youtube what product comes next to steal important life and working time [08:20] is youtube newer than facebook? [08:20] wait, twitter too? [08:20] <\sh> in the beginning there was usenet ,-) [08:21] heh [08:21] hmm on the hundred papercuts thing. if youre just reporting a bug so youll have something to hang the debdiff on, is it worth marking it as a papercut? [08:34] maco: just subscribe sponsors, FWIW [08:34] maco: the papercut queue is pretty full, and IIRC David asked not to add more [08:36] pitti, ok thanks [08:47] maco: a friend of mine lists his religion on facebook as chaotic good. [08:48] hey mine currently says Church of Vi [08:48] one friend asked what about my Pastafarianism. i said "polytheism" [09:11] pam: I just keep some canned runes around derived from how the CD image building stuff works ... [09:11] sudo mkisofs -r -V 'Ubuntu 9.10 i386' -o karmic-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386 [09:22] pitti, my powermanager tends to crash after some time, is there a known bug for this ? [09:23] ogra: not to me, but I'm not regularly following them [09:23] hmm, k [09:23] ogra: yesterday's update fixed a bug which made gpm crash when the battery got full [09:24] ah, that might be it, though i rarely unplug at home and didnt actually monitor when exactly its happening ... [09:25] i have the brightness applet in my panel and notice that it is crossed out in the morning usually until i fire up the power prefs [09:26] nothing intresting in .xsession-errors ... [09:26] .xsession-errors is a sucky logging facility... [09:26] ogra: no apport crash either? [09:26] (it would reallly help to have timestamps in that file) [09:27] nope, no apport [09:27] ogra: but perhaps it's fixed with yesterday's update [09:27] ogra, http://blog.liw.fi/posts/userlog/ :) [09:28] * ogra runs an upgrade and will watch if it occurs again tomorrow morning [09:28] http://tinyurl.com/nkypfa [09:28] liw, :) [09:29] liw, sounds like something to spec next UDS to me [09:29] though i would be happy already if we had timestamps [09:32] pitti, where does jockey get the text it displays explaining the driver it's offering? [09:34] (i see you in (C) line) [09:41] nevermind. i figured it out. === Quintasan_ is now known as Quintasan [09:54] maco: ok :) === pbn_ is now known as pbn [10:22] seb128, did you upload gtk and the apps out of order again ? [10:22] The following packages have unmet dependencies: [10:22] gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed [10:22] ? [10:22] is what i see on armel [10:22] there is no order, gtk didn't change abi or soname or anything [10:22] hmm, strange [10:22] well that probably means that gtk didn't build on armel [10:23] i'll try a give back of evo and friends [10:23] arch all/any desync [10:23] and arch any and all binaries are out of sync [10:23] it isnt on the ftbfs list, i think its just a timing issue [10:23] * ogra gives back gtkhtml [10:47] * ogra grumbles at whoever gave back mesa on armel [10:56] james_w: did you say you have a fix for the harvest-django filter problem? [11:02] dholbach: a partial one [11:02] I have a better idea though [11:02] heh, I can't seem to edit bug titles in LP today [11:04] james_w: I was just thinking "having the fix/workaround in trunk already would make testing and playing with it more interesting" :) [11:04] ok, ok :-) [11:12] hmm, why is pbuilder attempted to be built on the ports arches ? [11:12] Package: pbuilder [11:12] Architecture: all [11:12] weird [11:14] How should I deal with package that uses a src directory? When you untar the package there is only install.sh src/ and README. Pbuilder complains about missing CMakeLists.txt. [11:16] err that depends on what's in src/ :-) [11:16] basically your debian/rules build needs to do whatever the package says needs to be done to build its source code [11:16] there are no fixed rules [11:16] oh, hmm [11:17] Package: pbuilder-uml [11:17] Architecture: i386 amd64 [11:17] cjwatson: it's a plasmoid, I use pkg-kde-tools for compiling it. I think DEB_SRCDIR = src might solve it [11:20] * ogra wonders why armel isnt respecting "Architecture: i386 amd64" in the control file [11:21] ogra: Packages-arch-specific controls what is *attempted*. if debian/control forbids it then of course it will fail [11:21] cjwatson, well, it even attempts to build pbuilder-uml in a local build [11:21] (on armel) [11:22] "Architecture: i386 amd64" should prevent that, shouldnt it ? [11:23] ogra: should it? [11:23] i would expect it to :) [11:23] you expect wrong :) [11:23] seemingly [11:24] ogra: whether a source package attempts to build one of its binary packages is controlled entirely by debian/rules, not by debian/control [11:24] after all it's just what debian/rules build / binary depend on [11:24] well, all pbuilder-uml stiff is in binary-arch [11:24] while all the rest is in binary-indep [11:25] doesnt seem wrong to me [11:25] so why should it magically not get built then? [11:25] a -B build basically just does debian/rules build && fakeroot debian/rules binary-arch [11:26] if the package wants to do things only on certain architectures, it needs to conditionalise that in debian/rules [11:26] hmm, wouldnt it make more sense to check the control file ? [11:27] maybe if we were doing it from scratch; but it's not done that way now [11:27] if its not Architecture all or any at least [11:37] -s, --same-arch [11:37] This is a smarter version of the -a flag, that is used in some rare circumstances. It understands that if the control file lists "Architecture: i386" for the [11:37] package, the package should not be acted on on other architectures. So this flag makes the command act on all "Architecture: any" packages, as well as on any [11:37] packages that have the current architecture explicitly specified. Contrast to the -a flag, which makes the command work on all packages that are not architecture [11:37] independent. [11:37] cjwatson, ^^^ [11:37] then i dont understand the debhelper manpage [11:38] (pbuilder uses "dh_builddeb -s" for binary-arch [11:38] ) [11:40] (well, it uses -s not only for builddeb but for all commands) [11:42] i wonder if that flag not doing what is described is a fallout of the --dpkg-print-architecture change in dpkg [11:42] *--print-architecture [11:57] ogra: that causes *those specific debhelper commands* to act on the named packages [11:57] ogra: why don't you use DH_VERBOSE=1 so you can see exactly what's going on? [11:57] you seem to be blaming the tools, which IME is usually a mistake [11:57] * ogra does so ... but the code didnt change, the tools did though [11:57] they aren't perfect but it's not usually a good bet for a first guess [11:59] BTW, why is it a problem for pbuilder to harmlessly fail to build on non-x86 architectures? [11:59] you can just ignore it [11:59] it fills up my ftbfs list ... [11:59] you can still just ignore it :) [11:59] just sense of cleanness :) [12:01] pbuilder-uml is listed in Packages-arch-specific, so it's probably a Soyuz bug that it's tried [12:02] wel, my local system doesnt have PAS [12:03] then it'll fail on your local system. big deal :) [12:03] if i want to roll pbuilder here from source it fails [12:03] well, it actually doesnt because it calls arch-indep first if built locally, so i get my pbuilder deb ... [12:04] *build [12:05] BTW it can't possibly be fallout from the dpkg change you mention [12:06] 1) debhelper uses dpkg-architecture not dpkg --print-installation-architecture 2) dpkg --print-installation-architecture just prints a warning to stderr and calls through to --print-architecture [12:06] yep, i just looked at Dh_Lib.pm [12:07] debuild -b -aarmel works here [12:07] bunch of whining from dh_* -s but that's all [12:07] you aren't using -B are you? [12:09] no, and debuild -b -aarmel fails here on my amel machine [12:12] oh, wait, it fails on signing not due to -s [12:13] ok, now i'm completely confused === MacSlow is now known as MacSlow|lunch [12:42] Keybuk, ... [12:42] * Starting kernel event manager... error getting signalfd [12:42] [fail] [12:42] invoke-rc.d: initscript udev, action "restart" failed. [12:42] Keybuk, thats what i get on armel with a dist-upgrade [12:44] next time we announce a new port of Ubuntu, let's find an architecture that the kernel really supports [12:45] like m68k or something [12:45] haha [12:45] I assume that ARM has "forgotten" to implement signalfd() or something [12:45] well, the boards i have all only have a 2.6.26 binary kernel atm [12:46] ah [12:46] no source ... whats the kernel option that creates signalfd ? [12:46] yeah that probably won't work anyway [12:46] I think the syscall changed in 2.6.27 [12:46] gah [12:46] i though it changed post .25 [12:46] there's no kernel config [12:46] oh, k [12:46] * ogra just saw bug 397187 [12:46] Launchpad bug 397187 in ubuntu-on-ec2 "[karmic] udev requires new kernel, breaks on EC2" [Undecided,Confirmed] https://launchpad.net/bugs/397187 [12:47] oh, heh [12:47] yeah see my comment there too [12:47] so i'm not alone [12:47] yep [12:47] does upstart *already* use it in 0.6 ? [12:47] yes, but not for anything critical [12:47] ok [12:48] i'll try to downgrade udev then until we finally get something usable from the kernel team [12:48] a bug fix going into 0.6.1 makes it use it for critical things though [12:48] though i bet that will cause other issues [12:56] grmbl, why isnt signalfd mentioned anywhere in the udev changelog [12:57] how am i supposed to find out which is the last version i can use :( [12:57] bah [13:02] pitti, oh ... Jul 14 13:55:41 osiris kernel: [98748.268006] <6>gnome-power-man[23647]: segfault at 838b0c24 ip 004b0701 sp bfc7ba60 error 6 in libc-2.9.so[43f000+15c000] [13:02] just found that by accident in my /var/log/messages [13:02] ogra, use apport to send a bug? [13:02] ogra, just mentionning a crash on IRC without any detail is of no real use [13:03] seb128, i'm not up to date with my system yet, i was following up on an earlier conversation === mac_vr is now known as macvre === mac_vr is now known as macvre === MacSlow|lunch is now known as MacSlow [13:26] bah i was to fast giving back evolution-exchange ... === macvr is now known as mac_v === mac_v is now known as mac_V === mac_V is now known as mac_v_ === mac_v_ is now known as mac_V_ === mac_V_ is now known as mac_v === mac_v is now known as mac__v === mac__v is now known as mac_v [13:40] evand, again thanks for the catch. No summary is normal for me, coming from oem-config land. :) I merged your patch [13:42] james_w: how would I make lp:~ubuntu-core-dev/upstart/ubuntu be the "Ubuntu" branch (lp:ubuntu/karmic/upstart) ? [13:42] Keybuk: I can do that for you [13:43] however, I'm wary to make *that* branch the one to use given a couple of LP bugs we have at the moment [13:44] I can push it to another location and make that lp:ubuntu/karmic/upstart [13:44] mterry: great! I think given cjwatson's recent comment on the merge page, we're ready. [13:44] or we can wait for LP to be fixed instead [13:44] I've added you to the installer team, so you'll be able to commit directly to trunk now [13:45] * mterry is nervous anyway [13:45] also, would we be able to resurrect branches for < karmic? [13:45] evand, is there a test suite for the installer that the branch has been run through, or can be run through? [13:45] nope, but patches welcome for that [13:45] evand, oh, thanks for the team add [13:45] evand, heh [13:45] it is something we have on the horizon, but neither Colin nor myself have found time to write it [13:46] evand, maybe I could look into that. I have some experience with ldtp [13:46] mterry: any effort you can make on that would be hugely appreciated [13:47] evand, OK, well, I'll merge this branch, and keep an eye out for bugs reported, I guess === bjf-afk is now known as bjf [13:58] ogra: can you please enable apport then (/etc/default/apport) and send a crash report? thanks! [13:59] pitti, will do if it turns up with the upgrade, sorry i'm to busy today to donate time to that atm [13:59] ogra: no prob, just enable apport and let it sort out itself :) [13:59] yep [14:13] james_w: don't mind if you need to move the branch, the lp:ubuntu/... URL is better ;) [14:14] james_w: there's no real ubuntu/jaunty branches - while there was something in bzr, it actually was buggered up and missing all the changes [14:14] just the changelog entries [14:20] Keybuk: ok, I could do that [14:20] not having the branches available is a bit of an annoyance [14:21] james_w: they never really existed properly - you could do an auto-import of them if you liked [14:22] plus, it would currently take away your ability to write to the branch [14:22] which I imagine would be a pain for you? === dholbach_ is now known as dholbach [14:24] james_w: err [14:24] it would be kinda helpful to write to the branch :p [14:24] why wouldn't I be able to? [14:25] because the move would be out of the namespace of a team that you are a member of [14:25] so who can commit to lp:ubuntu/... branches? [14:25] shouldn't that be developers? [14:25] *confused* [14:25] we are waiting on LP to make the permissions for official branches match the uploaders [14:25] yes, it should be [14:25] it is not currently [14:26] oh, who is it currently? [14:26] and due to the other LP bug I mentioned, the branches can only be owned by the team we are using for "special" privileges [14:26] it's a team called ~ubuntu-branches [14:26] it's members are me and jml IIRC [14:26] err [14:26] so [14:26] and Colin actually [14:27] the lp:ubuntu/ namespace is really just read-only right now? [14:27] yeah [14:27] but that will be changing real soon now [14:27] what's the schedule for that bugfix anyway? it's been on the cards for ages [14:27] so I don't want to move the upstart/ubuntu branch there, because the whole point is people commit to it? :P [14:27] I'm not sure, it doesn't have a milestone yet IIRC [14:27] we need to sit on jml about that [14:27] or possibly thumper [14:27] Keybuk: yeah, but we can move it once that is fixed [14:27] ok [14:28] when that bug is fixed, does it just become an alias? [14:28] or will it still involve "moving" the branch? [14:29] bug 347768 [14:29] Launchpad bug 347768 in launchpad-code "Allow anyone with upload rights to write to a package branch" [High,Triaged] https://launchpad.net/bugs/347768 [14:29] the lp:ubuntu/... thing is an alias [14:30] however, you can't currently ask which branch that points to using the API without it crashing [14:30] so there is currently a hard-coded assumption that it is the branches owned by ~ubuntu-branches with a particular name [14:31] so once that is fixed we can just make the alias point to the ~ubuntu-core-dev branch if we like [14:31] would the same work for lp:debian/ [14:31] it might be nice for mbiebl to be able to have br branch lp:debian/sid/upstart for the Debian branch he maintains [14:31] however, we may want to move it anyway, so that it is a "package branch" [14:31] it will work for Debian [14:34] james_w: where would LP get information about who can upload to the Debian branches? [14:34] I suppose we could import the Debian keyring but I wasn't aware that we were doing that [14:34] ah [14:34] I assume it will have "branch owner, plus those able to upload to the Debian archive through LP" [14:34] * cjwatson comments on 347768 [14:34] which will be no-one [14:35] uploading to the Debian archive through LP would be a pretty odd thing to do :) [14:35] so only the owner will have write access [14:35] which I think is ok [14:58] that's kinda boring [14:58] bzr commit --fixes=lp:NNNNNN [14:58] doesn't mark the bug as "Fix Committed" [14:58] and links to the branch, not the revision [15:00] Keybuk: yeah, i've been disappoitned with --fixes too [15:00]