[03:10] <pitti> Good morning
[06:37]  * pitti unleashes new quantal langpacks; builders, beware
[06:38] <pitti> skaet_: ^ we aim to please
[07:09] <dholbach> good morning
[07:10] <dholbach> can somebody please reject https://code.launchpad.net/~jjesse/ubuntu/quantal/libstring-approx-perl/typo-fix/+merge/125547 and https://code.launchpad.net/~jjesse/ubuntu/quantal/liborigin/typo-fix/+merge/125549 and https://code.launchpad.net/~jjesse/ubuntu/quantal/libpam-foreground/typo-fix/+merge/125548?
[07:16] <pitti> dholbach: done
[07:17] <dholbach> thanks pitti
[08:06] <StevenK> pitti: compinit is a zsh function to set up tab completion, it will write the runes for it into .zshrc
[08:18] <pitti> StevenK: ah, thanks; as I said, /me <- zsh n00b
[08:19] <StevenK> pitti: Yeah, I saw that bit, which is why I helped out. :-)
[09:20] <doko> qt4-x11 built fine locally here ... and no build log available ...
[09:34] <mvo> cjwatson: want me to have a look at #1052605 or are you on it already?
[09:36] <cjwatson> mvo: I'm not on it yet - if you could that would be lovely
[09:37] <mvo> cjwatson: ok
[09:46] <jamespage> is ubuntu-devel an appropriate list to send call for testing type stuff?
[09:55] <xnox> jamespage: if it is general, it can be.
[09:55] <xnox> jamespage: tasting what stuff though?
[09:55] <Laney> there's a dedicated testing ML I think
[09:56] <jamespage> Laney, yeah - I was going to send it there as well
[09:56] <jamespage> xnox, its specifically about testing of java apps with the transition of default java from openjdk-6 to openjdk-7
[09:56] <xnox> sounds -devel worthy
[09:57] <xnox> I tested the transition by checking that purging java from my machine still works ;-)
[09:58] <jamespage> xnox, lol
[09:58] <jamespage> should od
[09:59] <xnox> jamespage: it is tricky though, trying to remove current implementation tries to install another one =)
[09:59] <jamespage> xnox, they co-exists quite happily
[09:59] <jamespage> managed via alternatives...
[10:04] <xnox> jamespage: install default-jdk, then try to remove it. Apt says: ok but i will install 6. remove default and 6? Ok but i will install gcj. Remove default, 6 and gcj? Sorry can't do anything.
[10:05] <xnox> jamespage: so you need to delete stuff like java-common & apps in a single go, for it to go away.
[10:29] <heno> doko, Hi, I've filed a freeze exception request -- https://bugs.launchpad.net/ubuntu/+bug/1053933
[10:32] <doko> heno, xnox already replied
[10:32] <xnox> doko: ;-)
[10:36] <heno> xnox, doko, ok thanks I'll pick it up on the bug :)
[11:28] <lamont> ctl-alt-t not working with as of sometime recently (on quantal) - is that expected?
[11:30] <didrocks> lamont: yeah, it's a keybinding conflict, bug #1050796
[11:34] <lamont> didrocks: but is there a trivial workaround? (what file to I smash?)
[11:34] <didrocks> lamont: you can go to gnome-control-center -> keybindings -> launcher
[11:34] <didrocks> you will see 2 "Launch a terminal"
[11:34] <didrocks> one has to be set, not the other
[11:34] <didrocks> (you have to try, they are both named the same)
[11:34] <lamont> does it matter which?
[11:35] <didrocks> lamont: yeah, only one is wired
[11:36] <lamont> much better
[12:13] <ahasenack> hi, can someone please sponsor this bug? It's critical for us: bug #1053057
[12:15] <SpamapS> ahasenack: I uploaded it to quantal-proposed yesterday... awaiting beta-freeze acceptance (or post-beta-thaw)
[12:15] <ahasenack> SpamapS: thanks, who can I talk to about that?
[12:15] <SpamapS> ahasenack: #ubuntu-release
[12:15] <ahasenack> SpamapS: thanks
[12:19] <cjwatson> pitti: What's up with the ARM test failures on https://launchpad.net/ubuntu/+source/glib2.0/2.33.14-1svn2 ?
[12:28] <ahasenack> hi, can someone please nominate bug #1053057 for lucid, natty, oneiric and precise? I have debdiffs ready and will change the bug description to comply with sru rules
[12:29] <SpamapS> ahasenack: on it
[12:47] <lucazade> hi all! Is bug #1053269 going to be solved or at least any idea why it happens?
[12:48] <cjwatson> lucazade: It might be related to a framebuffer handling bug that smb and I were talking about yesterday
[12:49] <cjwatson> lucazade: I have an nvidia box I can dig out, so I'll take a look as soon as I can dig myself out from under everything else ...
[12:49] <lucazade> cjwatson: is it a regression?
[12:49] <cjwatson> Well, you said it was a regression in the bug description
[12:49] <doko> tkamppeter, foomatic-db demoted
[12:49] <cjwatson> So who am I to argue
[12:49] <lucazade> cjwatson: if you need any test i'm here
[12:49] <cjwatson> What it's a regression *in* is a different question
[12:50] <lucazade> i've an optimus dell desktop to test it out
[12:50] <doko> apw, ping on https://launchpad.net/bugs/1048824
[12:51] <apw> doko, will look at it, thanks
[12:51] <smb> cjwatson, lucazade If there is a second machine to ssh into the one with the black screen, then dmesg from that machine with the black screen would be helpful to find out whether framebuffers are replaced
[12:52] <lucazade> smb: ok ... good idea.. i'll try to catch dmesg
[12:55] <doko> bryceh, nivida-common shows up on the demotion list. is this wanted?
[12:55] <lucazade> smb, cjwatson ... pasted my dmesg ... http://pastebin.com/VdDtBQqs  (ubuntu pastebin is broken atm)
[13:00] <cjwatson> doko,bryceh: 'apt-cache show nvidia-common' says it's a transitional package
[13:01] <doko> cjwatson, so I assume it's safe to demote
[13:01] <cjwatson> should be
[13:02] <cjwatson> lucazade: huh, you have the nvidia module loaded apparently (or did you file that bug from a different machine?), but that dmesg shows inteldrmfb
[13:02] <cjwatson> but I have to go out for a bit ...
[13:02] <smb> lucazade, I don't see a framebuffer switch from one kernel driver to the other (like I talked to cjwatson yesterday).
[13:02] <smb> cjwatson, Might be a dual gfx machine
[13:02] <cjwatson> smb: Yeah.  Any way you can think of to distinguish which of us owns this bug?
[13:03] <lucazade> smb it is an optimus machine: intel + nvidia
[13:04] <xnox> doko: if you demote to universe, how would main-only lts->lts upgrade happen? just fine?
[13:04] <smb> cjwatson, I may be tempted to go for option 3 and ask someone else...
[13:04] <xnox> doko: or is that not the package that people install to have nvidia?
[13:04] <cjwatson> xnox: this is hardly the only problem in that category - in any case LTS->LTS upgrades generally have universe enabled
[13:05] <cjwatson> So I wouldn't expect that to be a problem
[13:05] <xnox> cjwatson: ok. thanks.
[13:05] <cjwatson> It used to be a problem for cdromupgrade, but we've basically desupported that
[13:05] <xnox> =)
[13:07] <smb> cjwatson, The problem might be somewhere in the middle. I don't see failures to obtain resources like in the one I was looking at. Might just be a fail in switching gfx
[13:09] <smb> lucazade, Any way, you should upload the dmsg file to the bug report as it is likely to get lost otherwise
[13:15] <lucazade> smb: going to upload the dmesg to the bug report
[13:18] <smb> cjwatson, lucazade The only other thing I noticed (but cannot really decide about its influence) is that from the dummy 80x24 console the system goes to inteldrmfb and later enables the discrete nvidia gfx...
[13:19] <lucazade> smb, cjwatson.. if I disable the vt.handoff=7 feature at least I can see the VT.. is it possible that new grub rev is not patched against it?
[13:21] <lucazade> smb, cjwatson .. I can try to blacklist nvidia module to see if it is related to this
[13:24] <smb> lucazade, I guess it cannot hurt to gather that as an additional testing case... Not having really much experience with those dual gfx machines...
[13:34] <tkamppeter> doko, pitti, hi
[13:36] <cjwatson> lucazade: I was pretty careful to keep all those patches
[13:36] <cjwatson> lucazade: in fact most of them are upstream.  Perhaps you could attach your /boot/grub/grub.cfg as well though
[13:50] <lucazade> cjwatson http://pastebin.com/XstaeXXA
[13:51] <lucazade> cjwatson: going to blacklist nvidia module... rebooting
[13:55] <doko> tkamppeter, foomatic-db-compressed-ppds still recommends printer-driver-all
[13:57] <lucazade> cjwatson: dmesg blacklisting nvidia_current http://pastebin.com/ZVSqxYk8  (same behaviour)
[13:58] <cjwatson> lucazade: as far as I can see, all the necessary GRUB configuration is still in place
[13:59] <cjwatson> lucazade: It's possible that something is wrong with video setup internally in GRUB, but at this point I would be rather inclined to suspect the kernel instead
[14:00] <cjwatson> lucazade: You might try downgrading to a kernel version that previously worked to test this theory, or downgrading to GRUB 1.99; either ought to narrow it down
[14:04] <lucazade> cjwatson... going to try an old kernel
[14:11] <lucazade> cjwatson: reverted to -21 kernel (-22 is the new one) and it fixes the issue
[14:11] <lucazade> cjwatson: so it is the kernel!
[14:13] <lucazade> updated the bug report https://bugs.launchpad.net/linux/+bug/1053269  .. hope it is the correct project
[14:20] <micahg> could someone more familiar with objective-c binary dependencies take a look at bug 1051389?
[14:20] <cjwatson> lucazade: great, thanks
[14:20] <doko> bryceh, tjaalton: libdri2 is scheduled for demotion. is this intended?
[14:23] <tjaalton> doko: looks to be some linaro thing
[14:23] <tjaalton> rsalveti: ^
[14:26] <lucazade> cjwatson: will the bug be assigned to anyone or I should ping Tim Gardner?
[14:27] <cjwatson> lucazade: smb already knows about it, so let that team worry about their own assignment processes
[14:27] <lucazade> cjwatson: perfect.. tnx for the support!
[14:27] <smb> cjwatson, Thanks so much. :)
[14:27] <cjwatson> Oh, the bug is actually in the wrong place
[14:27] <cjwatson> Let me fix that
[14:27] <cjwatson> smb: can you delete the bogus linux upstream task from that bug?
[14:28] <cjwatson> lucazade: you should always use packages in Ubuntu, not (upstream) projects, unless you know that the bug is reproducible with upstream code
[14:28] <lucazade> cjwatson: ok... good to know
[14:28] <smb> cjwatson, hm.. not sure
[14:28] <tkamppeter> doko, I can demote the Recommends to a Suggests, but we need something which fits both Ubuntu and Debian.
[14:28] <cjwatson> smb: do you have the minus sign in a red circle next to the upstream task?
[14:28] <smb> cjwatson, Ah yea
[14:29] <smb> cjwatson, gone
[14:29] <cjwatson> ta
[14:29] <doko> tkamppeter, well, is the recommendation correct for Ubuntu? but then we have to promote some packages
[14:29] <tkamppeter> doko, no, Debian folks have added that.
[14:30] <cjwatson> you can generate recommends/suggests dynamically using substvars
[14:30] <doko> that would be an idea
[14:37] <doko> cjwatson, would it be good to have an Inclusion list for the seeds that python3-% is seeded, if python-% already is?
[14:39] <cjwatson> doko: Maybe for R.  Sounds likely to induce some confusion at this point
[14:39] <doko> yeah, not now
[14:39] <cjwatson> doko: I don't think germinate can do the particular logic you mention, though
[14:40] <cjwatson> It can include python3-* if anything else in its source package is in main, but it's quite possible that there are sources in main with python-* in universe
[14:40] <doko> and on second thought, we maybe want to demote the python2-% packages, so better seed these explicitly
[14:42] <rsalveti> tjaalton: doko: hm, this library is needed for the PowerVR SGX driver
[14:42] <rsalveti> for omap4
[14:42] <doko> rsalveti, then some reference was lost this cycle
[14:43] <rsalveti> the only package depending on it is the pvr-omap4 one, which is in restricted
[14:43] <rsalveti> don't know if that is what caused this
[14:45] <ahasenack> hi, can someone please sponsor and upload these sru packages to -proposed? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057
[14:53] <doko> cjwatson, is the libdri2 demotion a bug? still has references in the b-d's and the armhf binaries in restricted
[14:54] <ogra_> uh, definitely a bug
[14:54] <ogra_> the omap GLES driver that is in teh images needs it
[14:55] <doko> I mean, a bug in germintate
[14:56] <ogra_> well, dunno where a bug is here, just saying that demoting it is definitely worng :)
[14:58] <cjwatson> doko: one moment
[14:59] <didrocks> ogra_: waow, libreoffice on armhf?
[14:59] <ogra_> didrocks, used to always have it in the past
[14:59] <cjwatson> ogra_: what's the exact package name of that driver?
[15:00] <ogra_> cjwatson, pvr-omap4
[15:00] <didrocks> ogra_: oh, I didn't know, thought it was too slow fo the armhf image
[15:00] <ogra_> didrocks, why would it ?
[15:00] <ogra_> its not to slow for an atom
[15:00] <ogra_> cortext-a9 is faster than most low end atoms :)
[15:01] <ogra_> *cortex
[15:02] <didrocks> ogra_: ah, you were talking about armel at the time
[15:02] <didrocks> (just looked at the logs)
[15:02]  * cjwatson looks very confused
[15:02] <cjwatson> pvr-omap4 isn't in germinate output, but it isn't listed for demotion either
[15:03] <ogra_> cjwatson, at pvr-omap4 or at the conversation above ?
[15:03] <ogra_> :)
[15:03] <ogra_> intresting, it should be restricted
[15:03] <didrocks> ogra_: http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-release.html#t15:58 ;)
[15:03] <ogra_> could it be that it was promoted without seed update ?
[15:03] <doko> cjwatson, it is listed for demotion on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[15:04] <doko> ahh, you mean the driver
[15:04] <cjwatson> doko: pvr-omap4 isn't
[15:04] <cjwatson> ogra_: But then it should be listed for demotion
[15:04] <ogra_> didrocks, pfft, thats sooo 2011
[15:04] <cjwatson> It shouldn't be in this neither state
[15:04] <didrocks> ogra_: I so stick to the past, you know :)
[15:04] <ogra_> didrocks, we used to ship LibO before zoho ...
[15:04] <cjwatson> So I'd like to debug that before we do anything to the seeds
[15:04] <doko> ok
[15:05] <ogra_> didrocks, it was just that the slow builds on arm were always delaying the images
[15:05] <didrocks> ogra_: ok, was thinking it was a runtime issue, my bad :)
[15:05] <cjwatson> It does indeed seem that there was never an MIR for pvr-omap4
[15:05] <ogra_> didrocks, but that was pre-panda-buildd times ... wheer the buildds were only 10% as fast :)
[15:05] <cjwatson> Unless it was split out from something else
[15:05] <didrocks> heh
[15:06] <ogra_> cjwatson, no, it wasnt
[15:06] <cjwatson> But it's been there since precise now, so there's an argument that we should just grandfather it in now ...
[15:07] <ogra_> bug 1042151
[15:07] <ogra_> there was a mir for libdri2
[15:09] <ogra_> bug 959924 is the only papertrail i find for pvr-omap4
[15:09] <ogra_> but that has no MIR attached or anything
[15:13] <cjwatson> oh
[15:13] <cjwatson> wait, what
[15:13] <cjwatson>         if archive_source[pkg][1] == "restricted":
[15:13] <cjwatson>             continue
[15:17] <cjwatson> oh, great, it predates revision control of that file
[15:18] <cjwatson> elmo: do you remember why component-mismatches (née anastacia) ignores anything currently in restricted?
[15:19] <elmo> *blink*
[15:19] <elmo> cjwatson: no, sorry, I can't thin of any good reason to do that
[15:19] <cjwatson> It might not be from when you maintained it - I just unfortunately can't tell
[15:19] <elmo> think
[15:20] <cjwatson> There was a non-trivial period between you running the archive and all that stuff going into bzr
[15:21] <cjwatson> elmo: Unless ... there isn't revision control somewhere for Ubuntu's dak instance, is there?
[15:22] <cjwatson> The only reason I can think of is that really it ought to know to say "to multiverse" etc. for stuff in restricted
[15:22] <cjwatson> And vice versa
[15:24] <elmo> cjwatson: sorry, I don't think so, I don't seem to have the bzr trees from the jackass era dak
[15:24] <cjwatson> OK, never mind - thanks
[15:24] <elmo> at least not locally, it may be in the DC *somewhere*
[15:25] <cjwatson> Probably not worth it if it's not readily to hand
[15:25] <cjwatson> (What naming scheme was jackass from, anyway?)
[15:26] <cjwatson> Oh, penguins, duh
[15:26] <elmo> so, it apparently dates back to a copy of anastacia from 2005
[15:27] <elmo> which is so old it's in subversion
[15:27] <cjwatson> It's possible that at one point nothing in restricted was seeded
[15:29] <cjwatson> germinate's default set of components didn't include restricted until germinate 0.8 in February 2006
[15:29] <cjwatson> So that would sort of make sense
[15:40] <thebishop> hello hello
[15:41] <thebishop> has any work been done (or would anyone be interested in) adding Gamepad support to Unity?
[15:54] <xnox> thebishop: design is at #ubuntu-design, unless you are talking about writting a search lense to dash, than it's #ubuntu-app-devel i believe.
[16:28] <infinity> bryceh: Around?
[16:30] <infinity> bryceh: I'm going to remove the out-of-date intel-gpu-tools binaries on !x86, which is going to render xdiagnose uninstallable.  Care to move the intel-gpu-tools hard dep for xdiagnose to a recommends?  (I assume its use is guarded in some way, since not every computer has an intel GPU, but if it's not, that should be fixed too) :P
[16:31] <hallyn> rsalveti: hey, in qemu-linaro hav eyou seen https://launchpadlibrarian.net/116773384/buildlog_ubuntu-quantal-powerpc.qemu-kvm_1.2.0%2Bnoroms-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[16:32] <rsalveti> hallyn: not yet, just finished my local package to be able to push, so just missing the test for powerpc
[16:32] <hallyn> oh maybe i do that to myself
[16:33] <rsalveti> infinity: btw, package not seeded, but we're in freeze, should I just push it or would it be better to wait beta 2?
[16:33] <rsalveti> qemu-linaro I mean
[16:34] <infinity> rsalveti: My approval was based on the assumption that you'd both be uploading, so please do.
[16:34] <infinity> rsalveti: Though, it would be nice if it also builds...
[16:34]  * infinity glances at hallyn.
[16:34] <plars> didrocks: around still?
[16:34] <rsalveti> infinity: great, yeah, need to sort this build for powerpc
[16:34] <rsalveti> might be the same issue
[16:34] <didrocks> plars: was about to leave, what's up?
[16:34] <hallyn> infinity: builds everywhere ican test :)  non-upload would have caused spurious errors in all sorts of testers, so still think it was worth it
[16:35] <plars> didrocks: I filed bug #1054034 from a test I had running, but then noticed right after there was a compiz update
[16:35] <plars> anything in the update you think could have fixed it?
[16:35] <didrocks> plars: right, as I told you the other day, the new unity stack partially fixed it
[16:36] <didrocks> plars: we still have a dconf-writer bug, but most of the issue there is fixed
[16:36] <plars> didrocks: right, but you mentioned some fixes coming.  Just checking to see if this should have been fixed already in those or if it's still expected by you to be broken
[16:37] <didrocks> plars: no, this upload must fix it (but still with some known caveats)
[16:37] <didrocks> plars: the caveats are: some times the migration is reverted to the default
[16:38] <plars> didrocks: I don't think I'm getting the defaults... in fact I'm now getting two entries for launch a terminal
[16:38] <plars> didrocks: ok, I'll retest with the one that came in this morning
[16:39] <didrocks> plars: this is separate
[16:39] <didrocks> plars: launch a terminal is an opened bug
[16:39] <didrocks> plars: bug #1050796 FYI
[16:39] <didrocks> plars: needing a compiz fix, I set it to the release team tracking so that PS is looking at it (not trivial to change the binding)
[16:40] <plars> didrocks: but also launch hud is getting set to disabled
[16:40] <plars> which I don't think is the default
[16:40] <didrocks> plars: ah, this is part of the issue that are fixed with the newer version
[16:40] <plars> didrocks: right, so I'll check that. thanks!
[16:40] <didrocks> yw :)
[16:41] <hallyn> hm, interesting.  so this is fallout from the last merge with debian.
[16:41] <infinity> hallyn: Merging from experimental git, or from sid?
[16:42] <hallyn> infinity: from sid, early during quantal
[16:42] <hallyn> i need to find a power box to play on
[16:45] <Laney> davis.c.c
[16:46] <Laney> seems borked :(
[17:25] <cjwatson> doko: I'm still working on this component-mismatches bug, but it's rather involved.  I may not finish today.
[17:31] <jtaylor> there are a bunch of uninstallable php packages
[17:32] <jtaylor> is there an unfinished transition going on?
[17:45] <jtaylor> SpamapS: why are -imap and -interbase dropped form php5?
[17:46] <jtaylor> the argument in the changelog does not really apply as the universe ones are uninstallable and fail to build
[17:49] <bryceh> infinity, will do.  Do we need a new intel-gpu-tools in quantal?
[17:51] <infinity> bryceh: No, the one in quantal is correct (only builds on x86, as it should).
[17:51] <infinity> bryceh: It's xdiagnose that's wrong, by depending on it. :P
[17:52] <bryceh> ahh
[17:52] <micahg> infinity: maybe arch specific depends?
[17:52] <micahg> if it's really that important
[17:52] <micahg> although that doesn't make too much sense now that I think about it :)
[17:52] <infinity> Also a possibility.  But it still feels wrong to force it to be there on all systems, even if they don't have the GPU.
[17:55] <bryceh> I  think recommends should be fine.  Did a quick review of the code and looks like nothing will break if it's not present
[17:56] <infinity> bryceh: That would be lovely, if you just fix up the one that's currently in the queue and re-upload for me.
[17:57] <bryceh> infinity, uploaded as 3.2
[17:58] <infinity> bryceh: Cool, thanks.
[18:05] <SpamapS> jtaylor: for imap, because c-client is unsupported upstream
[18:05] <SpamapS> jtaylor: the changelog has lost information actually
[18:05] <SpamapS> jtaylor: I am fairly certain that it was a conscious decision to avoid having it in main
[18:06] <jtaylor> so what do we do with the broken ones in universe now?
[18:06] <SpamapS> jtaylor: I believe I already commented on the bug that I'd sponsor any work to get php5-imap updated
[18:07] <jtaylor> so if there is no patch remove?
[18:07] <fginther> Can someone please help with sponsoring a patch? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
[18:07] <fginther> I also have a debdiff attached to the bug: https://bugs.launchpad.net/ubuntu/+source/evemu/+bug/1051044
[18:08] <SpamapS> jtaylor: indeed. Perhaps removing it would help push a few people to migrate away from it ;)
[18:08] <jtaylor> is it there an alternative?
[18:08] <jtaylor> imap seems kind of important
[18:08] <infinity> What's "broken" with php5-imap?
[18:08] <jtaylor> fails to build. uninstallable
[18:08] <infinity> It was always a no-brainer to just update it and keep it lockstep with php5...
[18:09] <jtaylor> SpamapS: can you sponsor bug 1054249 please
[18:11] <infinity> Yeah, imap and interbase both should be simple to update, it's just that no one has done so in ages. :/
[18:11] <jtaylor> infinity: how is the procedure for that? extract it from php5 source?
[18:11] <jtaylor> no documentation in the package
[18:11] <infinity> jtaylor: Yeah.  I haven't done it for years (I was the one who originally split the sources), but it should be fairly evident from looking at the orig for each.
[18:11] <infinity> You can blame me for the lack of docs, I suspect.
[18:12] <jtaylor> I looked through php5 git, there is stuff in the imag orig that never appears in php5 git
[18:12] <jtaylor> specifically the part that now fails
[18:13] <infinity> Which is?
[18:13] <jtaylor> some stuff in a HAVE_IMAP2005 define
[18:13] <infinity> Other than that one patch we're apparently carrying, it should literally just be a cp -a of ext/imap.  If it's not, someone messed up.
[18:14] <SpamapS> infinity: I can't find the justification for them both not being in main actually.. was that an accident?
[18:14] <infinity> jtaylor: Yeah, that's a local patch.
[18:14] <infinity> debian/patches/kolab.patch
[18:14] <bryceh> infinity, try #2...
[18:14] <infinity> SpamapS: No, it was intentional, to keep the libs out of main.
[18:14] <jtaylor> oh
[18:14] <infinity> SpamapS: php-imap was also my example package long ago to show people how to do out-of-tree module builds.
[18:14] <SpamapS> infinity: but it wasn't documented anywhere I can find
[18:14] <jtaylor> do we still need thaT?
[18:14] <infinity> SpamapS: The split was documented waaaay back in php4, I suspect.
[18:15] <infinity> SpamapS: It's been like this ever since hoary.
[18:15] <bryceh> infinity, as 3.1 this time
[18:15] <SpamapS> infinity: the split is in the changelogs.. Ubuntu keeping them split is not (they've since been re-united in Debian)
[18:15] <infinity> SpamapS: Right, they were reuinted in Debian because of the lack of main/universe, and because I stopped maintaining it.
[18:16] <infinity> SpamapS: The only reason they were split in Debian was to keep the packages in sync, and so php-imap could be an example.
[18:16] <infinity> SpamapS: But the split in Ubuntu was purely for main/universe reasons.
[18:17] <infinity> Anyhow, the bit that's failing, you can blame zul for...
[18:17] <infinity> And if Debian's not carrying this "kolab" patch, nor is upstream after two years, it might be worth just dropping it.
[18:17] <SpamapS> infinity: I guess what I'm looking for is where we nacked c-client and interbase libs for main...
[18:17] <zul> infinity: that was before my time
[18:18] <SpamapS> heh, I was just looking for the status of said kolab patch
[18:18] <SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456591
[18:18] <infinity> Err, what?
[18:18] <SpamapS> thats in uw-imap
[18:18] <infinity> zul: You're the one who added the patch, how could that be before your time? :P
[18:18] <SpamapS> I believe the patch for upstream php was nacked tho
[18:18] <infinity> SpamapS: There was no MIR process in 2005.
[18:18] <zul> infinity: i thought you were talking about the imap split
[18:19] <infinity> zul: No, the imap split was me. :P
[18:19] <zul> infinity: but yeah i was asked to include that patch
[18:19] <SpamapS> https://bugs.php.net/bug.php?id=43948 .. there's part of it, I think
[18:20] <zul> infinity: iirc ScottK wanted that patch in
[18:20] <jtaylor> ok interbase has no patches I'll just try the cp -a approach for that
[18:20] <jtaylor> mcrypt still builds, but should we update it too?
[18:21] <infinity> jtaylor: If it's actually changed, yeah.
[18:21] <SpamapS> Looks like Kolab did the right thing and ditched the imap extension ;)
[18:21] <infinity> jtaylor: Just do a quick diff of the current source and the packaged one.  No point doing an empty version bump for nothing.
[18:21] <jtaylor> oh course I'm not that far yet
[18:22] <infinity> jtaylor: (Or just blindly update, cause who cares)
[18:22] <infinity> SpamapS: By which, you mean, dropping the kolab patch from php-imap would be a sane way forward?
[18:23] <SpamapS> infinity: indeed
[18:24] <infinity> SpamapS: Cool.  That's a 2-second fix that would be much better than talking about it. :)
[18:24] <infinity> SpamapS: (Though, again, if php-imap has changed upstream, worth revving to the latest too, which makes it a 4-second fix)
[18:25] <SpamapS> yeah we should do that too
[18:27] <infinity> bryceh: Trailing , on your Recommends seems a bit sloppy. ;)
[18:28] <infinity> bryceh: (I'm also not sure how dpkg parses that...)
[18:30] <fginther> infinity, can you take a look as some more utouch related packages, or recommend someone who can?
[18:30] <infinity> fginther: That would be my thing still, yeah.  Toss me a list in /msg and we can chat about them.
[18:30] <jtaylor> mcrypts diff is not really significant
[18:30] <jtaylor> -       {NULL, NULL, NULL}
[18:30] <jtaylor> +       PHP_FE_END
[18:30] <infinity> jtaylor: Well, if it touches the .c at all, I'd assume it's a bugfix. :P
[18:30] <fginther> infinity, thanks
[18:30] <jtaylor> though that might be worth it
[18:31] <infinity> jtaylor: Most of the extensions are pretty insanely old and stable, so generally any change to them is either a bugfix or catching up with Zend's API tweaks.
[18:31] <jtaylor> I'll just do it for that
[18:31] <jtaylor> seems like a change that makes sense even if it is a noop now
[18:33] <infinity> jtaylor: Oh, and <3 for the README.source additions.  That wasn't really a convention back when I did the splits, but totally still my fault for not documenting it.
[18:33] <ScottK> infinity: We added the patch to php to get rid of an embedded code copy being shipped with kolab.
[18:33] <infinity> jtaylor: (I guess it seemed "obvious" to me, which nothing ever really is)
[18:34] <infinity> ScottK: And that's no longer required?
[18:34] <ScottK> I'm not sure why people think that.  I don't know.
[18:34] <ScottK> I would be quite surprised if it weren't though.
[18:36] <infinity> ScottK: Oh, hrm.  Well, the other option is someone fixing the patch. :P
[18:37] <ScottK> what's the issue?
[18:37] <infinity> Dunno.  It's FTBFS, apparently, due to the patch.  I haven't looked at it.
[18:38] <ScottK> Riddell: Could you have one of your Kolab buddies look into this ^^^
[18:51] <r000t_bd> Who would I talk to about an idea I had that, while I didn't think was that great, 8 friends so far have told me to bring up to you guys
[18:52] <r000t_bd> The general idea is when one runs apt-get install/upgrade, it broadcasts the list of packages it needs to the LAN broadcast address, to see if anybody else has what it needs. If so, a computer replies with the package(s) it has, and a high-speed LAN transfer (that also doesn't bug the mirrors) begins
[18:53] <hallyn> i kinda like it
[18:53] <r000t_bd> apt-p2p is SIMILAR, but it doesn't solve the issue my idea solves with massive corporate installs hogging bandwidth whenever an update is released
[18:53] <r000t_bd> not to mention this could be enabled by default without the same concerns as doing the same for apt-p2p
[18:54] <r000t_bd> Bad packages aren't an issue since they're digitally signed anywya
[18:57] <hallyn> r000t_bd: could be a painful DOS though if not disabl-able
[18:57] <hallyn> unlikely, yes
[18:59] <Riddell> ScottK: what's that?
[19:01] <infinity> r000t_bd: To be far, massive corporate installs should either run local mirrors or local proxies.
[19:01] <infinity> s/far/fair/
[19:01] <infinity> But it's still a cute idea, if it could be implemented securely and sanely.
[19:02] <sarnold> r000t_bd: yeah, I kinda like that. but sooner or later _some_ system is going to have to ping the servers to see if updates are available..
[19:04] <r000t_bd> sarnold, well yeah, initial updates have to come from the mirrors
[19:05] <r000t_bd> which is why an updated package could be announced, "Hey, I have a newer version of BIND9, this version is x.x.x.x, who needs it?"
[19:06] <r000t_bd> The issue with local mirrors or apt-cachers is, off the top of the head, roaming clients (a friend of mine has a company provided laptop that he docks at work and then takes with him) that wouldn't be able to get new/updated packages when not at work
[19:06] <r000t_bd> and for MASSIVE installs, that server would get slammed
[19:06] <sarnold> r000t_bd: announce is odd; it'd be too easy for a temporarily down host to miss the announcement. Polling from clients tends to be more reliable.
[19:07] <r000t_bd> And it's not just about corporate users, consider maybe the house that has 9 computers but only a DSL connection
[19:07] <r000t_bd> And I don't think there would be a way to NOT have to ask the mirrors for a package list
[19:07] <r000t_bd> if the list comes from peers it can get very out of date
[19:08] <infinity> r000t_bd: Most corporate sysadmins I know loathe excessive broadcast traffic and often even actively prevent it.
[19:08] <sarnold> I did a caching web proxy once to try to address that problem for my multiple systems -- completely forgetting that between an x86_64 and an x86 system there was very little package overlap, surely not worth the hassle.
[19:09] <infinity> r000t_bd: As for the local mirror/cache issue, I see that as a misconfiguration.  A corporate setup that transparently proxies for archive.ubuntu.com isn't tough, for instance.
[19:09] <infinity> r000t_bd: There's no reason roaming needs to be hard for users.
[19:09] <r000t_bd> Now have any of you guys heard of apt-p2p?
[19:09] <infinity> r000t_bd: And there's also no real reason this needs to be apt's problem.
[19:11] <sarnold> infinity: though its hard to see firefox _really_ benefitting from this to the same extent :)
[19:11] <brendand> bryceh, did you ever think about putting lpltk in pypi?
[19:11] <infinity> sarnold: Hrm?  I'm not sure how firefox relates...
[19:12] <sarnold> infinity: ah. i thought you were going in the direction of generic http caching for all clients
[19:12] <infinity> sarnold: Or are you just referring to the part where all port 80 traffic would now route through a transparent proxy (even if it's usually a no-op)?
[19:12] <infinity> sarnold: Which again, to be fair, is a pretty common corporate setup. :P
[19:13] <infinity> Of course, we also don't use dnssec, so one could just spoof the DNS for archive.ubuntu.com to point at an internal machine.
[19:13] <sarnold> infinity: I'm guilty of inflicting that on users myself, when a 64K frame-relay link was the best affordable option....
[19:13] <infinity> And other awful fun things.
[19:14] <infinity> Because, again, a "large corporate environment" (or even a smallish one) that doesn't control its own DNS resolution is pretty rare.
[19:14] <r000t_bd> infinity, what about people who've used "select best server" in Software Sources and thus directly connect to a different mirror?
[19:15] <infinity> r000t_bd: People who don't use the corporate-prescribed setup (and are given root) tend to fall out of the realm of "stuff sysadmins should muck with" anyway, and you also can't guarantee they'd use your fancy p2p setup.
[19:15] <infinity> r000t_bd: If you trust them enough to be root on their own machines, you trust them to break things differently from how you wanted them to use them.
[19:16] <infinity> (You can also spoof for *.archive.ubuntu.com, it's not rocket surgery)
[19:16] <jtaylor> Riddell: php-imap fails to build in quantal partly due to an old kolab patch
[19:16] <arosales> iamfuzz: Hello, as we near beta2 for 12.10 I wanted to get your thoughts on https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-eucalyptus
[19:17] <infinity> r000t_bd: Anyhow, I'm not trying to discourage you from writing something cool, I'm saying that I doubt you'll get others interested in writing it for you, as I see any number of solutions to the "large install base updating" problem that are much more pleasant than broadcast storms and a fragile/untested new apt method.
[19:18] <infinity> r000t_bd: If you want to do it yourself as a fun project, go to town, cause, well, people working on fun new code are always welcome, whether it pans out or not.  Most of my "best" learning experiences were things no one but me used. :P
[19:20] <r000t_bd> mkay
[19:21] <r000t_bd> (reverting to smalltalk) Has anybody considered what happens when we hit release 17.04 and reach the end of the alphabet?
[19:21] <Laney> cyrillic
[19:22] <r000t_bd> AA, AB, AC, is an option... start with Aardvark
[19:23] <infinity> If you can find an animal that starts with BB, I'll be impressed.
[19:23] <r000t_bd> That's why you use AB instead of BB :p
[19:24] <micahg> well, we fixed the only place in the distro where it makes a difference (backports), so we can just start with A again
[19:25] <infinity> micahg: No, no, we need to start with W, H, and B again.
[19:25] <infinity> And that probably ends that discussion. :P
[19:30] <r000t_bd> What if we stop using animals?
[19:30] <r000t_bd> Starting with 17.04, using minerals instead
[19:31] <bryceh> brendand, pypi?  no I hadn't.  It's in the ppa now btw
[19:32] <bryceh> infinity, aiui dpkg parses it ok, but I can upload without that if you'd like
[19:33] <infinity> bryceh: Please do, it offends my sensibilities. ;)
[19:36] <bryceh> infinity, there you go.
[19:36] <infinity> bryceh: Many thanks.
[19:59] <iamfuzz> arosales, hey there
[19:59] <iamfuzz> arosales, we're just going to remain in the Partner repo for Quantal
[20:00] <iamfuzz> arosales, we're in Sid now so should be in future releases by default
[20:03] <infinity> H/win 197
[20:06] <Laney> that's a lorra windows
[20:07] <infinity> Laney: IRC is serious business.
[20:08] <stgraber> I usually try to restart irssi when I reach 100 as it's sometimes good to make sure all the channels are in auto-join and the config isn't completely broken ;)
[20:08] <stgraber> it so far it seems to nicely match our kernel release cycle
[20:09] <Laney> I garbage collect quite aggressively, as I have a big ol' window list at the bottom of my irssi
[20:10] <Laney> 197 would leave me with about 3 lines for conversation :P
[20:12] <stgraber> I'm always suprised how easily I can keep a full window-number => channel name mapping in my head :)
[20:12] <infinity> Laney: I do activity lists numerically at the bottom, and hilight lists in the title bar, but the activity list filters join/part cruft and such, so it's not unwieldly.
[20:12] <r000t_bd> (they use irssi and not a GUI client combined with a znc)
[20:13] <infinity> stgraber: And yeah, that creeps me out that I tend to know who/what a number is when it hilights.
[20:13] <Laney> I get to do that with letters instead, thanks to the window list
[20:13] <Laney> w = ubuntu-devel, 0 = ubuntu-release
[20:17] <arosales> iamfuzz: good to hear about being in sid. Regarding the 2 work items in servercloud-q-eucalyptus were those complete, valid todo, or need postponing?
[20:17] <arosales> iamfuzz: there were mainly around getting feedback
[20:17] <iamfuzz> arosales, the first is complete, second is ongoing
[20:19] <arosales> iamfuzz: ah good to hear, I'll update the blueprint accordingly.
[20:19] <iamfuzz> arosales, many thanks
[20:20] <arosales> iamfuzz: sure, np, and thanks for the update.
[20:35] <Riddell> jtaylor: where is this?  php-imap package that hasn't been updated since oneiric?
[20:35] <jtaylor> thats the problem
[20:36] <jtaylor> we need to update it, but the patch needs fixing or dropping
[20:48] <ScottK> Riddell: php5 ftbfs due to the patch we added for kolab, apparenlty.
[21:13] <bdmurray> stgraber: do you know anything about welcome.jpg in the slideshow still being a pangolin?
[21:14] <stgraber> bdmurray: nope, my guess is that we'll get yet another last minute slideshow, I'd actually be surprised if we ever get the slideshow in place by UIF ...
[21:14] <stgraber> bdmurray: might be worth poking Dylan about it
[21:15] <stgraber> I only take care of reviewing the stuff they land in the branch, making sure they have the required paperwork, update the translations and upload
[21:17] <bdmurray> stgraber: okay, thanks
[22:09] <cjwatson> doko: http://paste.ubuntu.com/1219512/
[22:10] <cjwatson> doko: deployed - I suggest you may want to seed a bunch of those rather than move them to multiverse :-)
[22:12] <cjwatson> Some arguably ought to be seeded by pattern to save effort later