[03:23] <linux_is_my_hero> my cups client computer sees the shared printer on the cups server, but when attempting to print, the job is sent and nothing happens.
[05:39] <pitti> Good morning
[07:11] <andy753421> I have a package and two dependency packages which are new to ubuntu that I would like to file a feature freeze exception for. Should I submit one bug on launchpad for all three packages, or three separate bugs?
[07:14] <micahg> andy753421: I'd suggest using requestsync -e to file the requests and mention the main bug in the ones for the dependencies
[07:14] <micahg> andy753421: and the dependencies in the main one
[07:16] <geser> micahg: wouldn't it be better to only have one bug? as either all 3 packages go in or none?
[07:17] <micahg> geser: well, if there are problems with any of the packages, it could get messy
[07:18]  * micahg should state that he is not a release team member
[07:19] <dholbach> good morning
[07:20] <geser> but you could see that in the one bug and don't sync the other parts by missing to check all three bugs
[07:20] <geser> good morning dholbach
[07:20] <dholbach> hey geser
[07:21] <micahg> geser: if sponsors aren't reading the bugs , don't we have bigger problems?
[07:21] <geser> micahg: true
[07:23] <pitti> dear LP, please stop timing out; love, pitti
[07:24] <pitti> I wish the timeout would be raised at least for launchpadlib
[07:24] <pitti> scripts keep breaking because of it :/
[07:24] <geser> dholbach: I was visiting FroSCon this weekend and saw an interesting talk about "Perceptions of rudeness in Free Software communities" (http://programm.froscon.org/2011/events/717.html). The study was done on some Ubuntu forum threads. The talk was recorded but the recordings aren't online yet.
[07:25] <micahg> pitti: file bugs and sic bryceh on the LP team :)
[07:25] <pitti> it times out during searchTasks(), and I'm trying to run the retracer to reduce that very number of searchTasks() results :)
[07:26] <dholbach> geser, thanks a lot for the pointer - I'll check it out
[07:26] <bryceh> pitti, yeah the lplib timeouts have been annoying me as well
[07:26] <pitti> unfortunaetly there is no "limit" argument for searchTasks(), that'd be sufficient for me
[07:26] <bryceh> if you ever find an oopsid, file a bug report on it; they always automatically set those to critical
[07:27] <pitti> x-lazr-oopsid: OOPS-2062O19
[07:27] <pitti> ah, nice, it's part of the exception
[07:27] <pitti> will do
[07:27] <lifeless> we'll probably move that to X-Oops-Id: soonish
[07:28] <lifeless> pitti: we need to talk about apport & crash dump formats at some point. Maybe in 3-4 weeks?
[07:28] <pitti> lifeless: sounds good
[07:28] <lifeless> pitti: searchTasks when you're iterating on a big set can end up with things that take *minutes*: raising the timeout there would have a very negative effect on LP as a whole
[07:29] <pitti> lifeless: do you know a workaround?
[07:29] <pitti> lifeless: something that just gives me the first 75 or 50 results or so?
[07:29] <lifeless> don't iterate the entire batch :)
[07:29] <lifeless> result = searchTasks()[:75] ?
[07:30] <lifeless> anyhow, adeuring is -very- close to having something that will handle offsets much much better
[07:30] <lifeless> it won't fix plain-poor queries but it will help large batches quite a bit
[07:33] <pitti> lifeless: [:75] is too late, though -- searchTasks() itself times out, not the iteration over the result
[07:34] <lifeless> pitti: that means the first batch is failin
[07:34] <lifeless> what are you searching for ?
[07:36] <pitti> lifeless: reproducer in bug 832566
[07:36] <pitti> x-lazr-oopsid: OOPS-2062O19
[07:36] <pitti> sorry
[07:36] <pitti> essentially: lp.distributions('ubuntu').searchTasks(tags='need-amd64-retrace')
[07:37] <lifeless> ok
[07:37] <lifeless> thats a dupe
[07:37] <lifeless> its utterly buggered :(
[07:40] <pitti> lifeless: seems I can work around it by using "created_since='2011-08-01'", and then working my way backwards
[07:40] <lifeless> cool
[09:05] <andy753421> micahg: does this look alright? https://bugs.launchpad.net/ubuntu/+bug/832611
[09:10] <andy753421> i forgot the -e flag, so i added ubuntu-release manually afterwards..
[09:42] <Laney> you should request those other syncs which need doing first separately
[09:42] <Laney> s/separately/explicitly/
[09:48] <Laney> ah, you did :-)
[11:25] <cjwatson> janimo: have you actually uploaded livecd-rootfs 2.32?  I don't see it in LP, but the branch is tagged
[11:25] <cjwatson> oh, maybe I'm just impatient.  /me recalculates timezones
[11:26] <janimo> cjwatson, yes, uploaded a few seconds afetr bzr push
[11:26] <janimo> cjwatson, is there a recommended sequence? The other presumably :) ?
[11:26] <ricotz> janimo, hello, could you take a look at the armel build of cogl? of course the configure-flags arent right yet http://anonscm.debian.org/viewvc/pkg-gnome/packages/experimental/cogl/debian/rules?r1=29484&r2=29483&pathrev=29484
[11:28] <ricotz> janimo, forgot this link https://edge.launchpad.net/ubuntu/+source/cogl/1.7.6-1/+build/2739607
[11:28] <janimo> ricotz, I know we had issues with clutter in Ubuntu because of the backends
[11:28] <janimo> for some reason I thought cogl was part of clutter source
[11:28] <ricotz> janimo, i cant build it myself
[11:29] <ricotz> the cogl lib was split out from clutter
[11:29] <janimo> ok
[11:29] <ricotz> and is now a dependency of it
[11:29] <janimo> I know with clutter we were waiting for an upstream fix that adds proper runtime backend selection (GL/GLES)
[11:29] <janimo> the patches in clutter were always messy
[11:30] <janimo> as we needed GLES/EGL to act as if it were GL/GLX but only at the .so naming level, even if the lib itself at the source level had certain assumtions - include file names IIRC
[11:30] <ricotz> janimo, i removed quite all ubuntu patches for clutter since they were obsolelete or consider not-needed by upstream
[11:30] <cjwatson> janimo: no no, don't worry, you did it right, I just miscalculated the timezone and thought you'd uploaded an hour or more ago
[11:30] <cjwatson> janimo: push before upload is correct
[11:30] <janimo> ricotz, if they are obsolete that is great - if it means it builds fine with GLES2 on arm
[11:31] <cjwatson> (or rather, thought you'd tagged an hour or more ago)
[11:31] <ricotz> janimo, yes, so that is why the configure flags specific for armel
[11:31] <janimo> cjwatson, ok. UDD still confuses me, and actually this was the first time I got it done with a single bzr uncommit. I am almost conversant in UDD now :)
[11:32] <ricotz> janimo, it would be great if you could testbuild it with the changed configure-flags
[11:32] <janimo> and one bzr tags --delete, oh well
[11:32] <ogra_> hmm, are environment variables not handed through from toplevel to bottom in live-build ?
[11:32] <cjwatson> generally should be
[11:32] <ogra_> i added FLASH_KERNEL_SKIP=1 to the config a while ago, but flash-kernel is still executed
[11:33] <ogra_> argh !
[11:33] <janimo> ricotz, sure, I'll test and see if I find the issue
[11:33] <cjwatson> you forgot to export it
[11:33] <ogra_> thinko ! ... update-initramfs is run chrooted
[11:33] <cjwatson> however - they aren't passed into the chroot
[11:33] <ricotz> janimo, i could do it myself if there is a easy way to set up some armel-thing with qemu-system-arm?
[11:33] <cjwatson> I already abandoned that solution to that problem
[11:33] <ogra_> no, i export it, but it doesnt seem to be hadned over by the chroot cmd
[11:33] <cjwatson> I thought I'd fixed it for you some other way
[11:33] <ricotz> janimo, thanks
[11:34] <cjwatson> I definitely remember looking at that and I'm sure I ticked it off my list
[11:34] <ogra_> well, i'll think about it, we werend in massive need of it until now
[11:34] <ogra_> with the mx5 artch showing up it will try to update the buildd bootloader now though
[11:34] <ogra_> *weren't
[11:35] <cjwatson> yes, I fixed it with a diversion in live-build
[11:35] <cjwatson> you might like to investigate why that isn't working
[11:36] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630350
[11:37] <cjwatson> it's possibly because lb_binary doesn't call lb_chroot_dpkg (and probably shouldn't) - I suggest you talk with Daniel Baumann about the best place for that diversion to go
[11:37] <cjwatson> a diversion is definitely a better way to handle this than an environment variable
[11:38] <cjwatson> ogra_: incidentally, you really don't export it, I checked, although that's irrelevant :)
[11:38] <ogra_> cjwatson, oh, a diversion wont work anymore
[11:39] <cjwatson> it should do, it's just done in the wrong place ...
[11:39] <cjwatson> I suspect, anyway.  I bet update-initramfs is being called in the lb binary phase?
[11:39] <ogra_> its called from some lb_chroot_hacks script
[11:39] <ogra_> pretty ugly that there is no function for it or some such
[11:40] <cjwatson> the diversion I added is in place when lb_chroot_hacks runs.
[11:41] <cjwatson> lb_chroot does (among lots of other stuff) lb_chroot_dpkg install; lb_chroot_hacks; lb_chroot_dpkg remove
[11:41] <cjwatson> lb_chroot_dpkg adds the diversion on install and removes it on remove
[11:41] <cjwatson> :q
[11:41] <cjwatson> (doh)
[11:42] <ogra_> hmm
[11:42]  * ogra_ checks the logs again, i'm probably looking in the wrong place
[11:43] <ogra_> bah, i indeed looked at a different update-initramfs call
[11:43] <ogra_> the one in the hack script doesnt spill the error
[11:45] <cjwatson> where's the other call?
[11:47] <ogra_> its manually added for ac100 in the build script in livecd-rootfs, i just need to make sure to export it inside the chroot call ...
[11:47] <ogra_> that shouldnt be an issue, sorry for the noise, that was really silly
[11:48] <cjwatson> right, easy to add for that one case then
[11:48] <pitti> Daviey, RoAkSoAx: powernap currently wants to go to universe, is that intended?
[11:49] <cjwatson> please remove it from live-build/auto/config again to avoid anybody being confused into thinking that works
[11:49] <ogra_> yep, will do
[11:49] <pitti> Daviey, RoAkSoAx: it's also uninstallable in main right now, don't know yet why
[11:50] <Daviey> pitti: No, I've made RoAkSoAx aware.. and we are currently looking at directly seeding or making it a depends.
[11:50] <pitti> Daviey: ok, thanks
[11:51] <Daviey> pitti: I'd rather keep the seed minimal and rely on depends for that.
[11:51] <pitti> Daviey: well, powernap at least sounds like the kind of "top level pacakge/feature" which are appropriate for seeds
[11:51] <pitti> but your call
[11:52] <jbicha> cjwatson: can I just remove the webbrowser dependency completely? a browser is kind of assumed these days
[11:54] <Daviey> pitti: Yeah, previously it was included as it was a required depends of eucalyptus, the same requirement hasn't yet been added to openstack.  So really, i wouldn't be too upset if it was demoted - but the fact that next cycle it will hopefully bounce back to required, makes it silly to demote IMO.
[11:54] <pitti> Daviey: right, we just need something to hold it in main, so seeding seems appropriate
[11:55] <Daviey> pitti: ok, i'll add it now.
[11:56] <cjwatson> jbicha: no, packages must depend on anything they need outside the Essential set, and a browser is not Essential
[11:56] <cjwatson> jbicha: the fixed version should only be two characters away from your initial MP
[11:57] <jbicha> cjwatson: ok
[12:23] <bdrung> jelmer: i saw that you moved everything to lptools. when will you release lptools? the u-d-t branch pull will depend on the release of lptools.
[12:24] <bdrung> jelmer: let me know if you need a review of that package and a debian sponsor.
[12:26] <jelmer> bdrung: I mainly need to coordinate with lifeless, who is the package maintainer of lptools in Debian
[12:26] <Laney> bdrung: jelmer is a dd ;-)
[12:31] <bdrung> i wasn't aware that lptools is available in debian
[12:35] <cjwatson> ScottK: any luck with the k3b libav patch?
[12:36] <ScottK> cjwatson: I didn't hear back.  Let me ping my tester again (I'm in a $WORK meeting all day today with no DVD player handy).  Thanks for double checking.
[12:39] <jdstrand> do any of you filter 'Branch linked' emails from launchpad? what are you looking at?
[12:41] <bdrung> jelmer: packaging-dev 0.2 uploaded (which recommends lptools)
[12:42] <jelmer> bdrung: awesome, thanks :)
[12:42] <bdrung> np
[12:42] <bdrung> jelmer: now it's time for you to make it worth recommending ;)
[12:44] <jelmer> bdrung: :) I'll talk to lifeless about lptools in Debian this evening
[12:44] <bdrung> great
[12:45] <jdstrand> I think I might be able to use a combination of 'X-launchpad-bug-modifier: Launchpad Janitor (janitor)' and 'Message-id: ...@ackee.canonical.com>', but that seems both brittle and perhaps too heavy-handed...
[12:46] <bdrung> jelmer: can you update the branch for u-d-t?
[12:52] <jelmer> bdrung: to mention what we've just discussed you mean?
[12:54] <bdrung> jelmer: to remove the last three moved tools.
[12:55]  * jdstrand attempts http://paste.ubuntu.com/673796/
[13:07] <pitti>   o scapy: python-scapy
[13:07] <pitti>     [Reverse-Depends: powerwake-common]
[13:07] <pitti> Daviey: ^ ah, that's why it's uninstallable
[13:08] <pitti> Daviey: universe dependency
[13:09] <Laney> jdstrand: a bug asking for a header might be useful ;-)
[13:09] <Laney> or a more descriptive From: or whatever
[13:13] <jdstrand> Laney: yes
[13:16] <janimo> ricotz, it builds fine with that config option change, but at .deb creation it fails in dh_makeshlibs. That in turn is easily fixed by foloowing what it suggests.
[13:16] <janimo> where should I file the bugreport and the diff? Or shall I upload?
[13:19] <mdeslaur> pitti: what releases are we still running retracers for?
[13:20] <pitti> mdeslaur: right now, oneiric; once that has caught up, I'll configure it for lucid/maverick/natty as well
[13:20] <pitti> mdeslaur: it's now dead cheap to do so, but retracing the oneiric ones is more urgent at this point
[13:20] <roadmr> gstreamer pipelines that used gconfaudiosink no longer work as this is not installed by default on oneiric, the obvious replacement (gsettingsaudiosink) is in gstreamer-plugins-bad and thus also not installed by default, will either one of these be included in the default install eventually?
[13:20] <mdeslaur> pitti: ah, ok, thanks!
[13:20] <pitti> mdeslaur: as the reports deterioate fast (unlike the stable ones)
[13:20]  * jdstrand files bug requesting 'X-launchpad-bug-branch-linked' (or similar) in bug 832753
[13:20] <mdeslaur> pitti: thanks for fixing the oneiric one btw :)
[13:21] <pitti> jdstrand: actually, filtering these out wouln't be hard, but it's nontrivial to filter emails which *only* have that message without anything else
[13:21] <pitti> mdeslaur: my pleasure; was a 13 hour hack session yesterday to rewrite them, but I'm quite pleased with them now; it's sooo much easier
[13:21] <pitti> mdeslaur: in bug 832740 I also asked to get the new goodness into oneiric
[13:22] <jdstrand> pitti: yes-- I was trying to avoid a body search
[13:22] <jdstrand> and this is also why my current attempt is putting them in a folder, rather than deleting them :) I have no idea if my current recipe is too heavy-handed
[13:22] <seb128> roadmr, -gconf should be installed by default since gnome-media depends on it
[13:23] <roadmr> seb128: oh, let me check again then, thanks for the heads-up!
[13:25] <seb128> roadmr, it's on the manifest of the daily livecd build
[13:25] <roadmr> seb128, you're right, it's there. I just hadn't checked recently. Thanks and apologies, I should check things are still bad before asking :)
[13:26] <seb128> roadmr, no worry ;-)
[13:28] <janimo> ricotz, uploaded, thanks for the fix
[13:31] <ricotz> janimo, thanks, to oneiric?
[13:33] <ricotz> janimo, alright, i will add your changes to debian later for a 1.7.6-2
[13:39] <Daviey> pitti: ah
[13:40] <janimo> ricotz, yes, oneiric
[13:41] <pitti> ev, cjwatson: today's desktop CD boots straight into the live session, whereas previosu versions defaulted to the "install / try" dialog from ubiquity; is that intended or a bug?
[13:41] <ev> bug
[13:42] <ev> pitti:  /var/log/installer/dm might have the error
[13:42] <pitti> ok, step 2: make kvm not freeze the guest when booting it
[13:46] <pitti> (EE) Failed to load module "vmwgfx" (module does not exist, 0)
[13:46] <pitti> (EE) vmware: Please ignore the above warnings about not being able to to load module/driver vmwgfx
[13:46] <pitti> (EE) open /dev/fb0: No such file or directory
[13:46] <pitti> ev: ^ is the /dev/fb0 error relevant?
[13:46] <ev> nope
[13:46] <pitti> after that I see two DBUG statements for launching the a11y bus, then it ends
[13:46] <ev> not to my knowledge
[13:46] <ev> anything in syslog or /var/log/installer/debug?
[13:48] <pitti> http://paste.ubuntu.com/673825/ -> syslog; v/l/i/debug doesn't exist
[13:48] <tseliot> cjwatson: is there a way to see if I blacklisted a card correctly in grub-gfxpayload-lists? (e.g. in some logs)
[13:48] <pitti> ev: actually I was trying to reproduce bug 831884 ; maybe that's related somehow
[13:52] <ev> pitti: anything in /var/crash? :)
[13:53] <pitti> ev: oha :) _usr_bin_ubiquity-dm.0.crash
[13:53] <pitti> that _might_ be related :)
[13:53] <ev> pitti: :-P
[13:53] <kirkland> pitti: hey, did you guys get PowerNap seeded?
[13:54] <pitti> kirkland: hey, how are you?
[13:54] <pitti> kirkland: Daviey said he was going to
[13:54] <pitti> ev: bug 830061
[13:55] <kirkland> pitti: hey man, good!  yourself?
[13:55] <pitti> splendid, thanks!
[13:55] <cjwatson> tseliot: you can run whatever the hwmatch command is by hand and look at the exit code
[13:55] <Daviey> pitti: kirkland thinks it's a desktop problem, suites me :)
[13:55] <ev> pitti: thanks
[13:55] <cjwatson> tseliot: if you don't have access to the machine, there are no logs - grub doesn't write to the filesystem
[13:55] <pitti> ev: should've looked first, sorry for bothering
[13:55] <ev> pitti: no worries at all; glad to help
[13:59] <tseliot> cjwatson: and that hwmatch command is run by grub, isn't it?
[14:03] <tseliot> cjwatson: I'm asking as I can't see anything in the grub-gfxpayload-lists package which could do it
[14:08] <cjwatson> tseliot: yes
[14:08] <cjwatson> /etc/grub.d/10_linux
[14:09] <smoser> anyone have thoughts on how i can create a static executable of http://paste.ubuntu.com/673848/ .
[14:10] <smoser> if I do so with simple 'gcc -static' the executable is 700k.
[14:10] <tseliot> cjwatson: that's exactly what I was looking for. Thanks a lot
[14:10] <smoser> i just need to be able to make that ioctl call in a limited busybox environment (ie, no perl or python)
[14:12] <pitti> ev: it seems the ubiquity window grew recently? starting it on a 1024x600 netbook doesn't work well any more, the bottom button bar is missing and there is no way to resize it
[14:13] <ev> pitti: indeed, I've noticed that as well.  It's on my list of things to fix
[14:13] <pitti> ah, good; thanks
[14:13] <ev> alt + click and drag for the meantime
[14:15] <smoser> doko_, might you have thoughts on above ? slangasek ?
[14:15] <cjwatson> smoser: might it be easieer to fix busybox?
[14:15] <cjwatson> *easier
[14:15] <smoser> :)
[14:15] <smoser> busybox *does* have what i need.
[14:16] <smoser> but ttylinux doesnt build with it, and i'm just re-bundling ttylinux. i wanted to avoid rebuilding it.
[14:20] <slangasek> smoser: what do you mean, "Build with it"?
[14:21] <slangasek> it seems like if buysbox's ip implementation already supports this, then you're set
[14:22] <slangasek> as for the size of static builds, no idea except for running 'strip'
[14:22] <smoser> yeah, strip -s ran
[14:22] <slangasek> and building with -Os
[14:23] <smoser> busybox already supports the 'ip' command, but the busybox built for ttylinux does not have that enabled. i'm really just stealing their root and re-purposing.
[14:23] <smoser> i dont want to re-build their entire distro or busybox if i can avoid it.
[14:24] <slangasek> ah
[14:25] <smoser> i was hoping someone woudl point me at an easy to use pre-built uclinux tool chain
[14:26] <smoser> or some other trvial solution.
[14:26] <ogra_> arent we actually using klibc's ip command in the initrd ?
[14:27] <smoser> i dont know. all my ubuntu initrds have busybox
[14:27] <ogra_> they also have klibc :)
[14:27] <ogra_> but i messed that up, it was ipconfig klibc delivers, not ip
[14:28] <smoser> i didn't realize klibc provided binaries. i thought just "kernel libc"
[14:29] <ogra_> klibc-utils provides binaries iirc
[14:30] <smoser> yeah. i see that now.
[14:57] <slangasek> infinity: any idea if the new ghc6 makes https://launchpad.net/ubuntu/+source/haskell-lexer/1.0-2build1/+build/2548362 any more likely to succeed if retried?
[14:58] <cjwatson> slangasek: ghc6->ghc surely ...
[14:59] <cjwatson> (though OK, having looked at that log I don't know)
[15:00] <slangasek> ah, it's no longer 6, is it, ok :)
[15:04] <infinity> slangasek:no idea, and stuck on a mobile phone in a doctor's office. :)
[15:05] <doko> Sweetshark, will you one more LO upload before the beta freeze?
[15:07] <cjwatson> Sweetshark: it'd be good if you could look over the entries in http://people.canonical.com/~ubuntu-archive/nbs.html where libreoffice binaries are depending on binaries that are no longer built from source, and see if any of your dependencies need tidying up
[15:07] <cjwatson> TIA
[15:11] <SpamapS> anybody know why mdadm has *no* udd branches at all?
[15:13] <Daviey> SpamapS: yes
[15:14] <Daviey> SpamapS: http://package-import.ubuntu.com/status/mdadm.html , and know you know aswell :)
[15:14] <Daviey> now you*
[15:15] <SpamapS> Thats what the computer knows. Please translate to *human*.
[15:16] <slangasek> infinity: i.e., "no idea sent from my iphone"?
[15:16]  * SpamapS has become woefully dependent on using branches
[15:17] <Daviey> SpamapS: bug #248459 seems to be as far as it got.
[15:17] <Sweetshark> doko: Im trying to get one out.
[15:18] <doko> jtaylor, could you keep the bug task and set it to invalid, so that I still the report for the package?
[15:25] <tjaalton> cjwatson: you didn't happen to push the recent grub-gfxpayload-lists natty upload to bzr? I've one more device id to add to the lenovo blacklist
[15:27] <jtaylor> doko: you mean keepass2?
[15:28] <doko> jtaylor, yes
[15:28] <jtaylor> k set to invalid
[15:28] <doko> Sweetshark, please apply my armel hack, if you don't have time for a proper solution
[15:29] <SpamapS> Is it ok to use /run directly in oneiric BTW?
[15:30] <SpamapS> Specifically in initramfs scripts
[15:31] <cjwatson> SpamapS: yes, but follow the dependency rules in http://wiki.debian.org/ReleaseGoals/RunDirectory
[15:32] <SpamapS> cjwatson: ty thats what I needed
[15:32] <cjwatson> tseliot: lp:~cjwatson/ubuntu/natty/grub-gfxpayload-lists/natty-proposed - that'll have to do
[15:32] <doko> Sweetshark, hmm, maybe better remove the .so explicitly
[15:34] <tseliot> cjwatson: oh, nice, for the SRU
[15:35] <SpamapS> Also, is it acceptible to just add -Wno-unused-but-not-set-variable to CXFLAGS to work around bug 829463? Seems like this late in the game introducing a big patch would be a folly.
[15:36] <Sweetshark> doko: that patch looks strange, why the added make call?
[15:37] <doko> Sweetshark, I did say `hack', not `patch'
[15:37] <dbarth> doko: ping, looking for a power user who can bump the score on https://launchpad.net/~unity-team/+archive/compiz-testing/+builds?build_state=pending
[15:37] <Sweetshark> doko: yes, but still:why?
[15:38] <doko> Sweetshark, to install the linker script
[15:38] <cjwatson> SpamapS: or nuke -Werror from orbit
[15:39] <doko> dbarth, done
[15:39] <SpamapS> cjwatson: it really is the only way to be sure.. :)
[15:39] <cjwatson> SpamapS: although, yes, IMO killing the specific warning is acceptable too
[15:39] <seb128> doko, can you score https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1909476/+listing-archive-extra as well? thanks
[15:40] <doko> fyi, test rebuild on amd64 is done
[15:41] <dbarth> doko: danke sehr!
[15:41] <doko> seb128, done
[15:41] <seb128> doko, thanks
[15:44] <doko> Sweetshark, ahh, I should check the return code from the first build ...
[15:46] <Sweetshark> doko: my approach was: it seems the only reason those files are there is to unprelink them if they are prelinked, so as we are not prelinking anything on arm, not putting any files in the solver should work, shouldnt it?
[15:46] <doko> Sweetshark, sure
[15:46] <Sweetshark> at least sal builds fine without them
[15:46] <doko> Sweetshark, we don't prelink on ony arch
[15:53] <mtaylor> anybody around who deals with wiki.ubuntu.com - I'm looking at openid integration with login.ubuntu.com on another moinmoin wiki
[15:56] <Daviey> mtaylor: #ubuntu-website is probably where you want, and isd is the team.
[15:56] <mtaylor> Daviey: ah sweet. thanks
[15:56] <mtaylor> Daviey: and I just sent you a (very long) email
[15:58] <tseliot> slangasek: hi, I've just requested an SRU for nvidia-common in Natty (bug #825259). This should save us a few crashes on dist-upgrade. The sooner the package gets in, the better.
[16:00] <Sweetshark> doko: attach'ed a simpler and a bit cleaner patch to the bug
[16:04] <doko> Sweetshark, thanks, could you start a build on davis?
[16:04] <Sweetshark> doko: I tried to, but got lots of 404s when trying to install deps :(
[16:05] <Sweetshark> doko: Ill try again later.
[16:05] <apw> cjwatson, is there are recipe for regenerating the casper initramfs correctly using initramfs tools ... i am trying to test a change in the compcache stuff
[16:06] <doko> Sweetshark, running sudo apt-get update && dist-upgrade usually works. if not, ping the vanguard
[16:06] <Sweetshark> doko: thanks for the tip, Ill give it a try.
[16:07] <cjwatson> apw: install casper, update-initramfs -u
[16:07] <cjwatson> (perhaps in a chroot ...)
[16:08] <doko> apw, could you make sure that the kernel header issue is fixed in the next upload? leading to build failures
[16:08] <Laney> cjwatson: a shiny new hat for you to wear? grats :-)
[16:08] <apw> cjwatson, ahh sensible yes
[16:08] <apw> doko, there is a kernel header issue ?
[16:08] <apw> doko, got a bug # ?
[16:09] <doko> apw, bug #824377
[16:11] <seb128> doko, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1909617/+listing-archive-extra please, and I'm done for today :-)
[16:12] <doko> seb128, done
[16:12] <seb128> thanks
[16:13] <apw> doko, it would be helpful to include the ftbs link
[16:14] <cjwatson> Laney: it's got a D on it
[16:14] <Laney> and a lovely swirl
[16:17] <apw> doko, can you point me at the rebuild archive (i assume that is where this failure is)
[16:19] <doko> apw, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2694433
[16:28] <OdyX> tkamppeter: m2300w uploaded to Debian included most (if not all) your changes.
[16:30] <apw> slangasek, about?  you helped do the multiarch conversion on the kernel headers.  am trying to work out how the include paths are modified for a build when multiarch is in play
[16:32] <slangasek> apw: on the phone, but what's the issue?
[16:34] <apw> slangasek, i have a build which includes asm/posix_types.h (i believe) and that is found in /usr/include/i386-linux-gnu/asm/posix_types.h just fine.  it includes "posix_types_32.h" which then fails, this file is in the same directory
[16:35] <apw> note is uses the #include "x" syntax
[16:35] <slangasek> apw: is this a kernel build failing?
[16:36] <slangasek> shouldn't be if it's looking at /usr/include, yah?
[16:38] <apw> slangasek, this is a gnat compilation, it is using the linux-libc-headers (which are multiarch now), includes something which #includes <linux/posix_types.h> which in turn includes <asm/posix_types.h> which works, which in turn includes "posix_types_32.h" which does not
[16:38] <apw> where the last two are in the same directory
[16:39] <apw> so in part i am trying to work out how it even finds the asm stuff, i am presuming that we have -I/usr/include -I /usr/include/<multi-arch-tuple> on the default options ?
[16:40] <slangasek> apw: right, I think doko was looking at the gnat issue already - it's because of the use of #include "posix_types_32.h" instead of #include <asm/posix_types_32.h>, combined with a particular cpp option that gnat is passing
[16:41] <slangasek> the /usr/include/, /usr/include/<multiarch> are the built-in gcc/cpp path
[16:41] <apw> slangasek, ok so this combination works ok in the normal run of the mill compilations, so as you say it must be gnat specific
[16:41] <apw> slangasek, what option is it using?
[16:41] <doko> no, it's specific to -I-
[16:42] <slangasek> but gnat is passing the -I- option that causes "" #includes to *not* use the default behavior of looking in the same directory as the parent include
[16:42] <apw> ok which means what ?
[16:42] <apw> and we think its reasonable for us to cope with that ?
[16:42] <slangasek> apw: the kernel headers should work even when -I- is used - i.e., all includes should be #include <path/header.h>, not #include "header.h"
[16:43] <apw> well it'd have saved me a bunch of time if any of this was in the bug
[16:45] <apw> slangasek, thanks for the help, will go poke it
[16:45] <slangasek> apw: ok, thank you :)
[16:46] <slangasek> apw: fwiw, seems there are only two affected headers: unistd.h, posix_types.h
[16:46] <tseliot> slangasek: are you ok with my changes ^^
[16:46] <slangasek> (grep '#[[:space:]]*include[[:space:]]\+"' /usr/include/i386-linux-gnu/asm/*)
[16:47] <slangasek> tseliot: sorry, missed the highlight!  let me see
[16:47] <apw> slangasek, will have a poke about, we'll need to get this mantra fixed upstream
[16:47] <tseliot> slangasek: thanks
[16:50] <slangasek> tseliot: this is the SRU that's been uploaded?
[16:54] <tseliot> slangasek: yes, the nvidia-common in natty-proposed is the one I mentioned in my SRU request
[16:58] <slangasek> tseliot: the upload seems to include changes unrelated to this bug (e.g., the multiarch class) - that doesn't appear to be consistent with the SRU rules
[16:58] <slangasek> tseliot: could you please cherry pick the upgrade-breaking bugfix?
[17:00] <tseliot> slangasek: I had thought about doing that but ok. Do you mind if I also disable the kernel hook and the debconf interface (to be sure that the fix covers all cases)?
[17:02] <tseliot> slangasek: the actual fix is just two lines of python code but I'd really feel more comfortable having these 2 things disabled/removed too ^
[17:03] <tseliot> this is the python fix: https://github.com/tseliot/nvidia-common/commit/fb38f30927173e45ead1c3d45afe6548d66c8eb1
[17:04] <SpamapS> Hrm.. sponsor-patch should be able to figure out that I want to sign things with my default key..
[17:05] <Drakeson> [rant] Has this lightdm thing heard of a cursor?  [I feel better now!]
[17:05] <tseliot> slangasek: and the other two changes that I mentioned are: https://github.com/tseliot/nvidia-common/commit/1cdb3ea13d912a9d28793d978c3173a8cb47a67d and https://github.com/tseliot/nvidia-common/commit/c025b9a57d0d2b2d93360ecc2b4ec8837db7a400
[17:10] <slangasek> tseliot: for removal of obsolete config files, we normally want to preserve any local changes the user might have made; unless there's a specific reason you believe no one would ever care about keeping a copy of local changes they might have made to this script, please see dpkg-maintscript-helper(1)
[17:11] <slangasek> (and please pay close attention to the pre-depends: requirement if you use this interface)
[17:11] <slangasek> tseliot: what's the rationale for getting rid of the debconf interface?
[17:12] <slangasek> pitti: it is incredibly frustrating that a bug filed 16 hours ago has been closed invalid by the retracer because "some outdated packages were installed on [my] system at the time of the report".
[17:13] <slangasek> pitti: actually, it seems most of what it complains about is *debugging symbol packages* being out of date - are we having a ddeb problem? https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/832454/comments/5
[17:13] <seb128> slangasek, well it's the reality
[17:14] <tseliot> slangasek: it was meant to deal with the transition from some rather old nvidia driver packages (back when we still used diversions instead of alternatives) to new package names when users dist-upgraded from the command line. Now I don't think we need it any more. The debconf interface simply warned users when the old package were still installed
[17:14] <seb128> slangasek, no we don't, we just got a new gnome-settings-daemon between the time you sent your bug and the retracing
[17:14] <tseliot> I didn't know dpkg-maintscript-helper though...
[17:19] <slangasek> seb128: we got *lots* of new things between the time it was sent and the time the retrace happened; a 16-hour queue for retracing doesn't seem unrealistic even under normal circumstances, and having the retracer throw it out instead of pulling the old binary to get a backtrace makes for a really poor experience, especially on a bug like this that has literally been happening on my system daily for the past month
[17:20] <slangasek> I understand the need to turf bugs that you're not going to get to, but the retracer's current behavior effectively makes it a waste of my time to file these with apport instead of getting the backtrace myself
[17:20] <slangasek> anyway, there's also the output there saying that dbgsym packages are out of date, which is worrisome
[17:21] <broder> i thought that there was no way to get ddebs for superceded packages
[17:22] <slangasek> I don't think the ddeb archive is even that smart - I thought it expired ddebs based on age
[17:22] <slangasek> (it really needs to get integrated into LP...)
[17:23]  * slangasek upgrades gnome-settings-daemon, so that the next time it crashes he has a shot at getting it retraced
[17:24] <tkamppeter> OdyX, thanks. About which of my changes are you in doubt whether you have included them?
[17:25] <tseliot> slangasek: but, if you prefer, I'll pull in only the 2 lines fix. We're still going to get some unexplainable crashes when the kernel hook (and its debconf interface) kicks in though.
[17:27] <slangasek> tseliot: it's fine to include those, just please use dpkg-maintscript-helper to properly dispose of the conffile
[17:27] <broder> slangasek: that can't be right - there are still packages in the ddebs archive from the lucid release pocket
[17:28] <tseliot> slangasek: ok, please reject my upload and I'll correct my changes tomorrow. Thanks for your help
[17:30] <slangasek> tseliot: done, thanks
[17:30] <slangasek> broder: perhaps I was misinformed then
[17:39] <stgraber> @pilot in
[17:40] <stgraber> Please note that I'm unfortunately quite busy with other things (getting Edubuntu in shape by tomorrow) so I'll do my best to go through the queue today or tomorrow morning (splitting my shift in two).
[17:40] <stgraber> If you have anything you want to see reviewed very quickly, please feel free to ping me on IRC and I'll stop doing Edubuntu stuff and process it immediately. Thanks!
[18:36] <mterry> Is anyone particularly familiar with trapping TERM signals in sh?
[18:37] <broder> vaguely? what are you trying to do?
[18:37] <mterry> I've got an sh script that traps TERM and echos, and works when I send the signal from within the script, but sending the signal in a different terminal just gets dropped (doesn't end, doesn't echo)
[18:39] <mterry> broder, see for example, http://pastebin.ubuntu.com/674038
[18:39] <broder> mterry: i think it doesn't catch the signal until the sleep returns
[18:39] <broder> i was just testing an ~identical script, but mine was just sleep 5
[18:39] <broder> i bet sleep is a bash builtin?
[18:40] <broder> hmm, maybe not
[18:40] <mterry> broder, if I change sleep to something like, xterm, same behavior
[18:40] <broder> if you close the xterm, does it get the signal?
[18:41] <mterry> broder, yes.  Also if I press ctrl+c (which is also trapped for testing), it will get the 'queued' TERM
[18:44] <infinity> mterry: I'm assuming it works if you TERM the sleep instead of the shell?
[18:46] <infinity> mterry: Oh, or not.
[18:46] <mterry> infinity, yeah, nope
[18:46] <broder> mterry: it kind of looks like it might just be a limitation in bash's signal handling
[18:46] <broder> it's probably a reentrancy issue
[18:46] <infinity> Oh, no, that's just cause sleep doesn't die on TERM. :P
[18:47] <apw> does anyone know if it is safe to install grub2 into a chroot
[18:47] <mterry> infinity, mine did (note that my sample script will loop again and start new sleep if it's killed).  I also tried with xterm, same result (it dies, but script doesn't catch signal)
[18:48] <mterry> broder, so you're thinking trapping TERM in sh just won't work?  (note that dash and bash both seem to have this bug then -- I tried both)
[18:48] <broder> mterry: i think it won't work until the child process exits
[18:49] <infinity> Anyhow.  A shell's only job when you run a foreground command is to waitr for it to exit.
[18:49] <infinity> mterry: What you want to do for that sort of job control is background your processes and then wait on them.
[18:49] <infinity> mterry: Then the shell is "active", and can process your signals.
[18:50] <broder> infinity: i tried stracing the shell. the wait4 call is interrupted, and then there's an rt_sigreturn call, then it goes back into wait4
[18:50] <infinity> Raplacing the while loop with:
[18:50] <infinity>   sleep 60 &
[18:50] <infinity>   wait
[18:51] <infinity> Does as mterry wants.
[18:51] <infinity> (ie: the parent shell will now process SIGTERM)
[18:51] <broder> is it relevant whether the shell has the controlling terminal?
[18:51] <mterry> infinity, ah, yes.  thanks!  I think that's what I want
[18:52] <infinity> broder: Nope.
[18:53] <infinity> mterry: Keep in mind that if your TERM handler is exiting the shell, it will happily leave the children running, so you need to clean them up too.
[18:53] <infinity> mterry: But every time you background a process, you can grab the PID and keep track of them for such control.
[18:53] <mterry> infinity, yes, thanks
[18:56] <highvoltage> cjwatson: congratulations!
[19:22] <seb128> re
[19:23] <seb128> slangasek, well, a  16 hour queue is unusual if the retracers are running and usually doesn't invalidate a retracing
[19:23] <seb128> slangasek, the bug are closed only if the stacktrace generated by the retraced is a junk one
[19:24] <seb128> having ddebs support in soyuz would be nice but wouldn't solve the issue, usually package index only have the current version, not the n previous ones
[19:25] <seb128> well, I'm not saying that invalid retracing are not annoying and an issue but in practice they are not problematic when the retracers are not down for 3 weeks like it just happened
[19:26] <seb128> hopefully with pitti's refactoring they will be robust now
[19:45] <tkamppeter> Can someone finalize bug 822587 ([MIR] icc-profiles-free) by seeding it into main or making it a dependency or at least Recommended: in an appropriate package, so that it gets into beta1?
[19:51] <seb128> stgraber, hey, do you think you could review https://code.launchpad.net/~gunnarhj/language-selector/type-error/+merge/72755 and upload if it's good? gunnar was looking for a sponsor before
[19:51] <seb128> (just saw that you are piloting)
[19:52] <seb128> stgraber, with maybe https://code.launchpad.net/~rodrigo-moya/language-selector/show-in-new-g-c-c/+merge/72737 if you do an upload of the source ;-)
[19:54] <stgraber> seb128: ok, I'll have a look at these
[19:54] <seb128> stgraber, thanks
[20:08] <bdrung> tumbleweed: can we please have test cases for syncpackage?
[20:09] <tumbleweed> bdrung: I think there's too much launchpadlib in it for many
[20:10] <tumbleweed> (also it's a script, so it's not importable)
[20:10] <Combatjuan> I built a new kernel as per the Ubuntu wiki using the "old-fashioned debian way".  When it boots with the new kernel, it sits for ~1 minute starting up and then drops to initramfs.  My menu.lst uses the same command line with the new kernel as with the old ones (except the kernel to use, obviously).
[20:11] <Combatjuan> It complains that the /dev/disk/by-uuid/XXXYYY does not exist, but the rootdelay and root are the same as kernels that work fine.  I'm not sure how to troubleshoot this.
[20:11] <bdrung> tumbleweed: we need a good stub for launchpadlib
[20:12] <bdrung> tumbleweed: writing the first test case will take some time, but it will give us the time back in the future
[20:12] <tumbleweed> I agree there
[20:12] <bdrung> tumbleweed: having test cases makes accepting new code easier
[20:12] <bdrung> tumbleweed: e.g. i found another bug
[20:12] <bdrung> $ syncpackage packaging-dev
[20:12] <bdrung> syncpackage: Error: Version in Debian 0.1.1 (unstable) isn't newer than Ubuntu 0.1.1 (None)
[20:12] <Combatjuan> It claims that "/dev/disk/by-uuid/XXXYYY...." doesn't exist.  It turns out that /dev/disk doesn't even exist.  Is that a good clue?
[20:12] <bdrung> -> None?
[20:16] <cjwatson> highvoltage: thanks!
[20:17] <cjwatson> apw: grub-pc-bin might be what you want
[20:17] <cjwatson> apw: (ships the binaries but doesn't own the boot sector)
[20:18] <Chipzz_> cjwatson: grats (on both accounts)! :)
[20:21] <tumbleweed> bdrung: that (and a related bug I just noticed) isn't an issue with my merges, I'll prepare a separate merge for that
[20:25] <tumbleweed> bdrung: meh, actually it'll conflit with the bug closing branch, I'll do it there. I'm also tempted to try and get changelog entries out of launchpad rather than packages.debian.org (it'll make testing against qastaging way easier)
[20:42] <tumbleweed> bdrung: meh, that was a wild goose chase. I've already fixed that bug and the one I thought I saw was a package I maintain being removed from Ubuntu without me noticing :)
[20:52] <ahasenack> guys, this error is driving me crazy, I'm certainly missing something obvious: dpkg-source: error: cannot represent change to meliae-0.4.0/meliae/__init__.pyc: binary file contents changed
[20:52] <ahasenack> here is some info:
[20:52] <ahasenack> http://pastebin.ubuntu.com/674132/
[20:54] <ahasenack> I grabbed an existing debian/* structure and am trying to clean it up, so some bits I haven't touched yet like that PYVERS stuff
[20:54] <ahasenack> if I drop the orig.tar.gz from the parent directory, the build proceeds, but it creates a native package and a new tarball of course
[21:07] <james_w> ahasenack, has that file been deleted?
[21:07] <ahasenack> hmmmm
[21:08] <james_w> ahasenack, if it's in the tarball you can't delete it
[21:08] <ahasenack> james_w: that file (pyc) doesn't exist in the tarball
[21:08] <ahasenack> james_w: I just found out that it was being created in the clean target, by "python setup.py clean"
[21:08] <ahasenack> or so I think
[21:08] <james_w> ah, that would do it
[21:08] <james_w> clean should remove those files
[21:09] <ahasenack> james_w: funnt that setup.py clean actually creates one :)
[21:09] <james_w> yeah
[21:09] <ahasenack> the only reason I was overriding clean was to remove the *.so files
[21:09] <james_w> I suspect it's got an "import meliae" to get the version
[21:09] <ahasenack> setup.py from upstream doesn't handle that
[21:10] <ahasenack> james_w: exactly,
[21:11] <ahasenack> james_w: success \o/
[21:11] <ahasenack> got a v3 source package built
[21:39] <ahasenack> I'm backporting a package version 0.4.0-1 to lucid, and will upload it to a ppa. Does this version look ok for this case: 0.4.0-1~lucid1~ppa1 ?
[21:40] <tumbleweed> ahasenack: sounds good (backportpackage in ubuntu-dev-tools does that automatically for you)
[21:41] <ahasenack> tumbleweed: cool, thanks. I tried that tool once, but in lucid it doesn't exist (or doesn't work, I can't quite remember)
[21:41]  * ahasenack on lucid
[21:41]  * ahasenack bookmarks https://help.ubuntu.com/community/UbuntuBackports
[21:42] <tumbleweed> yeah the u-d-t PPA build for lucid is waiting on the dh_python2 backport
[21:42] <ahasenack> ah, dh_python2 will be backported? nice
[21:42] <tumbleweed> ...at some point...
[21:42] <ahasenack> but it's part of the python package in oneiric, so will there be a new python package for lucid or will it be part of some other package?
[21:43] <tumbleweed> it involves changes to python-defaults, yes (whichis probably why nobody has done it)
[21:43] <ahasenack> hehe
[21:44] <slangasek> seb128: right, soyuz only keeps the latest file, but the librarian would keep more... which would make it possible to get backtraces on old executables, and let a lot of these "invalid" bugs get relabelled as duplicates
[21:45] <bdrung> tumbleweed: can you add an TODO item to the code and point to bug #833384?
[21:46] <tumbleweed> sure
[21:46] <seb128> slangasek, well I guess it would be "just a matter of adding the librarian logic"
[21:46] <slangasek> yep :)
[21:46] <seb128> slangasek, but at the same time I'm not sure how much extra bugs on old deprecated version we want
[21:47] <seb128> the experience is suboptimal for submitters but for our side we don't miss anything
[21:47] <slangasek> sure, I understand that
[21:47] <slangasek> but the collateral damage is high
[21:47] <slangasek> no, it *does* cause bugs to be missed
[21:47] <seb128> like you can be sure that frequent segfaults will be reported and retraced
[21:47] <slangasek> right, but not consistently throughout the cyle
[21:47] <slangasek> cycle
[21:47] <seb128> well, sure, instead of getting 260 bugs a day we get 90 bugs
[21:47] <seb128> we still read only 15 of those
[21:48] <slangasek> as I said, this g-s-d crash has been happening to me for a month; I guess I'll know tomorrow if it's still there in the new upstream version
[21:48] <seb128> what we really need is that database out of launchpad
[21:48] <seb128> slangasek, I'm ready to bet it's a dup of one of those bugs that get 15 duplicates a day
[21:48] <slangasek> maybe so. if the retracer had processed it, we would know for sure ;)
[21:49] <seb128> and we wouldn't be able to open the master bug because launchpad would timeout on it :p
[21:49] <slangasek> hmm, well, at that point we have bug patterns...
[21:50] <slangasek> but yeah, point taken
[21:50] <seb128> slangasek, let's say with you I agree on the sentiment and other do
[21:50] <seb128> we really need a database out of launchpad
[21:50] <seb128> handling of those in launchpad is suboptimal for several reasons
[21:50] <slangasek> the crash database?
[21:50]  * slangasek nods
[21:50] <seb128> yes
[21:51] <seb128> it's creating lot of email spam and noise and adding constrain on the quality of what we collect
[21:51] <seb128> if that was out of the bug tracker we could just collect infos there
[21:56] <seb128> 'night
[22:01] <Daviey> tumbleweed: Having the changelog via API isn't as exciting as having publish information via API.
[22:02] <Daviey> (for Debian)
[22:02] <tumbleweed> you mean not having everything "Pending"?
[22:02] <Daviey> tumbleweed: yeah
[22:02] <tumbleweed> that wolud be rather nice :)
[22:03] <Daviey> I *think* i raised a bug about that.. or at least discussed it
[22:04] <tumbleweed> Daviey: it's rather fun trying to test things against 2 month old qastaging snapshot when you are getting current changelogs from Debian which disagree :)
[22:05] <Daviey> happy happy joy joy
[22:41] <cjwatson> any of the ubuntu-devel moderators know who approved https://lists.ubuntu.com/archives/ubuntu-devel/2011-August/034011.html ?
[22:41] <cjwatson> it contains at least one incredibly offensive insinuation, and in general it's a paranoid rant that I'm not sure belongs on our lists
[22:42] <cjwatson> I think approving it for ubuntu-devel was a mistake
[22:44] <slangasek> oh, did that get cross-posted to ubuntu-devel?  I didn't notice which lists I was deleting-unread on
[22:45] <stgraber> @pilot out
[22:49] <davidm> cjwatson, I shudder any time Luke Kenneth Casson Leighton gets on his soap box
[22:50] <davidm> Nice guy but he does have some interesting points of view
[22:51] <cjwatson> bringing a suicide victim into it is a new low in terms of taste
[22:51] <cjwatson> astoundingly inappropriate
[22:52] <slangasek> oh sigh
[22:53] <cjwatson> I'm very tempted to knee-jerk ban but I'm too personally involved
[22:53] <infinity> I haven't gotten that far...
[22:55] <infinity> Okay, wow.  That's just beyond tasteless. :/
[22:57] <soren> cjwatson: I didn't approve it, but had I seen it come through, I probaby would have. At a glance, it looks on-topic (in the sense that it's a non-spam response to an existing thread).
[22:57]  * soren starts reading
[22:58] <infinity> soren: Don't.  You'll hate yourself for doing so.  Especially the low point that Colin mentions. :/
[22:59] <soren> infinity: I'm a sucker for this sort of thing.
[22:59] <soren> infinity: And I think I need to read something frustrating that isn't aimed at me for once.
[23:00] <infinity> soren: Suit yourself.  I kinda want to go punch concrete a bit right now.  Normally, the only effect he has on me is the perfectly rational urge to punch HIM.
[23:00] <infinity> And I think I may have just stepped a few meters over the CoC line myself there, so I'll shut up. :P
[23:00] <infinity> cjwatson: If there was any way to undeliver it, I'd be all for it.  Sadly, removing it from the archives won't do much.
[23:01] <ajmitch> infinity: having read it, I can understand the frustration
[23:02] <infinity> cjwatson: Banning lkcl from posting follow-ups won't hurt my feelings, though.
[23:02] <infinity> cjwatson: Then again, I'm about as personally affected as you, for very different reasons.  So... :/
[23:03]  * soren starts to understand what the fuss is all about
[23:05]  * soren stops