[00:06] <cjwatson> doko: no joy with ppa3 either
[00:06] <cjwatson> doko: I think I'll have to build a debug shell tomorrow with some added printf debugging
[00:10] <doko> cjwatson: thanks for checking. although I do like the outcome somewhat ;)
[00:10] <cjwatson> that we don't need a new eglibc?
[00:10] <cjwatson> I'm not too sad about that myself, I must admit
[00:11] <doko> yes
[00:11] <slangasek> Keybuk: ok, sorry - any idea how to fix this properly, then?  Because /without/ that change, after fixing plymouth, pressing 'c' gets you a segfault instead of an fsck cancellation
[00:11] <cjwatson> anyway, hacking printfs into exactly the right place in the shell requires a special state of mind, and this ain't it, so ... night
[00:12] <Keybuk> slangasek: why does it give a segfault?
[00:12] <Keybuk> do you have a bt?
[00:15] <slangasek> Keybuk: actually, sorry, the segfault was the second bit of the patch; the first bit was that plymouth_answer() returns at line 3028 because plymouth-mnt->error never gets set to ERROR_FSCK_IN_PROGRESS
[00:15] <slangasek> plymouth_mnt->error
[00:16] <slangasek> er, no - was the other way around
[00:16] <slangasek> segfault first
[00:16] <slangasek> because plymouth_mnt wasn't set
[00:16] <slangasek> line 3093
[00:19] <Keybuk> whuh?
[00:19]  * Keybuk wonders whether slangasek has a sort "in order" button
[00:20] <Keybuk> so
[00:20] <Keybuk> plymouth_mnt is initialised to NULL
[00:21] <slangasek> without the change from > to >=, plymouth_mnt never gets set to anything in the case that plymouth_error == ERROR_FSCK_IN_PROGRESS, because there's no value greater than that in the enum
[00:21] <Keybuk> so I don't see how it can ever be "not set"
[00:21] <slangasek> "not set" -> "not set to a value that it's useful to try to dereference"
[00:22] <Keybuk> but it doesn't need to be set to any value
[00:22] <Keybuk> S kills all running fsck
[00:22] <Keybuk> err C I mean
[00:22] <slangasek> not with the existing code, it doesn't
[00:22] <Keybuk> that's why the 'C' case never uses mnt
[00:22] <Keybuk> prove it to me with a bt ;)
[00:23] <Keybuk> oh, cock
[00:23] <Keybuk> no, I see what you mean ;-)
[00:23] <Keybuk> right at the top of the case
[00:23] <Keybuk> that's just a bug in its own right
[00:23] <Keybuk> I was adding those, and clearly didn't put my brain on
[00:23] <slangasek> should that point at plymouth_error, then?
[00:23] <Keybuk> yes!
[00:24] <slangasek> ok - you changing, or shall I?
[00:24] <Keybuk> I'll change that, since I have emacs open right now
[00:24] <slangasek> ok
[00:24] <Keybuk> I clearly made it != not ==, but didn't think all the way through
[00:24]  * Keybuk cleans up the rest of that code
[00:28] <Keybuk> ok, pushed as -r 325
[00:28] <Keybuk> what was the first bit of that patch for?
[00:31] <slangasek> Keybuk: the first bit was knock-on from the second bit
[00:31] <Keybuk> ah right
[00:32] <Keybuk> yeah I can see how you got there
[00:32] <slangasek> so if we're checking plymouth_error now, it should work
[00:32] <Keybuk> but since we always run fsck, but fsck doesn't always check, I was trying not to do your exact patch ;-)
[00:32] <Keybuk> the reason mnt isn't set is on the assumption that we "don't know" which message is being displayed
[00:32] <Keybuk> clearly
[00:32] <Keybuk> 1) plymouth needs to support these kinds of "press X for" messages/prompts
[00:33] <Keybuk> 2) plymouth then needs to deal with receiving multiple of them and showing one at a time
[00:33] <Keybuk> 3) mountall then gets simpler again
[00:33] <slangasek> so, cool; that means you've fixed a regression I'd noticed but didn't realize was my fault ('press C' showing up when no checks were needed)
[00:33] <slangasek> sorry about that
[00:34] <Keybuk> hey, that's ok ;)
[00:35] <Keybuk> I'm still trying to figure out why /tmp has to be nodev ;)
[00:36] <slangasek> well, without that, the code for handling placeholder entries never triggers
[00:36] <slangasek> is never reached, should say
[00:36] <Keybuk> hahah
[00:36] <Keybuk> I just found the code
[00:36] <Keybuk> I'm such a lazy git
[00:36] <Keybuk> I could have just done mnt->placeholder = TRUE or something
[00:36] <Keybuk> but no
[00:36] <Keybuk> I had to abuse nodev combined with strcmp (type, "none")
[00:38] <Keybuk> I can see why I did it like that - it means anything in fstab with /tmp overrides the lot
[00:38] <Keybuk> oh well
[00:38] <Keybuk> that patch is clearly right :p
[00:39] <Keybuk> btw
[00:39] <Keybuk> how did we miss http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/326 ?
[00:59] <slangasek> Keybuk: oh, geez; well I missed it because I wrongly assumed we already fixed that
[00:59] <Keybuk> slangasek: so did I
[00:59] <slangasek> I guess we only fixed it in upstart
[01:00] <Keybuk> I'm sure I fixed it in mountall
[01:00] <Keybuk> I bet this is case of I fixed it, and then forgot to push
[01:00] <Keybuk> or it got overwritten by the importer
[01:00] <Keybuk> so the fix was lost
[01:00] <Keybuk> so I'm pretty sure that's the LVM bug ;-)
[01:00] <slangasek> yeah, so am I
[01:01] <slangasek> well, before when we were fixing this we were focusing on upstart-udev-bridge (upstart 0.6.5-2), so I was just assuming it was fixed by false analogy - never saw the code to do it :)
[01:09] <persia> kees: Is it a bug that rng-tools' init script doesn't seem to start for me on boot?  Is this just me?
[01:10] <kees> persia: if you're using it with TPM, it's a bug -- trousers needs to start first, but doesn't.
[01:12] <persia> kees: Does it have a bugnumber, or shall I add description to the lamentably short bug #544545?
[01:12] <persia> (this being a different issue than bug #519427, which also makes it not start under those conditions)
[01:13] <kees> persia: there's no bug number yet, no.
[01:13]  * persia repurposes 544545 to track this
[01:19] <kees> persia: what do you think the best solution is for this?  either moving trousers one S-level earlier, or rng-tools one S-level later.  probably the latter.
[01:20] <persia> I like moving things later better.
[01:20] <persia> I'm not sure I care enough to fix for lucid though.
[01:20] <kees> I probably should fix it (and the example typo)
[01:21] <persia> close all the bugs in the package all at once?  That would be exciting.
[01:23] <Keybuk> I think we should do that
[01:23] <Keybuk> close all launchpad bugs
[01:23] <Keybuk> delete them
[01:23] <Keybuk> and start over
[01:23] <persia> Is the example typo really I typo?  I thought it was just your blog software being smart.
[01:23] <persia> Keybuk: Why?  I often find bugs that are over a year old and still apply to the development releases.
[01:24] <Keybuk> mostly for fun
[01:24] <Keybuk> but also because the "find" bit is hard
[01:25] <persia> Hm.  True.  When we had < 100K bugs, finding them was lots easier.
[01:26] <kees> persia: no, I mean, like to add an example at all.
[01:26] <persia> Oh, heh.  I've a patch to do that in the bug.
[01:27]  * persia forgets why it wasn't just uploaded back in February, precisely
[01:27] <Caesar> Is it normal practice to have a source package in main, but some of its binary packages in universe?
[01:28] <crimsun> FSVO normal, yes
[01:28] <persia> Caesar: It's not uncommon at all.  source packages must be in main if any binary packages are in main.  binary packages are encouraged not to be in main unless they are required to be in main.
[01:28] <Caesar> ok
[01:35] <persia> Caesar: Do you have a specific package that is confusing or problematic in some way?
[01:45] <Caesar> persia: I was slightly confused by autofs5-ldap
[01:45] <persia> Caesar: Are you less confused now, or do you have more questions?
[01:46] <Caesar> persia: I'm less confused now that you've explained things
[01:46] <persia> Great!
[01:46] <Caesar> I had just assumed that if a source package was in main, *all* of its binary packages should be too
[01:47]  * jdong cries a bit about vdpau... lower CPU usage != longer battery life
[01:47] <jdong> not really surprising though
[01:47] <persia> Caesar: It's an artifact of how "main" is defined.  With luck, it will make more sense once we can abolish components.
[02:14] <jdong> wow, the splashy issue still exists, doesn't it :-/
[02:14] <jdong> bug 328089
[02:14] <jdong> I forgot the reason why we decided we didn't want to yank it from Lucid?
[02:14] <jdong> or make it conflict lsb-base or some other obvious "installing this package won't work" error
[02:15] <ScottK> It's not too late for removals
[02:15] <persia> are we in removals-freeze pending RC?
[02:15] <jdong> ScottK: what's your opinion on the matter? splashy tries to install a file in lsb-base, and it seems like the two parties have reached an impasse for a year
[02:17] <ScottK> jdong: Since it conflicts with a package in ubuntu-minimal, I don't see how it could be suitable.
[02:18] <ScottK> So it wouldn't be installable except in a system that had been somewhat heavily tortured.
[02:18] <jdong> ScottK: really? apt-get -s install splashy happily removes some usplash packages and continues
[02:18] <ScottK> OTOH, I didn't investigate if the conflicts is correct.
[02:18] <jdong> ubuntu-minimal doesn't spark the Essential: Yes warning, does it?
[02:19] <ScottK> Don't think so.
[02:19] <ScottK> persia: No.  Removals are still being processed.
[02:20] <jdong> well, it doesn't seem to yell at me when I try to install it, minus an unpack phase overwrite failure
[02:20] <slangasek> jdong: no, it doesn't - but splashy isn't going to work right with plymouth, and removing that *does* spark the Essential: yes error
[02:20] <ScottK> Although at least in my case the RM has gone to the length of putting my name in the removal rationale so people know who to go hunt down.
[02:20] <jdong> slangasek: ah, good point
[02:20]  * persia only has a few removals pending, for superceded sources
[02:20] <slangasek> ScottK: don't worry, IME people will still come to me first ;)
[02:21] <ScottK> persia: If only I had shell access they'd be done.
[02:21] <persia> They should check +publishinghistory, which should document the bug number, which should answer *all* their questions :(
[02:21] <slangasek> (I get two or three mails a cycle from users begging me to add back a package that I removed as part of process-removals of stuff disappearing from Debian)
[02:21] <persia> Oh, removals require shell access?
[02:21] <ScottK> Yes
[02:21] <jdong> slangasek: seems like two people on/upgrading to lucid have commented on that bug report, though.
[02:21] <jdong> is there any benefit to having splashy in the archive if it's not installable?
[02:22] <ScottK> And will never be installable again ...
[02:22] <jdong> indeed. it's plain incompatible with the new boot system.
[02:22] <ScottK> (I don't expect Plymouth is going anywhere)
[02:22] <persia> Just file the removal bug already :)
[02:23] <ScottK> jdong: You've already expended far too many brain cell s on it already
[02:23] <jdong> lol ok, filing removal
[02:25]  * jdong subscribes ubuntu-archive to bug 568193
[02:27] <ScottK> There's a goodly number of removal requests stacked up there.
[02:28]  * ajmitch can think of a few packages which would be nice to remove
[02:29] <slangasek> jdong: sure, there are two people running lucid saying "splashy error problem exists" - I can't see how this rules out there being a big explosion if they managed to get splashy installed. :)
[02:30] <jdong> slangasek: haha don't get me wrong, I'm equally amused at how people can have "Lucid" setups that boot with splashy installed
[02:30] <slangasek> but they /don't/ have splashy installed
[02:30] <slangasek> because they got the conflicts error message
[02:31] <slangasek> so the undeclared file conflicts is saving them from themselves
[02:31] <jdong> lol it would seem that way.
[02:31] <jdong> but that hardly makes this year-old bug a feature ;-)
[02:35] <persia> I think 568193 is the clear and obvious solution.
[02:35]  * slangasek nods
[02:35] <jdong> ok, and onwards towards more productive uses of our minds!
[02:40] <Keybuk> every time I see his quit message, I want to shout and rant and rave
[02:41] <jdong> haha
[02:41] <Keybuk> because clearly he's never seen a baby try and figure out a nipple for the first time
[02:41] <Keybuk> or known a woman who understands that babies get it wrong and bite
[02:41] <Keybuk> et.c
[02:41] <Keybuk> </downfall moment>
[02:46] <ion> Perhaps the phrase is deeper. “The only intuitive interface is the nipple – and even it’s not intuitive”? :-P
[02:48] <Keybuk> I'd go with
[02:48] <Keybuk> "There's no such thing as intuitive, there's just things that are familiar based on other things you've already learned"
[02:48] <Keybuk> and I bet I'd get a gold star from mpt for that
[02:48] <jdong> everything should have one button but it's up to you to figure out what to.... oh.
[02:49] <jdong> eh I was close.
[02:50] <Keybuk> if there was just one button, with "PUSH" written on it, somebody would pull it
[02:50] <Keybuk> to prove that, go to any public restroom and look at the tap on the sink
[02:51] <jdong> so we just call them security engineers and move on ;-)
[02:51] <stgraber> Keybuk: you'd need a button that works whatever you do (except nothing ;))
 "There's no such thing as intuitive, there's just things that are familiar based on other things you've already learned" --> isn't that the definition of intuition?  :P
