[00:01] <calc> so i went to the doctor and he prescribed me an immune suppressant... good luck with that (to me) ;-\
[00:02]  * calc has a feeling he will get much more sick than he currently is before getting better
[00:03] <ogra> calc, ugh, why is that ?
[00:04] <calc> ogra: well he gave me that to reduce the inflamation of my eustachian tubes, but i have something else also and my wife has (we think) pneumonia
[00:05] <calc> so i probably will end up more sick taking this than i am now, but hopefully not, we'll see :\
[00:06] <ogra> yeah, doesnt sound like fun flying with that
[00:07] <ogra> ugh, pneumonia ?
[00:07] <ogra> thats really bad
[00:17] <calc> ogra: yea she's pretty sick
[00:17]  * calc going to get something to eat for dinner
[00:22] <kirkland> slangasek: hey, has your pam-auth-update stuff made it into debian unstable yet?
[00:24]  * directhex ponders how to fix usplash sickage
[00:29] <kirkland> slangasek: libpam-runtime, right?
[00:29] <kirkland> slangasek: looks like it's here: http://packages.debian.org/source/unstable/pam
[00:29] <kirkland> slangasek: just sanity check me ....
[00:36] <directhex> bah. too much C, too much low-level. i hate bugs i can't patch
[00:37] <NCommander> directhex, ?
[00:37] <directhex> NCommander, trying to patch the suck out of usplash
[00:38] <NCommander> You are in a maze of twisty little passages, all alike. Exits in all directions.
[00:38] <directhex> indeed
[00:39] <directhex> NCommander, i've mostly managed to convince usplash to do what i want on this laptop. mostly. one glitch remains, which i'd like to patch away, but i'm headed into the land of ioctl()
[00:43] <NCommander> directhex, A sign on the wall says "Abandon All Hope"
[00:43] <stgraber> directhex: hey, while you are at it, can you fix geode GX2 support too ? :) thanks
[00:45] <Mithrandir> usplash is love
[00:45] <stgraber> directhex: X just doesn't start if usplash is started at boot time so basically the customer is either complaining because it doesn't get the usplash or complaining because he only has the usplash but no X :)
[00:45] <directhex> stgraber, which part of "too much low-level" wasn't clear? o_o
[00:46] <stgraber> directhex: bah, it's C, could be worse :)
[00:46] <directhex> oh, hey, look, the random wifi-related lockups i was warned about happened
[00:47] <NCommander> directhex, x86 assembly code looks at you confused. (it only wants to be your friend)
[00:48] <directhex> NCommander, this is such a simple desire, too
[00:48] <directhex> NCommander, i want......... an offset!
[00:49] <NCommander> x86 assembly language isn't hungry for offsets, its only pinning for fjords
[00:49] <NCommander> (if anyone gets that reference, you are awesome)
[00:49]  * directhex nails NCommander to his perch
[00:50] <NCommander> Not the answer I was looking for
[00:51] <directhex> as it stands, usplash assumes it has a "full screen" framebuffer to work with. that framebuffer is always 4:3 - but if usplash knows it's really on a widescreen monitor, then it'll use a 4:3 theme which has been compressed horizontally so it looks 16:9 when stretched from 4:3 to 16:9
[00:52] <directhex> now, if you pass a framebuffer mode via vga=X, then this breaks things a little - usplash still tries to draw assuming the framebuffer is the size it's been informed of (values in usplash.conf, determined god knows when), and if usplash.conf numbers are larger than vga=X, everything goes to hell
[00:53] <directhex> if usplash.conf is smaller than vga=X, then it displays fine - in the top-left corner
[00:54] <directhex> so what i would like is the ability to essentially offset usplash, so i can make it use a "4:3" theme, offset from the left margin enoguh to center it on a 16:10 monitor
[01:18] <Riddell> tjaalton: do you know where /usr/include/X11/extensions/XInput.h has disappeared to?
[01:21] <Riddell> hmm, should be in x11proto-input-dev according to debian but not yet in our version
[02:25] <MiladKhajavi> which is better: Intel or AT&T mnemonic for assembly programming?
[02:26] <savid> Does anyone know much about the nvidia issue as mentioned in the intrepid release notes?  Is there a bug for this?
[02:27] <RAOF> savid: What particular nvidia issues?
[02:28] <savid> RAOF apparently certain nvidia drivers are incompatible w/ intrepid...
[02:29] <RAOF> savid: If you're referring to the lack of 3d drivers for <= geforce4 cards, then that particualar problem has either been fixed or is in the process of being fixed.
[02:29] <savid> RAOF,  anywhere I can track the status on that?
[02:29] <RAOF> savid: nvidia released a new driver, which works.  It's either in intrepid-proposed or intrepid-updates, I'm not sure which.
[02:29] <savid> hmm
[02:29] <RAOF> There's undobtably a launchpad bug on it, but I don't know the number offhand.
[02:30] <savid> ok, thanks.  I'll keep looking around for it :)
[02:30]  * savid needs his compiz!
[02:49] <savid> Hmm, interesting.   this page says nvidia-glx-177 should work w/ my card (GeForce 8600M GT),  and the release page says that nvidia-glx-177 should work w/ intrepid:   http://packages.ubuntu.com/intrepid/nvidia-glx-177
[03:01] <aaaantoine> May I ask about gnome-panel applets here?
[03:02] <RAOF> savid: Absolutely.  It was only cards older than geforce5's that suffered from that problem.
[04:25] <slangasek> kirkland: it's not in Debian unstable yet, no
[04:26] <kirkland> slangasek: oh, hrm, okay.  is it intended to land there at some point?
[04:26] <slangasek> after the lenny release
[04:26] <kirkland> slangasek: i was trying to get the ubuntu and debian ecryptfs-utils packages back in sync
[04:33] <persia> kirkland, For pre-release Debian packages, there's a fair precedent for pulling from Debian Vcs with -0ubuntu1 (generally by agreement with Debian maintainers) with a note in the changelog that reminds one to sync when Debian is published.
[04:33] <kirkland> persia: sorry, it's been a long day, and i've worked on a lot of different packages today ...  which are you referring to?
[04:35] <persia> kirkland, " i was trying to get the ubuntu and debian ecryptfs-utils packages back in sync" as reference to "after the lenny release"
[04:36] <persia> It's a suggestion for a workaround to avoid future confusion, rather than a criticism of something you've done.
[04:37] <kirkland> persia: by "back in sync", i meant that i'm working with the debian maintainer to feed the remaining ubuntu changes back to Debian
[04:37] <slangasek> persia: ecryptfs-utils diverges in Debian due to local changes for compatibility with pam-auth-update, which is Ubuntu-only until after the lenny release
[04:38] <persia> Ah, and there's no post-Lenny branch in Vcs yet.  Nevermind: this package is different than many others I've seen recently.
[05:08] <tjaalton> Riddell: it has moved to libxi-dev
[05:42] <dholbach> good morning
[05:55] <TheMuso> Hey dholbach.
[05:56] <TheMuso> dholbach: When you have some time, could you please do me a favour and add me to ubuntu-main-sponsors please? Thanks.
[05:57] <dholbach> TheMuso: done
[05:58] <dholbach> brb
[07:37] <pyrosanltd> Hello I have an Tyan k8w system that is experiencing random lockups I cannot find any information in the log files or in my dmesg,  and I am completely stumped as to what action to take next to trouble shoot this, any help or suggestions would be appreciated
[07:38] <geser> pyrosanltd: have you tried running memtest already?
[07:39] <pyrosanltd> yes I have
[07:39] <pyrosanltd> and everything turned out clean
[07:41] <pyrosanltd> I am able to get the system to hang if I have amarok update my music collection (which is on a NFS mount) while moving a large file over my network say 4gb
[07:41] <pyrosanltd> also coming from the NFS mount
[07:41] <RAOF> Well, starting that off and then switching to a VT to catch the kernel output might be instructive.
[07:42] <pyrosanltd> is there a specific VT that would dump out  kernel output ?
[07:43] <RAOF> All of them.
[07:43] <pyrosanltd> ok  one moment let me get an extra irc client up on my laptop
[07:52] <pyro_> huh
[07:55] <pyro_> RAOF I was not able to get output in the VT
[07:56] <pyro_> this is pyrosanltd bthw
[07:58] <RAOF> pyro_: You got to a VT, and it crashed, but there was no output, or you couldn't get to a VT?
[07:58] <pyro_> RAOF I did get to a VT but  no output when it crashed
[08:01] <RAOF> Urgh.
[08:01] <pyro_> ?
[08:02] <RAOF> Well, there _should_ have been copious debug spew as the kernel paniced.  I don't know what the lack of output means.
[08:02] <RAOF> But I can't imagine it's good :)
[08:02] <pyro_> indeed I have been pluaged with this issue since 6.2.24 was used
[08:03] <pyro_> I have been living with it for quite some time
[08:03] <pyro_> I would love to file a bug report But I really do not have enough info to do so
[08:04] <liw> pyro, how long did you run memtest?
[08:04] <pyro_> 2 days
[08:04] <liw> that's long enough
[08:05] <pyro_> chuckles yeah I wanted to make damn sure it was not my memory
[08:05] <liw> I typically only get errors from memtest after at least several hours of testing, so the minimum I run it is 12 hours
[08:05] <liw> anyway, that's my only guess
[08:05] <pyro_> gotcha
[08:06] <pyro_> would a rundown  of what hardware I  have in my system be of any help ?
[08:10] <pyro_> I have a tyan k8W with dual Opteron246he processors an LSI megaraid controller configured with a striped array for my system disk an nvidia Geforece 6600 with 4 gigs of ram
[09:15] <tkamppeter> doko, are you aware that you are producing a spam bomb bug (bug 299813)?
[09:18] <doko> tkamppeter: well, ok, will continue with separate reports
[09:19] <seb128> doko: do you really need bugs to list those?
[09:20] <seb128> doko: isn't the jaunty_outdate listing those?
[09:22] <doko> seb128: no, these are packages which require fixes, not just buildd admin interaction
[09:23] <seb128> doko: do you expect the buildd admin todolist to have lot of items?
[09:24] <seb128> doko: because theorically the outdated list should only be packaged to fix after once the buildds have played catching up on builds
[09:52] <cjwatson> doko: oh, goodness, yes, don't file a single bug with all build failures as tasks!
[09:53] <cjwatson> doko: people will rightly get really upset with you. I suggest closing that and opening individual bugs
[09:53] <cjwatson> you can use tags or whatever for aggregation
[09:55] <persia> doko, You do know about the tracker at http://qa.ubuntuwire.com/ftbfs right?
[09:56] <wgrant> persia: I believe the bug is for tracking things which aren't due to Soyuz not detecting depwait properly.
[09:57] <wgrant> So that list is excessive.
[09:58] <persia> Fair enough.  Some stuff is known hard as well: http://wiki.debian.org/ArmEabiProblems
[10:00] <doko> persia: so for which one did I file a bug mentioned in the wiki?
[10:01] <persia> doko, None.
[10:01] <doko> persia: yes the tracker is meaningless for now
[10:01] <doko> cjwatson: yes, will do
[10:02] <cjwatson> thanks
[11:47] <Ademan> is there a way to modify the current volume of the system via dbus? (maybe by accessing the volume control applet?)
[11:55] <tjaalton> Riddell: looks like libxi was autosynced because the old package version was wrong (should've been -1ubuntu6 instead of -2build1), so I'll upload a new version shortly. It'll have XInput.h again
[12:02] <Riddell> tjaalton: so we deliberatly differ from Debian and want the heard in that package?
[12:03] <tjaalton> Riddell: yes, upstream moved it while preparing input properties
[12:03] <Riddell> tjaalton: thanks, I'll look out for your fix and retry the packages that are failing then
[12:10] <tjaalton> Riddell: yep, it will be uploaded soon
[12:21] <soren> Err... Can two cores in a Core 2 Duo run at different speeds?
[12:22] <soren> I'm thinking "no", but:
[12:22] <persia> soren, Not last time I read the spec, although if they could it might save power.
[12:22] <soren> $ grep "cpu MHz" /proc/cpuinfo
[12:22] <soren> cpu MHz		: 1596.000
[12:22] <soren> cpu MHz		: 2394.000
[12:22] <persia> Is this a very new chip?
[12:22] <soren> Not at all.
[12:22] <soren> model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
[12:23] <persia> Well, that's special.
[12:23]  * soren suspects /proc/cpuinfo of lying.
[12:24] <persia> Is it generated atomically?  Maybe you hit a race condition.
[12:24] <soren> Oh,  it's consistent.
[12:24] <soren> /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq tells the same story, even.
[12:31] <directhex> core 2 can scale each core independently
[12:32] <directhex> early athlon64 x2 can't. i'm not sure about other chips beyond those two
[12:34] <cjwatson> doko: could you score up libtool on armel, please?
[12:34] <cjwatson> doko: the previous version misbuilt amusingly
[12:35] <doko> cjwatson: done
[12:35] <cjwatson> thanks
[12:39] <tjaalton> Riddell: uploaded
[12:50] <soren> directhex: Really? That's pretty cool. Thanks.
[12:55] <ogra> hrm, no seb128
[12:57]  * ogra wonders if its sane to add a libxi-dev dependency to gnome-c-c
[12:57] <ogra> it FTBFS due to it apparently
[12:58] <Riddell> ogra: is that the same problem I've had
[12:58] <Riddell> XInput.h went temporarily missing
[12:58] <Riddell> but tjaalton just added it back
[12:59] <ogra> Riddell, ah
[12:59]  * ogra gives back g-c-c on arm then 
[12:59] <ogra> Riddell, ta
[13:20] <directhex> soren, whic is why i have multiple cpufreq applets in my gnome panel
[13:20] <directhex> soren, perhaps it's a good thing my itanium2 box has no frequencsy scaling though, i don't have a monitor big enough for one applet each
[13:25] <soren> directhex: Yikes. How many cpus?
[13:26] <directhex> jms@orac:~> grep -c ^processor /proc/cpuinfo
[13:26] <directhex> 256
[13:27] <geser> and you for each an applet in  your panel?
[13:27] <geser> you have *
[13:29] <directhex> geser, not on that system
[13:29] <directhex> geser, one bar per cpu in htop though. needs a tiny font...
[13:39] <jdong> directhex: ha that's nasty, I remember pulling up Windows Task manager on one of the megacomputers at work.
[13:39] <jdong> the CPU graph tab was.... interesting....
[13:40] <directhex> windows runs on megacomputers? :o
[13:40] <jdong> apparently :-/
[13:40] <jdong> it was around 64 processors or so
[13:40] <jdong> dunno any more details about that, I barely had task manager access on the system
[13:41] <directhex> hm. itanic?
[13:41] <directhex> don't know of any windows x86 kit with that many cores
[13:42] <jdong> directhex: yeah I think it was IA64
[13:42] <jdong> we probably won't see x86 Windows like that until 2008 HPC
[13:47] <NCommander> infinity, ping?
[13:57] <directhex> jdong, for the hordes of hpc windows users *snicker*
[14:01] <jdong> directhex: :D
[14:10] <NCommander> directhex, mono got uploaded last night
[14:11] <directhex> NCommander, your armel-patched 1.9.1-4ubuntuwhatever?
[14:11] <NCommander> yeah
[14:11] <NCommander> WOrked
[14:11] <directhex> excellent. please b.d.o it
[14:13] <NCommander> b.d.o?
[14:13] <NCommander> oh
[14:13] <fta2> kees, i tested your native 64b flash, there's a problem with libuuid1, flash expects it in /usr/lib, but it's in /lib so it needs a symlink
[14:22] <slangasek> Riddell: are you on top of the kubuntu uninstallabilities in jaunty?  livecds obviously won't build right now
[14:23] <Riddell> slangasek: yeah, things were blocked on that libxi missing header, should be able to get more sorted now
[14:23] <slangasek> ok, cool
[14:23] <fta2> kees, hm, nm. this box had nspluginwrapper installed. it worked after purging nspluginwrapper+flashplugin-nonfree.
[14:33] <seb128> fta2: hi?
[14:35] <fta2> seb128, hi, yep, i saw for cairo, i've been busy lately
[14:35] <fta2> and a new cairo is out
[14:35] <seb128> fta2: ok, are you interest to look into the update or should I do it?
[14:36] <fta2> i'll try to do it tonight
[14:39] <seb128> fta2: ok, thanks, debian has the new version in experimental so it would be nice to use that to do the update
[14:39] <Riddell> slangasek: on the kde 3 side the problem seems to be liblualib50-dev mysteriously moving to universe, ok for me to move back to main?
[14:39] <fta2> i have a problem with our libjpeg. it's old and insufficient for firefox (and all moz products) so we are using in-source since hardy. now, working on chromium, our lib is also failling some tests (they are using the lib from mozilla).
[14:40] <directhex> is ubuntu libjpeg using the most recent upstream, i.e. does moz using a svn snapshot?
[14:40] <fta2> upstream is dead, last version is from 1998 and mozilla continued to improve/fix it since
[14:40] <fta2> sse/sse2/mmx support, some crashers, etc..
[14:41] <fta2> it's much faster than ours
[14:41] <fta2> btw, ours make ff crash during printing
[14:41] <directhex> API/ABI compat?
[14:41] <fta2> i think so
[14:43] <Keybuk> libtool (2.2.4-0ubuntu5) jaunty; urgency=low
[14:43] <Keybuk> cjwatson: do you have a bug# for that?
[14:43] <directhex> jms@destiny:~$ apt-cache rdepends libjpeg62 | wc -l
[14:43] <directhex> 603
[14:43] <directhex> be sure
[14:44] <slangasek> Riddell: sure, no objections here if it was in main before
[14:45] <fta2> directhex, i referenced ~110 patches from mozilla, on top of the last known upstream version. but it's difficult to isolate the old patches, coming from merges during the netscape->free-the-lizard migration
[14:46] <fta2> I would like firefox and the future chromium to use our system jpeg but it's only possible if we integrate some of those patches
[14:47] <persia> fta, regarding chromium, have you entered into a naming discussion with the chromium BSU people?
[14:47] <directhex> fta, if it's ABI-incompat, then you need to make sure all 600-odd packages that dep it rebuild against your new one. if it's api compat, you need to deal with hundreds of devs who want to kill you
[14:48] <directhex> fta, have you spoken with the debian people? better to minimize divergence in libs
[14:49]  * persia remembers a number of packages having issues with system libjpeg, and suspects there may be some possibility for coordination.
[14:53] <cjwatson> Keybuk: no, it was following a build failure
[14:53] <cjwatson> Keybuk: (dictd)
[14:53] <cjwatson> Keybuk: it only broke on armel due to the weird way the bootstrap was done
[14:55] <cjwatson> Keybuk: i.e. it was done initially in a sort of vaguely Debianish chroot that had /bin/sh -> bash, so libtool thought "hey, /bin/sh is good enough" and hardcoded that in /usr/bin/libtool
[14:55] <cjwatson> Keybuk: when the chroot was fixed/updated to have /bin/sh -> dash, that broke
[14:55] <Keybuk> cjwatson: hmm, libtool should be ok with dash too though, right?
[14:56] <cjwatson> apparently not, no
[14:56] <cjwatson> doesn't support var+=value
[14:56] <Shanix> hi all, question about a tool called: conga used for control clustering, the only page that I found is https://wiki.ubuntu.com/UbuntuFeistyHAClusters
[14:56] <cjwatson> Keybuk: http://launchpadlibrarian.net/19676627/buildlog_ubuntu-jaunty-armel.dictd_1.10.11.dfsg-2ubuntu2_FAILEDTOBUILD.txt.gz
[14:57] <Keybuk> cjwatson: could you file a bug
[14:57] <Shanix> which says at unresolve
[14:58] <Shanix> unresolved issue:     * conga packaging complexity and licensing (GPL) since it links with openssl.
[14:58] <Shanix> any news on that?
[15:02] <cjwatson> Keybuk: ok, bug 299931
[15:02] <Keybuk> thx
[15:02] <cjwatson> Keybuk: (BTW, the practical effect of my change AFAIAA is simply to make armel consistent with the other arches)
[15:03] <Keybuk> indeed
[15:03] <Keybuk> it surprised me that you had to force bash and it wasn't ok with dash
[15:03] <Keybuk> libtool's _supposed_ to be the very model of a portable shell script ;)
[15:03] <Keybuk> and dash would make it a lot faster
[15:04] <fta2> directhex, persia, as debian didn't care to do it in >10 years, it's safe to assume that i can experiment on my side and propose to debian later. too bad we don't have a regression test suite for the whole desktop to track eventual regressions.
[15:05] <persia> fta, For jpeg, yes.  For chromium, I do encourage you to speak with the chromium BSU people.  I suspect that it's easier to get it right the first time.
[15:05] <cjwatson> Keybuk: well, it's using bash on every other architecture right now :)
[15:05] <cjwatson> otherwise I wouldn't have made that change
[15:06] <Keybuk> I'm not arguing that point :p
[15:06] <cjwatson> defending myself against an imagined charge, perhaps :)
[15:12] <liw> Keybuk, does MoM remove .git from a source package? looking at lockfile-progs, the Debian .tar.gz seems to have it, the MoM-generated Ubuntu one does not
[15:12] <Keybuk> not deliberately
[15:12] <Keybuk> it always favours the ubuntu .tar.gz though
[15:13] <Keybuk> so if Debian's .orig.tar.gz has a .git and Ubuntu's doesn't, the result won't
[15:13] <Keybuk> (since there's no point providing a merge that you can't upload due to md5 sum change :p)
[15:14] <liw> it's a native package so in this instance the tarball is always re-created, as far as I can see
[15:15] <Keybuk> hmm
[15:15] <Keybuk> it rarely cares about that ;)
[15:15] <Keybuk> oh, wait
[15:15] <Keybuk> isn't lockfile-progs one of the spethial ones
[15:15] <Keybuk> with extra chest-thumping
[15:15] <liw> but yeah, the current tarball in ubuntu doesn't have .git
[15:15] <Keybuk> the Ubuntu one isn't even in the same version series as the debian ones
[15:15] <liw> I don't see why Debian has .git in there, I'd consider that a bug
[15:15] <Keybuk> right
[15:15] <Keybuk> ignore that entierly
[15:15] <liw> Keybuk, oh?
[15:15] <Keybuk> that merge is bogus
[15:16] <Keybuk> the Ubuntu maintainer uploaded 0.1.11 with the version 0.1.11ubuntu1
[15:16] <Keybuk> which meant that when the next Debian version was 0.1.11-0.1
[15:16] <Keybuk> the Ubuntu version was *still* higher
[15:16] <liw> should it be marked somewhere, somehow, so it gets dropped off the MoM list?
[15:16] <Keybuk> so the maintainer merged with 0.1.11ubuntu2
[15:16] <Keybuk> I could blacklist it :)  but I felt it was unsporting
[15:17] <Keybuk> blacklisted
[15:17] <asac> pitti: i did ppp and network-manager-pptp SRU
[15:18] <asac> pitti: i uploaded -pptp twice to intrepid-proposed ... so in case it shows up two times, take the last upload
[15:18] <asac> ok off again
[15:22] <Keybuk> libtool should so support --without-included-libtool
[15:22] <Keybuk> to make it use /usr/bin/libtool instead of generating its own
[15:22] <Keybuk> gettext can do it
[15:23] <fta2> persia, for chromium, i'm in frequent contact with upstream, and i try to upstream my patches when they are ready.  what are "chromium BSU people" ?
[15:23] <persia> fta, It's the upstream that handles the package named "chromium" in Ubuntu.
[15:24] <persia> It's a game called "chromium BSU".  I suspect that working together to determine package names early will lead to the least stress later.
[15:24] <persia> One of the members of the upstream chromium BSU team is also a member of the Debian Games team, so there's close coordination available at all levels for that package.
[15:49] <ahasenack> I have mysql installed for test purposes, i.e., I only need it now and then. I ran "update-rc.d -f mysql remove" and
[15:50] <ahasenack> that prevents it from starting on boot, most of the time
[15:50] <ahasenack> when there is an update, I get it, but the update marks it again to start at the next boot
[15:50] <ahasenack> I checked /etc/default and there is no *mysql* file there
[15:50] <Keybuk> ahasenack: don't use update-rc.d
[15:50] <persia> ahasenack, That's a bug.  initiscripts should be conffiles, and not autostomped on boot.
[15:50] <ahasenack> so, what's the proper way to have it installed but not started during boot?
[15:50] <Keybuk> persia: no, it's not
[15:50] <persia> Keybuk, No?
[15:51] <Keybuk> he's using a tool only intended for postinst scripts
[15:51] <persia> Ah.  Right.
[15:51] <ahasenack> Keybuk: what's the proper way?
[15:51] <Keybuk> ahasenack: use a tool like sysv-rc-conf or bum
[15:51] <ahasenack> Keybuk: that's the "official" ubuntu way?
[15:52] <ahasenack> Keybuk: just checking, because I don't have them installed (hardy)
[15:52] <ogra> or just mv S* K*
[15:52] <ogra> then the distro tools will leave it alone
[15:52]  * NCommander summons infinity 
[15:53] <Keybuk> cjwatson, BenC: if it's ok, I'd like to own the module-init-tools and initramfs-tools merges
[15:55] <BenC> Keybuk: fine by me
[15:55] <liw> if the only reason to keep a package as a merge is to retain Ubuntu-specific debian/changelog entries, it can be turned into a sync, right?
[15:55] <Keybuk> liw: right
[15:57] <cjwatson> Keybuk: fine by me
[15:57] <liw> hm, I remember having to do something to get requestsync to work with my mail setup
[16:05] <liw> anyone here understand X events, GTK, or synergy? https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/293589 is need of someone who knows things
[16:08] <jg> BenC: I gather you also have a Latitude Xt...
[16:13] <cjwatson> cody-somerville: could you change xubuntu.jaunty/STRUCTURE to say 'include platform.jaunty' rather than 'include platform.intrepid', please?
[16:13] <cody-somerville> cjwatson, certainly
[16:14] <cjwatson> superm1: could you change mythbuntu.jaunty/STRUCTURE to say 'include platform.jaunty' rather than 'include platform.intrepid', please?
[16:14] <superm1> cjwatson, sure
[16:14] <cjwatson> thanks to you both
[16:14] <directhex> well they weren't gonna say NO! were they?
[16:20] <cjwatson> directhex: no reason not to be civil :)
[16:31] <BenC> jg: yeah
[16:31] <jg> BenC: turns out that most of the device's functionality is getting most of the way through the usbhid system.  evtest is quite enlightening...
[16:35] <jg> BenC: You have to move X out of the way to see the results.
[16:36] <BenC> jg: do you have anything to test with?
[16:36] <NCommander> anyone around who's in the mood to rescore stuff?
[16:36] <jg> BenC: first step is to get the events out of the kernel properly.
[16:37] <jg> The data isn't being entirely correctly decoded.
[16:37] <jg> and additional stuff needs to be sent up for X to deal with.
[16:37]  * NCommander turns on the buildd admin like
[16:37] <NCommander> *light
[16:37] <jg> A touch is not just x/y, but includes size information.
[16:37] <BenC> jg: it is definitely all HID stuff though, right/
[16:38] <jg> BenC: I think so.  I'm under NDA, but I've not received the specs yet.
[16:38] <jg> evtest makes me think it's a pretty simple extension to where we are.
[16:39] <Mithrandir> doesn't mpx implement a lot of what you're talking about, with blob events and all?
[16:39] <jg> Mithrandir: no blob support yet.
[16:39] <jg> also nothing in the X driver for devices using evdev.
[16:40] <jg> Peter's demo was on a diamond touch table with spit and bailing wire.
[16:42] <Mithrandir> oh? http://wearables.unisa.edu.au/mpx/?q=node/88 claims otherwise, but that might just not be merged?
[16:43] <jg> blobs were a hack, and not merged.
[16:43] <jg> time to make blobs real....
[16:43] <jg> The Latitude XT is interesting precisely because it is the first multitouch screen with blob kind of reporting.
[16:45] <cjwatson> NCommander: would be better to say what you want rescored, so that people know what they're letting themselves in for
[16:45] <NCommander> Can the buildd admins please rescore x11-utils
[16:46]  * NCommander tries to find the rest of the to be rescored list
[16:46] <jg> Diamond Touch tables are a bit hard to come by...
[16:46] <jg> Mithrandir: we're starting work on an XInput extension v. 2 to do this right.....
[16:56] <Mithrandir> NCommander: x11-utils/jaunty/armel rescored
[16:56] <NCommander> Thank you
[17:18]  * kees scratches his head
[17:18] <kees> what's responsible for putting utmp in /etc/group ?
[17:20] <rtg> cjwatson: can you tell me what privileges are conferred by being a member of ubuntu-drivers in Launchpad? I'd really like kernel devs to be able to make their own release nominations. Otherwise myself or ogasawara has to approve/decline all of them.
[18:04] <savid> So, I've created a patch for a certain app that I've hacked,  and I've used dpkg-buildpackage to re-build it.  How can I install the new deb without having update-manager think that the package needs updating?
[18:08] <highvoltage> http://no-name-yet.com doesn't go to ubuntu.com anymore :/
[18:08] <highvoltage> mdz: are you there?
[18:26] <slangasek> kees: is utmp not a base-passwd group?
[18:29] <kees> slangasek: ah, base-passwd.  that's what I was looking for.  someone opened a bug saying base-files failed to install due to missing the utmp group (!?)
[18:29]  * slangasek shrugs? :)
[18:29] <kees> yeah
[18:29] <slangasek> base-files does require the utmp group to be present, yes
[18:30] <slangasek> and it's one of the groups listed in /usr/share/base-passwd/group.master
[18:30] <slangasek> so "user error"
[18:30] <slangasek> or "bug in evil non-default tool"
[18:32] <ogra> tedg, mind if i add a hackish patch to g-p-m to turn off Werror in configure to make the build survive on armel (assuming you will package a new g-p-m anyway soon)
[18:34]  * ogra wonders what will be left of liboil once doko is done :)
[18:34] <mvo> savid: please give it a different version number than the one in the archive
[18:35] <doko> ogra: it fails on the buildd only, so just building without having access to this hardware is ... nice
[18:35] <ogra> send it over if it doesnt take a day to build
[18:35] <ogra> i have HW
[18:36] <nxvl> kirkland: congratulations!
[18:36] <nxvl> well, almost
[18:36] <nxvl> :P
[18:45] <tedg> ogra: Uhm, okay.  If you want you can upgrade to 2.24.2 while you're at it :)
[18:45] <ogra> tedg, to busy fixing arm FTBFS atm
[18:47] <tedg> ogra: NP, I'll get to it.  If you just propose your changes as a merge: https://code.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging-2.23
[18:47] <ogra> tedg, nh, my change should be dropped asap and get a proper fix
[18:47] <ogra> *nah even
[18:48] <ogra> something included from gstreamer produces warnings which g-p-m automatically turns into errors ... richard constantly forgets to switch Werror off in releases
[18:48] <ogra> i had to remind him each release :)
[18:50]  * ogra has to test-build anyway first ... takes quite a while on ARM
[18:54] <fta> persia, sorry for the confusion, when i said chromium, i meant the open source version of google chrome, https://edge.launchpad.net/chromium-project; of course, i already knew there's a game named chromium in ubuntu, which is really unfortunate.
[18:55] <ogra> fta, same prob as epiphany ...
[18:57] <savid> mvo, by "different version number" do you mean just the version # in the .deb file name?
[19:05] <tedg> ogra: Yeah, we fixed the first couple FTB errors for Sparc but got stuck on the GStreamer one.
[19:19] <mvo> savid: just update the debian/changelog file with a new version nubmer before you run debuild
[19:19] <savid> awesome, thanks
[19:50] <NCommander> can a buildd admin please rescore kde4libs/armel ?
[19:52] <Mithrandir> NCommander: given-back
[19:52] <Mithrandir> (and rescored)
[19:53] <NCommander> Mithrandir, we just uploaded it, why did it have to be given back?
[19:53]  * ogra wonders if the armel machines already start glowing :)
[19:54] <Mithrandir> NCommander: which version did you just upload?
[19:55] <Mithrandir> 4:4.1.73-0ubuntu5 ?
[19:55] <NCommander> [ubuntu/jaunty] kde4libs 4:4.1.73-0ubuntu6 (Accepted)
[19:55] <NCommander> Damn it
[19:55] <ogra> ouch
[19:55] <NCommander> can you kill 0ubuntu5?
[19:55] <NCommander> Or rescore it so it goes last?
[19:55] <NCommander> We'll loose a buildd for six hours if it builds
[19:56] <Mithrandir> I don't think it'll be built at all, since the build will be superseded by 0ubuntu6
[19:56] <Mithrandir> 0ubuntu6 has a higher score
[19:56]  * ogra wonders if cacao every finishes ...
[19:56] <ogra> *ever
[19:57] <ogra> cant take that long to make hot beverage
[20:21] <shay> hey
[20:21] <shay> no Xen support on 8.10?
[20:24] <ion_> /boot/config-2.6.27-7-server:CONFIG_XEN=y
[20:24] <shay> and compile kernel?
[20:25] <ion_> No
[20:25] <shay> $ uname -r - 2.6.27-7-server
[20:25] <shay> and no /proc/xen/
[20:26] <ion_> Dunno then.
[20:27] <shay> and trying to modprobe all the xen-* modules on /lib/modules/`uname -r` give a "No such device" error
[20:28] <shay> I would like to know if there's anyone involved in the development of Xen on Ubuntu, I would like to help in any way i can
[20:29] <Daviey> shay: check the kernel mailing list.. it's been spotted :)
[20:30] <shay> will check, thanks
[20:50] <ogra> bah ...
[20:51]  * ogra was wondering why his g-p-m configure mangling didnt work ... running autoconf at buildtime is mean
[20:51] <Mithrandir> no, it's wonderful.
[20:51] <ogra> bah
[20:51] <wasabi> So ... Intrepid has this Samba bug where Winbind crashes every few minutes. It seems to be fixed in 3.2.4 on jaunty. It completely makes winbind useless in Intrepid.
[20:52] <ogra> only if you think of it while applying evil hacks :P
[20:52] <wasabi> I'm not sure if it was a specific fix between 3.2.3 and 3.2.4 that solved it.
[20:52] <wasabi> What would bt eh best way to approach this? Try to pinpoint the exact problem and a quick patch to get in -updates, or advocate that we just port 3.2.4 to -updates?
[20:53] <Mithrandir> wasabi: how big is the diff from .3 to .4?
[20:53] <wasabi> eh. dunno.
[20:53] <wasabi> checking
[20:53] <wasabi> http://us1.samba.org/samba/history/samba-3.2.4.html
[20:54] <wasabi> Well, they know they fixed the winbind crash, at least.
[20:54] <wasabi> And it looks like very few other things are not 'fixes'
[21:01] <doko> hmm, I forgot to turn off the testsuite run for the cacao-oj6 armel build ... lets look again next week for the results
[21:03] <ogra> eeek
[21:03] <ogra> it runs since yesterday already
[21:48] <NCommander> lamont, ping, I need your help with xvfb again
[21:55] <directhex> cjwatson, i think it was you i spoke with before. did you favour including mono-debugger in main, rather than dropping mono-dbg to universe?
[21:55] <cjwatson> I did say something like that, although I haven't looked at mono-debugger at all
[21:56] <directhex> cjwatson, well, the package in jaunty currently doesn't serve much purpose. i'm still planning for release, which if all goes according to play means mono-debugger (and mono) 2.2, where jaunty has 0.6 right now
[21:56] <cjwatson> but all other things being equal it's the approach I'd normally prefer ... stuff in main should come with debugging support as a general principle
[21:57] <directhex> debian NEW delays are really messing us around
[22:02] <NCommander> directhex, just do a fast sync (upload with -0, or 1~ubuntu1), and then when it goes through new, it gets clobbered by the package ins id
[22:03] <directhex> NCommander, huh? explain?
[22:03] <NCommander> directhex, you can version an upload so that it will get clobbered by the next sync from Debian. A few packages in main do this, and I've done it for the Desktop team
[22:03] <NCommander> (or just give it a 0ubuntu1, then sync once its in Debian by hand)
[22:04] <directhex> NCommander, will sync by hand. this is a monumental project. about 100 syncs/merges will be needed (or ubuntu patches applied) after mono 2 syncs in. and we need to rebuild all those things in experimental
[22:05] <NCommander> so what's stopping you from uploading as 0ubuntu1?
[22:06] <directhex> NCommander, duplication of work. i don't see why motu and core-devs should alter 100 packages by hand, this far before release, when they can just nab the needed changes from debian
[22:06] <NCommander> I thought you were waiting on a few individual packages :-P!
[22:35] <ScottK> NCommander: Even trickier is upload it as -0build1 and autosync will clobber it after it gets out of New.
[22:35] <NCommander> ScottK, well, I would upload as 0~ubuntu1, or 1~ubuntu1
[22:35] <NCommander> (0~ubuntu1 if you expect a non-maintainer new upstream release upload)
[22:35] <ScottK> Well you'd still have to ask for it to be sync'ed over then.
[22:44] <NCommander> directhex, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506260
[22:44] <NCommander> ScottK, not if it was 0~ubuntu1
[22:44] <NCommander> (note the tide)
[22:47] <directhex> NCommander, i saw. thanks
[23:11] <cjwatson> NCommander: ScottK is correct - the "ubuntu" substring in a version is what inhibits autosyncing
[23:12] <cjwatson> in fact that is the entire root of the purpose of putting "ubuntu" in version numbers
[23:21] <NCommander> cjwatson, oh, I thought only XubuntuX prevented sync, X~ubuntuX would still work
[23:22] <directhex> okay, i've talked with meebey..... sod debian NEW... i'd like to get people able to work on the packaging transition ASAP, which means uploading a mono stack somewhere people can work with
[23:24] <cjwatson> NCommander: no, it's just the "ubuntu" substring. that simple.
[23:24] <NCommander> cjwatson, ah, you learn something new every day :-)
[23:24] <cjwatson> I don't know where the ~ubuntu idea came from
[23:24] <NCommander> directhex, I can setup a Debian PPA for you using OBS
[23:25] <ldiamond> Did anyone here ever build Synergy2 from source? The project seems to be dead and buggy, I was wondering if anyone wanted to start a similar project (from scratch or from synergy).
[23:25] <directhex> so. NCommander i've got an OBS repo. want mono 2.0 for RHEL5? ^_^
[23:27] <directhex> NCommander, okay then. let's get this party started. it's gonna be pretty major. i suppose i should mail -devel and -motu about it
[23:27] <NCommander> directhex, well, I need to setup the infrastructure
[23:27] <NCommander> I can provide you with x86, and maybe amd64 builders
[23:27] <directhex> NCommander, i mean uploading a 0ubuntu1 to jaunty.
[23:27] <NCommander> for Debian etch, lenny, or sid
[23:27] <NCommander> Oh
[23:28] <NCommander> So what do you need me for?
[23:28] <directhex> you specifically? well, nothing. you started offering ME things!
[23:28] <directhex> NCommander, though if you want to help with the packaging transition, then that'd be sweet ;)
[23:29]  * directhex preps a 0ubuntu1
[23:29] <NCommander> sure, I'll help
[23:29] <NCommander> directhex, LP is down, remember?
[23:29] <directhex> oh cocks
[23:29] <ldiamond> Nobody know about any KM/KVM soft switch project around (besides Synergy)
[23:29] <directhex> back in half an hour though, no?
[23:29] <cjwatson> at least the bug system is back up already
[23:32] <cjwatson> well, up-ish
[23:33] <cjwatson> yeah, it's fine for me
[23:33] <cjwatson> oh, admittedly I'm using edge