[00:00] <Keybuk> heh, you think I'm reading -changes? :p
[00:01] <Keybuk> ah that
[00:01] <Keybuk> I look forwards to your ureadahead upload <g>
[00:49] <TheMuso> grrr haven't built i386 packages with sbuild for ages, and now I find it desn't just work when using an i386 chroot on an amd64 machine.
[00:49] <StevenK> TheMuso: What's the error? It ought to work
[00:50] <TheMuso> StevenK: hrm hang on maybe I was doing something wrong.
[00:50] <TheMuso> No I wasn't.
[00:50] <TheMuso> E: Build architecture (amd64) is not the same as the chroot architecture (i386)
[00:51] <TheMuso> I: Please specify the correct architecture with --arch, or use a chroot of the correct architecture
[00:51] <TheMuso> But when I use --arch=i386 I get this.
[00:51] <RAOF> Works for me?  Let me check my sbuild settings.
[00:51] <TheMuso> Chroot natty-i386 for architecture i386 not found
[00:53] <RAOF> What's your schroot called?  AFAICT sbuild only really cares about the chroot personality, as specified in schroot.conf (or chroot.d/*)
[00:54] <TheMuso> Oh I have to set a personality now... Ok will update my schroot.conf.
[00:54] <TheMuso> ...but this was not needed in the past... *grumlbes*
[00:57] <TheMuso> Ok that doesn't help, still get the same above errors.
[00:58] <psusi> any of the rest of you guys use emacs?  since I upgraded from emacs22 to emacs23, I can't debug properly since running gdb with sudo hangs after entering the password.
[00:59] <broder> TheMuso: do sbuild -d natty --arch i386
[01:00] <TheMuso> broder: Thats what I have been trying.
[01:00] <broder> not -d natty-i386 or -c natty-i386?
[01:00] <TheMuso> sbuild -d natty-i386 filename.dsc is what I normally use.
[01:00] <TheMuso> or -d natty-amd64
[01:01] <TheMuso> Ok order of args does not make a diff.
[01:01] <broder> don't use -d natty-amd64
[01:01] <broder> sbuild isn't clever enough to extract the architecture
[01:01] <broder> you need to pass it as a separate argument
[01:01] <broder> sbuild -d natty --arch amd64
[01:01] <TheMuso> ah ok.
[01:01] <TheMuso> THis is stupid, that used to work.
[01:02] <broder> the sbuild maintainer is super responsive, for what it's worth
[01:02] <TheMuso> I'll get used to it I guess, but a while back, I didn't have to specify any arch or personality, just the chroot name.
[01:03] <RAOF> broder: sbuild's clever enough to work for me when I sbuild -d natty-i386?
[01:04] <broder> yeah, it'll pick the right chroot, but i bet there's something new in the setup code that cares about the arch and isn't getting it
[01:05] <TheMuso> RAOF: yeah thats what I *was* doing.
[01:05] <RAOF> Hm, yeah, you're right.
[01:05] <RAOF> Something's changed since my last i386 build, which would have been mere days ago.
[01:06] <RAOF> Oh, I see.
[01:06] <RAOF> That's a deliberate change in 0.60.9-1
[01:06] <TheMuso> Yeah just saw that.
[01:07] <RAOF> Well, that's annoying :)
[01:07] <TheMuso> Agreed.
[01:07] <TheMuso> On one hand I understand why the change was made, but, it now means that one has to type in more when running sbuild. Oh well, I'll get used to it.
[01:08] <TheMuso> It will eventually become muscle memory.
[01:57] <kees> lamont: postfix is uninstallable.
[01:58] <StevenK> kees: "Feature"
[01:58] <kees> StevenK: hehe
[02:55] <ScottK> lamont: Also postfix 2.8.1 is out, so time to turn once more around the course ....
[04:11] <robert_ancell> StevenK, how do I remove a package from the archive?
[04:11] <StevenK> robert_ancell: You file a bug
[04:11] <StevenK> Well, it depends.
[04:11] <StevenK> More information, please
[04:14] <robert_ancell> StevenK, the gtk3-engines-murrine package no longer builds, but it's also obsolete as GTK3 change it's themeing so much it no longer works.  I want to remove it so no-one can install it from natty when it's released
[04:15] <StevenK> robert_ancell: Then file a bug against it stating that and asking that the source and binaries are removed from natty, subscribing ubuntu-archive
[05:07] <cody-somerville> hmm... pidgin + MSN doesn't work anymore :(
[05:07] <cody-somerville> I guess its time to migrate to empathy finally.
[05:08] <micahg> cody-somerville: what version of pidgin?
[05:08] <micahg> ah, it's explicit, no MSN fix yet :(
[05:08] <cody-somerville> micahg, seems to affect all versions - you can't add new contacts anymore :(
[06:23] <achiang> cody-somerville: the real bug is using MSN. ;)
[06:23] <micahg> I remember the pidgin devs putting out a call for help with the MSN support a while back
[06:23] <cody-somerville> achiang, the real bug is you... now leave me be... I'm busy playing Klondike solitaire :P
[06:30] <cody-somerville> bam. I've become so pro at solitaire it ain't funny ;)
[06:30]  * cody-somerville has Keybuk to thank for this.
[06:38] <pitti> Good morning
[07:19] <alexbligh1> Does anyone know if the current Natty development version of cobbler is supposed to support multiple interfaces with static IP? (i.e. generate ubuntu style networking scripts rather than redhat)
[07:26] <lamont> ScottK: yeah - and we want 2.8.1 for a segv fix
[07:51] <didrocks> good morning
[08:45] <dholbach> good morning
[08:46] <lag> If I want to use multiple (3) monitors, which graphics card manufacturer is most likely to work and least likely to be a bugbear?
[09:00] <rishi> Which package provides the debug symbols for hostapd on Ubuntu 10.04?
[09:09] <lag> rishi: Perhaps there isn't one
[09:09] <lag> rishi: You could always build it yourself and include the symbols: sudo apt-get source hostapd
[09:10] <kklimonda> rishi: you can enable ddebs repository and install hostapd-dbgsym
[09:10] <kklimonda> (ddebs repository being the repository mentioned in https://wiki.ubuntu.com/DebuggingProgramCrash)
[09:12] <rishi> kklimonda: Ok. Thanks.
[09:13] <rishi> So, packages coming from Universe do have their -dbg counterparts in the repositories by default?
[09:17] <kklimonda> rishi: no
[09:17] <kklimonda> rishi: -dbgsym packages are created automatically, by the builders. -dbg packages have to be explicity enabled by package maintainers.
[09:18] <kklimonda> (all binary packages have -dbgsym counterparts, but only some packages ship -dbg)
[10:32] <ogra> jhunt, how is the serial world of upstart looking (i have a workitem for A3 i would like closed at some point)
[10:32] <ogra> (or is that already in and i just missed the changelog entry)
[10:33] <jhunt> ogra: last I heard we were waiting for SpamapS to tweak the .conf file?
[10:33] <ogra> ah, k, i'll wait until he gets up to poke him ... and offer help if he needs any
[10:40] <cdbs> Hi, I am uploading a new package to Ubuntu which would enter Debian very soon. I am MOTU. Do I need to file needs-packaging bug?
[10:41] <pitti> cdbs: usually not; just upload it
[10:41] <cdbs> pitti: okay
[10:52] <zyga> hi, what is the recommended way to package python stuff? I'm reading https://wiki.ubuntu.com/PackagingGuide/Python and it specifies two options cdbs and debhelper
[10:52] <cdbs> zyga: I'd recommend debhelper, its the better way
[10:52] <cdbs> zyga: and preferably dh_python2
[10:52] <zyga> cdbs, dh_python2? is that a third choice?
[10:52] <zyga> cdbs, any official guide/hints?
[10:53] <cdbs> zyga: dh_python2 is the debhelper8 way of doing python packaging
[10:53]  * cdbs g2g
[10:53] <zyga> cdbs, thanks
[10:56] <zyga> cdbs, does dh_python2 make python central/support obsolete?
[10:58] <cjwatson> it's intended to, AIUI
[11:00] <cdbs> zyga: ^
[11:00] <pitti> ev: uploading jockey with the --no-dbus option now
[11:00] <zyga> thanks
[11:01] <pitti> ev: I haven't changed the nvidia driver to autoinstall yet
[11:01] <ev> pitti: you're my hero, thanks!
[11:01] <zyga> I'm googling for docs about how to use it
[11:01] <pitti> ev: that should be something like http://paste.ubuntu.com/571047/, if you want to experiment
[11:01] <pitti> ev: (it's not just "True", as there might be several versions available, and we just want the 'best' one
[11:01] <ev> pitti: I don't think we want it as autoinstall, actually.  That would cause it to get installed in the live session when ubiquity calls jockey-text -a for the wireless driver.  My intention was to call jockey-text -C in the chroot to get the nvidia driver.
[11:02] <pitti> ev: ah, even better then :)
[11:02] <ev> :)
[11:02] <pitti> ok, I need to disappear for ~ 2 hours
[11:10]  * zyga now reads http://wiki.debian.org/Python/Packaging
[12:08] <mvo> @pilot in
[12:09]  * dholbach hugs mvo
[12:09] <dholbach> yooohooo
[12:11] <mvo> !!!
[12:25] <mok0> I am looking for an example of sophisticated option parsing in C++
[12:25] <mok0> anyone? ^
[12:27] <didrocks> someone know if there is a policy when you upgrade a package and replace a hard link by a file? (IIRC, dpkg doesn't remove the inodes before the upgrade, so the file content will be erased with the new one for all linked inode?)
[12:27] <didrocks> my issue is that the compiz hook is a hard link to the xorg one. I want know to ship a real separate hook for compiz than xorg
[12:29] <cjwatson> a hard link is a file
[12:30] <cjwatson> there should be no problem, anyway
[12:30] <cjwatson> dpkg will unpack the new contents of the file and rename it into place
[12:30] <cjwatson> the effect of that will be to decrease the link count of the inode that was previously there
[12:30] <cjwatson> or IOW to break the hard link
[12:30] <cjwatson> you don't need to do anything special
[12:33] <siretart> are NEW packages uploaded today going to make it for feature freeze?
[12:35] <didrocks> cjwatson: excellent, thanks for the info :) (I was wondering if they could have been an issue)
[12:35] <mbiebl> james_w: ping
[12:36] <cjwatson> siretart: yes, AA delay is not taken into account
[12:36] <siretart> excellent, thanks!
[13:06] <james_w> hi mbiebl
[13:07] <mbiebl> james_w: hi
[13:07] <mbiebl> I was asked by the debian gnome maintainers for polkit 0.100
[13:07] <mbiebl> and was wondering what to do about your patch
[13:08] <mbiebl> it no longer applies
[13:08] <mbiebl> and in the upstream bug report you wrote that you can no longer reproduce the issue
[13:08] <mbiebl> http://bugs.freedesktop.org/show_bug.cgi?id=30515
[13:09] <james_w> mbiebl, I've never been able to reliably reproduce
[13:09] <james_w> I don't think the bug will be gone with the changes that were causing the conflicts when I last looked
[13:11] <mbiebl> james_w: what would you suggest we do? drop the patch for now?
[13:11] <mbiebl> update it for the new upstream release?
[13:12] <apw> cjwatson, just a heads up on bug #672699, i have just pushed some changes to enable speakup-modules in natty, will be in the next upload
[13:12] <apw> it was unclear if there was more work to be done on the installer or not to my eye
[13:13] <james_w> mbiebl, update it, I see no reason for the bug to be gone otherwise, and it does affect a lot of people and makes polkit pretty useless for them apparently
[13:15] <mvo> bdrung: hi, I just looked at the poedit sponsoring request, looks fine to me, do you mind if I upload or would you rather want to coordinate with debian?
[13:16] <mvo> (bug #717168 )
[13:17] <bdrung> mvo: upload it! the ff is coming and waiting for debian may take too long. we still can sync it later on
[13:17] <mvo> bdrung: great, thanks. that is my feeling as well
[13:18] <bdrung> mvo: do you process the upgrade requests first?
[13:18] <mvo> bdrung: I currently go over the list from top to bottom, but I'm happy to look at specific stuff too
[13:19] <bdrung> mvo: please look at the type=upgrade items first (due to the nearing ff)
[13:20] <mvo> ok
[13:21] <seb128> bdrung, do you know how is the "upgrade" set?
[13:22] <bdrung> seb128: i don't get your question.
[13:22] <seb128> bdrung, what is the logic which makes "upgrade" show in the type column
[13:22] <seb128> bdrung, the pango and gtk binding updates are not tagged as upgrade
[13:22] <seb128> they should
[13:24] <bdrung> seb128: either the bugs are tagged with 'upgrade' or ... let me check
[13:24] <cjwatson> apw: thanks.  I don't expect we need to change anything
[13:24] <mvo> the nice thing about the sposnoring is that you always learn about new packages. ucommon - sounds like a misisng n (but that has tradition I guess)
[13:24] <cjwatson> er, well, wait, not sure
[13:24] <bdrung> seb128: or upgrade-software-version tag or 'new upstream version' in the title
[13:25] <cjwatson> will have to look latere
[13:25] <cjwatson> *later
[13:25] <cjwatson> apw: I've created a debian-installer task
[13:25] <seb128> bdrung, ok
[13:25] <bdrung> seb128: let me know if there are other ways to detect it
[13:25] <seb128> mvo, well in any case the pango and gtk bindings ones should be trivial if you want to upload those
[13:26] <seb128> bdrung, not that I know about, I was just curious because those are not tagged and you asked mvo to review tagged things :p
[13:31] <rniamo> hi, will libmapi be packaged soon? A new version fixed this bug http://www.ubuntuupdates.org/packages/show/281187
[13:32] <rniamo> here is the bug on gnome bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=632784
[13:34] <mvo> seb128: looking at the pangomm one now, that 2.27.1 version is fine? 2.27 is not some unstable version or somesuch?
[13:35] <mvo> seb128: or if it is then you want it, right?
[13:35] <seb128> mvo, it's unstable on the way to 1.28 which is our pango version
[13:35] <seb128> the bindings are just a bit behind
[13:35] <seb128> but we do want the update
[13:35] <seb128> it's required for the gtk bindings update to 2.24
[13:35] <mvo> ok
[13:39] <pitti> oh ergh, why does jockey still show the nvidia driver
[13:39] <ari-tczew> cjwatson: what about lilo merge?
[13:40] <tjaalton> anyone on natty, other than radeon/intel/nvidia gfx, and virtual consoles do/don't work? at least on my ancient thinkpad with savage there's just a blinking cursor
[13:41] <tjaalton> installed today
[13:42] <bdrung> ari-tczew: it doesn't show up in the sponsors queue
[13:43] <ari-tczew> bdrung: I leave this one for cjwatson, but there is special case, very close to FFe, do you would like to take sponsorship?
[13:43] <bdrung> ari-tczew: no
[13:43] <bdrung> just wondered that it doesn't appear on the list
[13:44] <ari-tczew> ;]
[14:24] <tjaalton> cjwatson: when editing the grub options from the grub boot menu, should the variables be expanded or not? I see 'set gfxpayload=$linux_gfx_mode', and only by changing it to 'text' or removing completely do I get working vc's
[14:34] <cjwatson> tjaalton: variable expansion is probably not your problem.  linux_gfx_mode is likely set to 'keep'
[14:34] <cjwatson> tjaalton: I bet you'll see the same thing if you say set gfxpayload=keep
[14:35] <cjwatson> tjaalton: see https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard etc.
[14:48] <tjaalton> cjwatson: with 'keep' I have a grub message on every vt ('booting a command list')
[14:49] <tjaalton> but yeah, equally broken anyway
[14:52] <RoAkSoAx> vish: ping?
[14:53] <cjwatson>  xserver-xorg-input-evdev-udeb : Depends: xserver-xorg-core (>= 2:1.9.99.902-2ubuntu1) but it is not installable
[14:53] <cjwatson> agh, I wish d-i builds would stop breaking
[14:58] <tjaalton> cjwatson: do you see actual bugs, or is it just bad timing?
[15:01] <cjwatson> tjaalton: udebs depending on non-udebs is clearly a bug.  I'm investigating why this regressed
[15:01] <tjaalton> cjwatson: ah, ok
[15:04] <cjwatson> oh wow, it's even an explicit dep
[15:05] <cjwatson> broken in xserver-xorg-input-evdev 1:2.6.0-1ubuntu7 - I'll upload a fix
[15:06] <vish> RoAkSoAx: hi, pong..
[15:07] <tjaalton> cjwatson: oh, duh...
[15:08] <tjaalton> bad cnd :)
[15:08] <ari-tczew> doko__: what does it mean "spring time, drop all Ubuntu changes" ?
[15:09] <vish> ari-tczew: spring cleaning?
[15:09] <ari-tczew> vish: yea, why does it mean?
[15:09] <ari-tczew> why we are cleaning?
[15:10] <vish> oh, why i dont know :)
[15:10] <doko__> context?
[15:10] <ari-tczew> doko__: https://launchpad.net/ubuntu/+source/jasperreports/3.7.4+dfsg-1ubuntu2
[15:11] <Laney> I assume it means that the FTBFS no longer happens.
[15:12] <RoAkSoAx> vish: hi there! You created the icons for TestDrive right :)?
[15:12] <doko__> well, look at the previous version ...
[15:13] <tjaalton> cjwatson: should I file a bug about 'keep' not working with savage, or that it should use 'text' instead?
[15:13] <ari-tczew> doko__: yes, I saw, I was an uploader then
[15:14] <doko__> then I don't get your question
[15:15] <ari-tczew> doko__: OK Laney
[15:15] <ari-tczew> 's answer is enough for me.
[15:20] <cjwatson> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
[15:21] <vish> RoAkSoAx:  yup. :)
[15:25] <RoAkSoAx> vish: would you like, and have the time, to create a new one for the IndicatorApplet I just added (but just to draw attention, such as one in red or something like that :))
[15:26] <vish> RoAkSoAx: sure, no probs. to match the ubuntu-mono icons or just general?
[15:26] <vish> RoAkSoAx: and by when do you want them done..?
[15:29] <RoAkSoAx> vish: just a general one. I mean, the same icon as we are currently using, but with another color that will draw the attention. The indicator applet will appear only when something X happens, and it needs to be a visible icon that draws the attention (For example, the messaging indicator icon is white, and green when drawin attention)
[15:30] <RoAkSoAx> vish: I don't have an exact date, but would be nice to have it by alpha3 :)
[15:31]  * vish checks alpha 3 date :)
[15:32] <cnd> cjwatson, tjaalton: sorry!
[15:32] <vish> RoAkSoAx: hmm, ok.. if you have a bug open for it you can just assign it to me …
[15:32] <cnd> I should have depended on xserver-xorg-core-udeb?
[15:32] <RoAkSoAx> vish: will do. Thanks a lot :)!!
[15:32] <vish> np.. :)
[15:33] <cjwatson> cnd: yes, I made that chance
[15:33] <cjwatson> *change
[15:33] <cnd> cjwatson, thanks
[15:33] <cjwatson> udebs must never depend on debs, or vice-versa
[15:33] <cnd> yeah
[15:33] <cnd> I should have realized that
[15:39] <dholbach> barry, heya - what do you think we should do about the packaging guide merge proposal?
[15:41] <dajhorn> bdrung: You should cancel the lshw sync because it is phoning home again.  The last time this happened,  Kees Cook authorized an NMU on it.
[15:46] <tjaalton> cnd, cjwatson: the drivers should get correct deps on build
[15:47] <cnd> tjaalton, it's because there's an explicit dependency on the new xi 2.1 stuff in that server
[15:48] <tjaalton> cnd: that's why serverminver was bumped on the server?
[15:48] <tjaalton> meaning that drivers built against it will get the correct dependency
[15:48] <cnd> tjaalton, maybe that's how it should be done?
[15:49] <cnd> I don't really know about all the debian x packaging dependency stuff
[15:53] <tjaalton> cnd: it's the ${xinpdriver:Depends} field in control which is then substituted with the value from the xserver it's built against
[15:53] <cnd> tjaalton, ok, then the depends probably wasn't necessary
[15:54] <tjaalton> but it doesn't matter too much, it should be possible to drop it from the next upload
[15:56] <tjaalton> cjwatson: thanks, i'll file one with those instructions
[16:06] <dajhorn> bdrung: Nevermind.  Resolution in the Launchpad ticket.
[16:08] <lool> cjwatson: Eh did you see joeyh did the same Maintainer: change to debootstrap as I had pushed for the dpkg toolchain issue?  :-)
[16:08] <cjwatson> yeah - I figured whatever
[16:09] <lool> cjwatson: Ah, and I was expecting a clash of the titans!
[16:09] <lool> oddly enough, he didn't close my bug
[16:18] <apw> i assume the current threat to remove ubuntu-desktop is a temporary publishing glitch
[16:22] <Chipzz> cjwatson: 15:53 < cjwatson>  xserver-xorg-input-evdev-udeb : Depends: xserver-xorg-core (>= 2:1.9.99.902-2ubuntu1) but it is not installable
[16:23] <Chipzz> cjwatson: why do udebs have different names from regular debs anyway?
[16:23] <cjwatson> because it was easier to manage the archive that way
[16:23] <Chipzz> I thought debs and udebs where different "namespaces" anyway
[16:23] <Chipzz> ?
[16:23] <cjwatson> no, they share a namespace
[16:23] <Chipzz> maybe I should phrase that better
[16:23] <cjwatson> certainly not going to change that now :)
[16:24] <Chipzz> udebs are a collection in itself
[16:24] <Chipzz> debs are a collection in itself
[16:24] <cjwatson> whatever
[16:24] <cjwatson> their names can't collide
[16:24] <cjwatson> maybe we would design it differently if we were doing it again, but it is not worth changing now
[16:25] <cjwatson> one example of where it's a shared namespace:
[16:25] <cjwatson> https://launchpad.net/ubuntu/natty/+package/xserver-xorg-core
[16:25] <cjwatson> https://launchpad.net/ubuntu/natty/+package/xserver-xorg-core-udeb
[16:26] <cjwatson> (that reflects namespacing in the LP database, and dak is similar)
[16:26] <cjwatson> actually, TBH, I find it better this way, as an installer developer
[16:26]  * lool throws tdebs at Launchpad and dak
[16:26] <cjwatson> it means that you can unambiguously talk about the dependencies of <package name>
[16:27] <cjwatson> without being confused about those being different depending on whether you mean a deb or a udeb
[16:27] <cjwatson> sure, no doubt a computer could resolve the differences, but it's clearer for human developers
[16:27] <Chipzz> cjwatson: my usage of the word "namespace" was badly chosen, let me clarify: I meant the collection of debs and the collection of udebs are independant in the same way as say, the collection of .i386.deb's and .amd64.deb's are independent
[16:28] <Chipzz> they are directed graphs with no overlap
[16:28] <cjwatson> that's as may be, but I hope my comments above are a sufficient answer
[16:28] <Chipzz> anyway, if it's more convenient to you, by all means keep it
[16:28] <Chipzz> who am I to argue with someone who works on the installer
[16:29] <cjwatson> your comment about i386 and amd64 is about to become a lot less true, mind you ;-)
[16:29] <Chipzz> the point I was trying to make is that them having different names causes a different set of issues, like the one from above, because certain tools need to have special cases
[16:29] <cjwatson> fortunately, foo_i386.deb and foo_amd64.deb usually look fairly similar
[16:30] <Chipzz> right :)
[16:30] <cjwatson> whereas foo_i386.deb and foo-udeb_i386.udeb are typically significantly different in terms of e.g. their file lists and metadata
[16:30] <cjwatson> they really aren't the same type of thing, and it's worth the effort to call them by different names
[16:30] <cjwatson> makes debian/control less confusing too
[16:31] <cjwatson> and in fact debian/ in general - you can have debian/foo.install and debian/foo-udeb.install, and it all falls out nicely
[16:31] <cjwatson> it could have gone either way at the start (it was debated), but I quite like the way it's ended up
[16:32] <Chipzz> you're right about debian/foo.install vs debian/foo-udeb.install of course, that would have causes a different set of special casing
[16:33] <Chipzz> *caused
[16:33] <Chipzz> I guess you get to choose between different sets of issues :)
[16:33] <cjwatson> yeah
[16:35] <Chipzz> I don't agree with you on this though: 17:26 < cjwatson> it means that you can unambiguously talk about the dependencies of <package name>
[16:35] <Chipzz> since dependencies can be arch-specific anyway
[16:35] <Chipzz> but that's a nitpick I suppose
[16:36] <cjwatson> yeah I realise that, but in practice they're not usually wildly different
[16:36] <Chipzz> anyway, decision has been made, little point in discussing it further, I'll leave you to your job :)
[16:36] <cjwatson> whereas they almost always need to be different between debs and udebs
[16:43] <cnd> Riddell, I've posted a merge request for the qt touch stuff: https://code.launchpad.net/~utouch-team/ubuntu/natty/qt4-x11/xi2.1/+merge/50952
[16:43] <hrw> hi
[16:44] <hrw> mvo: thanks for review of gcc-4.5-armel-cross
[16:44] <mvo> hrw: sure, you are welcome
[16:45] <mvo> should be in natty by now
[16:45] <hrw> ok
[16:45] <cnd> Riddell, I'm building this package in ppa:utouch-team/xorg-unstable right now, though it works properly on my machine
[16:45] <hrw> mvo: next week will get new version anyway
[16:46] <hrw> but I finally applied for UD/UC status
[16:51] <mvo> @pilot out
[16:55] <mvo> hrw: hm, I only just now saw the message about that I should not upload. if you want to avoid this for the future, its probably best to just remove the merge request (as otherwise it will appear in the sponsoring queue and someone like me will look at it and act on it)
[16:55] <hrw> mvo: ok, will take care next time
[16:55] <hrw> mvo: having updated version in archive is not a problem anyway
[16:56] <mvo> hrw: ok
[17:07] <ogra> SpamapS, where do we stand wrt serial support in upstart ? (/me has a workitem he would like to close)
[17:11] <SpamapS> ogra: Its been proposed as a merge, and debated upstream.. but nobody has pulled the trigger on merging it. Nobody has -1'd it either yet...
[17:11] <ogra> hmmm
[17:11] <ogra> i thought we wanted to make it a package patch
[17:13] <SpamapS> ogra: yes, and thats where the MP sits
[17:14] <ogra> why do we need to wait for an upstream merge for a distro patch ?
[17:14] <SpamapS> we don't.. we, as in, I, have no upload rights. ;)
[17:15] <SpamapS> hopefully changing soon
[17:15] <SpamapS> ogra: IIRC, cjwatson also wanted to see if we could incorporate the same logic that d-i uses to configure serial console for the kernel to create this file.
[17:16] <ogra> no, he wanted that we look at the d-i implementation to not run into the same probs that were solved there already another time
[17:16] <SpamapS> ogra: so instead of just always installing it, we'd only install it if the install was over serial console.. otherwise it would be something like /etc/init/tty-serial.conf.disabled
[17:17] <ogra> that doesnt help me at all
[17:17] <SpamapS> ogra: unfortunately jhunt and I have been swamped with critical bugs in the boot and shutdown and haven't been doing much feature work. :(
[17:18] <SpamapS> ogra: well for the time being the proposed fix is to just install it and let it do its thing as you wrote it.
[17:18] <ogra> on arm you might do your install graphically but still want a serial console if the console=ttySX option is set, it shoudl react on the ernel option not be based on installation procedure
[17:18] <ogra> that would be fine too
[17:19] <SpamapS> ogra: the concern is, as you know, that there is some small delay in opening and reading /proc/cmdline
[17:19] <ogra> yep
[17:19] <SpamapS> ogra: but upstart has no simple way to pass along the console= options that the kernel is happily copying into its environment now.
[17:20] <SpamapS> ogra: So.. the best course of action may be to bump cjwatson or keybuk and see if they'd be amenable to accepting the patch from the bug fix that I proposed. If I could do more .. I would. :-P
[17:20] <ogra> yeah, i understand, i just need to know what to do with my workitem, i can leave the hack in place that creates the .conf file on all arm installs
[17:32] <bdrung> mvo: did you upload the fix for bug #494096?
[17:51] <chrisccoulson> bdrung / mvo, that's been sat in the lucid-proposed queue for a while already
[17:52] <bdrung> ups, i looked at the maverick queue. there i couldn't find it...
[17:53] <chrisccoulson> yeah, mvo did upload it, so it is in the queue twice now
[18:37] <ari-tczew> when FF is starting?
[18:37] <ogra> ari-tczew, tomorrow evening UTC i was told
[18:37] <ogra> or texan lunch time, as you wanna put it ;)
[18:38] <ari-tczew> ogra: so we have ~29 hours for uploading?
[18:38] <ogra> 28h 7min and 13sec
[18:38] <ogra> :P
[18:38] <ogra> no idea, really
[18:39] <ogra> i can just say what our release manager said when i asked
[18:39] <ogra> around lunch time TX
[18:42] <micahg> ogra: tomorrow UTC?  so we get an extra day?
[18:42] <ogra> micahg, ??
[18:42] <ogra> here its the 23rd still
[18:42] <micahg> ogra: freezes start at midnight according to the wiki
[18:42] <alkisg> I'm a little mixed up about LP bug #494096, so are we (users that are interested in getting the bug fixed on lucid) to test the maverick version of gnome-session, or are we to wait until gnome-session gets approved in lucid-proposed?
[18:42] <ogra> thats not what skaet_ said
[18:43] <hrw> hi ari-tczew
[18:43] <ari-tczew> hello hrw
[18:48] <cjwatson> micahg: realistically, freezes start whenever it's convenient for them to start, on the given day :)
[18:52] <micahg> cjwatson: right, but generally, they've started the UTC morning after UTC midnight on the day in question, I was just quoting from the second bullet here: https://wiki.ubuntu.com/NattyReleaseSchedule
[18:52] <ogra> yeah ... papers
[18:53] <ogra> dont belive everything you read ;)
[18:53] <micahg> cjwatson: when will be the last sync run before feature freeze?
[18:54] <Laney> usually anything requested before is OK
[18:55]  * ogra feels the level of pre-freeze panic rising :D
[18:59] <cjwatson> micahg: I was about to start one; then maybe one tomorrow morning or so
[19:00] <mvo> chrisccoulson: hrm, haven't seen that. I unsubscribe ubuntu-sposnors now to ensure its not uploaded a third time
[19:00] <micahg> cjwatson: ok, thanks
[19:00] <chrisccoulson> mvo - thanks
[19:00] <mvo> chrisccoulson: did you do the other upload? would be nice to mention it in the bugreport (and verify that my sru instructions are good)
[19:01] <chrisccoulson> mvo - i should have commented really. pitti sponsored my upload
[19:01] <mvo> chrisccoulson: ok, not a big deal, patch is tiny
[19:02] <hrw> ogra: ;)
[19:02] <hrw> ogra: no one said that feature freeze == feature complete
[19:05] <barry> mvo: are you still around?
[19:08] <maco> aw crud, feature freeze is tomorrow huh?
[19:08] <barry> it is :)
[19:09] <maco> oh damn, utc...
[19:09] <maco> i wont even be home from work tonight by the time FF kicks in
[19:09] <micahg> maco: we were chatting about that earlier, you have a little more time than that apparently
[19:10] <maco> well i have a feature to write into gally that promised highvoltage i'd have in there for natty
[19:12] <skaet_> all, just to be clear feature freeze will be at 1800 UTC Feb 24th for Natty,  after that please follow the https://wiki.ubuntu.com/FreezeExceptionProcess if something needs to get uploaded.
[19:12] <highvoltage> I'm sure that would be fine for an FFe :)
[19:12] <highvoltage> (well, we can at least try, right?)
[19:14] <micahg> skaet_: ok, thanks for the clarification
[19:14] <maco> skaet_: thanks
[19:14] <maco> highvoltage: i finally got internets! i can hack again!
[19:15] <Daviey> doko, Are you around?  I could do with some ld help :)
[19:17] <highvoltage> maco: \o/
[19:17]  * Laney ponders
[19:18]  * Laney ponders in the wrong channel
[19:26] <Chipzz> Laney: are you pondering what I'm pondering? ;)
[19:27] <Laney> whether it's OK to upload new versions of quickcheck, mtl, src-exts for the new Agda? ;-)
[19:27] <Chipzz> I guess you missed the reference to Pinky & The Brain then ;)
[19:27] <Laney> deliberately :P
[19:28] <mvo> barry: yes
[19:28] <Chipzz> p&tb rule :)
[19:28] <barry> mvo: hi.  leonard has signed off on the update of launchpadlib to 1.9.7, so we'd like to get that into natty.  i have a merge proposal for that, however, it will require MIR of python-keyring 0.5.1
[19:28] <barry> mvo: mir is bug 686257
[19:29] <barry> mvo: merge proposal is: https://code.launchpad.net/~barry/ubuntu/natty/python-launchpadlib/bug-702375-1.9.7/+merge/50818
[19:29] <barry> is there anything you can do to help? :)
[19:29] <mvo> barry: ok, will you do the MIR?
[19:29] <mvo> barry: aha, ok
[19:29]  * mvo looks
[19:29] <barry> mvo: thanks.  i'm not sure if we need more in the mir bug comments
[19:30] <mvo> barry: ok, looks good, mir got approval, so uploading should be fine now
[19:30] <alkisg> mvo, sorry for the ping, about LP bug #494096, I still don't see gnome-session in lucid-proposed.
[19:31] <barry> mvo: awesome, can you do both packages for us?
[19:31] <alkisg> Erm nor metacity
[19:31] <mvo> alkisg: someone needs to manually approve it first, it should appear soon (tomorrow, the day after tomorrow)
[19:32] <mvo> barry: does the other one require a update as well?
[19:32] <alkisg> OK, I thought it was already there since the 15th, thanks
[19:33] <barry> mvo: ah, no i guess it doesn't.  python-keyring 0.5.1-0ubuntu1 is already in natty, so we just need launchpadlib updated
[19:33] <barry> mvo: thanks!
[19:37] <mvo> barry: uploaded
[19:37] <cnd> bryceh, do you know how to set a bug so that it has two ubuntu packages for it?
[19:37] <barry> mvo: awesome, thanks
[19:37] <mvo> thank you for the update!
[19:38] <cnd> bryceh, oh, I think it's in "also affects distribution"...
[19:38] <cnd> so nm :)
[19:39] <m4n1sh> bdrung: ping
[19:39] <bdrung> m4n1sh: pong
[19:40] <m4n1sh> bdrung: AFAIK  you have expertise packaging firefox addons
[19:40] <m4n1sh> am I right?
[19:40] <bdrung> yes
[19:40] <m4n1sh> I have one addon
[19:40] <m4n1sh> which I would like to get packaged
[19:40] <m4n1sh> is the process somewhat unusual than other packages?
[19:41] <m4n1sh> bdrung: it is zeitgeist firefox dataprovider
[19:41] <m4n1sh> for pushing events in the daemon
[19:41] <bdrung> no, but addons won't be accepted in ubuntu unless they are architecture specific and needs to be compiled.
[19:42] <m4n1sh> bdrung: they are
[19:42] <bdrung> m4n1sh: the extension specific things are explained in http://wiki.debian.org/mozilla-devscripts
[19:42] <m4n1sh> it links against libzeitgeist
[19:42] <m4n1sh> which is a native libraru
[19:42] <m4n1sh> *library
[19:43] <bdrung> other question: is it a XUL extension or plugin?
[19:43] <pitti> cjwatson: back now; do you want me to copy the maverick-proposed kernel, or did you already?
[19:43] <m4n1sh> bdrung: plugin
[19:44] <m4n1sh> bdrung: http://bazaar.launchpad.net/~zeitgeist-dataproviders/zeitgeist-dataproviders/trunk/files/head:/firefox-libzg/
[19:44] <bdrung> hm, mozilla-devscripts is for xul extensions. dunno if it helps packaging plugins
[19:44] <m4n1sh> it is written in C++
[19:44] <m4n1sh> it does have XUl files
[19:44] <m4n1sh> XUL
[19:44] <m4n1sh> for UI i think
[19:44] <cjwatson> pitti: just finished doing it
[19:45] <pitti> ah, good
[19:45] <bdrung> looking at the link, it's a xul extension. so you can use mozilla-devscripts
[19:45] <pitti> cjwatson: sorry, had to be away for the afternoon, but back now
[19:46] <m4n1sh> thanks.. if I have some problems, I might ask you if you are free
[19:46] <bdrung> m4n1sh: yes. build the xpi file with the upstream makefile, then use xpi-install to install the xpi file
[19:46] <NCommander> @pilot on
[19:46] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[19:47] <NCommander> @pilot in
[19:47] <NCommander> :-)
[19:47] <m4n1sh> bdrung: you mean to say for checking whether it works or not OR for packaging it?
[19:47] <bdrung> NCommander: recommendation due to the nearing FF: please review the items with type=upgrade first.
[19:47] <bdrung> m4n1sh: for packaging
[19:48] <m4n1sh> thanks
[19:48] <NCommander> bdrung: indeed
[19:48] <cjwatson> pitti: np
[19:50] <micahg> NCommander: if you're piloting now, maybe I'll wait until 0:00 UTC
[19:51] <bdrung> micahg: why?
[19:51] <micahg> bdrung: some we don't end up working on the same things
[19:52] <micahg> *so
[19:52] <NCommander> micahg: you could take now, I can go later
[19:52] <micahg> NCommander: no, it's fine
[19:52] <bdrung> micahg: you can coordinate by assigning bugs to yourself and by beeing verbose on irc
[19:52] <bdrung> *being
[19:53] <NCommander> bdrung: how do I see type=upgrade?
[19:54] <bdrung> NCommander: http://reports.qa.ubuntu.com/reports/sponsoring/ -> click on the column type
[19:54] <jcastro> anyone know who's running backports these days?
[19:56] <jamespage> doko, kees, mterry, didrocks, asac: please could one of you review MIR bug 676904; I'd like to get the associated sync with Debian (bug 661230) complete before FF - thanks
[20:26] <pitti> kees: dapper/hardy/karmic kernels are v-done now, want me to copy to -updates and -security?
[20:39] <kees> pitti: if they have CVEs, yes
[20:39] <pitti> kees: shall I just copy, or send a ping somewhere?
[20:39] <pitti> (I'll update the bugs, of course)
[20:39] <kees> pitti: if you can for now do the copies (and related ABI packages) and then email security@ubuntu.com, that would be appreciated.
[20:40] <pitti> roger
[20:40]  * kees hugs pitti
[20:41]  * pitti hugs you back
[20:42] <apw> is the language-selector triggering a deinstall of ubuntu-desktop a known, is it transient?
[21:07] <kees> lifeless: remember the ancient gpg bug you opened about it keeping the keyring locked after running it?
[21:07] <kees> lifeless: I have a work-around, if you still are interested.
[21:08] <kees> lifeless: to my ~/.gnupg/gpg.conf file, I added "no-auto-check-trustdb" and then added this to my crontab:  37 5 * * * gpg --check-trustdb 2>&1 | egrep -v '(depth: | needed,|next trustdb check)'
[21:08] <lifeless> kees: *blink*
[21:08] <lifeless> kees: shouldn't we, uhm, fix the bug ? :)
[21:08] <kees> it's not technically a bug
[21:08] <kees> it's updating the trust db.
[21:08] <kees> so you have to wait for it.
[21:09] <kees> it's an annoying feature.
[21:09] <lifeless> kees: evolution killing gpg, and gpg not cleaning up when killed - thats the bug
[21:09] <kees> so I turned off the feature.
[21:09] <kees> oh. :(
[21:09] <kees> didn't remember that was the issue. :)
[21:09] <lifeless> kees: I don't mind the process taking a bit to do the auto check. Thats -fine-
[21:09] <kees> it's been a while
[21:09] <lifeless> kees: when there is no gpg running and a lock file, thats not expected behaviour ;)
[21:10] <lifeless> theres a cluster of bugs
[21:10] <lifeless> gpgme or whatever it is that evolution uses to run gnupg doesn't handle an autocheck occuring properly.
[21:10] <lifeless> thats one
[21:10]  * kees nods
[21:10] <lifeless> secondly, it doesn't handle the gpg process lifetime properly - *or* - gpg has a bug around locks and signals.
[21:11] <kees> I'm curious if turning off autocheck would fix it for you, though.
[21:13] <lifeless> it would address the former cosmetic issue of the output being treated as meaning a gpg error had occured
[21:14] <lifeless> I doubt it would /fix/ the stale lock problem - lots of other folk encounter the gpg handling issue
[21:14] <lifeless> it might reduce the frequency
[21:16] <pitti> StevenK, wgrant: hm, did anythign change wrt. copy-packages.py recently? copying the hardy/karmic kernels to -updates takes aaaages (it's sitting there for 10 min already doing nothing)
[21:17] <lifeless> pitti: our servers are rather busy
[21:17] <pitti> I already ^C'ed it twice, and it seems to get stuck in recalculateBugHeatCache
[21:17] <StevenK> pitti: I'm personally not aware of anything. Hm, perhaps bug heat is broken. :-(
[21:20] <lifeless> if its called
[21:20] <lifeless> bah
[21:20] <lifeless> so
[21:20] <lifeless> there is a bug about bug heat calculation being expensive
[21:21] <lifeless> what its doing is refreshing the heat across -all- bugs for that source package
[21:21] <pitti> I guess I'll just let it sit there then and hope that it'll finish at some point?
[21:21] <lifeless> which is more than a little crazy
[21:21] <lifeless> it will, yes
[21:21] <pitti> lifeless: ugh, and as this is linux, there will be many thousands
[21:21] <lifeless> see lib/lp/registry/model/distributionsourcepackage.py
[21:21] <lifeless> that function in that module
[21:21] <pitti> shouldn't it only touch the bugs referenced in the changelog, i. e. the ones that it closes automatically?
[21:21] <lifeless> is what you may be hitting
[21:22] <lifeless> or are you in BugTarget.recal...
[21:22] <lifeless> ?
[21:22] <pitti>   File "/srv/launchpad.net/codelines/soyuz-production-rev-12381/lib/lp/registry/model/distributionsourcepackage.py", line 222, in recalculateBugHeatCache
[21:22] <pitti>     BugTask.status.is_in(UNRESOLVED_BUGTASK_STATUSES)).one()
[21:22] <lifeless> pitti: context bug heat is defined with a global algorithm
[21:22] <lifeless> pitti: yeah, thats the one I thought it might be.
[21:22] <lifeless> pitti: please file a bug and let me know the number
[21:23] <pitti> against soyuz? or malone?
[21:23] <lifeless> pitti: note that if it takes > 10 seconds you'll be causing timeouts in the webapp.
[21:23] <lifeless> pitti: launchpad.net/launchpad
[21:23] <pitti> lifeless: it's shell command on cocoplum
[21:23] <lifeless> pitti: I know
[21:23] <lifeless> pitti: if it takes > 10 seconds, all bug updates in the context that you're working on will queue in the db for the source package row lock.
[21:23] <pitti> ah
[21:24] <lifeless> foreign key constriants ftw
[21:24] <lifeless> constraints
[21:24] <lifeless> once a transaction starts a write on row X with FK Y, a row lock on the FK table row Y is taken out.
[21:24] <lifeless> to prevent the FK relationship being  broken.
[21:25] <kees> pitti: my the ABI checker is complaining that lucid's -update for linux-mvl-dove does not match linux-meta-mvl-dove (209 for meta, 211 for the kernel)
[21:25] <lifeless> pitti: the 10 second figure is because the timeout is 14 seconds
[21:26] <lifeless> and many updates are reasonably quick, so letting them have 4 seconds is probably ok.
[21:27] <pitti> lifeless: filed as bug 723955
[21:27] <lifeless> thanks
[21:27] <pitti> thanks to you
[21:28] <pitti> kees: uh, that's right; at least the ones in -proposed now seem to match
[21:28] <kees> pitti: so we should just wait for those to verify?
[21:29] <pitti> sconklin: ^
[21:29] <sconklin> reading back
[21:29] <pitti> sconklin: as the current linux-mvl-dove in lucid-proposed is v-failed, would it be possible to upload a fixed mvl-dove-meta to lucid-updates?
[21:30] <pitti> kees: FYI, I copied dapper to -updates/-security, but as karmic/hardy take ages to copy, I might not finish those two; I have the email to security@ staged
[21:30] <pitti> kees: finish tonight, I mean
[21:30] <sconklin> I'll check with Tim, who has been making those kernels
[21:30]  * pitti ^Cs again and runs in screen
[21:31] <kees> pitti: you can move processes into screen... http://blog.nelhage.com/2011/01/reptyr-attach-a-running-process-to-a-new-terminal/
[21:31] <kees> might need to turn off ptrace restriction briefly.
[21:31] <kees> anyway.
[21:32] <kees> pitti: that's fine about the kernels as long as they're not uninstallable.
[21:32] <pitti> kees: which I probably can't do on cocoplum
[21:32] <kees> ah-ha
[21:32] <pitti> but locally that sounds great, /me reads
[21:32] <kees> we have to do 1 USN per kernel anyway now because the CVE fixes are not contiguous any more.
[21:32] <pitti> queued up all copy commands, will hopefully finish over night
[21:32] <pitti> kees: ah, ok
[21:34] <GunnarHj> NCommander: Hi Michael, do you possibly have time to sponsor https://code.launchpad.net/~gunnarhj/language-selector/lp-533159/+merge/50265 ?
[21:34] <NCommander> GunnarHj: looking
[21:35] <GunnarHj> NCommander: Ok, thanks.
[21:36] <broder> kees: hmm...you know what would be awesome? a shell builtin that does the PTRACE_ME prctl for a child :)
[21:36] <cjwatson> wow, ghc6 takes long enough to build
[21:37] <kees> broder: hung.
[21:37] <cjwatson> glad my laptop has loads of memory
[21:37] <kees> er, hunh
[21:37] <kees> broder: isn't that just exporting LD_PRELOAD?
[21:37] <broder> doesn't help with an already running process
[21:37] <pitti> barry: new python-launchpadlib is missing the python-keyring dependency; it's crashing now
[21:37] <kees> sure, but nothing in the shell could help with that.
[21:38] <broder> kees: i guess i actually want a shell builtin that ptraces a given child, and calls the prctl from there, which is even more Awesome
[21:38] <kees> heh
[21:38] <sconklin> pitti, ot sure what you're asking for on mvl-dove. There are packages on the PPA ready to be copied out which replace the ones in -proposes and resync the ABI numbers
[21:38] <kees> yeah, that would be wild.
[21:38] <kees> broder: honestly, if you're running into it that much, just turn off the ptrace restrction instead. :P
[21:39] <pitti> sconklin: it's the ones in -updates which are broken
[21:39] <pitti> sconklin: oh, there are? I wasn't aware of that
[21:40] <sconklin> I wasn't either until I just looked
[21:40] <mterry> tedg, bam! https://code.launchpad.net/~mterry/indicator-datetime/clock-prefs/+merge/51013
[21:41] <sconklin> pitti: hold up, there's a regression in the ones on the ppa
[21:44] <sconklin> pitti, kees: There is a regression in the mvl-dove kernel that is affecting devices in the field, and the meta package was held back in updates to prevent updates to the known bad kernel
[21:44] <tedg> mterry, Cool!
[21:44] <sconklin> There's no fix known yet but kernel folks in Taipei are working on it
[21:45] <pitti> sconklin: how did we manage to catch the regression before updating the metapackage and yet had this copied to -updates?
[21:45] <sconklin> I don't know. I'm relaying this from Tim Gardner, he knows the details
[21:45] <bjf> pitti, we just got "lucky"
[21:46] <kees> sconklin: ah-ha! okay, good to know; thanks
[21:47] <sconklin> I'm going to delete the packages from our PPA, since they are known bad also
[21:53] <micahg> pitti: yeah, I haven't had a chance to rethink the pidgin-facebookchat SRU yet
[21:53] <pitti> no problem, I just stumbled over it when doing SRUs
[22:10] <kees> pitti: I was expecting to see QA sign-off on 716472. am I looking in the wrong place?
[22:11] <kees> sconklin-afk: ^ ?
[22:12] <pitti> kees: it's security only, so there are reduced tests (only the regression tests)
[22:12] <kees> pitti: right; I see no "verification-done" on it. Where is the link to the QA test report. i.e. https://wiki.ubuntu.com/QATeam/KernelSRU-karmic-2.6.31-22.73
[22:13] <pitti> hm, where did I see that..
[22:15] <pitti> there were a lot of duplciated tracking bugs this time, probably was on one of those
[22:15] <wgrant> pitti: Hi.
[22:47] <micahg> NCommander: FTR, from what I've been told, we generally don't bump standards in Ubuntu when updating ahead of Debian since it's an unnecessary diff
[22:49] <kees> pitti: based on the USN history, smb tested 2.6.15-55.91. I was expecting QA to test 2.6.15: 2.6.15-55.93.
[22:49] <kees> marjo: ^^
[22:49] <kees> sconklin: ^^
[22:51] <Quintasan> jcastro: ping
[22:51] <NCommander> micahg: I bump standards personally, and I'm not going to veto a diff that does.
[22:52] <jcastro> Quintasan: hi
[22:52] <Quintasan> jcastro: If I am applying for sponsorship, any idea why should I fill in https://forms.canonical.com/udsreg/ before I get sponsorship?
[22:52] <jcastro> not sure
[22:53] <micahg> NCommander: I personally wouldn't have vetoed, just reverted it and uploaded
[22:53] <jcastro> I guess it doesn't hurt
[22:55] <charlie-tca> Quintasan: near as I can tell, that was a mistake, since you can't actually fill it in before you get sponsored and get the flight booked
[22:56] <Quintasan> charlie-tca: I concluded the same thing and asked
[22:56] <Quintasan> jcastro: Huh, apparently I have already requested sponsorship @_@
[22:57] <jcastro> did you apply before?
[22:57] <jcastro> I see your submission
[22:58] <Quintasan> jcastro: I think I did but I was told it was a test form and I would have to reapply
[22:58] <jcastro> I can delete it if you want, up to you, then you can reapply
[22:58] <Quintasan> jcastro: Please do.
[22:59] <jcastro> Quintasan: ok, all set
[22:59] <Quintasan> jcastro: Thanks :)
[23:10] <Quintasan> jcastro: applied, can you check if it is there?
[23:18]  * cjwatson notices the source package lwjgl
[23:18] <cjwatson> are we naming packages with pwgen now?
[23:19] <ion> apt-cache search '^[bcdfghjklmnpqrstvwxz]{5,}$'
[23:20] <kees> ion: that's an alarmingly long list
[23:21] <ion> Which piece of software do you prefer? ltspfsd, sgmlspl, fstrcmp, ncmpcpp, ppthtml, qpsmtpd, rbldnsd or wzdftpd
[23:21]  * cjwatson wonders why apache2-mpm-event is showing up theree
[23:21] <cjwatson> even with -n
[23:21] <cjwatson> ion: haha
[23:35] <highvoltage> jono_: are you around? the process on http://uds.ubuntu.com/participate/sponsorship/ is a bit flawed (if you click on the first step you'll see why)
[23:36] <jono_> jcastro ^
[23:36] <highvoltage> thanks :)
[23:37] <jono_> :-)
[23:37] <jcastro> highvoltage: what do you mean?
[23:39] <jcastro> highvoltage: ok got it
[23:39] <jcastro> I've just removed that form
[23:41] <jono_> thanks jcastro
[23:44] <highvoltage> jcastro: cool bananas
[23:49] <kees> tedg: haha, love it. debconf frontend. you could totally do that, too.