[00:18] <slangasek> lamont: poking at the libmount code, I'm reasonably convinced it's a bug rather than a feature given the amount of code related to the mtab that *does* get called
[00:18] <slangasek> lamont: but I've yet to find the actual bug :P
[00:48] <lifeless> bryceh: ping
[00:53] <bryceh> lifeless, yes
[00:53] <lifeless> bryceh: hi
[00:53] <lifeless> bryceh: can you join #launchpad-ops (internal) for a bit ?
=== dmb is now known as ]dmb[
=== ogasawara_ is now known as ogasawara
=== hunger_ is now known as hunger
[09:14] <jelmer> doko, slangasek: making some progress on the one-time import; 14k out of 26k left at the moment
[09:16] <\sh> hmm...why is the global menu bar missing from gvim now since the last unity update on natty...strange
[09:17] <slangasek> jelmer: whee :)
[09:24] <geser> \sh: are you perhaps affected by bug 776499?
[09:24] <ubottu> Launchpad bug 776499 in vim (Ubuntu) "gvim gets no global menu, timeout warning on the console" [Undecided,Confirmed] https://launchpad.net/bugs/776499
[09:25] <\sh> geser, dunno, because I don't see any menubar on gvim anymore...before the last unity update this was working
[09:26] <\sh> and no...I don't even get the console message the people are talking about
[09:26] <\sh> but gvim -f helps
[09:26] <slangasek> jelmer: is there a bzr-svn package update pending for oneiric?
[09:28] <jelmer> slangasek: Yes, but it's blocked by a strange interaction with libapr/iconv that makes the testsuite segfault
[09:31] <slangasek> jelmer: do you have a log?
[09:35] <slangasek> jelmer: or, a pointer to the package currently failing?
[09:35] <jelmer> slangasek: It should be reproducable by building http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable in a sid chroot
[09:39] <jelmer> slangasek, I'll see about filing a bug about it, so the rest of the world is also aware of it.
[09:43] <slangasek> jelmer: got it, cheers
[09:49] <jelmer> slangasek, https://bugs.launchpad.net/subvertpy/+bug/803353
[09:49] <ubottu> Ubuntu bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged]
[09:52] <slangasek> jelmer: btw, I think there's a missing breaks: bzr-builddeb or something in the latest bzr, because natty->oneiric upgrade warned me about bzr-svn, but let bzrlib get upgraded out from underneath, breaking things
[09:53] <jelmer> slangasek, unlike bzr-svn, which relies more on bzr internals, bzr-builddeb should work with multiple bzr series
[09:53] <pitti> kees, jdstrand: published linux-meta-mvl-dove linux-mvl-dove to lucid-u/s, for bug 802554
[09:53] <slangasek> jelmer: well... it didn't :-)
[09:53] <ubottu> Launchpad bug 802554 in linux (Ubuntu) "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/802554
[09:54] <jelmer> slangasek: that's the theory though, if something's breaking it should be fixed :)
[09:54] <slangasek> jelmer: natty bzr + oneiric bzrlib + oneiric bzr-builddeb, and bzr bd fails with an internal error
[09:54] <pitti> kees, jdstrand: with the automated emails being sent now, and me changing te status on the tracker bug, do you actually need/want me to ping you on IRC about this?
[09:54] <slangasek> jelmer: where should I file the bug?
[09:54] <pitti> kees, jdstrand: sorry, bug 794695
[09:55] <ubottu> Launchpad bug 794695 in Kernel SRU Workflow "linux-mvl-dove: 2.6.32-217.34 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/794695
[09:55] <kees> pitti: it's nice to get the ping, but I don't think it's required any more. if you happen to remember, that's fine
[09:56] <jelmer> slangasek: ubuntu/bzr I think
[10:10] <slangasek> jelmer: bug #803362
[10:10] <ubottu> Launchpad bug 803362 in bzr (Ubuntu) "partial upgrade to oneiric (to keep bzr-svn installed) bails with bzr bd -S" [Undecided,New] https://launchpad.net/bugs/803362
[10:11] <jelmer> slangasek: thanks
[10:12] <jelmer> slangasek: Ah, sorry - I misunderstood. You're right, this is indeed a missing Breaks
[10:49] <RAOF> kees: Is security looking at bug #657598 ? It's proposed as an sru but looks like a security fix.
[10:49] <ubottu> Launchpad bug 657598 in g15daemon (Ubuntu Natty) "g15macro crashes with buffer overflow" [Undecided,Confirmed] https://launchpad.net/bugs/657598
[10:52] <micahg> RAOF: it's not a security issue per say since it crashes on startup
[10:52] <micahg> *per se
[10:53] <RAOF> micahg: So we'll accept that as an SRU then?
[10:54] <micahg> RAOF: if the SRU team thinks it's worth it, why not?
[10:54] <RAOF> Right.
[10:57] <kees> RAOF: right, what micahg said :) I've added a note to the bug now just to clarify
[11:01] <siretart> Laney: please consider merging http://bazaar.launchpad.net/~siretart/+junk/transition-tracker.libav/revision/106, I had to bump libswscale's soname again very close before the final 0.7 release
[11:02] <siretart> or anyone else with access to the branch
[11:08]  * micahg congratulates RAOF on becoming a member of the SRU team
[11:19] <cjwatson> zul: well, er, thanks for uploading image-store-proxy, but you didn't fix the test failure that was the reason I didn't just upload it myself ...
[11:19] <zul> cjwatson: damn it sorry about that
[11:21] <barry> zul, cjwatson i set bug 802402 back to confirmed state
[11:21] <ubottu> Launchpad bug 802402 in image-store-proxy (Ubuntu) "convert to dh_python2" [Undecided,Confirmed] https://launchpad.net/bugs/802402
[11:21] <Laney> siretart: not easily since my PC is offline due to a house move
[11:22] <Laney> someone else can though
[11:22] <doko> RAOF: mesa/llvm ping
[11:23] <barry> cr3: you will hate me now: checkbox :)
[11:23] <barry> cr3: it's the last desktop cd package that needs conversion from python-central (bug 788514)
[11:23] <ubottu> Launchpad bug 788514 in Ubuntu Oneiric "python packages on the CDs not using dh_python2" [Medium,Confirmed] https://launchpad.net/bugs/788514
[11:47] <slangasek> wendar, barry, ScottK: wrt python2.7 in Debian and the transition tracking: for ignorable issues on packages not in testing (only in stable, unstable), is it preferred to remove the dex usertag, or to remove it from the 'blocks' list?
[11:47] <kees> pitti: can you check the components for linux-mvl-dove lucid? it seems to have gone into universe instead of main
[11:47] <pitti> *sigh*
[11:47] <kees> pitti: e.g. http://ports.ubuntu.com/pool/universe/l/linux-mvl-dove/ vs http://ports.ubuntu.com/pool/main/l/linux-mvl-dove/
[11:47] <pitti> kees: I'll promote it
[11:47] <kees> pitti: well, can you double-check?
[11:48] <kees> pitti: I *think* it hsould be in main. the others have been, but perhaps all of those are mistakes too?
[11:48] <pitti> they were in main in the final release
[11:48] <kees> I see a history of 2.6.32-2xx in main, but we should make sure
[11:49] <pitti> hmm
[11:49] <pitti> that's for lucid or maverick?
[11:49] <pitti> I see some -di modules in universe
[11:49] <pitti> https://launchpad.net/ubuntu/+source/linux-mvl-dove/+publishinghistory says "main", too
[11:49] <kees> I'm looking at lucid linux-mvl-dove. whatever the components were for release is what it should be for -security
[11:49] <cjwatson> there's a nascent pocket-mismatches script in ~lp_archive/dak/ that you can use to analyse this kind of thing
[11:50] <cjwatson> observe the hideous pile of output
[11:50] <pitti> ah, right; so these -di modules were in main for the release, but aren't any more
[11:51] <pitti> so that was apparently mis-binNEWed
[11:56] <pitti> kees: fixed
[11:57] <kees> pitti: thanks!
[11:58] <cjwatson> at the risk of being a broken record: people need to use kernel-overrides when binNEWing kernel packages
[11:59] <cjwatson> pitti: language-pack-ky-base seems to be out of date: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/edubuntu-dvd/latest/livecd-20110629-i386.out
[12:02] <evfool> what's the difference between a debian ITP and RFP?
[12:02] <pitti> language-pack-kde-ky | 1:11.10+20110627 |       oneiric | source, all
[12:02] <pitti> cjwatson: ^ hmm
[12:02] <StevenK> ITP == Intent To Package -- I will do it.
[12:02] <pitti> language-pack-kde-ky-base | 1:11.10+20110623 |       oneiric | source, all
[12:03] <StevenK> RFP == Request For Package -- someone else, please do it.
[12:03] <pitti> cjwatson: oh, indeed -- madison on cocoplum has the new one, but rmadison doesn't
[12:04] <pitti> according to LP it was published 3 days ago
[12:07] <seb128> janimo, ogra_: could somebody look at the json-glib armel ftbfs?
[12:07] <seb128> it's make the new libdbusmenu depwait on armel and the new indicator stack picked depends on the old libdbusmenu soname
[12:08] <janimo> seb128, will check
[12:08] <seb128> thanks
[12:09] <evfool> thanks StevenK, the debian site description doesn't define them that nice :)
[12:42] <sveinse> How can I create a debian package without any content (but with dependencies)? I know how to do that for a normal package, but I dont know how to build it without having any software to put into it. Any pointers please?
[12:43] <tsimpson> just create an empty <project>/ dir and create <project>/debian/
[12:46] <sveinse> Thanks. Obvious really
[12:48] <cjwatson> pitti: huh, ok
[12:54] <ScottK> slangasek: Unless it's an RC issue in and of itself (so we can be sure the package will stay out of Testing) I think just drop the DEX tag.
[12:57] <slangasek> ScottK: these are all RC issues that I'm referring to
[12:58] <ScottK> slangasek: Then I think they don't need to block.
[12:59] <sveinse> Is it possible to configure dpkg-buildpackage/debuild to use other file than Makefile for building the upstream source?
[12:59] <slangasek> ScottK: righty-o.  do you have the transition bug # handy? (bts being slow)
[12:59] <ScottK> No.  Sorry.
[12:59] <slangasek> k
[13:00] <ScottK> sveinse: debian/rules is the make file that is used.  It may call an upstream make file, it may not.  Depends on what's in it.
[13:11] <sveinse> ScottK: I'm using the default %:   dh $@, so dh must be assuming a Makefile in ../ (relative to the debian dir)
[13:11] <ScottK> Yes, but you can override this.
[13:13] <sveinse> How? I couldn't find any mention of it in man dh
[13:15] <ScottK> These examples are very Perl specific, but ought to give you an idea: http://pkg-perl.alioth.debian.org/debhelper.html
[13:16] <sveinse> excellent, thanks
[13:16] <sveinse> A bit more tedious than I hoped for, but I get the idea
[13:17] <Laney> if you want to build from a different directory then there's -D to the various dh_auto tools
[14:03] <cjwatson> sveinse: dh won't use a Makefile if there isn't one
[14:04] <cjwatson> sveinse: if all you need to do is install some files, it's more usual to use debian/*.install files (see 'man dh_install')
[14:05] <siretart> cjwatson: please consider merging http://bazaar.launchpad.net/~siretart/+junk/transition-tracker.libav/revision/106, I had to bump libswscale's soname again very close before the final 0.7 release
[14:06] <sveinse> cjwatson: Yes. In my case, the top level Makefile is autogenerated, and thus I can't change it to do make install into $DESTDIR, so I planned on writing a small Makefile.debian to wrap the build & install process. But when I come to think of it, I can do this wrapping within debian/rules
[14:06] <cjwatson> siretart: done
[14:07] <cjwatson> override_dh_auto_install:
[14:07] <cjwatson>        # either just a comment, or do what you need instead
[14:07] <cjwatson> sveinse: ^-
[14:07] <sveinse> thanks
[14:07] <siretart> cjwatson: thanks
[14:08] <sconklin> pitti: could you please copy natty from the kernel ppa to -proposed when you can? Sorry to nudge you, but this should fix the problems that a lot of people are seeing here at the rally
[14:08] <cjwatson> Makefile.debian would not usually be an idiomatic thing to do, no
[14:08] <pitti> sconklin: oh, sure; I noticed it on pending-sru, but there was no workflow task assigned, so I wasn't sure I was supposed to
[14:09] <sconklin> The workflow bot should have just ticked the tasks over about 5 mins ago
[14:09] <pitti> sconklin: oh, actually there is now
[14:09] <sconklin> pitti: thanks!
[14:10] <pitti> sconklin: done
[14:27] <pitti> tseliot: I committed your nvidia multiarch patch, seems to work fine on my fake intel testing; thanks!
[14:28] <pitti> tseliot: I get a crash in NvidiaDetector/alternatives.py set_alternative(), looking into that now; but enabled() now gives the correct results
[14:28] <tseliot> pitti: np. I can do the same for fglrx
[14:28] <tseliot> pitti: if you show me the crash I can fix it
[14:29] <pitti> tseliot: http://paste.ubuntu.com/635026/ -> happens when I enable or disable nvidia
[14:29] <pitti> 2011-06-29 14:26:43,099 DEBUG: NVidia(nvidia_current).enabled(): target_alt None current_alt /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf
[14:30] <pitti> tseliot: prsumably it tries to pass None as an argument?
[14:30] <tseliot> pitti: that None looks suspicious, I'll check the code
[14:30] <pitti> tseliot: I'll add a debugging line for other_open_drivers
[14:30] <tseliot> thanks
[14:35] <pitti> tseliot: right, as I suspected
[14:35] <pitti> 2011-06-29 14:35:34,609 DEBUG: NVidia.disable(nvidia_current): open_drivers: /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
[14:35] <pitti> 2011-06-29 14:35:34,938 DEBUG: NVidia.disable(nvidia_current): other_open_drivers: None
[14:36] <pitti> tseliot: should the nvidia driver just not call self._other_alternatives.set_alternative(other_open_drivers) if it's none?
[14:36] <simon-o> Hi, I tried to build a oneiric package for natty using a build recipe: https://code.launchpad.net/~simono/+recipe/scala-natty but this didn't work: https://code.launchpad.net/~simono/+archive/personal/+recipebuild/55045 Any ideas why it failed?
[14:36] <pitti> tseliot: or should set_alternative be robust with that?
[14:36] <micahg> simon-o: I think you want #ubuntu-packaging
[14:36] <pitti> tseliot: I'll add a None test for now
[14:37] <simon-o> micahg, right, thanks
[14:37] <RAOF> doko: Pong re: mesa/llvm.  Are you in the foundations room?
[14:37] <slangasek> RAOF: he's next door w/ me at the moment, but we'll be over there soon
[14:38] <RAOF> slangasek: Over here in the desktop room?
[14:38] <RAOF> Or over there in the foundations room?
[14:39] <slangasek> RAOF: over there in the foundations room
[14:40] <seb128> RAOF, they are the ones having issues, they should be the one moving to us :p
[14:40] <pitti> well, disk space is not really an one-team problem
[14:41] <seb128> pitti, see the ":p"
[14:41] <seb128> ;-)
[14:42] <pitti> tseliot: ok, working fine now; I'll commit the None check
[14:42] <doko> RAOF: in 5min
[14:43] <tseliot> pitti: right other_open_drivers can be None, that's what I forgot to handle. Good catch
[15:13] <cr3> barry: guess what I'm doing?
[15:17] <cr3> barry: question for you: the new package contains python files under ./usr/lib/python2.6/dist-packages/ and ./usr/lib/python2.7/dist-packages/ in addition to ./usr/share/pyshared/ whereas the old package only contains files under the latter directory.
[15:17] <cr3> oddly, this doesn't seem to affect the resulting size of the package much... viva compression
[15:18] <ScottK> cr3: Did you just switch it to use dh_python2?
[15:18] <cr3> ScottK: yes, is that expected behavior?
[15:18] <ScottK> The /usr/lib ... are symlinks.
[15:19] <cr3> ScottK: ah, my mistake, I was looking at the output of dpkg -c | awk '{print $6}'... thanks!
[15:19] <ScottK> This is expected.
[15:19] <ScottK> pysupport/central would generate these symlinks at install time.
[15:19] <ScottK> Including them in the package is better.
[15:25] <jelmer> doko, slangasek: lp:~jelmer/gcc/gcc-4.6-import is up now
[15:31] <cr3> pitti: I'm planning to increase the size of the checkbox deb by 169Kb, is that alright?
[15:31] <cr3> bladernr: ^^^ thought you might be interested
[15:34] <cr3> barry: checkbox-gtk depends on gir1.2-gtk-3.0; however: Package gir1.2-gtk-3.0 is not installed.
[15:38] <cr3> barry: I'm not sure I understand why though, the depends and recommends line look the same
[15:46] <slangasek> jelmer: and can that be pushed to lp:gcc?
=== smb` is now known as smb
[15:48] <barry> cr3: hi.  hmm, i'm not sure why either, since i didn't touch those parts
[15:48] <barry> cr3: what room are you in?  maybe i can come down and pair with you?
[15:49] <cr3> barry: my mistake, I'll get back to you shortly
[15:49] <barry> cr3: cool!
[15:49] <cr3> barry: give me a moment before running around, I wouldn't want you to see me screw up in person :)
[15:49] <pitti> cr3: shold be okay; but thanks muchly for caring!
[15:52] <cr3> pitti: awesome, thanks for the confirmation :)
[16:11] <BenC> Any good ubuntu coders looking for work (fulltime/telecommute/mpeg/rtsp/little bit of kernel/mpeg4/h264/alsa/v4l2/packaging/daemon/sql/php)?
[16:12] <nigelb> wow, you've gone from kernel all the way to php+sql
[16:13] <BenC> I'm looking to replace myself with my last employer
[16:13] <BenC> big shoes :)
[16:14] <BenC> The kernel isn't important, but you need to understand v4l2 and alsa API
[16:15] <nigelb> You could post the planet for a wider audience
[16:35] <jelmer> slangasek, I can fix lp:gcc but by pointing it at a different branch for the moment ("bzr branch lp:gcc" would still do the right thing)
[16:36] <slangasek> jelmer: and would continue to do the right thing later, not give us branch divergence? :)
[16:37] <jelmer> slangasek: yes, that would not cause divergence later
[16:37] <slangasek> jelmer: that would be great then :)
[17:02] <cr3> barry: checkbox done!
[17:20] <janimo> anyone else seeing issues with latest apt? apt-get changelog segfaults on oneiric. dist-upgrade does nothing. x86
[17:22] <pitti> tseliot: hm, so I'm confused -- "modinfo nvidia" doesn't exit, "modinfo nvidia_current" does; but once you load it, "lsmod" will show "nvidia", but not "nvidia_current"; is that supposed to be that way?
[17:24] <tseliot> pitti: yes but you can resolve the alias and find the real name in nvidia-common, IIRC
[17:27] <pitti> tseliot: ah, it already seems to do that, it overrides used()
[17:27] <pitti> so I'll debug that then
[17:27] <tseliot> right
[17:32] <pitti> 2011-06-30 02:00:53,876 DEBUG: Nvidia.used: module nvidia_current, module_alias nvidia, resolved alias:
[17:32] <pitti> tseliot: ^
[17:32] <pitti> tseliot: so the module_alias seems correct (it's calling module_loaded() on that)
[17:32] <pitti> tseliot: but it seems that resolve_module_alias("nvidia") is returning nothing, instead of "nvidia_current"
[17:33] <pitti> tseliot: this seems to be a bug in MultiArchUtils
[17:33] <tseliot> pitti: I don't know if it works in both directions
[17:33] <pitti> tseliot: what's the direction it's supposed to work in?
[17:34] <pitti> tseliot: right now it expects resolve_module_alias("nvidia") == "nvidia_current"
[17:34] <pitti> i. e. translate the name in "lsmod" to the actual kmod file name
[17:35] <tseliot> pitti: all the library does is call modprobe --resolve-alias $alias
[17:37] <pitti> modprobe --resolve-alias nvidia -> ""
[17:38] <pitti> so is that the bug?
[17:38] <pitti> tseliot: how is that alias defined?
[17:38] <pitti> /etc/modprobe.d/nvidia-graphics-drivers.conf just has a couple of blacklist s
[17:41] <barry> cr3: hey man, how's checkbox going?  anything i can do to help?
[17:46] <tseliot> pitti: dkms does it
[17:47] <tseliot> pitti: in dkms.conf
[17:48] <barry> jelmer: ping
[17:48] <jelmer> barry, hello
[17:49] <tseliot> pitti: you can find more about it in dkms' man page
[17:49] <barry> jelmer: hi.  i'm starting to work on gnome-orca but it's got import failures.  was just wondering if this was one i could fix manually, and if so, how? :)
[17:50] <jelmer> barry: I'm not entirely sure, it seems like a bzr bug of some sort but I haven't looked into this one
[17:50] <jelmer> barry: vila or maxb might be able to say more about it
[17:51]  * maxb checks that one
[17:51] <barry> maxb: if it's not easy i can always import-dsc to unblock
[17:51] <maxb> Oh, that's one of the NoFinalPath ones
[17:51] <barry> maxb: what does that mean?
[17:52] <maxb> It means we need someone who understands bzrlib's preview transform merge code to figure out why it's throwing that exception
[17:52] <barry> maxb: ;)  okay, no worries.  i'll import-dsc
[17:53] <barry> maxb, jelmer thanks!
[19:30] <elmo> what happened to the parseable copyright file stuff - did that get stalled/not happen?
[19:31] <tumbleweed> it's going to be in the next debian policy release
[19:31] <slangasek> that's a bit of an overstatement
[19:31] <slangasek> there are still bugs in the spec that need fixin'
[19:31] <tumbleweed> well, as an appendix, IIRC. Not a MUST by any means :)
[19:31] <slangasek> elmo: http://dep.debian.net/deps/dep5/
[19:32] <elmo> slangasek: yeah, thanks, I found that - but the ubuntu packaging guide's initial example doesn't use it, but i see now the more detailed example does
[19:37] <micahg> any archive admin around for a PPA -> archive copy?
[19:43] <slangasek> elmo: ah; well I don't consider the spec to have the kinks worked out yet to the point of recommending adoption, but I think I'm being more conservative than average
[19:43] <slangasek> micahg: if we can do it quickly :)
[19:44] <micahg> slangasek: yep, ubuntu-mozilla-security PPA, lucid firefox -> lucid-security
[19:44] <slangasek> micahg: a little less brevity and a little more cutnpasterity? :)
[19:44] <micahg> oh, hmm, let me see if I can find the commands...
[19:45] <slangasek> I don't have it in my command buffer, sadly
[19:45] <slangasek> ah, here it is
[19:46] <micahg> slangasek: copy-package.py -b --ppa=ubuntu-mozilla-security -s lucid --to-suite lucid-security -e 3.6.18+build2+nobinonly-0ubuntu0.10.04.2  firefox
[19:47] <slangasek> micahg: ack - done
[19:47] <micahg> slangasek: thanks :)
=== elif is now known as elif_brb
=== yofel_ is now known as yofel
=== dendrobates is now known as dendro-afk
[22:22] <jochensp> Hi, my PPA doesn't want to install libvtk5.6 in oneiric, is that known?
[22:25] <tumbleweed> jochensp: we are half way through a VTK transition (mostly stalled, the remaining packages all fail to build): http://people.canonical.com/~ubuntu-archive/transitions/vtk.html (does that help at all?)
[22:26] <dtchen> there's also the versioned conflict for libavutil51.
[22:27] <dtchen> (rather, the versioned dep prevents its installation)
[22:27] <tumbleweed> oh, right, I think vtk needs a rebuild
[22:27] <tumbleweed> indeed: http://people.canonical.com/~ubuntu-archive/transitions/libav.html
[22:49] <jochensp> tumbleweed: thx, will try it again later
[22:52] <tumbleweed> jochensp: if it only needs a no-change rebuild, I'll upload it soon
[22:58]  * Chipzz sighs @ http://lkubuntu.wordpress.com/
[22:58] <broder> ‘/var/lib/dpkg/tmp.ci//.svn’: Is a directory> i don't even want to speculate on how your system ends up like that
[22:58] <Chipzz> "A listing of useful software, tips, tweaks and hacks for Ubuntu". I've only read about 6 articles from there, but all of them were crap
[22:59] <Chipzz> deb-extract. really??
[22:59]  * Chipzz facepalms
[23:00] <Chipzz> broder: http://lkubuntu.wordpress.com/2011/06/29/extract-fully-a-deb-archive-with-deb-extract/
[23:00] <broder> Ugh. I didn't actually realize all of those articles were coming from the same site
[23:01] <Chipzz> next one:
[23:01] <Chipzz> cat << EOF | sudo tee /etc/ld.so.preload /dev/null
[23:01] <Chipzz> /usr/lib/libv4l/v4l1compat.so
[23:02] <Chipzz> EOF
[23:02] <Chipzz> more facepalm :(
[23:02] <Chipzz> actually 2 facepalms for the price of one
[23:05] <Chipzz> actually 3 if you count the unnecessary use of cat
[23:25] <tumbleweed> jochensp: vtk rebuild uploaded
=== dendro-afk is now known as dendrobates