[02:55] <Keybuk> no, the definition of intuition is knowing things without having learned them
[02:56] <ion> Visits to public restrooms tend to go better if you refrain from looking. In fact, the more senses you suppress the better. (Perhaps Finns just suck more than the saner part of the planet at this whole public restroom business.)
[02:56] <JanC> you didn't learn those things, you make a guesd based on other things you learned  ;)
[02:56] <JanC> *guess*
[02:58] <JanC> (without knowing you base your guess on that)
[06:12] <Madkinder> Hi. Upon uploading my new package to PPA I get "Unable to find distroseries: unstable" error. I googled for it and everybody suggests to hardcode the series to a particular Ubuntu version.
[06:13] <Madkinder> The problem is that I want to upload this package to both Debian and Ubuntu.
[06:13] <Madkinder> I took irrlicht library as an example as it is maintained by the same person and it is present in both Debian and Ubuntu.
[06:14] <micahg> Madkinder: you can set the series in your dput.cf
[06:14] <Madkinder> the most weird thing is that debian/changelog version of Ubuntu's package contains unstable!
[06:14] <micahg> Madkinder: #ubuntu-packaging is a better place to discuss
[06:15] <micahg> Madkinder: if it's for PPA
[06:15] <Madkinder> micahg: I didn't configure dput at all. I just used the new ppa/ppa-name syntax
[06:17] <Madkinder> ok, if I'm on the wrong place
[06:17] <micahg> Madkinder: I'm in the other channel too
[06:23] <kees> jdong: did you just say I pull "push" doors?  :P
[06:23] <jdong> kees: hahahaha :)
[06:24] <jdong> kees: that buffer was marked char[80] for a reason!
[06:24] <jdong> :)
[06:24] <kees> hehehe  :)
[06:24] <jdong> but hey, I'll admit to making sure push doors don't pull ;-)
[06:53] <Damascene> how to test the xorg thing?
[06:53] <Damascene> I heard there is need for testing
[06:54] <SwedeMike> https://wiki.ubuntu.com/X/Testing/GEMLeak
[07:20] <pitti> Good morning
[07:28] <Damascene> glxinfo is not installed
[07:28] <Damascene> is that normal
[07:28] <Damascene> https://wiki.ubuntu.com/X/Testing/GEMLeak
[07:29] <Damascene> UNE
[07:29] <RAOF> That's not unexpected; I don't think anything depends on glxinfo.
[07:29] <RAOF> (Or, rather, mesa-utils)
[07:31] <Damascene> seems like terminal auto-completion become slower
[07:31] <Damascene> I've extra compiz eanbled
[07:31] <Damascene> enabled
[07:32] <RAOF> I'm pretty sure that'll be placebo.
[07:32] <pitti> auto-completion slowness is usually due to enabled bash-completion
[07:32] <Damascene> what is placebo?
[07:33] <Damascene> this is not the first time I use it
[07:34] <Damascene> sudo aptitude install mesa-u* TAB takes long time
[07:34] <RAOF> The placebo effect is from medicine, where giving people sugar pills while telling them that the pills will help makes the pills help.
[07:38] <Damascene> now the completion is back to normal
[07:38] <virtuald> damascene: that's because there are lots of packages, and now the list is cached
[07:38] <Damascene> I see. thanks
[07:42] <Damascene> by the way is there a way to upload photo to the wiki instead of using out side service
[07:55] <mdke> Damascene: yes, see the "Attachments" link at the top of the page
[08:07] <pitti> slangasek: gnome-keyring> upstream ack'ed the patch and committed it upstream with one refinement; he also confirmed that storing the password was an inadvertent glitch, not a design issue to make the user.keystore work; also, jdstrand pointed out that this is quite an easy root escalation hole for local processes (through sudo); so my confidence has risen a lot about this, and I'd rather like to see
[08:07] <pitti>  it in lucid final; WDYT?
[08:08] <slangasek> pitti: yes, please upload then
[08:08] <pitti> will do (still giving it another round of testing)
[09:14] <Damascene> mdke, thanks I see it now
[09:16] <joaopinto> good morning
[09:17] <Damascene> morning
[09:21] <dholbach> good morning
[09:34] <pitti> slangasek: I have another pkg-create-dbgsym which fixes building debug symbols for X (bug 562418); it's all testcase'd
[09:34] <pitti> slangasek: should I upload this now, so that we have it available for the rush of after-RC uploads, or postpone?
[09:36] <slangasek> pitti: go ahead and upload
[09:36] <pitti> it's version 42, it *must* be good
[09:37] <pitti> uploaded
[09:41] <pitti> slangasek: it's in unapproved now
[09:49] <lool> mvo: Mind pushing latest apt to bzr?  (ubuntu7)
[09:51] <mvo> lool: ups
[09:51] <mvo> lool: done
[09:52] <lool> thanks
[10:05] <chrisccoulson> who rejected libjdic-java from the queue? did micahg ask someone to do that?
[10:15] <pitti> Riddell, ScottK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt> should knm-runtime stop recommending the vpnc bits?
[10:27] <pitti> same question about kigo recommending gnugo
[10:29] <pitti> slangasek: seems http://launchpadlibrarian.net/18628527/mono_1.9.1%2Bdfsg-4ubuntu1_1.9.1%2Bdfsg-4ubuntu2.diff.gz got dropped in some merge in lucid; I'll upload it again to fix the mono-debugger entry in c-m, ok?
[10:30] <slangasek> pitti: yes please
[10:37] <pitti> slangasek: (I'll upload recommends fixes for xfonts-mathml and texlive-extra-utils as well, FTR)
[10:40] <slangasek> pitti: cheers
[11:10] <lool> bryceh: heya
[11:10] <lool> pitti bryceh: I'm worried that I see my Xorg using 60%+ CPU ATM after swithing to the xorg updates packages
[11:12] <ogra> lool, intresting, didnt happen for me
[11:13] <ogra> it bumps up to 12-15% here in max
[11:13] <ogra> and ma gem objects seem to look sane
[11:16] <slangasek> Sarvatt: ^^ seen this issue that lool reports?
[11:16] <lool> So I stupidly tried stracing Xorg
[11:16] <lool> don't do that
[11:17] <lool> I mean don't do that from a xterm in top of the Xorg you're stracing *cough*
[11:17] <slangasek> haha
[11:17] <slangasek> lool: has it fixed the actual leak problem for you?
[11:17] <slangasek> lool: and what wm are you using?
[11:18] <lool> slangasek: I think it did fix the leak
[11:18] <lool> slangasek: I didn't try the test case, I had a workload causing the bug to manifest relatively quickly
[11:18] <slangasek> ok
[11:19] <lool> I'm unison-syncing my mail/, used to be 1 GB and is now about 500 MB and 30 000 files, that would not fit in the kernel caches after running Xorg for a while because GEM was taking kernel memory
[11:19] <ogra> slangasek, for me it definately fixed it
[11:19] <lool> and so suddenly my system would be hitting the disk hard all the time
[11:19] <ogra> i has the gem objects counter running negative after 24h
[11:20] <ogra> now it stays around 350000000
[11:21] <ogra> s/has/had/
[12:06] <pitti> lool: there's also some program called xrestop which might show you which client is actually causing so much X activity?
[12:06] <pitti> (sorry, was away for lunch)
[12:13] <tseliot> mvo: does update-manager disable nvidia on dist-upgrades from karmic to lucid? See LP: #568041
[12:13] <mvo> tseliot: it should not do that
[12:14] <mvo> tseliot: hm, without the upgrade logs its hard to tell
[12:15] <tseliot> mvo: can you ask the user to attach the relevant logs, please?
[12:16] <mvo> tseliot: done
[12:16] <tseliot> mvo: thanks
[12:32] <lool> pitti: Ack; I remember using xrestop to track abusive x resource consumption, but not CPU; I will give it a try if I reproduce
[12:33] <lool> it doesn't render my system unusable, just takes one full CPU, so should be debugable
[12:33] <pitti> lool: right, that's worrysome; you never had that before?
[12:33] <pitti> lool: once you can reproduce it, it might help to kill processes one by one, to see which one is causing it
[12:33] <pitti> usually it's not really X itself, but some particular program which just spams it with requests
[12:37] <lool> pitti: No, I never had that before
[12:37] <lool> pitti: it might be another program indeed; unfortunately, I had to reboot
[12:50] <slangasek> tseliot: hi, have you seen bug #567425?
[12:50] <slangasek> (yet another divert bug)
[13:03] <mdeslaur> thanks for fixing gnome-keyring pitti! :P
[13:16] <c_korn> hm, if I see it corrently some patches in the vlc package make changes to configure.ac but autoreconf is never run. there neither is a autoreconf.patch nor is it run in debian/rules
[13:18] <pitti> mdeslaur: with pleasure :)
[13:19] <seb128> pitti is made of awesome no doubt ;-)
[13:19] <mdeslaur> :)
[13:21] <seb128> does anybody knows about nis and has an idea about bug #553142
[13:21] <seb128> ?
[13:23] <seb128> not sure if that's a gdm issue
[13:35] <slangasek> smoser: ping
[13:38] <smoser> slangasek, here
[13:39] <slangasek> smoser: hi - just checking to see if you were around yet :) I think the RC will be ready to go out within an hour or two
[13:40] <smoser> oh wow. i'll get the amazon pages ready.  the images have been pre-published as rc.
[13:40] <slangasek> yep, saw that, thanks
[13:40] <ttx> slangasek: are you fully operational /without/ smoser ? I heard he might be lost in a small island during release week.
[13:40] <smoser> i think they have network access there.
[13:41] <slangasek> "lost in a small island"? :)
[13:41] <ttx> slangasek: a tax haven, if you see which one I'm referring to.
[13:41] <smoser> volcano permitting i'm going to be sprinting with niemeyer
[13:42] <slangasek> ttx: yes, I have all the info, but it's convenient to have a second set of hands for that stuff since it's highly parallelizable wrt the rest of the publishing
[13:42] <ttx> slangasek: ok, was just belt-and-suspender checking that we are not vulnerable to subaquatic cable cuts
[13:43] <smoser> slangasek, the scripts have never been tested for moving from an rc to a release (the promote-daily), assuming we wanted the 20100420 as GA.
[13:44] <smoser> going from daily to 'release' should be easy, so i will just make sure that daily gets kept around until we know its not fit.
[13:45] <slangasek> smoser: in practice we've never reused an rc as ga without changes; we already know we have a queue of updates that we'll accept, at least some of which will touch UEC/EC2 images
[13:45] <smoser> then its not to worry
[13:45] <apw> pitti, just confirming that your "dell don't suspend" work on the machine i have which is affected
[13:52] <Riddell> pitti: knm-runtime does not recommend vpnc except on sparc where the newest version hasn't compiled
[13:53] <pitti> Riddell: oh, thanks; I thought c-m would only consider i386/amd64 (at least it seems to ignore the ia64 ones)
[13:54] <Riddell> pitti: that's the only reason I can see it would still have that listed anyway
[13:59] <c_korn> any chance the new vlc-1.0.6 makes it into lucid (before the release)? according to the news it has only security and stability fixes: http://www.videolan.org/news.html
[14:43] <mvo> ccheney: hi, I uploaded a new OOo based on my branch (the one I proposed for merging). I uploaded from the apt-get source tarball becuase it appears that bzr is not up-to-date with the archive
[15:14] <slangasek> superm1: do we get a http://mythbuntu.org/10.04/rc page for this round?
[15:15] <superm1> slangasek, yes; i'll ping the guy to get it up there, thanks for the reminder
[15:15] <slangasek> superm1: n/p
[15:23] <slangasek> mterry: hi, is bug #528887 going to make it for release?
[15:24] <mterry> slangasek, ah yes, I was going to look at that today/tomorrow
[15:24] <slangasek> mterry: ok, great
[15:28] <tseliot> slangasek: as regards LP: #567425 , I think something like this would suffice: http://pastebin.ubuntu.com/420452/
[15:29] <slangasek> tseliot: what owns the file that you're rm -f'ing?
[15:30] <slangasek> tseliot: in theory, you should just conflict with that to force it off the system beforehand
[15:31] <tseliot> slangasek: xorg-driver-fglrx from either the repository or from the ati installer
[15:32] <jdstrand> pitti: thanks for all your work on gnome-keyring. I've got a couple machines that are affected that I haaven't fixed yet-- do you need more testing (standard desktop installs, nothing fancy)?
[15:32] <tseliot> slangasek: what I did in the patch is something I've been doing with nvidia for while now to get rid of the diversion ugliness ;)
[15:33] <slangasek> tseliot: but an older version of xorg-driver-fglrx, right?  So Conflicts: xorg-driver-fglrx (<< $version) is possible?
[15:34] <tseliot> slangasek: yes, older versions of that package. But still we can't be sure about which version the ati installer installed
[15:34] <ccheney> mvo: ok
[15:34] <slangasek> tseliot: ah - argh
[15:34] <slangasek> tseliot: ok, do it the ugly way then :/
[15:35]  * ogra_cmpc would suggest to do both
[15:35] <tseliot> slangasek: it's all about ugliness with these things ;)
[15:35] <ogra_cmpc> conflict and check if the file still exists
[15:35] <ogra_cmpc> then rm it if it does
[15:35] <slangasek> tseliot: then in maverick, you can drop the transitional package and conflict unconditionally :-P
[15:35] <tseliot> heh
[15:36] <slangasek> apw: did we overlook something wrt making 'nomodeset' work again?: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539878/comments/15
[15:53] <joaopinto> slangasek, yesterday Keybuck mentioned he migh have found a mountall bug related to that LVM mount issue, do you happen to know anything about it ?
[15:54] <slangasek> joaopinto: yes, mountall didn't have the fix to raise its udev input buffer to a sensible value, so could drop events when they came in too quickly
[15:55] <slangasek> joaopinto: fix is committed to bzr; chances are this fixes all the unreproducible "my device didn't get mounted" issues
[15:55] <joaopinto> there is one persone on #ubuntu+1 reporting an issue, but on his case it's LVM+crypted swap, but it's random, so I am not sure it's the same issue to advise him to try the ppa version
[15:56] <slangasek> I don't know if Keybuk uploaded to ppa
[15:56] <ion> He did
[15:56] <slangasek> then yes, advise to test
[15:57] <joaopinto> ok
[15:58] <pitti> jdstrand: I'm pretty confident on it by now, but of course more testing is always good
[15:59] <pitti> jdstrand: there's a package in ppa:ubuntu-desktop/ppa; it's my original patch, though, not the refined one from upstream
[15:59] <pitti> jdstrand: but if you want to, feel free to grab the source from the queue (dget http://launchpadlibrarian.net/45006207/gnome-keyring_2.92.92.is.2.30.0-0ubuntu3.dsc) and build locally?
[16:00] <pitti> oh, dget wouldn't actually work there, sorry; you need to grab the diff individually
[16:01] <jdstrand> pitti: cool, I'll build from unapproved. again, thanks! :)
[16:14] <lamont> wow.  X performance sucks after the last reboot I did here.  I wonder what got turned on or killed or such
[16:15] <apw> slangasek, nothing that i am aware of
[16:16] <joaopinto> slangasek, mountall ppa didn't fix, but this seems to be different case, I will try to reproduce
[16:17] <slangasek> superm1: still no love on http://mythbuntu.org/10.04/rc
[16:17] <slangasek> joaopinto: ok
[16:18] <superm1> Daviey, could you just copy the beta2 page to rc  and s/beta2/rc/ until tgm can more properly give it love?^
[16:29] <tseliot> lamont: maybe because of this? https://lists.ubuntu.com/archives/ubuntu-devel/2010-April/030673.html
[16:30] <ogra> lamont, use a bucket to catch gem objects
[16:31] <tseliot> :-D
[16:32] <lamont> that would make sense
[16:32] <lamont> grep: /sys/kernel/debug/dri/0/gem_objects: No such file or directory
[16:32] <lamont> except for that
[16:32] <ogra> cat ?
[16:33] <ogra> hmm, no, indeed
[16:33] <lamont> # ls -la /sys/kernel/debug/dri/
[16:33] <lamont> total 0
[16:33] <lamont> drwxr-xr-x  2 root root 0 2010-04-22 07:35 .
[16:33] <lamont> drwxr-xr-x 14 root root 0 2010-04-22 07:35 ..
[16:33] <lamont> #
[16:33] <lamont> iz boring there
[16:34] <dholbach> wooooo!
[16:34] <lamont> mind you, I killed all visual effects (Appearance) in order to get my keyboard focus back, since metacity has it, but compiz never learned about strict
[16:34] <ogra> intel card ?
[16:34] <lamont> and really DO. NOT. CARE. about visual effects and pretty wizzy stuff... just want machine cycles for me, thanks
[16:34] <lamont> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
[16:35] <lamont> inspiron 1520
[16:35] <ogra> weird
[16:35] <ogra> even if you dont run compiz the dri module should be loaded and create that file
[16:35] <lamont> right now, I have overlapping firefox and xchat windows.  switching between them results in 4-5 seconds of X taking 90% of one of two cores
[16:35] <lamont> more like 96%
[16:36] <lamont> this is the fresh lucid install, too
[16:36] <lamont> well, from beta1
[16:36] <ogra> sounds a bit like what lool reported
[16:36] <ogra> and i think Keybuk had similar issues
[16:37] <lamont> and GM card
[16:37] <ogra> (at least both were load related)
[16:37] <lamont> I'd be happy to test a fix....
[16:37]  * ogra hasnt one ... 
[16:38] <seb128> lamont, do you use the lucid version or the ppa one which had a call for testing?
[16:38] <ogra> nor do i have a bug with the fixed gem objects thingie
[16:38] <lamont> and we expect that the GEMLeak fix is different?
[16:38] <lamont> seb128: stock lucid at this point
[16:38] <seb128> ok so it's not a bug in the candidate fix at least
[16:38] <seb128> I doubt it's the issue you are having anyway there
[16:39] <lamont> seb128: not a regression in it no.  probably a "still a bug" bug
[16:49] <jdstrand> mvo: is 'do-release-upgrade -d' supposed to work with hardy - lucid upgrades?
[16:49] <mvo> yes
[16:50] <jdstrand> mvo: as in, 'right this second'
[16:50] <jdstrand> hmm
[16:50] <mvo> what is the error? or just nothing?
[16:50]  * jdstrand wonders why it said 'No new release found'
[16:50] <jdstrand> I do use a local debmirror
[16:51] <jdstrand> but that didn't stop a recent karmic - lucid desktop upgrade via update-manager -d
[16:51] <jdstrand> mvo: could Acquire::http::Proxy being set affect things?
[16:54] <jdstrand> mvo: scratch Acquire::http::Proxy -- I'm not actually using that
[16:59] <jdstrand> mvo: nm-- seems it needs to contact rookery.canonical.com for stuff-- this machine has outgoing http blocked
[17:00] <persia> jdstrand: That would be getting the newest hints files to work around known issues.
[17:00] <jdstrand> makes sense
[17:01]  * jdstrand temporarily adjust firewall
[17:02] <lamont> jdstrand: the metafiles that say what do-release-upgrade can do live on rookery
[17:02] <jdstrand> cool, easy enough to fix
[17:02] <lamont> so not just known issues
[17:06] <lamont> so first I get to wait for it to slow down again, and thereby see howlong it takes for evil
[17:06] <mvo> jdstrand: longer term we want to shift them to archive.u.c
[17:07] <jdstrand> it also seems to want lithium.canonical.com
[17:07] <jdstrand> lamont: what is that for? ^
[17:07] <lamont> archive.u.c includes lithium
[17:08] <jdstrand> hmm, it would be nice if it used my debmirror there...
[17:08] <jdstrand> ok
[17:08] <lamont> jdstrand: to do that, you need to remove all mention of *.archive.u.c from sources.list
[17:08] <lamont> then it goes "ZOMG shall I use yours?"
[17:09] <lamont> otherwise, it disables all local archives
[17:09] <lamont> for values of local != *.archive.u.c
[17:09] <jdstrand> lamont: negative. I don't have any reference to archive.u.c
[17:09] <jdstrand> and apt-get update just proved that to me
[17:09] <lamont> I wonder if it's fetching the lucid tarball
[17:09] <lamont> anyway, dunno
[17:09] <jdstrand> mvo: is this expected as well? ^
[17:10] <jdstrand> extracting 'lucid.tar.gz'
[17:10] <jdstrand> seems that was it, yes
[17:11] <lamont> \o/
[17:11] <lamont> that's one of them special files from update-mangler
[17:12] <AaronMT> Which build of Firefox is bundled in the RC? 3.6.2?
[17:13] <Pici> AaronMT: 3.6.3
[17:13] <AaronMT> Thanks
[17:19] <persia> lamont: jdstrand: There's a confuguration file that lets you change the "official mirror" if you want to get something network-closer when using python-apt's sources.list munging.
[17:20] <lamont> persia: nice
[17:20] <lamont> persia: I just cheated when I did my mirror, and abused DNS like there was no tomorrow
[17:20] <lamont> archive.ubuntu.com has address 192.168.35.42
[17:21] <lamont> but I won't support such activities
[17:27] <Caesar> So https://wiki.ubuntu.com/Bugs/HowToFix has the most contrived example possible
[17:28] <Caesar> What I'd like to know is if I'm fixing a bug in a package that currently lacks a patch system, should I be introducing a patch system or just fixing the bug and letting the change wind up in the diff.gz directly?
[17:28] <cjwatson> just fix the bug
[17:28] <Caesar> If it makes a difference, I'm trying to cherry pick a fix for bug #539814
[17:28] <Caesar> cjwatson: ok thanks
[17:29] <cjwatson> the general rule is that we should avoid changing the packaging structure of packages we modify relative to Ddebian
[17:29] <cjwatson> *Debian
[17:29] <Caesar> cjwatson: makes sense
[17:30] <ScottK> Caesar: This is even more true for SRUs (like I assume you are working on)
[17:30] <zul> slangasek/pitti: when you get a chance can you have a look at #533029
[17:30] <persia> For those that have extra time, if there are no other patches in the packaging, it may be worth trolling through the Debian Maintainer's other packages to see if they have a preferred patch system, etc. but in most cases, this isn't useful or necessary. (and never correct for SRUs)
[17:31] <cjwatson> hopefully all this will become irrelevant over time given http://upsilon.cc/~zack/stuff/dpkg-v3/
[17:31] <cjwatson> I don't think converting 1.0 to 3.0 (quilt) in Ubuntu is any wiser than other conversions, though
[17:47] <Caesar> Grr. This is not easy :-(
[17:49] <tseliot> slangasek: ok, I have tested and uploaded my fix for fglrx. The fix is also upstream, in git
[17:51] <jdstrand> pitti: fyi, tested gnome-keyring on a few systems and it worked beatifully. nice work! :)
[18:01] <pitti> jdstrand: cheers :)
[18:22] <Q-FUNK> slangasek: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/416305   does it make sense to merge this now?
[18:28] <ccheney> slangasek: i got a bug today about openoffice.org-hyphenation file conflict that i will probably need to fix, will try to get it prepared and tested by later today/early tomorrow
[18:30] <ScottK> ccheney: There's an OOo upload in queue right now.  I think we have at most one more OOo upload before release.
[18:34] <ccheney> ScottK: openoffice.org-hyphenation isn't part of the OOo source
[18:34] <ScottK> ccheney: Oh, right.  Sorry.
[18:35] <ccheney> ScottK: the new ooo-dictionaries package added some more bits that used to only be in the hyphenation package so it needs those parts removed and verify the replaces line, maybe more checking to verify thats all that broke
[18:36] <ccheney> ScottK: openoffice.org-hyphenation only exists in Ubuntu and is there to fill in the gap from the dictionaries source package
[18:37]  * ccheney bbiab
[19:26] <mathiaz> mvo: hi!
[19:26] <mathiaz> mvo: it seems that there is some issue with mysql on upgrade from 8.04 to 10.04 - bug 568606
[19:27] <mathiaz> mvo: I've attached all the logs from /var/log/dist-upgrade/ as well as /var/log/apt/term.log to make sure mysql-server was installed before the upgrade
[19:27] <mathiaz> mvo: do you need anything else?
[19:29] <Keybuk> slangasek: is bug #567964 matching a pattern you know about?
[19:30] <slangasek> Keybuk: I would infer that's bug #559761
[19:32] <Keybuk> that's the one I was thinking of
[19:32] <Keybuk> thanks
[19:32] <Keybuk> couldn't find/remember the bug'
[19:54] <upd> this tcptraceroute program really don't seem like it would work, i get anywhere  * * * for response ? is this event ubuntu question ?
[19:57] <ScottK> upd: No.  That's the same no matter where you run it.
[19:58] <upd> ah okey
[19:59] <ramvi> Building plymouth from source returns an error only when building for i386... What can I do?
[20:02] <mvo> mathiaz: thanks, the logs looks complete
[20:02] <persia> ramvi: Track down the error.  Last time I encountered a per-arch build failure on plymouth, it was related to the build-status of libdrm2 (but I suspect it's unlikely to be the same cause).
[20:06] <Chipzz> upd: I have used tcptraceroute on numerous occasions, and yes, it does work
[20:06] <upd> well it does not work for me.
[20:06] <Chipzz> I do however not see how your question is relevant here ;P
[20:07] <Chipzz> problems on your side then.
[20:08] <upd> i send syn packet's and get back icmp packet with time-to-live flag set on, but tcptraceroute doesn't show anything
[20:08] <Chipzz> are you aware that tcptraceroute is not traceroute?
[20:08] <upd> yes
[20:08] <Chipzz> and that both do very different things?
[20:09] <upd> yes..
[20:10] <upd> well, i'm not sure how it works, i think the response is the same in both program, but tcptr send tcp/syn packet instead of udp packet
[20:11] <ScottK> This probably isn't the best channel for the discussion, however.
[20:11] <upd> so, tcptr will work only if target has open ports ?
[20:11] <Chipzz> that's the whole point...
[20:11] <upd> ScottK, wher can i ask than ?
[20:11] <upd> ah okey than
[20:11] <ScottK> upd: No idea, but it's nothing to do with Ubuntu development
[20:13] <Chipzz> upd: small suggestion: you are expected to read the topic of a (/any) channel before talking there; pls make a habbit out if it ;)
[20:14] <upd> yes yes
[20:52] <pitti> directhex: indicator-application> erm, renaming binary packages after RC? any chance that this could be moved to maverick, and we just fix the .pc?
[20:54] <directhex> pitti, already went through this with slangasek. it'll mess up backports badly to need to re-break the packages each time
[20:55] <pitti> directhex: ah, did he ack it?
[20:55] <pitti> at least those packages don't have any rdepends
[20:55] <directhex> pitti, yeah. 1 rdepends, banshee-community-extensions in universe
[20:55] <directhex> pitti, i can find the logs if you like
[20:55] <directhex> or #ubuntu-release is logged i guess
[20:55] <pitti> directhex: oh, if he ack'ed it, that's fine for me
[20:56] <pitti> directhex: i. e. your word for it
[20:58] <directhex> pitti, hopefully next time canonical folks are making a mono binding, they can copy-paste the packaging from lib1u or now from libappindicator
[20:58] <directhex> or make raof do it, he's your best mono person on staff
[20:58] <apw> pitti, this keyring update, does installing that do the cleanup you mention or is some other part of the upgrade process responsible..  ie. if i am already upgraded to close to -rc will i get cleaned too?
[20:59] <pitti> apw: it's not in the postinst, since it's per-user; cleanup happens on startup of gnome-keyring-daemon, i. e. when you log into GNOME
[20:59] <pitti> apw: yes, we'll keep the cleanup in lucid final
[20:59] <pitti> and drop it in maverick
[20:59] <pitti> we might perhaps drop it in 10.04.2 or so, but it doesn't really hurt
[21:00] <persia> Seems a bit invasive for 10.04.2
[21:00] <apw> pitti, cool as long as i will be cleansed too i am happy, thanks for the clarification
[21:01] <pitti> directhex: ah, found the discussion
[21:02]  * pitti accepts and watches NEW
[21:39] <pitti> directhex: why is there a version mismatch? libappindicator0.0-cil vs. libappindicator0.1-cil-dev ?
[21:40] <directhex> pitti, i'm just going with the API and ABI versions that upstream (i.e. you guys) have in the source
[21:40] <pitti> ok, so that's intended?
[21:41] <pitti> NEWed, so banshee-community-extensions shold build now
[21:42] <directhex> pitti, it's intended for the package to fit upstream. whether that's what *upstream* meant to say is another matter ;)
[21:42] <sebner> directhex: let's ask upstream *muahahahaha*
[21:43] <directhex> pitti, should i request an immediate rebuild of b-c-e then? is there any publishing delay to worry about?
[21:45] <persia> You probably at least want libappindicator0.1-cil-dev to build and be published.
[21:45] <ScottK> directhex: You'd actually rather just wait.
[21:45] <directhex> ScottK, thought as much
[21:46] <ScottK> Automatic retries get the build priority the package originally got.  Manual retries get a build priority of 0.  Touching of a manual retry will actually slow things down.
[21:46] <directhex> ooh, advanced technology
[21:47] <persia> Well, it depends on why the rebuild will be required.  For things not DEPWAIT, you still have to press the button.
[21:53] <Caesar> Whoa: http://www.osnews.com/story/23191/Rumour_Apple_To_Acquire_ARM_
[21:55] <ScottK> Caesar: I imagine they're too busy sueing themselves now that Android can run on iPhone.
[22:03] <Caesar> ScottK: heh
[22:10] <joaopinto> more people reporting unable to mount with LVM, but no one caring enough to test the fix :\
[22:11] <arand> joaopinto: Could be done in VM?
[22:12] <joaopinto> arand, I was not able to reproduce, but I don't know much about LVM either
[22:13] <arand> joaopinto: Ah, well me neither, but would happily mess about a bit in a VM if it would help.
[22:15] <joaopinto> arand, I just know it fails to mount some LVs
[22:42] <jdstrand> slangasek: hi-- is it accurate to say that everything that is in main should be in a seed file?
[22:42] <seb128> jdstrand, no, lot of things are depends of things which are seeded
[22:42] <seb128> jdstrand, no, lot of things are depends of things which are seeded
[22:42] <seb128> ups
[22:42] <persia> Or recommends od stuff that is seeded.
[22:43] <persia> And lots of stuff is seeded but not in main.
[22:43] <persia> Because only some seeds are considered for main inclusion.
[22:43] <jdstrand> so a seed it the very toplevel, and it will pull in what it needs
[22:43] <jdstrand> is that accurate?
[22:43] <persia> All this will actually make sense once components go away, and we don't have "main"
[22:43] <jdstrand> (for the seeds considered for main inclusion)
[22:44] <persia> Kinda.
[22:44] <persia> It actually requires manual action by an archive admin to move stuff between components.
[22:44] <persia> But that's driven by a combination of MIRs and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[22:44] <jdstrand> right
[22:44] <persia> And component-mismatches is generated by actions on the seeds.
[22:45] <persia> (well, a subset of the seeds)
[22:45] <ScottK> Or changes in build-depends, depends, and recommends of seeded packages and the packages they pull in.
[22:45] <jdstrand> I didn't mean it automatically happens-- I mean that everything a seeded item depends on, if that seed is considered for main, should end up in main-- if it isn't, there is component-mismatches
[22:45] <persia> Well, let's say component-mismatches is generated based on the current state of the archive and a subset of seeds.
[22:46] <persia> jdstrand: That's roughly correct.
[22:47] <persia> jdstrand: That said, the answer is to clear component-mismatches.  The right way to do this may not involve promotion/demotion: it may involve changes to other packages so that something does/doesn't end up as part of the depends/recommends tree.
[22:49] <persia> jdstrand: And whilst you're at it: how about those binary-only demotions :)  linux-headers-2.6.32-21-versatile is only interesting for folks running in qemu, which isn't well supported, libappindicator0-cil/libappindicator-cil-dev will go away soon thorough NBS.  libboost... ought get investigated to find out why it's no longer in the depends/recommends tree
[22:54] <jdstrand> persia: is does seem that component-mismatches won't complain if something is in main, but isn't seeded and/or nothing in the rdepends chain is seeded
[22:54] <persia> It should.
[22:54] <jdstrand> persia: devio is an example
[22:54] <persia> That's where the source and binary demotions list is generated.
[22:55] <persia> jdstrand: How many architectures did you check for depends/recommends?
[22:55] <jdstrand> it's rdepends in slugimage
[22:55] <jdstrand> good point
[22:57] <persia> jdstrand: I'd recommend checking the component-mismatches code directly (although I don't remember what geneates it: I thought it used to be anastasia, but I heard that was deprecated at one point)
[22:57] <persia> That should give you a better understanding than speculations :)
[22:58] <jdstrand> heh
[23:10] <persia> I've just gotten confused between  lp:~ubuntu-core-dev/ubuntu-seeds/unr.lucid and  lp:~ubuntu-core-dev/ubuntu-seeds/netbook.lucid : Does anyone know why both exist?
[23:11] <persia> Also, if anyone feels like marking https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.lucid as Abandoned, I'd appreciate it.
[23:13] <lool> cjwatson: While upgrading, got prompted on which devices to run grub-install on; I had recently dpkg-reconfigured grub-pc and selected sda, sdb, sdd, sde after sdc had failed and had been replaced with sda in my RAID10 setup, but in the upgrade dialog only sde was selected; will file a bug
[23:31] <YokoZar> Keybuk: poke
[23:33]  * persia advocates avoiding contentless pokes for all the same reasons one avoids contentless pings
[23:37] <jdong> pitti: do you have a preference on SRU versioning conventions for lucid-proposed? Most of the debdiffs I'm coming across are using bump-by-1 versions as if they are non-SRU uploads...
[23:37] <persia> That would be just plain wrong.
[23:38]  * jdong also bawks at the sheer complexity of http://launchpadlibrarian.net/45030477/poppler_0.12.4-0ubuntu4_2_0.12.4-0ubuntu5.debdiff
[23:38] <mathiaz> slangasek: hi - do you think bug 529686 is worth fixing?
[23:38] <mathiaz> slangasek: in time for the release of lucid?
[23:39] <seb128> jdong, persia: I've always updated the version by one when doing sru updates
[23:39] <seb128> especially when the new serie is not open and there no way to conflict
[23:40] <seb128> and usually after too because we often get new versions in the new serie anyway
[23:40] <persia> I'd think that dangerous, as there's no good way to communicate with others that one is doing this, so the same increment with entirely different contents could get pushed to maverick.
[23:41] <seb128> the sru team review debdiffs
[23:41] <persia> I recall that the convention of using .X was encouraged for SRUs (although I'm not an SRU person)
[23:41] <seb128> I fail to see where it would be dangerous
[23:41] <seb128> the good way is the upload target in the changelog
[23:41] <persia> Because you might upload foo-1.2-3ubuntu5 to lucid-proposed, and I might upload a completely different foo.1.2-3ubuntu5 to maverick.
[23:42] <seb128> that would fail
[23:42] <persia> Safer to have had you upload 1.2-3ubuntu4.1 in the first place, because then I don't have to check what you did.
[23:42] <seb128> 2 versions of the same source can't be accepted
[23:42] <seb128> if you do that one upload will fail and then you have to fix what you screwed
[23:42] <persia> Even to different series?
[23:43] <seb128> yes
[23:43] <seb128> well I think so, I didn't try recently I think
[23:43] <jdong> seb128: for packages where the maintainer keeps a VCS, I don't have any issues with full version bumping, but the SRU versioning policy is the same as the Security versioning policy...
[23:43] <jdong> which means you should be doing X.Y bumps
[23:44] <seb128> security has an harder job that they touch packages they don't usually maintain
[23:44] <seb128> so it's easier to not screw with that convention
[23:44] <seb128> but for a source you maintain and where you know what you are doing...
[23:44] <persia> jdong: Regarding painfully long patches: You could always insist on DEP3
[23:45] <seb128> the patch is a git commit backport
[23:45] <jdong> persia: it's not the length, it's that the diff seems to completely reimplement the text selection algorithm, though as a upstream git commit, it seems fine
[23:45] <seb128> the issue has been discussed already and pitti said to do a sru rather than try to get the change in lucid now
[23:46] <seb128> the issue is an annoying want that we would like to see fixed in a lts
[23:46] <seb128> the issue is an annoying want that we would like to see fixed in a lts
[23:46] <seb128> ups
[23:46] <jdong> *nods* I totally agree with you on the merit
[23:46] <persia> I only suggested DEP3 to force the link to the git commit: not to suggest it shouldn't go.
[23:47] <seb128> I tend to not tag git commit
[23:48] <seb128> they have the commit id info already
[23:49] <persia> I try to do at least author/source/bug when cherrypicking just for ease of reference by others.
[23:49] <persia> But I generally like to try to make it easy for *anyone* to be the next person making a change to a package I touch.