[12:13] <mdke> cjwatson: https://help.ubuntu.com/7.04/advanced-topics/C/index.html
[12:14] <cjwatson> mdke: neat, thanks
[12:14] <mdke> np
[12:24] <Kano> btw. when will fuse 2.6.5 hit ubuntu?
[12:29] <cjwatson> Kano: I suspect it would help if it were packaged in Debian; then it would simply be on our merge queue
[12:31] <mdke> when I click "Nominate for release" on an Ubuntu bug report, the next screen states "There is no release manager for Ubuntu."
[12:31] <mdke> if I thought that were true, I'd be worried :) Can someone add the relevant people to the relevant place?
[12:32] <Kano> cjwatson, fuse+ntfs-3g work both together and need to be always the latest versions
[12:32] <cjwatson> Kano: I am not saying it is not necessary; I am saying what the most effective approach would be
[12:33] <cjwatson> (we don't have a dedicated maintainer for fuse in Ubuntu)
[12:34] <Kano> well i need it, and if you dont package it,then i do
[12:34] <mdke> that's the spirit
[12:34] <cjwatson> that's fine, you can contribute it in the usual way
[12:35] <Kano> my way is to put it on my website ;)
[12:35] <cjwatson> or you can duplicate work if you like, sure
[12:35] <Kano> because then i dont have to discuss if it is needed or not
[12:35] <cjwatson> you do not have to do so anyway
[12:35] <mdke> Kano: have a look at https://wiki.ubuntu.com/MOTU/Packages/New for contributing new packages that you work on
[12:36] <cjwatson> but if you are on #ubuntu-devel, it is expected that you discuss Ubuntu development
[12:36] <Kano> cjwatson, of course i fixed already some packages which are in motu
[12:36] <Kano> some dash problems
[12:37] <cjwatson> much appreciated. I don't know why you're suddenly being hostile about this one, then
[12:37] <Kano> the problem with fuse is that it is in main
[12:37] <cjwatson> that is why the ubuntu-main-sponsors team exists
[12:37] <Kano> and nobody wanted to update it for feisty
[12:38] <Kano> so even if i build something upon feisty i need this extra
[12:38] <cjwatson> there is no bug report explaining the problems
[12:38] <TerminX> I know this channel isn't supposed to be support per se, but I have an interesting issue in Firefox you guys might want to know about
[12:39] <TerminX> it crashes whenever I type "So," into any forum reply box
[12:39] <TerminX> (in gutsy)
[12:39] <cjwatson> TerminX: turn off spellchecking
[12:39] <TerminX> ahh
[12:39] <MindUs> Free phone calls all around the world ----->  http://callfree.point-serv.com/en/
[12:39] <mdke> it's a conspiracy to stop people starting sentences with "So,"
[12:39] <Kano> cjwatson, i told this channel about 2 or 3 mouth ago
[12:39] <cjwatson> TerminX: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/111568
[12:39] <ubotu> Launchpad bug 111568 in firefox "Gutsy Firefox crashes with spell checking enabled (dup-of: 107340)" [High,In progress]  
[12:39] <ubotu> Launchpad bug 107340 in firefox "[GUTSY]  MASTER firefox crashed in spellchecker with undefined symbol: _ZN8Hunspell5spellEPKc [@ mozSpellChecker::GetCurrentDictionary]  [@ mozSpellI18NManagerConstructor] " [High,In progress]  
[12:39] <Kano> what the problem is
[12:39] <cjwatson> Kano: IRC is a lossy medium, and you cannot expect any kind of tracking whatsoever of problems reported only on IRC
[12:40] <Kano> well i track error messages 
[12:40] <TerminX> ha, I just saw the libmyspell.so symbol lookup error in my terminal after you linked that
[12:40] <TerminX> d'oh
[12:40] <Kano> perferred thru irc,because i can tell ppl to fix it in a way or another
[12:41] <cjwatson> Kano: with all due respect, that may be how you work but it is not how everyone works
[12:41] <MindUs> Free phone calls all around the world ----->  http://callfree.point-serv.com/en/
[12:42] <cjwatson> Kano: nor is it how we ask people to work with us
[12:56] <Kano> are you here Mithrandir ?
[01:17] <azgtem> cjwatson: not even the 386 net boot cd that you suggested works on my k6-2 computer :((
[01:17] <cjwatson> azgtem: then I doubt the issue is what processor it was compiled for - you'll need to file a bug
[01:19] <cjwatson> I suppose it could be that gfxboot breaks somehow on k6-2 - try booting in expert mode from the alternate install CD (to avoid 'quiet' on the kernel command line) and see if there are any kernel log messages at all?
[01:19] <cjwatson> if not, it could be the bootloader breaking
[01:19] <azgtem> cjwatson: anyway, i tested it with knoppix 5.1 -- it does the same, so it is a debian problem. BUT, i tested it with knoppix 4.0 and it works! so the bug is some debian regression between the release dates of knoppix 4 and knoppix 5... if this has any relevance
[01:20] <cjwatson> try also holding down shift at boot time to suppress the fancy boot menu
[01:20] <cjwatson> note that neither our fancy boot menu nor our kernel is common with Debian; at that point, the only thing definitely common with Debian is syslinux
[01:20] <azgtem> cjwatson: oh, didn't know about the shift trick
[01:22] <azgtem> cjwatson: anyway, knoppix does have some similar boot menu, so it seems i need to test debian itself, after all, before i conclude it's a debian problem
[01:23] <azgtem> cjwatson: ok then, is there any net boot cd equivalent of the one you gave me that i could use to install ubuntu?
[01:23] <cjwatson> azgtem: given that I have no idea what the problem is, I cannot answer that question
[01:24] <cjwatson> we do not have a magic CD that fixes all unknown bugs, if that's what you mean ;-)
[01:24] <azgtem> cjwatson: no, i was only asking about a debian one
[01:24] <cjwatson> oh, right
[01:24] <cjwatson> azgtem: http://www.debian.org/releases/etch/debian-installer/
[01:24] <azgtem> i want to give debian a try and then to somehow install ubuntu
[01:25] <azgtem> cjwatson: cool, thanks a lot
[01:25] <cjwatson> holding down shift should bypass most of the bootloader code that differs between Debian and Ubuntu
[01:25] <cjwatson> so that is still worth a try too
[01:25] <cjwatson> if that fixes it, please file a bug on gfxboot
[01:25] <jdong> cjwatson: wait, what does shift do?
[01:25] <cjwatson> jdong: skips gfxboot
[01:25] <jdong> disable gfxboot?
[01:25] <jdong> REALLY?
[01:25] <jdong> that would've helped me a lot with kvm!
[01:26] <cjwatson> jdong: see /usr/share/doc/syslinux/README.gfxboot
[01:26] <cjwatson> actually that says that it lets you interactively disable certain bits, which is a lie, but that's not important
[01:26] <jdong> cool
[01:26] <jdong> then I'll kvm a bit again
[01:27] <jdong> confirmed, it works
[01:27] <jdong> yay, kvm boots now
[01:27] <azgtem> jdong: you don't even see the ubuntu logo??
[01:27] <jdong> although WOW are kvm graphics impressingly slow
[01:28] <jdong> azgtem: before I saw a nice kvm stackdump
[01:28] <jdong> becase intel-vt doesn't do the realmode calls for gfxboot's screen
[01:28] <azgtem> jdong: oh, i thought you were testing that on a normal computer boot
[01:28] <jdong> nope; kvm
[01:28] <azgtem> right
[01:29] <azgtem> cjwatson: even when i keep shift pressed, i still see the nice orange ubuntu logo
[01:29] <jdong> yes
[01:29] <azgtem> or pink
[01:29] <jdong> that's the old syslinux style logo
[01:29] <cjwatson> what jdong said
[01:29] <jdong> not the gfxboot one that puts the video in weird modes :D
[01:29] <azgtem> oh, right
[01:30] <azgtem> cjwatson, jdong: but shouldn't fb=off (or something like that) solve this problem anyway?
[01:30] <azgtem> something like that = i am not sure about the syntax
[01:31] <cjwatson> azgtem: that's much later
[01:31] <jdong> Colin is the expert past this point. I have no experience with d-i internals
[01:31] <cjwatson> fb=false translates to debian-installer/framebuffer=false which tells the installer not to use a framebuffer; this does not help if the kernel isn't coming up
[01:31] <cjwatson> and it's unrelated to gfxboot
[01:33] <`23meg> cjwatson, would it be possible/feasible to create a barebones X environment to let Ubiquity run on systems with low memory?
[01:36] <cjwatson> `23meg: it's been discussed, but I haven't had time to actually do it
[01:37] <`23meg> so it looks doable; good to know
[01:38] <azgtem> cjwatson: it seems shift doesn't help on my box, so could you please tell me what level the error is, so that i may search for deeper answers myself? i also mention, if of any help at all, that most of the times i can see some ten quickly disappearing "progress bar" dots before the computer reboots, but at least once i saw more than thirty... if you find my description funny then you just know how desperate i am :)
[01:39] <cjwatson> azgtem: I think you need help from a kernel developer at this point, TBH
[01:40] <azgtem> cjwatson: good to know
[01:40] <azgtem> cjwatson: thank you again
[01:40] <cjwatson> sorry I can't help more
[01:43] <jdong> a friend sent me his travel itinerary to Hawaii complete with 3 PDF's of boarding passes, while he sent his family a build log.....
[01:43] <azgtem> cjwatson: the fact that i know where to look further already means enough help to me, to be honest, i didn't even know the kernel could be responsible for this
[01:44] <jdong> azgtem: unexpected reboots typically are the kernel's fault at some point :)
[01:44] <jdong> it's also a convenient way of saying "not my fault" :D
[01:44] <azgtem> heh
[01:44] <azgtem> true
[01:46] <azgtem> cjwatson: and one last question: from your experience, the level you think this problem is -- is it the same level boot options like "noapic" etc. apply? i mean, is it still possible, in principle, that some magical boot option solve the problem?
[01:46] <mjg59> Well, it's either syslinux or the kernel
[01:46] <mjg59> If it's the kernel, it's happening in early setup code where any failure is quite likely to result in the machine rebooting
[01:47] <mjg59> Diagnosing is likely to be immensely painful
[01:47] <mjg59> Does the current Fedora test release have the same problem?
[02:13] <azgtem> cjwatson: oh, btw, i forgot to mention: after i installed ubuntu on it (by using another machine and copying the contents of the hdd), it could boot into ubuntu, so it is only a cd live/alternate problem
[02:15] <cjwatson> azgtem: that does tend to suggest syslinux
[02:15] <cjwatson> doesn't make it a whole lot easier, mind
[02:18] <azgtem> cjwatson: is it possible to use grub on /dev/hda and force it to boot the cdrom? or what methods do multidistro cds use?
[02:36] <jdong> azgtem: only if grub was compiled with cdrom support or patches or whatnot
[02:36] <jdong> which default Ubuntu GRUB is not
[02:38] <azgtem> jdong: but in that case it does??
[02:58] <jdong> azgtem: the bootable CD's that use GRUB do support CD's. Ubuntu does not use GRUB to boot its CD's.
[02:58] <azgtem> jdong: btw, *why* doesn't ubuntu use grub?
[02:59] <mjg59> Traditionally, it's been more fragile than iso/syslinux
[02:59] <jdong> azgtem: apparently more prone to failure
[02:59] <jdong> heh mjg59  beat me
[02:59] <mjg59> Also less scriptable, as far as I can remember
[03:00] <azgtem> jdong, mjg59: oh, right, i experienced that myself. actually even lilo is much more reliable, imo
[03:00] <jdong> but lilo is too static :D
[03:00] <jdong> it apparently has some other limitations too....
[03:00] <azgtem> i hate it that grub has so many wonderful features and yet is less dependable
[03:01] <azgtem> especially considering that reliability is very important for a boot loader
[06:27] <fabbione> monring
[06:28] <poningru> bwhahahahahha
[06:28] <poningru> http://lolgeeks.com/wp-content/uploads/2007/05/125060350_bc84204cd9.jpg
[06:31] <ajmitch> morning fabbione 
[06:32] <Nafallo> morning fabbione :-)
[08:33] <fabbione> YAY for standalone nss and nspr!
[08:33] <Nafallo> oh. nice! :-)
[08:34] <ubijtsa> poningru: *lol*
[08:35] <Burgundavia> fabbione: hmm?
[08:35] <dholbach> good morning
[08:35] <ubijtsa> moin alles
[08:36] <fabbione> Burgundavia: libnss and libnspr were in FF sources but they are used by different packages
[08:39] <fabbione> Burgundavia: with the split, i don't need to ship FF sources on server-source.iso
[08:40] <Burgundavia> ah, right
[08:40] <Burgundavia> nspr is required for fds as well
[08:41] <Nafallo> fds?
[08:41] <Burgundavia> fedora directory servcer
[08:41] <Nafallo> ah
[08:43] <fabbione> Burgundavia: it's much easier than that... RHEL is moving away from openssl for all its packages
[08:43] <fabbione> Burgundavia: and they either switch to nss/nspr for strong encryption or to gnutls for weak
[08:43] <ubijtsa> fabbione: where have you heard this?
[08:44] <fabbione> ubijtsa: just talking with some of our developers
[08:44] <ubijtsa> fabbione: 'our' as in Ubuntu or.. ?
[08:45] <fabbione> s/our/their
[08:45] <fabbione> i am still drinking my first cup of coffee
[08:45] <ubijtsa> fabbione: thank's for the heads up, first I have heard of it..
[08:46] <fabbione> ubijtsa: it's not really a secret.. openssl was not certified by the US gov authorities till a few weeks ago
[08:46] <fabbione> and to sell support to US Gov you need to have conformant ssl/crypto libs/apps
[08:46] <Nafallo> fabbione: does that mean firefox-dev build-dep that was libxul-dev in debian should be something else now? :-)
[08:46] <ubijtsa> fabbione: yes, but it would be nice if the support organisation was aware of such a change. ;-)
[08:47] <ubijtsa> s/was aware/was made aware/
[08:47] <fabbione> ubijtsa: well i was only told that.. i have no clue how that's communicated internally to RH....
[08:47] <ubijtsa> fabbione: that's what I'll find out today
[08:47] <fabbione> ubijtsa: neither i can be 100% certain how official is that
[08:48] <ubijtsa> fabbione: if it's going in to Fedora, it'll make its way into RHEL pretty much.
[08:49] <fabbione> ubijtsa: as i said, i was told this.. not how the process is taking place
[08:49] <fabbione> ubijtsa: might as well be a RH fork of packages only that doesn't influence Fedora
[08:49] <fabbione> i really don't know more than what i told you already
[08:49] <ubijtsa> fabbione: that is less likely
[08:50] <ubijtsa> fabbione: thank you for letting me know though :)
[08:50] <fabbione> np
[08:53] <dholbach> can we sync from Debian NEW?
[08:54] <cjwatson> dholbach: in theory it could probably be arranged, but it would require me to abuse privileges and is not a good idea anyway
[08:55] <dholbach> cjwatson: ok, I'm just being impatient :)
[08:55] <dholbach> nevermind :-)
[09:00] <pitti> Good morning
[09:17] <pitti> merges.ubuntu.com!!
[09:18] <tepsipakki> whee!
[09:18] <ajmitch> it's back & better than ever?
[09:18] <tepsipakki> umm, no :)
[09:18] <ajmitch> tepsipakki: well up-to-date is better than ever :)
[09:19] <ajmitch> I see that the main pages listing merges aren't updated yet
[09:19] <tepsipakki> correct :)
[09:19] <tepsipakki> but something is happening
[09:30] <stittel> Where is development of Ubuntu taking place? I mean the packages commited to the apt-repositories seem to be more or less finished and ready to use, but there must be some place where things are commited and discussed before the package is finished?
[09:30] <stittel> Most probably this happens in a revision control system like CVS or Subversion. If so, what is it's address?
[09:31] <mdke> stittel: https://wiki.ubuntu.com/UbuntuDevelopment is a good overview of the processes
[09:31] <stittel> I am thinking about getting involved as a package maintainer at same point but I'd really like to have a closer look at the development process.
[09:31] <stittel> Thanks.
[09:39] <pitti> Riddell: any reason why kdebase still depends on pmount?
[09:39] <pitti> Riddell: (and kubuntu-desktop)
[09:40] <stittel> Doesn't KDE use pmount/pumount for mounting removable media like USB sticks?
[09:41] <stittel> Just a thought, I am not a developer. :)
[09:44] <pitti> stittel: I thought it would have switched to using hal long ago
[09:44] <pitti> stittel: in fact, it used hal even earlier than Ubuntu's Gnome AFAIR
[09:44] <pitti> and we just made hal use pmount as a backend in dapper
[09:45] <stittel> What happens if you move the pmount binary and attach an USB stick?
[09:45] <stittel> This should give us some clearity.
[09:47] <pitti> stittel: well, that's why I asked Jonathan, I don't have a KDE here ATM
[09:47] <stittel> Wait a sec.
[09:47] <pitti> I would just really like to move it to universe, since I don't have  much motivation to develop it any more
[09:49] <stittel> Do you want me to move pmount-hal, too?
[09:49] <pitti> stittel: oh, just try sudo dpkg -P --force-depends pmount
[09:49] <pitti> stittel: pmount-hal will just fail without pmount, so it doesn't matter much
[09:50] <cjwatson> stittel: I've added a practical note on revision control to UbuntuDevelopment
[09:50] <cjwatson> (under "Revision control (Bazaar)")
[09:50] <stittel> cjwatson: Thanks.
[09:51] <stittel> pitti: USB sticks works fine with KDE without pmount installed. Everything like usual.
[09:51] <pitti> stittel: right, that's what I guessed; just a forgotten dependency
[09:51] <pitti> stittel: thanks for testing!
[09:52] <stittel> BTW: Why is "Storage Media" in the KDE System Menu pointing to "/media" and not to the "media:/" KIO slave?
[09:53] <stittel> "/media" is rather useless for examle to remount and unmounted USB stick.
[09:53] <stittel> s/and/an/
[09:54] <ssam> is there much chance of Bug #109204 being fixed in feisty? it makes gnumeric mostly unusable on powerpc. the patch is tiny, has been commit up stream, and there are a few positive test reports.
[09:54] <ubotu> Launchpad bug 109204 in goffice "Gnumeric strange colors (purple charts) on bigendian" [Undecided,Fix committed]  https://launchpad.net/bugs/109204
[10:06] <shawarma>  /win 2
[10:06] <shawarma> doh
[10:18] <asac> Mithrandir: can you please give back nss?
[10:19] <Mithrandir> asac: it's depwait
[10:20] <asac> on what?
[10:20] <Mithrandir> so it'll be done once libnspr4-dev
[10:20] <Mithrandir> which is probably in NEW
[10:20] <asac> libnspr4-dev should b e there
[10:20] <asac> ah
[10:20] <asac> ok
[10:20] <Mithrandir> s/so it'll be done once//
[10:20] <Mithrandir> once that hits the archive, it'll be retried automatically
[10:22] <asac> Mithrandir: i see libnspr4-dev in gutsy /pool
[10:22] <asac> ... and can install it ;)
[10:22] <asac> ah ... it ended up in universe
[10:22] <asac> hmm
[10:23] <zyga> morning
[10:24] <asac> cjwatson: didn't you direct nss/nspr to main?
[10:26] <cjwatson> asac: I only processed the source package; somebody else must have done the binaries
[10:27] <Lure> stittel: this was done as part of https://wiki.ubuntu.com/KubuntuKDEMedia
[10:27] <cjwatson> asac: and I did set the source package components to main
[10:27] <Lure> stittel: if you are missing some feature, ping Riddell or Sime in #kubuntu-devel
[10:27] <Mithrandir> somebody probably just blatted it through and didn't pay enough attention.  Easy enough to fix.
[10:28] <cjwatson> asac: anyhow, I've moved the nspr binaries to main, which should fix the dep-wait problem after the next publisher run
[10:28] <cjwatson> they'll have dep-waited due to the ogre model (the archive has layers; main can't build-dep on universe)
[10:28] <asac> cjwatson: yes that makes sense
[11:02] <ajmitch> cjwatson: I presume we have the same stance as debian on gpl & openssl?
[11:02] <cjwatson> ajmitch: yes
[11:03] <Mithrandir> that's hardly a stance, it's just how the licence is.
[11:03] <ajmitch> ok, thanks
[11:05] <ajmitch> the lack of a decent gnutls patch for openldap 2.3 stops mit kerberos having an ldap kdb backend
[11:06] <ajmitch> from what I found, the ssl linking issue was the main reason for not having libldap2-dev built from openldap2.3
[11:14] <Riddell> pitti: I don't think it does need to depend on pmount any more, I'll check to confirm
[11:15] <pitti> Riddell: stittel already confirmed
[11:16] <pitti> Riddell: that would be nice; the same dependency is in Debian as well, btw
[12:19] <seb128> bryce: when you file a sync request please describe the ubuntu changes and why they can be dropped
[12:31] <gnomefreak> pitti: are you around for a quick question?
[12:31] <pitti> gnomefreak: please don't ask to ask, just ask
[12:31] <gnomefreak> pitti: in /etc/default/apport i have enable=1 but i never get the crash dialog
[12:32] <gnomefreak> is that a bug or just not fully worked out yet?
[12:32] <pitti> gnomefreak: it controls a different thing
[12:32] <gnomefreak> oh
[12:33] <pitti> gconftool-2 -s --type boolean /apps/update-notifier/show_apport_crashes true
[12:33] <gnomefreak> ok ty
[12:34] <pitti> I think for gutsy I'll enable it soon again
[12:34] <pitti> once the initial merge rush is done
[12:34] <gnomefreak> cool :)
[12:39] <pitti> Riddell: do you think that we need to discuss http://people.ubuntu.com/~cjwatson/uds-sevilla/kubuntu-restricted-manager.html?
[12:39] <pitti> Riddell: AFAICS there's little to discuss, it's a SMOP
[12:40] <Riddell> pitti: SMOP?
[12:40] <pitti> simple matter of programming
[12:40] <Mithrandir> simple matter of programming
[12:40] <Mithrandir> oh, so much for paying attention. :-P
[12:41] <pitti> Riddell: the backend is already UI agnostic, we just need to pull out the Ui independent stuff from the current frontend and cobble a KDE frontend
[12:41] <pitti> Riddell: I see little value of wasting a pre-scheduled BoF on it TBH
[12:42] <Riddell> pitti: I seem to remember a while ago you talking about having to make it frontend independent
[12:42] <Riddell> pitti: but if that's not an issue then it doesn't need a full session
[12:43] <pitti> Riddell: well, of course there need to be some GTK/Qt specific bits, such as .glade vs. .ui and so on
[12:43] <pitti> Riddell: but the workflow can be in an abstract base class
[12:43] <pitti> similar to apport-{qt,gtk}
[12:46] <Riddell> pitti: so we probably don't need that session, but I'd still like to flesh out the spec and have it checked by you
[12:46] <pitti> right, of course
[01:02] <stittel> Lure: Thanks, I will do that.
[01:14] <cjwatson> 677 packages in NEW, 677 packages; take one down, process it, 725 packages in NEW
[01:14] <shawarma> *G*
[01:15] <ajmitch> cjwatson: long day then? :)
[01:15] <Nafallo> cjwatson: ouch
[01:17] <asac> cjwatson: ok, can you move nss binaries to main as well now?
[01:23] <tepsipakki> asac: I tried to change the default homepage by editing /etc/firefox/pref/firefox.js, but it only shows a blank page no matter what (this on Feisty). Ideas?
[01:23] <asac> yes
[01:23] <tepsipakki> same on dapper, too
[01:23] <asac> you have to change alternative
[01:23] <asac> not pref
[01:24] <cjwatson> asac: done for next publisher run
[01:24] <asac> tepsipakki: /etc/alternatives/firefox-homepage
[01:24] <asac> cjwatson: thanks
[01:24] <tepsipakki> asac: but the same holds for other settings
[01:24] <asac> which?
[01:24] <asac> e.g. do you see the settings changed in about:config ?
[01:25] <tepsipakki> that I'd like to override.. as it's said in the firefox.js, that file (or files in that directory) can be used to override settings in /usr/share/firefox/defaults/pref
[01:26] <tepsipakki> hm, I'll try other settings first :P
[01:26] <asac> yes please do
[01:28] <Mithrandir> seb128: slab (the source package) is called gnome-main-menu in Debian; ok to sync with override or do you want to upload a merge?
[01:40] <seb128> Mithrandir: I'll upload a merge, there is some changes to do like making it use gnome-app-install
[01:41] <Mithrandir> seb128: ok, thanks.
[01:42] <seb128> no problem
[01:42] <tepsipakki> asac: nope, no setting is overridden by /e/f/p/firefox.js
[01:43] <tepsipakki> oh wait
[01:43] <tepsipakki> maybe the parser is buggy
[01:51] <tepsipakki> yep, if there is an error somewhere, it fails to apply the rest
[01:55] <asac> so does it work or not?
[01:55] <tepsipakki> it works, if the config has no errors ;)
[01:55] <asac> hopefully the default config has no errors, does it?
[01:56] <tepsipakki> no, that seems to be fine, but our site-wide settings were busted
[01:56] <tepsipakki> used to work with mozilla, no-one had touched it for three years...
[01:57] <tepsipakki> yay for maintenance
[02:00] <asac> oh ... so mozilla was more robust about syntax errors? or what kind of errors did you have in your config?
[02:01] <tepsipakki> all kinds of.. I need to double check that
[02:02] <siretart> cjwatson: is there any Forum or Workshop about some 'unattended-install infrastructure'? Mark mentioned it on ubuntu-devel-announce, but I cannot find it on http://people.ubuntu.com/~cjwatson/uds-sevilla/track-installer.html
[02:03] <siretart> or does the 'automated installation' workshop cover that?
[02:55] <TheMuso> If someone gave back ardour, it still FTBFS on the same weird issue. Only i386 built so far, but same problem.
[02:56] <Tonio_> #ubuntu-fr-classroom
[02:56] <Tonio_> oops
[02:56] <Tonio_> sorry for this :)
[02:57] <Tonio_> is there a common/known way to "divert" a debconf generated file, so that not any other package can overwrite it ?
[02:58] <Treenaks> Packages should not overwrite manually edited files without asking.. even IF they use debconf, afaik
[03:00] <Tonio_> Treenaks: yes but in automatic deploiement environment
[03:01] <Tonio_> Treenaks: I cannot take the risk to always answer "yes" or "no"
[03:01] <Tonio_> Treenaks: that's why I'm searching for a dpkg-divert equivalent
[03:01] <Treenaks> Always answering 'no' means changed config files will remain in their changed state
[03:02] <Tonio_> hum...
[03:03] <Tonio_> well that doesn't exactly feet my needs btw, but if that's the only solution.... :)
[03:09] <Mithrandir> Tonio_: chattr +i on the file?
[03:10] <Tonio_> Mithrandir: ouch ;)
[03:10] <Tonio_> Mithrandir: well that'll work ;)
[03:11] <Tonio_> Mithrandir: well waiting for debconf to handle that (sounds like in project) that's not a bad option, thanks :)
[03:12] <TheMuso> hmm. Ok pbuilder + uploaded ardour package still don't choak.
[03:14] <Mithrandir> Tonio_: except debconf doesn't do anything about configuration files, so it's the wrong place to apply any kind of fix.
[03:16] <Tonio_> Mithrandir: I know, well I don't know what'll be fixed, but I read on the debian wiki there was kind of a project to make it possible to divert debconf generated files
[03:16] <Tonio_> I don't know much more on that point, except I would love it was already implemented since I need this :)
[03:17] <ivoks> Tonio_: ;) hi
[03:17] <Tonio_> hey ivoks :)
[03:29] <jsgotangco> hey jono
[03:29] <ajmitch> hello jono, jsgotangco 
[03:29] <jono> hey
[03:29] <jsgotangco> hey ajmitch
[03:30] <jsgotangco> ajmitch: err are you somewhere that is not around the southern hemisphere?
[03:30] <ajmitch> jsgotangco: I am still deep in the south
[03:34] <bhale> hi jsgotangco, ajmitch 
[03:34] <jsgotangco> hey bhale hows it going there
[03:35] <bhale> good thanks
[03:39] <ajmitch> hi bhale 
[03:39] <ajmitch> jsgotangco: don't worry, I'll leave soon
[03:39] <jsgotangco> yeah its a very long swim for sure
[03:39] <ajmitch> hopefully I won't have to swim
[03:40] <ajmitch> time for me to sleep anyway
[03:40] <ajmitch> night
[03:41] <siretart> ajmitch: have a good flight!
[03:43] <Mithrandir> the merge-o-matic should be back in business now.
[03:44] <StevenK> YAY!
[03:44] <Mithrandir> I'll send an announcement to u-d-a soonish
[03:49] <StevenK> Mithrandir: How often will MoM update?
[03:50] <Mithrandir> StevenK: I need to confirm with Scott that everything is fine, but once he's ok with it, I'll have it run as often as it used to (which I believe is every two hours or so)
[04:01] <jdong> seb128: WRT backports bug 76382, the version verified is 0.15-0ubuntu2, but it also needs that trivial debdiff I posted. The lowered python b-d has been verified with bzr developers.
[04:01] <ubotu> Launchpad bug 76382 in edgy-backports "Backport bzr 0.13-0ubuntu1 from Feisty to Edgy" [Undecided,In progress]  https://launchpad.net/bugs/76382
[04:05] <jdong> seb128: in addition, please backport bug 111630 for Dapper and Edgy too, thanks!
[04:05] <ubotu> Launchpad bug 111630 in edgy-backports "backport KTorrent 2.1.4" [Undecided,In progress]  https://launchpad.net/bugs/111630
[04:15] <seb128> jdong: I don't know how to source change a backport
[04:15] <jdong> seb128: I was told it's done like a normal dput upload by a core-dev and ends up in backports source NEW
[04:16] <seb128> so a normal upload with edgy-backports target?
[04:16] <seb128> Mithrandir: ^
[04:18] <pitti> seb128: that'll work, but we want to avoid it at all costs
[04:18] <jdong> in this case it's a trivial build-dep change that doesn't have any negative impacts, IMO
[04:18] <pitti> jdong: can't we do it as alternative build dep in gutsy and backport then?
[04:19] <jdong> pitti: that would also work, but I was told before not to request development uploads to fix backports problems.....
[04:19] <jdong> I don't mind which way it's done :)
[04:19] <jdong> gutsy has 0.16~rc2 though....
[04:21] <pitti> jdong: if we have to do an upload anyway, it seems easier to me to do it once for gutsy and then keep backportability instead of repeatedly doing it for backports
[04:22] <jdong> pitti: ok, that's a good plan for future packages, but in this case gutsy has already progressed to a development release of bzr... :(
[04:22] <pitti> jdong: ah, I see
[04:22] <pitti> in this case it's justified, I guess
[04:23] <jdong> pitti: so do alternate build-deps always work?
[04:23] <seb128> jdong: are you sure you want the gusty ktorrent backported to dapper? ;)
[04:23] <seb128> that seems to be quite some change
[04:23] <pitti> jdong: as long as the first one doesn't exist (as opposed to doing the wrong thing), yes
[04:24] <jdong> seb128: yep, I have tested it, and it works fine. the Dapper backports users welcome the new feature additions
[04:24] <seb128> I don't like doing changes to dapper but it's your call ;)
[04:25] <jdong> seb128: hehe fortunately only I have to deal with supporting -backports :D
[04:25] <seb128> ktorrent backports done
[04:26] <jdong> pitti: would it be feasible that when developers upload a tightened build-dep to also leave in an alternate, for non-EOL Ubuntu releases?
[04:26] <jdong> thanks seb128!
[04:26] <pitti> jdong: certainly feasible, but most often we forget about it
[04:28] <jdong> pitti: yeah, that's understandable. It's hard for me to figure out when a b-d is serious, and when it's just to force a build against a newer library for a gutsy-specific reason...
[04:28] <jdong> a lot of the times the changelog is helpful
[04:28] <jdong> but other times it's not :D
[04:28] <pitti> jdong: it eases transitions
[04:28] <pitti> jdong: you can upload all bits of a transition at once, and the buildds will DRTR with 'depwait'
[04:28] <jdong> right
[04:29] <jdong> but a lot of times those tightened build-dep are only meaningful for the development release during that transition period
[04:29] <pitti> right
[04:30] <jdong> it's just I can't help but think there must be a more sensible way of doing than me requesting transitioning b-d's to be removed or alts be added in; there must be a better way of doing it that doesn't inconvenience everyone involved...
[04:34] <wwoods> pitti: ping - got some apport questions and some code you might be interested in
[04:35] <asac> someone has a minute to NEW thunderbird 2.0? pitti?
[04:37] <pitti> wwoods: pong
[04:38] <pitti> asac: oh, why source new? just a source package rename from m-t?
[04:39] <asac> transition
[04:39] <asac> name
[04:39] <wwoods> pitti: when you've got a few minutes, I've got an rpm implementation and some code to read PID/signal out of elfcore files
[04:39] <cjwatson> siretart: ubiquity-automation covers that
[04:40] <wwoods> the latter, of course, will require some patches to apport, so I'm wondering how you want those made (bzr repo magic? patches against tarball?)
[04:40] <pitti> wwoods: oh, cool; did you develop against recent bzr head? I recently had to extend the packaging interface a bit
[04:40] <wwoods> pitti: I didn't, actually. I was just checking that out
[04:40] <pitti> wwoods: bzr branch would be best of course, for mutual merging
[04:40] <wwoods> I'll do that and come back with some patches against bzr head then
[04:41] <bddebian> Heya
[04:41] <pitti> wwoods: great!
[04:41] <asac> pitti: sorry got a phone call ... its transition of source package as well as bin package names (e.g. with transitional packages)
[04:41] <pitti> wwoods: I'll be off for a bit and then be back online, in an hour or so
[04:42] <pitti> asac: alright, so this will need binary-NEW again after it built; source accepted
[04:42] <asac> further i dropped dom-inspector which is constantly broken :)
[04:43] <wwoods> pitti: cool, I've got a Fedora QA meeting in a bit so I'll be back around later today
[04:43] <pitti> wwoods: TTYL then, looking forward to it :)
[04:43] <asac> pitti: can i upload locale packages now as well ... or will this cause mor bugging around - so better wait till tbird is up?
[04:44] <pitti> asac: I guess it doesn't matter much in which direction they break :)
[04:44] <pitti> asac: (old locales with new tbird or new locales with old tbird)
[04:44] <pitti> and it's transient anyway
[04:45] <asac> hehe ... i mean not for the user, but for the archive administration :)
[04:45] <asac> but nevermind :)
[04:45] <pitti> asac: doesn't matter much AFAICS
[04:46] <asac> pitti: in 15 minutes :)
[04:46] <pitti> asac: in 15 mins is what?
[04:47] <asac> distro meeting?
[04:47] <asac> or has it been cancelled?
[04:47] <asac> pitti: ^^
[04:47] <pitti> asac: noone announced it yet, and we'll see each other on Sunday anyway
[04:47] <asac> yeah ;)
[05:03] <fabbione> distro team meeting is NOW
[05:04] <iwj> Are you sure ?
[05:04] <iwj> Thu May  3 15:04:50 UTC 2007
[05:06] <seb128> iwj: and meeting is a 15utc
[05:06] <seb128> at
[05:06] <fabbione> iwj: yes
[05:44] <wwoods> stupid question: are .deb files GPG signed?
[05:45] <shawarma> wwoods: Not individually, no.
[05:46] <wwoods> really? huh
[05:46] <shawarma> wwoods: our source packages are signed, and so is the Release file which provides basic authentication of the source of the packages.
[05:46] <shawarma> wwoods: So you trust the repository rather than each package.
[05:47] <cjwatson> there's an unbroken chain of signatures of hashes that you can use to verify the authenticity of each .deb
[05:47] <cjwatson> (to put what shawarma said another way)
[05:47] <cbx33> hey guys in feisty, anyone know who deals with libnotify?
[05:47] <cbx33> or anyone know about the set_icon_from_pixbuf?
[05:47] <cbx33> "This will only work when libnotify is compiled against D-BUS 0.60 or higher."
[05:48] <cbx33> i thought we were hight dbus than that now?
[05:48] <cbx33> hight = higher
[05:48] <cbx33> however it still refuses to set the icon from the pixbuf
[05:49] <wwoods> shawarma: okay, hm. so the Release file is part of the repo, and it's got package hashes?
[05:50] <wwoods> (please forgive my amazingly poor grasp of apt repos. heh)
[05:50] <mvo> cbx33: look at the update-notifier source code, it works there
[05:50] <shawarma> wwoods: It's got hashes of the Packages files.
[05:51] <shawarma> wwoods: which in turn has hashes of the individual packages.
[05:51] <cbx33> mvo hmmm
[05:51] <cbx33> that's what I thought
[05:51] <cbx33> that's written in python isn't it?
[05:51] <wwoods> shawarma: ah, okay. I think I get it.
[05:51] <mvo> cbx33: oh, you talk about the python-bindings, no u-n is written in C (for memory effiecency reasons)
[05:52] <wwoods> so there's nothing intrinsic about an installed package that tells you whether or not that package came from an 'official' repo.
[05:52] <shawarma> wwoods: In short: If you get packages from the repository (and trust gnupg and the ubuntu folks) you can trust the packages.
[05:52] <cbx33> ahhh
[05:52] <shawarma> wwoods: If you get them individually from elsewhere, you shouldn't trust them.
[05:52] <cbx33> so it could be the python binding don't work yet?
[05:52] <cbx33> that's a kick in the pants
[05:52] <shawarma> wwoods: Oh, sure there is.
[05:52] <wwoods> (where "official" means "from a trusted repo", I suppose)
[05:52] <shawarma> wwoods: Gimme a sec.
[05:53] <mvo> cbx33: it could be that the python binding do have a bug, yes. aren't there tests in the python bindings package for this?
[05:53] <cbx33> not sure
[05:53] <cbx33> but it looks like a bug cos the c code does exactly what I would do
[05:53] <cbx33> I'll file a bug later
[05:53] <cbx33> ;)
[05:53] <wwoods> basically I'm trying to figure out why apport just checks to see if the string 'Ubuntu' is in the origins
[05:53] <cbx33> thanks mvo
[05:53] <wwoods> instead of checking, like, keys or hashes or something
[05:54] <pitti> wwoods: oh, does it?
[05:55] <pitti> wwoods: it should check lsb_release
[05:55] <wwoods> pitti: yeah, it does
[05:55] <pitti> so it does, jsut checked
[05:55] <wwoods> but still, that's just a string match against a package tag - anyone could lie and say their package is from the 'Fedora' distribution
[05:56] <pitti> wwoods: in Ubuntu that Origin: tag is taken from python-apt which in turn takes it from the Release files on the archive
[05:56] <pitti> wwoods: so it's reasonably reliable
[05:56] <pitti> wwoods: also, it's not meant to be foolproof
[05:56] <pitti> wwoods: the use case was that we ship some stuff in dapper-commercial, for example opera
[05:56] <pitti> wwoods: and when that crashed, users got a 404 since opera is not a product in LP
[05:56] <pitti> since it's not an actual Ubuntu package
[05:57] <wwoods> pitti: gotcha. Yeah, we generally use the GPG signatures to determine whether a package is genuine or not
[05:57] <wwoods> since our packages will be signed with one of our keys
[05:57] <pitti> wwoods: I'm fine with making that interface more abstract
[05:58] <pitti> wwoods: get_origins(self, package) -> is_distro_package(self, package)
[05:58] <wwoods> yeah, that'd work nicely.. dunno if you use get_origins elsewhere though
[05:58] <pitti> wwoods: no, I don't
[05:59] <pitti> wwoods: I just added that function a few days ago to clean up after some quick hacks I had to do for the feisty release
[05:59] <cprov> pitti: do you know how to define a fqdn with PORT in dput config ?
[05:59] <wwoods> is_distro_package would probably be a good way to abstract that
[05:59] <pitti> cprov: hm, no; just appending ':port' to the host doesn't work?
[06:00] <cprov> pitti: as in "foobar:2121" ? no, it doesn't work.
[06:01] <pitti> wwoods: added to TODO
[06:01] <pitti> wwoods: can we talk in ~ 1 hour? I need to grab some food
[06:04] <wwoods> pitti: sure
[06:09] <thekorn> cbx33: set_icon_from_pixbuf is working for me in feisty
[06:10] <cbx33> thekorn, in python?
[06:11] <cbx33> if so, got some example code?
[06:12] <thekorn> cbx33: yes, wait a second
[06:12] <cbx33> thanky ou
[06:13] <thekorn> cbx33: http://paste.ubuntu-nl.org/18974/
[06:14] <thekorn> cbx33: you don't need that win = ...
[06:14] <cbx33> thekorn you rock
[06:15] <cbx33> my problem was in the docs, it looks like the icon parameter for the initialisation was required
[06:15] <cbx33> i thought i could overwrite it later with set icon from file
[06:15] <cbx33> thanks so much
[06:15] <cbx33> VCSFrenzy gets custom icons ;)
[06:16] <thekorn> cbx33: VCSFrenzy rocks!
[06:17] <popey> you cbx33 
[06:17] <popey> er
[06:17] <popey> -u
[06:18] <cbx33> thekorn, it rocks even more now ;)
[06:18] <cbx33> hi popey 
[06:18] <cbx33> hang on lemme pm you
[06:24] <vciaglia> hi
[06:35] <cbx33> whoops kill my x server
[06:35] <kwah> How one can change mount options for automounted devices like flash-cards?
[06:35] <jdong> lol
[06:36] <jdong> kwah: /etc/hal/fdi/policy/ IIRC
[06:52] <pitti> wwoods: I'm back for a bit
[07:16] <pitti> wwoods: I committed that change and pushed, should be on LP in a few minutes
[07:17] <wwoods> pitti: awesome! thanks. I just finished up that meeting and I need to grab some lunch but I'll be back in a bit
[07:17] <pitti> wwoods: hm, I need to leave now, sorry
[07:17] <pitti> wwoods: can you mail me about remaining questions and issues?
[07:21] <wwoods> pitti: will do
[07:21] <wwoods> doh
[08:59] <Treenaks> iwj: hmm.. good idea
[09:18] <xxxxx1> hi all.
[09:18] <xxxxx1> i've built a custom kernel
[09:18] <xxxxx1> can i replace linux-libc-dev ?
[10:14] <ajmitch> morning all
[10:28] <mjunx> hey guys, I've got a suggestion/question
[10:29] <mjunx> would it be feasible if all the packages in ubuntu were maintained as bzr branches so that other people can easily submit branches on launchpad for fixes?
[10:30] <mjunx> one particular situation I'm thinking of is an easier way for people to write documentation or modify it from the base translation
[10:33] <ash211_> mjunx: sounds like https://wiki.ubuntu.com/NoMoreSourcePackages
[10:34] <pygi> hi folks
[10:35] <mjunx> ash211, that sounds like a GREAT idea! I love it
[10:35] <ash211> subscribe to the spec and propose it to the coming UDS then
[10:36] <mjunx> hmm, I'm not an official developer here or anything...
[10:37] <ash211> me neither, I've just heard that proposal thrown around before
[10:40] <mjunx> this developer summit you speak of, is it a real life meeting? if so, where does it take place? I'm a college student with like no job and stuff
[10:43] <geser> yes, it's an offline meeting :), try Seville, Spain as location
[10:52] <mjunx> hmm, quite a bit far from chicago :/
[10:52] <ajmitch> yes, quite a way from NZ too
[10:53] <ajmitch> hi doko 
[10:53] <doko> ajmitch: good morning
[10:56] <JohnFlux> mjunx: but wouldn't it be better to have the documentation etc pushed upstream?
[10:57] <mjunx> JohnFlux, yes, but when you wait for over a month for that to happen, it gets kinda annoying...
[10:57] <JohnFlux> yeah, but hmm
[10:58] <JohnFlux> it's already a pain that launchpad has its own bug system
[10:58] <JohnFlux> as a kde developer I often don't see bug reports filed just in ubuntu's system and not upstream
[10:59] <JohnFlux> having a 2nd source tree with its own patches might get annoying
[10:59] <seb128> JohnFlux: you can subscribe on a package in launchpad
[11:00] <JohnFlux> seb128: but I can't close the bugs etc 
[11:00] <mjunx> JohnFlux, I've reported kde bugs to launchpad only because sometimes I really think that ubuntu might have been the ones who screwed it up, and if not, the maintainer should know to forward the bug
[11:01] <JohnFlux> mjunx: yeah
[11:01] <JohnFlux> I'm not saying it's a big problem, but the majority of kde developers don't have a launchpad account etc
[11:01] <seb128> JohnFlux: ask on #ubuntu-bugs to get bug triage rights
[11:01] <mjunx> JohnFlux, you can join the bugsquad team and then you can close bugs and stuff
[11:02] <seb128> JohnFlux: users are usually asked to report the bug at the distribution level because it might be due to a distro patch or something
[11:03] <seb128> JohnFlux: we lack manpower to send everything upstream then though
[11:03] <JohnFlux> I do understand
[11:03] <seb128> JohnFlux: you are welcome to subscribe to the package on launchpad if you want to help there or read bugs that are not sent upstream
[11:03] <JohnFlux> and kde does the same thing anyway - we have imported versions from other projects
[11:03] <JohnFlux> our own modified copy of qt, and so on
[11:04] <manchicken_> We do a pretty good job sending KDE stuff back upstream.
[11:05] <manchicken_> But most of us Kubuntu folks are also KDE folks as well.
[11:05] <JohnFlux> it would be nice to have launchpad opensourced etc and then have kde etc use it :-)
[11:05] <manchicken_> I'm not as much of a big KDE contributor though.  A handful of stuff here and there, but the big players seem to be involved.
[11:05] <JohnFlux> but there's an argument for another day heh
[11:05] <JohnFlux> yeah
[11:05] <manchicken_> launchpad isn't proprietary.  It's custom software.  It's not released.
[11:06] <manchicken_> And KDE could use launchpad.
[11:06] <manchicken_> It's pretty easy to register things on launchpad.
[11:06] <manchicken_> It's just that KDE has its own thing going on.
[11:06] <manchicken_> KDE has been around for a while, and they've already got what they like pretty well defined.
[11:06] <JohnFlux> heh, nah
[11:07] <JohnFlux> we've changed a lot of things
[11:07] <JohnFlux> it wouldn't be a biggie to change the bug tracking system as well
[11:07] <manchicken_> If KDE wanted to do launchpad, it's really quite simple to do so.
[11:07] <JohnFlux> not politically
[11:07] <JohnFlux> :-)
[11:08] <manchicken_> What do you mean?
[11:08] <mjunx> I like how they have a link to their "websvn", but instead they use viewcvs or something
[11:08] <mjunx> I mean, I am/was a developer for websvn, and it would have been awesome to get feedback like that from a project with commits in the 6 digits
[11:08] <JohnFlux> personally, I still remember what happened with the linux kernel and it relying on a proprietary revision control system
[11:08] <manchicken_> Launchpad is a service provided by custom software running on privately owned servers.
[11:08] <manchicken_> JohnFlux: bzr isn't proprietary.
[11:09] <JohnFlux> it wasn't an exact analogy :-)
[11:09] <JohnFlux> but in reference to using launchpad
[11:09] <mjunx> I like subversion more than bzr, but that's because I don't have any experience with bzr ;p
[11:09] <manchicken_> Launchpad isn't proprietary
[11:09] <JohnFlux> i don't understand how you can say it's not proprietary
[11:09] <manchicken_> It's not distributed software.  It's custom software running on managed servers.
[11:10] <seb128> it is for the moment
[11:10] <manchicken_> If it's not distributed, it's not licensed, it's not proprietary.
[11:10] <seb128> JohnFlux: you can get back any data you put it though so it's doesn't enclose you
[11:10] <manchicken_> Even RMS agreed with me on that when he visited Chicago not too longago.
[11:10] <JohnFlux> not sure I agree with that definition heh
[11:10] <JohnFlux> anyway, I'm sure the kde guys would want to have it running on their own systems
[11:11] <manchicken_> Software that is only being used on servers you own and is not distributed is by every definition Free Software.
[11:11] <manchicken_> And bzr can be run on their own systems.
[11:11] <manchicken_> You can use bzr with any host that supports sftp.
[11:11] <JohnFlux> but not launchpad
[11:11] <JohnFlux> can't you buy launchpad btw?
[11:11] <manchicken_> Launchpad is a web site, not a piece of software.
[11:12] <JohnFlux> I thought I saw canonical selling it or something
[11:12] <JohnFlux> #define launchpad the software that runs launchpad
[11:12] <JohnFlux> :P
[11:12] <manchicken_> You're merely requesting content from their HTTP servers.
[11:14] <JohnFlux> anyway, it would be nice to have launchpad released and open sourced :-)
[11:14] <JohnFlux> if that happened, I can see kde seriously considering using it
[11:14] <manchicken_> And I'm having a hard time finding anything that would lead me to believe that Launchpad is distributed in any way.
[11:14] <manchicken_> It would be nice to have Launchpad released as free software, yes.  But it is not by any definition that I can see non-free software.
[11:15] <manchicken_> Not any more than google is non-free software
[11:15] <thom> #ubuntu-offtopic
[11:15] <ion_> apt-get install googled
[11:15] <manchicken_> Nice.
[11:15] <manchicken_> apt-get install fsf.org
[11:16] <JohnFlux> manchicken_: can you imagine ubuntu relying on 3rd party servers for its bug tracking?
[11:17] <JohnFlux> manchicken_: where it has no control over them, and no way of running the service itself etc
[11:17] <JohnFlux> manchicken_: it's just not a wise idea
[11:17] <manchicken_> JohnFlux: Nope.  I can't.  That's why they wrote their own.
[11:17] <bhale> this isnt in the scope of the topic
[11:17] <bhale> #ubuntu-offtopic
[11:18] <JohnFlux> bhale: it's about ubuntu development.  how much more on topic can you get?
[11:18] <bhale> JohnFlux: been asked once.
[11:18] <JohnFlux> it was a silly request
[11:18] <thom> it's not anything to do with the technical development of the ubuntu distribution
[11:18] <JohnFlux> not distribution, but development
[11:18] <bhale> "ubuntu development" in this context is very specific to development of packages and features of the open distro
[11:19] <JohnFlux> this is ubuntu-devel not ubuntu-distribution
[11:19] <thom> JohnFlux: if you wish to talk about launchpad, try #launchpad. or #ubuntu-offtopic
[11:19] <manchicken_> JohnFlux: I agree that this isn't one of those things where we clearly are off-topic, but if it's bothering/annoying/irritating folks, I don't think it'd be too much to ask for us to -offtopic it.
[11:19] <thom> you are not on-topic in this channel
[11:21] <mjunx> it started off as on-topic ;)
[11:27] <sharms> JohnFlux: #ubuntu-offtopic