[00:01] <psusi> what's the incantation to get emacs into the style mode of the kernel again?
[00:04] <Drakeson> psusi: ?
[00:04] <psusi> so it does things like use hard tabs to indent instead of 2 spaces
[00:05] <cjwatson> psusi: it's in Documentation/CodingStyle
[00:07] <Drakeson> is emacs-snapshot older than emacs23?
[00:15] <kklimonda> looks like it
[00:17] <ebroder> cjwatson: reading the foundations team logs. in addition to the packaging probably needing some love, i've tested not yet tested the whole patchset together (just the individual pieces). just fyi
[00:20] <cjwatson> ebroder: gotcha
[00:21] <cjwatson> been distracted by upstart/plymouth anyway
[01:04] <Drakeson> Was there a huge recent change regarding compiz and the indicators?  I don't seem to have the indicator applets anymore.
[01:19] <RAOF> Drakeson: There was the upload of compiz 0.9; that's a big compiz change.
[01:27] <psusi> well holy crap... I wrote a kernel patch and it compiled on the first try
[01:27] <psusi> now to see if it /works/ ;)
[01:43] <psusi> wow... it worked...
[01:53] <TheMuso> psusi: It must have been a one-liner. :)
[01:54] <psusi> TheMuso, heh, actually was adding a few bit flags that weren't defined to headers, then cloning some sysfs functions to export them and modifying them to work with the new flag
[01:55] <TheMuso> Well, close.
[01:58] <psusi> so not that much, but not exactly a one liner either... still amayzed it compiled AND worked on the first try
[02:01] <psusi> now to see if it correctly reports true for the external status of the esata port on my laptop... desktop doesn't have an external port...
[02:06] <psusi> AHAH!  IT WORKS!
[02:09] <psusi> cat /sys/devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/achi_port_external -> 1
[02:10] <chrisa> What package do I need to actually do a build-dep on to get all the dependencies of newer gccs? I can do build-dep gcc-4.1 for instance, but gcc-4.3, gcc, etc don't seem to work out
[02:20] <steev_> sorry to intrude, but to which channel would i go for assistance in packaging an application for ubuntu?
[02:23] <RAOF> steev_: Either #ubuntu-motu or here (if you're aim is to get the package into the official archives) or in #ubuntu-packaging if it's just for a PPA.
[02:25] <steev_> thanks RAOF
[02:53] <ebroder> does the intel driver do its own round of mode setting when X starts, even with KMS?
[02:54] <ebroder> (is this configurable somehow?)
[02:56] <RAOF> ebroder: No; once KMS is in use, the kernel is the only thing that can do modesetting without making everything fall down in a screaming heap.
[02:57] <ebroder> RAOF: hmm...ok, maybe i understand this less well than i thought. if i have an intel gfx machine, and i boot it with multiple monitors plugged in, KMS appears to set the mode correctly (and independently for the two monitors), then when X starts something switches it into cloned mode
[02:57] <RAOF> ebroder: That starting X *will* cause the X driver to probe available modes from the kernel, and then X will make its own decision as to the best mode, possibly triggering the intel driver to delegate a modeswitch to the kernel.
[02:57] <ebroder> ah, ok - right
[02:58] <ebroder> i'm wondering if this is a piece of why people think multi-monitor is so non-deterministic
[02:58] <RAOF> It is, a bit.
[02:59] <RAOF> Hm.  Actually, it might be reasonable to delegate the clone-setting to the DE / login manager.
[03:01] <ebroder> I don't suppose there's a way to change X's mode selection algorithm without hard-coding layouts and resolutions in xorg.conf?
[03:02] <ebroder> (I know we decided to always clone at UDS; I happen to have a scenario where I want to always extend)
[03:04] <RAOF> This is a case where delegating to gnome-settings-daemon would be the right thing to do.
[03:04] <ebroder> That would certainly be awesome
[03:05] <RAOF> Which is the X policy anyway.  I don't think there'd be a huge outcry against leaving the KMS-set mode until the settings daemon says otherwise.
[03:06] <ebroder> And it's not like there'd be anything to show in place of plymouth before then
[03:17] <RAOF> Right.
[03:58] <psusi> cjwatson, you around?  I'm not sure but it looks like dist-upgrade to natty is broken because grub2 depends on a natty version of base-files, but base-files depends on a natty version of grub2-common, so dist-upgrade can't upgrade...
[04:02] <psusi> weird.. third time is the charm I guess..
[04:19]  * psusi sighs at the number of times things like update-grub and update-initramfs are still run during a dist-upgrade, despite dpkg-triggers
[04:24] <freeflying> persia, ping
[04:26] <ebroder> psusi: update-grub isn't triggerized, is it?
[04:39] <c4pt> hi
[04:39] <c4pt> i was reading an log of this irc channel and i had a similar question to what i was reading
[04:40] <pipegeek> Hi, folks.  It looks like the kernel option CONFIG_SOUND_OSS_CORE was disabled lucid => maverick.  Why was that done?  I have some very old binaries that are oss-only, some of which open /dev/sequencer explicitly and which no longer work
[04:40] <c4pt> YokoZar, hello, what do you think about updating the packaging of ia32-libs for mesa-dri-experimental? like it is done in xorg-edgers ppa
[04:40] <c4pt> ricotz
[04:40] <c4pt> ^^
[04:40] <pipegeek> Also, disabling CONFIG_SOUND_OSS_CORE and friends breaks the oss-compat package.  I've filed a bug report
[04:40] <YokoZar> c4pt: for 11.04?  I think I'm still waiting on multiarch
[04:40] <pipegeek> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/60987
[04:40] <c4pt> YokoZar, well i am trying to install this on debian
[04:40] <YokoZar> c4pt: relatedly I am putting together an ia32-libs update for the Wine PPA though
[04:41] <YokoZar> that will contain all the gstreamer codecs
[04:41] <YokoZar> yum
[04:41] <c4pt> YokoZar, and xorg-edgers breaks X11 pretty bad when i let apt-get do its thing for that package
[04:41] <pipegeek> errg.  WRong bug
[04:41] <pipegeek> sorry
[04:41] <YokoZar> c4pt: you mean if you do/don't have xorg-edgers ppa?
[04:41] <c4pt> YokoZar, if i add xorg-edgers into debian squeeze sources and start installing stuff i can kiss my X11 goodbye eventually
[04:42] <YokoZar> well yeah
[04:42] <c4pt> YokoZar, but i just want two packages from it
[04:42] <c4pt> lol
[04:42] <YokoZar> but how would updating ubuntu's ia32-libs change that?
[04:42] <c4pt> YokoZar, well i was searching around for someone who i could talk to . to give me an idea of what i can do?
[04:42] <pipegeek> https://bugs.launchpad.net/ubuntu/+source/oss-compat/+bug/673845
[04:43] <pipegeek> Should I also file a feature request to get kernel oss compat turned back on?
[04:43] <c4pt> YokoZar, ive tried building mesa from sources (i got it working once or twice but i am overlooking a symbolic link somewhere or something isnt getting updated
[04:44] <c4pt> YokoZar, i found this ia32-lib-mesa-exp packag on ubuntu one day for nouveau and its so simple its mindblowing
[04:44] <c4pt> *package
[04:44] <YokoZar> yes it's something that should be in ubuntu's ia32-libs
[04:45] <YokoZar> but not as a backport, so it can be fine in its ppa atm
[04:45] <c4pt> YokoZar, well how can i get it installed on debian?
[04:45] <YokoZar> I really don't know, debian has quite a delta with ia32-libs
[04:46] <YokoZar> and the 11.04 goal is to get rid of ia32-libs for multiarch, so I don't see the reason to futz around with it unless that gets delayed again
[04:46] <c4pt> brb
[04:48] <RAOF> Aww, man.  Proper multiarch.  Woot!
[04:49] <ebroder> pipegeek: have you seen the padsp command?
[04:50] <pipegeek> I do, but I'm not sure how useful that is in the case of things that need /dev/sequencer
[04:50] <pipegeek> It's certainly not useful for things which explicitly *open* /dev/sequencer
[04:50] <ebroder> pipegeek: oh, sorry. i thought /dev/sequencer was one of the things padsp faked
[04:51] <pipegeek> I'm not sure.  I thought padsp just overrode calls to the oss API
[04:51] <pipegeek> I thought it was an LD_PRELOAD hack
[04:51] <ebroder> it is an LD_PRELOAD hack, but it works by intercepting open() calls for /dev/mixer, /dev/sndstat, and /dev/dsp
[04:51] <pipegeek> oh neato
[04:51] <pipegeek> :)
[04:52] <pipegeek> OK, in any event..... is there a reason that was removed?  Is there a reason it shouldn't be turned back on?
[04:52] <pipegeek> It is useful, now missing functionality
[04:53] <ebroder> I can't speak to the decision-making process, but I can only assume it's because OSS has been deprecated for years, so it was finally time to put it out to pasture?
[04:53] <pipegeek> I mean, I'm happy to build my own kernels for now, but .... a) if that was an intentional removal, then oss-compat should be removed from universe and b) I'd love to be able to partake in ubuntu security updates which I can't do if I'm rolling my own
[04:54] <pipegeek> ebroder: Is anything (except maybe a few kB) lost by leaving it in?
[04:54] <pipegeek> I know it's long since deprecated, but there are things that can't be rebuilt
[04:54] <pipegeek> and projects that petered out years ago
[04:55] <pipegeek> I'm a dreadfully unimportant case of this, but I'm sure there are others
[04:55] <pipegeek> I don't think it's been taken out of debian unstable
[04:56] <pipegeek> at the very least it'd be nice to have those modules there, even if they're not loaded by default
[04:57] <ebroder> pipegeek: Honestly, I have no idea why it was actually taken out
[04:57] <pipegeek> If I wanted to press the issue, what's the correct channel to go through?  Should I file a feature request?
[04:57] <pipegeek> ebroder: yeah, and sorry for the textual deluge :)  I'm just disappointed
[04:58] <ebroder> pipegeek: It's probably worth looking through the archives for the kernel-team mailing list to see if there's an explanation (http://lists.ubuntu.com/mailman/listinfo/kernel-team)
[04:58] <pipegeek> OK.  Will do, and thanks
[04:58] <RAOF> TheMuso will have insight into the process, if he's around.
[04:59] <pipegeek> Is it alright (if I don't find a relevant thread) if I post to that list, or do I need to be an ubuntu developer or package maintainer?
[04:59] <ebroder> https://lists.ubuntu.com/archives/kernel-team/2010-May/010647.html points to https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickConfigReview points to bug #579300
[05:00] <pipegeek> https://lists.ubuntu.com/archives/kernel-team/2010-May/010647.html
[05:00] <pipegeek> oh
[05:00] <pipegeek> ehehe
[05:00] <pipegeek> you beat mne :)
[05:01] <pipegeek> there's a lot of unhappiness in that bug
[05:02] <TheMuso> As as been said, OSS has been deprecated for ages. If your app still uses OSS and OSS only, then you need to find a new app, or request that the upstream author switches to ALSA or pulse, depending on what the app is, and who it targets.
[05:02] <TheMuso> Unfortunately we ran out of time to get ossproxy in Ubuntu maverick, hopefully it will be in for natty.
[05:04] <pipegeek> TheMuso: Does ossproxy handle /dev/sequencer?
[05:04] <TheMuso> pipegeek: No I don't think it does, as PulseAudio doesn't deal with MIDI at all.
[05:04] <pipegeek> TheMuso: which means anything that is trying to speak MIDI through OSS is now stranded.  ossproxy/padsp aren't complete replacements for oss emulation in the kernel.
[05:05] <pipegeek> in my case, the app is a game whose maintainers stopped working on it ten years ago, and the svn repository went down a few years after that.  I am supremely unimportant, but I don't doubt there are other old binaries floating around
[05:05] <TheMuso> Right, but OSS is deprecated.
[05:05] <TheMuso> Hrm ok.
[05:05] <pipegeek> Why not build the modules?
[05:05] <pipegeek> they don't have to be loaded by default, but having them there is tremendously useful for the few who need them.
[05:06] <pipegeek> and I believe they're still included in debian
[05:06] <TheMuso> Well Ubuntu and Debian's kernels tend to be rather vastly different.
[05:06] <pipegeek> hehe, fair enough
[05:06] <pipegeek> but.... why cut people off from OSS before linus decides it's time?
[05:06] <TheMuso> As for your use case, I think it bares consideration.
[05:07] <TheMuso> i.e re-enable OSS emulation for MIDI only.
[05:07] <pipegeek> that'd be nice :)
[05:08] <pipegeek> but if that's being done anyway, why not include all the modules (perhaps as a separate, installable/buildable package, ala sshfs et al)?
[05:08] <pipegeek> err, perhaps I shouldn't push my luck :)
[05:08] <pipegeek> yes.  That would entirely solve my problem
[05:08] <pipegeek> or a userspace LD_PRELOAD hack to reroute /dev/sequencer to /dev/snd/midi
[05:08] <pipegeek> or something :)
[05:09] <ebroder> pipegeek: Wait, does /dev/snd/midi exist and function as a drop-in replacement for /dev/sequencer?
[05:10] <pipegeek> no
[05:10] <ebroder> oh. ok :)
[05:10] <TheMuso> ebroder: No, didfferent protocols etc, you have to go through alsa-lib to reliably use /dev/snd stuff.
[05:10] <pipegeek> err, I don't know.  I'll try symlinking it and seeing if it works, but I really doubt the ioctls are the same
[05:10] <pipegeek> ebroder: what TheMuso said :)
[05:11] <ebroder> TheMuso, pipegeek: Got it. Sound is still on my list of "things where I vaguely know the terms but have no clue how they actually work" :)
[05:11] <ebroder> (I need to fix that at some point...)
[05:11] <pipegeek> TheMuso: Thank you very much for considering my case.
[05:11] <TheMuso> I'll see what can be done.
[05:12] <pipegeek> I really appreciate it.
[05:50] <rocket16> Hello friends
[05:50] <rocket16> Is it true that Ubuntu 11.04 will only have Unity as its default desktop?
[05:50] <persia> rocket16, That's complex.
[05:51] <persia> It's more true to say that "Ubuntu Desktop 11.04" will feature the Unity interface.
[05:51] <rocket16> persia: Oh, I see. Then will GNOME be available by default as well?
[05:52] <persia> rocket16, Unity is mostly atop GNOME.  I'm not sure what you mean by "available by default".
[05:53] <rocket16> persia: Oh, many thanks. I just meant to say whether GNOME will be installed by default or not. But your answer already answered my question. Thanks. :)
[05:53] <rocket16> Thanks for the help, persia.
[05:54] <persia> My understanding is that Ubuntu Desktop will remain a GNOME-based flavour, just with Unity.
[07:06] <pitti> Good morning
[08:04] <pitti> kirkland: *chuckle* at the byobu (3.8-0ubuntu1) changelog -- s3kr1t stuff?
[08:08] <dholbach> good morning!
[08:13] <stefanlsd> james_w: im looking at merging dahdi-linux using udd. It seems debian uploaded a .pc directory with patches applied (not sure how this happened) - do we have an idea how we handle this .pc directory with udd?
[08:29] <pitti> stefanlsd: perhaps bzr imports the source packages with the patches already applied now? that's the way dpkg-source unpacks 3.0 (quilt) packagese
[08:29] <pitti> james_w: ^ ?
[08:32] <stefanlsd> pitti: i guess if thats the case, we def. need the .pc directory, as to build it needs to unapply
[08:32] <pitti> yes, with pre-applied patches you also need .pc/
[08:33] <stefanlsd> pitti: yeah. there was talk about not importing .pc. in this case we cant do that.
[08:33] <pitti> in that case we shouldn't pre-apply patches
[08:49] <cjwatson> uh
[08:49] <cjwatson> it's a bit more complicated than that, IMO
[08:51] <cjwatson> 3.0 (quilt) must *always* be patches-applied except when you're actively editing patches; but importing .pc creates a lot of noise and it's tricky to figure out how to commit correctly atop that; http://bugs.debian.org/572204 is probably part of this
[08:51] <cjwatson> what I do at the moment is run http://people.canonical.com/~cjwatson/dpkg-quilt-setup if patches are applied but the .pc directory isn't there
[08:52] <cjwatson> but I think what we want is for bzr to set up the .pc on checkout, or similar
[08:52] <cjwatson> it's as yet an incompletely solved problem
[08:53] <pitti> cjwatson: why wouldn't we have .pc/ tracked in bzr in this case then? I thought the goal would be to mimic what apt-get source does, i. e. have a buildable tree?
[08:53] <cjwatson> I've never seen anyone get the commits right on top of that
[08:53] <pitti> if we want to require using bzr bd (which would be okay, I think), then we might just as well not apply the patches
[08:53] <pitti> I've not seen it either yet
[08:54] <cjwatson> the other longish-term approach is to represent the patches as a loom
[08:54] <cjwatson> if that ever works, then it should be good
[08:54] <pitti> that'd be even better
[08:54] <Laney> I thought that was agreed by the bzr guys at UDS, so hopefully there will be some movement there
[08:54] <pitti> right now it seems kind of silly that we don't use revision control for the things that would benefit most from it :)
[08:54] <cjwatson> I'd really rather not have unapplied patches though, that's just back to the bad old days
[08:55] <cjwatson> there are strong benefits to having things like bzr blame for 3.0 (quilt)
[08:55] <cjwatson> if the revision control representation is patches-applied, then you have blame across both upstream and distribution-patches transparently
[09:01] <cjwatson> FWIW, I do 3.0 (quilt) in bzr outside udd, without committing .pc, and it works quite nicely for my purposes except that you have to do something like that dpkg-quilt-setup business on checkout
[09:01] <cjwatson> but IMO this is a small price to pay, and if bzr sorted it out automatically it would be nice and smooth
[09:01] <cjwatson> (I talked to the bzr developers about this at the last platform rally)
[09:03] <maxb> cjwatson: Ooh, nice script. And yes, the current situation (of .pc in branch) is just broken
[09:36] <geser> cjwatson (or someone from ubuntu-desktop): could you please also do a no-change rebuild of pyorbit as the recent rebuild of gnome-python (for py2.7) added a dependency on python2.7-pyorbit (to python-gnome2) which isn't in the archive yet. Thanks
[09:40] <mvo> geser, cjwatson: I can do that
[10:54] <ifdef> cjwatson: morning! do you mind if I install a pkg in the natty chroot on kakadu (ctags)?
[10:54] <cjwatson> ifdef: not at all, in general you're free to on porter boxes
[10:54] <ifdef> cjwatson: thx
[10:58] <juk> hi, i accidentally pointed anjuta ide to my home folder, as project root, and it won't start now for hours!
[10:59] <juk> anyway to stop anjuta ide from going through my home dir at startup? it 80Gb+ big
[11:24] <JamesPage> hi, how do I get a package that FTBFS rebuilt for Natty?  The missing main dependency has now been MIR'ed
[11:25] <tumbleweed> JamesPage: you ask a core-dev to rebuild / "give-back" it, you need to mention the package name...
[11:28] <JamesPage> tumbleweed: OK so if I follow the normal sponsorship route with the bug that should do the trick?
[11:28] <tumbleweed> JamesPage: no, all you need to do is ask here
[11:28] <JamesPage> tumbleweek: ah - right understand now;
[11:28] <pitti> JamesPage: which package is it?
[11:28] <JamesPage> tumbleweed: libmx4j-java
[11:29] <JamesPage> pitti: ^^
[11:29] <pitti> JamesPage: done
[11:29] <JamesPage> pitti: thanks!
[11:38] <ifdef> cjwatson: something nasty going on with dpkg - getting corrupt stack frames
[11:59] <lool> Hmm new linux-libc-dev causes some FTBFSes like https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/672580 and eglibc
[12:09] <geser> lool: perhaps a similar change like in the recent busybox upload helps here too
[12:17] <lool> ah thanks for the pointer; this is going to be painful  :-/
[12:28] <cjwatson> ifdef: I think valgrind is at least somewhat usable on armel nowadays, so might be worth a go
[12:28] <cjwatson> lool: I thought cyphermox was already dealing with that
[12:29] <ifdef> cjwatson: I was going to install that, but it seems to be trying to pull in a new libc...?
[12:29] <cjwatson> ifdef: otherwise, maybe traditional malloc-arena-debugging techniques might help
[12:29] <cjwatson> ifdef: if it's just an upgraded version, that should be ok
[12:29] <cjwatson> ifdef: the 'sudo apt-get install' is pretty locked down, it shouldn't let you do anything excessively dangerous
[12:30] <cjwatson> lool: https://code.launchpad.net/~mathieu-tl/ubuntu/natty/wpasupplicant/ftbfs-lp672580
[12:46] <lool> cjwatson, ifdef: for Linaro, we prepared an updated valgrind which was too intrusive to upload to maverick late in the cycle; it's in https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages
[12:47] <lool> I expect we will update to 3.6.0 in natty though
[12:47] <lool> I mean in natty itself, no need for a PPA anymore
[12:48] <lool> cjwatson: Yeah wpasupplicant has been taken care of, I'm facing the eglibc FTBFS
[12:48] <lool> and I don't want to change eglibc code to use linux headers instead of glibc headers, this would be insane
[12:53] <cjwatson> lool: I filed bug 673073 about the painful bit of the incompatibility
[12:53] <ogra_ac> cjwatson, btw, do we have a bug for the dpkg/debootstrap issue ?
[12:53] <ogra_ac> else i'll open one
[12:55] <cjwatson> ogra_ac: not to my knowledge
[12:55] <lool> cjwatson: Thanks for the pointer; sub-ed
[12:55] <ogra_ac> cjwatson, k
[12:55] <lool> I checked the upstream glibc list and git repos and didn't see anything relevant going in
[13:00] <cjwatson> likewise
[13:10] <lool> Nothing in Fedora's packaging either
[14:39] <stgraber> doko: ping
[14:40] <highvoltage> doko: ping
[14:40] <stgraber> doko: Does http://launchpadlibrarian.net/58992414/icedtea-web_1.0~20101021-0ubuntu4_1.0~20101021-0ubuntu5.diff.gz look like an acceptable fix for bug 673524 ?
[14:42] <stgraber> doko: apparently quite a few packages depends on/recommends icedtea6-plugin still making some DVD builds to fail
[14:50] <frukt_> hi! i'm not a ubuntu user, but i use the ubuntu-patched cairo, fontconfig, libxft and freetype2 on my arch install. it seems that as of late, the lcdfilter settings in fontconfig have no effect? i.e. lcdlegacy, lcdlight and lcddefault all look the same. can anyone shed a light on that?
[15:02] <jdstrand> wendar: hey. so I have on my todo list to add to the wiki the security team's thoughts/recommendations on ARB. where is the best place to put that?
[15:19] <kirkland> where did pitti go?
[15:23] <Ng> .1
[15:23] <Ng> bah
[15:26] <gamerpro2000> Guys, I realize this is a dev channel, but I have a serious problem with Ubuntu that is dev related.
[15:26] <gamerpro2000> Anybody in here got a minute to assist?
[15:27] <pitti_> gamerpro2000: you should just ask your question, otherwise nobody will know what it is about
[15:27] <gamerpro2000> ....................................................seriously?
[15:27] <gamerpro2000> Yay! life!
[15:28] <pitti_> (and some patience, please..)
[15:28] <gamerpro2000> pitti_, sorry.  I've been trying to develop a script and stuff to get this working for 9 weeks.  patience is wearing thin
[15:29] <kirkland> pitti_: howdy;  sorry, I don't get what you mean?
[15:29] <pitti_> kirkland: now, if only I'd remember what I asked :) /me reads logs
[15:29] <gamerpro2000> Anyway, XOrg is giving me a segmentation fault with a signal of 13
[15:29] <gamerpro2000> However, it only happens once and a while
[15:29] <pitti_> kirkland: aah
[15:29] <kirkland> pitti_: the 3.7 release moved ~/.byobu to the xdg recommended location of ~/.local/share/byobu
[15:29] <pitti_> kirkland: well, the changelog just said "UNRELEASED"
[15:30] <kirkland> pitti_: huh?  really?
[15:30] <gamerpro2000> and only about 25% of the time.  I'm trying to patch Xorg to stop it from doing this.  It seems that there is a buffer or something that's getting stuf
[15:30]  * kirkland checks
[15:30] <pitti_> kirkland: https://launchpad.net/ubuntu/+source/byobu/3.8-0ubuntu1
[15:30] <gamerpro2000> *stuck
[15:30] <pitti_> gamerpro2000: signal 13 is SIGPIPE, not a buffer overflow
[15:30] <kirkland> pitti_: whoops, i wonder how that happened
[15:30] <gamerpro2000> Because it happens several times over and over again, then once it comes out of it, it won't do it for several reboots
[15:31] <gamerpro2000> pitti_, just so that you're aware, this is a multiseatX environment
[15:31] <kirkland> pitti_: okay, thanks for the heads up
[15:31] <pitti_> kirkland: so I just joked about "you now accidentally released your s3kr1t stuff" :)
[15:31] <kirkland> pitti_: hah :-D
[15:32] <kirkland> pitti_: my release script broke somehow
[15:32] <gamerpro2000> Much of this started happening when gdm and kdm updated, removing support for multiseat
[15:33] <gamerpro2000> Does anybody know when the multiseat additions will be added back into the tree so that it will make it easy again for people to use multiseat
[15:34] <gamerpro2000> or does anybody know a good implementation for a multiseat environment?
[15:35] <gamerpro2000> for Ubuntu 10.04 LTS
[15:46] <psusi> pitti_: I came up with a working patch last night to export the esata bit and it correctly identified the external port on my laptop... now for udisks to use that, it still needs to be picked up by udev and added to the information it keeps for the block device right?
[15:46] <krisphillips> Hey guys, I realize you guys don't do support, but sine you guys are devs, I was wondering if you can tell me what this segmentation fault means from my logs?  I would really appreciate it, since I've been beating my head against it for weeks.
[15:46] <krisphillips> Log is here: http://pastebin.com/qg1TtiXz
[15:47] <krisphillips> I don't have any understanding on what the heck it means, and I would be in your debt if you could explain it and give me a direction to resolve it.
[15:47] <pitti_> psusi: right; but once that's in the kernel, that should be easy
[15:47] <pitti_> psusi: well, in udisks, not in udev
[15:48] <krisphillips> Anyone?  Please? :(
[15:49] <pitti_> kirkland: that's not a very useful stack trace, I'm afraid; did you get an apport report?
[15:49] <kirkland> pitti_: i did not
[15:49] <kirkland> :-)
[16:17] <pitti> ebroder: thanks for forwarding the gst perl fix upstream!
[16:18] <pitti> ebroder: you are going to do that for gutenprint as well, I suppose? I'll sponsor that now
[16:18] <ebroder> pitti: please don't just yet
[16:18] <pitti> oh, ok
[16:18] <ebroder> I'd like to do at least a modicum of testing :)
[16:20] <ebroder> pitti: if you're hunting for something to upload :), you can drop the perl dep from libnss-mdns with no other changes
[16:21] <ebroder> (dep as in it's in debian/control directly for no good reason)
[16:23] <pitti> ebroder: right, that's on my mental queue
[16:24] <pitti> ebroder: just thought you'd like to see your change in action :)
[16:39] <krisphillips> So, anybody willing to help me now?
[16:40] <krisphillips> I submitted a bug report here: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/674112
[16:40] <krisphillips> I would reaaaalllllly appreciate it :)
[16:54] <segv`> There anyway to install 10.04 with the 10.10 CD? 2.6.32 likes to make my 'hdd's dissapear. 2.6.35 does not however.
[16:55] <cjwatson> not really
[16:56] <cjwatson> I suppose you could debootstrap and then fix it up afterwards, but that's definitely a "some assembly required" kind of option
[16:56] <segv`> Figured as much, i'm willing to dive in and build a livecd with a newer kernel on it, would that work?
[16:57] <cjwatson> I suppose.  You can't just install 10.10 directly?
[16:57] <cjwatson> (since you said its kernel works)
[16:58] <segv`> I have it installed, I just want LTS (for various other reasons, compatibility etc.) and I have cfengine managing these machines
[16:58] <segv`> Like to keep them all the same version
[16:58] <segv`> So i don't have a one off other than kernel version.
[16:59] <psusi> should probably try to figure out what's wrong with 2.6.32 and fix it...
[17:00] <segv`> DID_BAD_TARGET is what happens, ICH7, USB drops out too during "hardware detection"
[17:01] <segv`> with acpi enabled, noacpi, usb doesn't drop.
[17:01] <segv`> 2.6.35 does not require any of these steps etc.
[17:01] <segv`> and it's alread in lucid-proposed so *shrug*
[17:07] <segv`> psusi: I really should, I just need this system up, it's a virtual server host it being down for > 24 hours is bad.
[17:07] <segv`> If I had time to debug, I would *love* to.
[17:08] <segv`> If I can find another D945GTP intel mboard with a 64bit proc for under 140 in the next week or two, i'll go down the gauntlet of debugging it
[17:25] <segv`> cjwatson: you think it's possible to use the kernel off of the 10.10 livecd and use it on the 10.04 livecd?
[17:25] <pitti> segv`: we already have a maverick kernel backport in lucid
[17:26] <segv`> pitti: (i can't install it w/out the livecd using it)
[17:27] <segv`> pitti: 2.6.32 (the version on the livecd) as soon as hardware detection goes through the hdd's become inaccessible
[17:27] <pitti> yeah, you'd need to remaster then
[17:28] <pitti> or perhaps try a netinstall; the expert mode should allow you to select a kernel, but I'm not quite sure whether this requires extra magic in d-i
[17:28] <segv`> pitti: that's what I was thinking, i was going to just add the lucid-proposed, where the linux-image-2.6.35 is hiding
[17:28] <segv`> to the live-cd giving me the ability to use it.
[17:33] <segv`> hmm, wish I knew how to make custom kernels work for the live-cd..
[17:33] <segv`> pitti: Would copying over the kernel from the 10.10 cd work and just rebuild it?
[17:34] <pitti> segv`: I thought the 10.04 CD wouldn't even see your hard disk -- so no
[17:34] <segv`> it sees it it just dumps it
[17:35] <segv`> as soon as it gets to hardware detection is throw DID_BAD_TARGET errors (Read errors)
[17:48] <segv`> Got it, figured out a pretty hack.
[17:48] <segv`> pitti: I booted with the 10.10 livecd just cloning a 10.04.1 install with the 2.6.35 kernel installed, just need to chroot grub install and done. Problem solved.
[17:49] <pitti> heh
[17:49] <segv`> Sometimes I make things way too difficult/
[17:59] <ifdef> ogra: hi! could you raise a bug for the armel dbootstrap/dpkg sigsegv issue?
[18:00] <ogra_ac> ifdef, yeah, will do
[18:00] <ogra_ac> did you take a look already ?
[18:01] <ogra_ac> ifdef, do youu want it against dpkg or debootstrap ?
[18:02] <ifdef> ogra_ac: I've been looking at it all day. So far, I've hit a bugs in valgrind and dmalloc and a limitation with gdb :)
[18:02] <ogra_ac> yeah, valgrind and arm dont go so well together
[18:02] <ifdef> the problem seems to be with dpkg-query so I guess dpkg
[18:03] <ifdef> I got the classic, "valgrind: the 'impossible' happened:"
[18:03] <ogra_ac> heh
[18:09] <ogra_ac> ifdef, bug 674146
[18:47] <doko> stgraber: yes, looks ok
[18:51] <highvoltage> doko: unping (I emailed you instead!)
[20:04] <superm1> pitti, what exactly is this PNG optimization that started happening in builds for natty?  i'm assuming another size reduction initiative?
[20:07] <ifdef> ogra: a belated thx for 674146
[20:07] <ebroder> superm1: https://blueprints.edge.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint (in short, yes, it's a size optimization thing)
[20:09] <superm1> ebroder, thanks, that explains it.  i guess i'll just need to double check the pngs that are being optimized to make sure they still look right afterward then
[20:09] <ebroder> superm1: pitti wrote a script to do that verification - it's somewhere in pkgbinarymangler
[20:10] <superm1> pitti wrote a script to verify how they /look/ ? i knew he was smart, but didn't think he could make computers replace humans for that kind of stuff :)
[20:11] <ebroder> It converts them to bitmaps and compares them somehow :)
[20:11] <ebroder> I think it's pixel-for-pixel, but I don't remember for sure
[20:12] <gamerpro2000> Can someone look at my bug report and at least give me a bit of direction?  Thank you.  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/674112
[20:17] <ikonia> gamerpro2000: this isn't a support channel, please don't ask for support in here
[20:50] <psusi> pitti: if I patch udev's ata_id utility to add a new variable to the udev db entry for esata, that will be sufficient for udisks to auto mount them right?  do you have a preference for what it should be called?
[20:52] <psusi> hrm... no, ata_id isn't the right place... hrm...
[20:57] <psusi> hrm... how can you have the shell test a bit in a hex number?  hrm...
[20:58] <ebroder> psusi: if you're using bash, you can use && and || within $(( ))
[20:58] <ebroder> if not...call out to something more powerful?
[20:59] <ebroder> psusi: err, sorry, '&' and '|'
[21:00] <psusi> hrm... is bash what udev uses? or does it use the default shell, which these days is dash?
[21:00] <ebroder> psusi: probably dash
[21:07] <psusi> aha!  bash -c 'test $((1 & 0x$(<foo))) -eq 1' should do it
[21:55] <Book_em_Dano> can I aks questions regarding packaging here?
[21:56] <micahg> Book_em_Dano: #ubuntu-packaging is probably better for generic questions
[22:18] <kees> lool: still around?
[22:18] <lool> yup
[22:18] <kees> lool: I sent two emails, and then realized I could probably talk with you live. :)
[22:19] <lool> EH!
[22:19] <kees> if you have a moment, can you read those, and then we can compare notes again? I think eglibc is close, but some minor re-arrangements would be nice.
[22:21] <lool> kees: I'm bzr pushing as maybe my branch is out of date
[22:21] <lool> xmlrpclib.Fault: <Fault -1: 'Unexpected Zope exception: AssertionError: '>
[22:21] <lool> but Pushed up to revision 87.
[22:22] <lool> kees: I think I had failed to push r87 with cvs-issue12113
[22:23] <kees> ah! okay
[22:23] <kees> let me know when it's there and I'll look again
[22:23] <lool> kees: it is now
[22:23] <lool> I also have it in my tree and in the series
[22:23]  * kees waits for LP
[22:24] <lool> kees: You're looking at lp:ubuntu/eglibc, right?
[22:25] <kees> I was looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/eglibc/natty because I'm still waiting for bzr checkout to finish :)
[22:26] <kees> lool: okay, cool, let me re-arrange some other patches, and I'll commit too
[22:26] <lool> kees: Now keep in mind that some of these patches landed via Ubuntu
[22:27] <kees> I'll just move the one ld_audit one, since that'll stay ubuntu-specific
[22:27] <lool> kees: Ah you say debian/patches/any/disable-ld_audit.diff in changelog but it's ubuntu/disable-ld_audit.diff everywhere else
[22:28] <lool> I got it via the maverick-security which uses debian/patches/any/disable-ld_audit.diff
[22:29] <kees> right, I moved it for the old -pkg tree
[22:29] <kees> and updated it's comment to include the CVE
[22:29] <bdrung> bryceh: wow, you are cleaning up all old audacious bugs
[22:29] <lool> kees: Ok; this indeed wasn't copied over
[22:30] <lool> We have a debian/patches/any/dst-expansion-fix.diff instead of patches/any/cvs-dst-expansion-fix.diff
[22:30] <lool> (cvs- missing)
[22:31] <lool> Albeit it's the Debian name, so you could keep it like that
[22:32] <lool> And patches/any/ignore-ORIGIN-in-priv-progs.diff was not added but we got any/submitted-origin.diff from Debian which is disabled
[22:33] <lool> kees: So just a rename from /any to ubuntu of disable-ld_audit.diff + updated desc to copy; you're doing it, or you want me to?
[22:33] <kees> lool: I've got it, one sec
[22:34] <kees> okay, I've committed now.
[22:35] <lool> kees: I've added a comment in the old branch's changelog to point at the new one
[22:36] <lool> the good news is that bzr merge lp:debian/eglibc just works now  :-)
[22:36] <kees> \o/
[22:37] <lool> kees: Hmm you chose to move debian/patches/any/cvs-dst-expansion-fix.diff around? we don't use it and it will show up in a straight diff with Debian; I guess people should use bzr
[22:38] <lool> kees: Looks good; thanks for moving this across, and sorry for missing parts of it
[22:45] <kees> lool: no problem, sorry it was so confused. :)
[22:45] <kees> we do use debian/patches/any/cvs-dst-expansion-fix.diff ... ?
[22:46] <kees> I just chose to stick to their naming convention since eventually that patch will go away when we get it automatically from upstream.
[22:49] <lool> Sorry, #any/submitted-origin.diff is the one which is disabled because redundant with our fix
[23:14] <bryceh> bdrung, yeah was gonna put in 30 min on fixing a bug, but saw that just tons of cruft had built up so ended up just cleaning out obsolete bugs.