[00:01] <slangasek> calc: so mdz_'s suggestion wrt bugs that you're working on but aren't actually RC is to use the "in progress" state.  Does this sound sufficient for your needs?  If so can you please go through https://launchpad.net/ubuntu/+milestone/hardy-alpha-1, dropping the milestone and changing the state for any of these OOo bugs of yours that you don't think are RC?
[00:01] <slangasek> (for the ones that are RC, feel free to leave them there since there's still some ongoing discussion about how to handle, I'll be happy to shuffle them around for you when the time comes)
[00:39] <bigon> hi, is someone working on the merge of dpkg?
[00:39] <evand> bigon: soren took care of it.  It's in the process of being tested.
[00:39] <bigon> ok thx :)
[00:39] <evand> anytime
[00:40] <bigon> is there a place where I can get the pkg to test it too?
[00:41] <evand> deb http://ppa.launchpad.net/shawarma/ubuntu hardy main
[00:41] <ion_> Will my system break by testing that? ;-)
[00:41] <bigon> thx (again)
[00:42] <evand> Reports so far have been positive, from the two I've seen, but your milage may vary.
[00:43] <slangasek> ion_: yes, but we're asking for testing anyway because we're sadists ;)
[00:44] <ion_> I’ll install it after this episode of B5.
[00:58] <ion_> evand: I installed dpkg from the PPA, removed another package and reinstalled it. No problems so far.
[00:59] <evand> ion_: soren would be the person to tell.  I'm just the messenger.
[01:00] <ion_> soren: I installed dpkg from the PPA, removed another package and reinstalled it. No problems so far.
[01:15] <ion_> soren: apt-get upgrade worked as well.
[01:16] <ion_> soren: Including the triggers
[01:36] <bigon> soren: I've quickly read the debdiff of dpkg (between debian and your last version) and it seems that changes in some files (lib/showpkg.c, lib/tarfn.c and src/configure.c) are mostly cosmetical, it's maybe a good idea to resync these files with the debian one
[01:50] <calc> slangasek: yea that sounds good enough for me
[02:10] <calc> slangasek: i moved my bugs over to in progress from the milestone if you notice any left laying around elsewhere ping me :)
[03:32] <slangasek> calc: looks good, thanks
[03:43] <calc> is there a way to determine what is holding a mount open?
[03:43] <StevenK> fuser -m
[03:45] <calc> its a bind mounted /proc and none of the processes look like they could actually be the culprit
[03:45] <calc> since they were running before the bind mount happened
[03:46] <StevenK> calc: lsof | grep ?
[03:46] <calc> StevenK: nothing shows up with lsof -n | grep /path-to/proc
[03:47] <calc> can the kernel get confused and think mmapped files for real proc are on the bind mount version?
[03:49] <StevenK> I'm not sure.
[03:50] <calc> there are only 11 processes running that started today
[03:51] <calc> and of those only [pdflush] are by root which is who owns the chroot dirs
[03:54] <lamont> slangasek: core-dev app goes to motu-council?
[03:54] <slangasek> lamont: so the wiki tells me
[03:54] <lamont> how very interesting.  OK
[03:54] <slangasek> lamont: and several apps over the past few months have done so
[03:54]  * lamont hasn't looked at the process in some time
[03:55] <lamont> I guess I'll do a group repoly
[03:55] <lamont> "steve knows processes far better than I do."
[03:55] <lamont> :-)
[03:55]  * slangasek snorts
[03:56] <Hobbsee> lamont: it does, yes.
[03:56]  * lamont is glad he went through the old core-dev process. :-)
[03:57]  * bddebian is glad he doesn't have to worry about it :)
[03:57]  * StevenK was one of the last to go through the old way
[03:58] <lamont> StevenK: did you hire in that long ago>?
[03:58]  * Hobbsee was also one of the last
[03:58] <StevenK> I became a core-dev long before I applied for a position at Canonical
[03:59] <Hobbsee> oh hang on, no, i was one of the new bunch
[03:59] <StevenK> Right
[04:00] <StevenK> You had the public humiliati^Wsponsor begging on the m-c list
[04:00] <lamont> StevenK: ah, ok.
[04:00] <Hobbsee> or the sponsors who shoved you into it, if you were unlucky
[04:01] <lamont> Subject: Your message to Motu-council awaits moderator approval
[04:01] <lamont> feh
[04:01] <calc> heh
[04:01]  * lamont tries another address. :-{
[04:02]  * ajmitch looks for list password
[04:02] <StevenK> That reminds me.
[04:02] <lamont> sending it from lamont@u.c instead of lamont@m.c should prolly work, eh?
[04:02]  * StevenK wields listadmin
[04:02] <lamont> StevenK: you might look to see if my mail already made it through first... :)
[04:03] <lamont> in which case you could discard and add me to accepts, instead of accepting and adding. :-)
[04:03] <lamont> nope.
[04:03] <lamont> also held
[04:03]  * Hobbsee wields listadmin too
[04:03] <StevenK> lamont: Different lists, but you talking about it reminded me
[04:03]  * lamont hands StevenK some weights to add to the smacking stick of listadmin
[04:03] <lamont> ah, ok
[04:04]  * lamont waits with baited breath for the next data point on graph2
[04:04] <ajmitch> lamont: sorry, accepted the first
[04:04] <lamont> heh.  np
[04:04] <lamont> the second got blockaded too.
[04:05] <lamont> and mail to the list is more likely to be from lamont@m.c, since I'm too lazy to remember to change it to @u.c
[04:05] <calc> openoffice.org-2.0.4.dfsg.2/ooo-build/patches/src680/cws-hsql1808.diff |  807 ++++++++++   <- fun stuff to port to 3 unsupported versions of OOo
[04:05]  * ajmitch still doesn't see slangasek's mail
[04:06] <lamont> calc: while you're there, please code trampolines for ia64.
[04:06] <lamont> :-)
[04:06] <slangasek> ajmitch: https://lists.ubuntu.com/archives/motu-council/2007-December/000583.html ?
[04:06] <calc> lamont: hahaha yea right ;)
[04:06] <ajmitch> slangasek: considering that I've had dsl issues all day, it wouldn't surprise me if something went funny with my mail
[04:07] <ajmitch> but thanks for the archive link
[04:07] <ajmitch> ah, still in mail queue locally, too many came in at once
[04:22] <lamont>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/libcdb.a(cdb_init.o): relocation R_X86_64_PC32 against `__fxstat@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
[04:22] <lamont> I wonder... do I care?
[04:23] <slangasek> hum, what's linking cdb into a shared lib?
[04:28] <lamont> backport of postfix to dapper (which lacks libcdb.so), on amd64
[04:28] <lamont> and, well, it's, um, crackports after all.......
[04:29] <lamont> and someone would probably shoot me if I backported tinycdb
[04:29] <slangasek> heh
[04:40] <lamont> OTOH, I could do a new backport that drops postfix-cdb on amd64. :-)
[05:28] <lamont> dh_installmenu
[05:28] <lamont> dh_iconcache
[05:28] <lamont> make: dh_iconcache: Command not found
[05:28] <lamont> feh
[05:28] <lamont> so how come ksocrat built on the other 6 architectures?
[05:29] <Hobbsee> lamont: use dh_icons now
[05:29] <Hobbsee> lamont: did they build before the debhelper changes?
[05:29] <lamont> much
[05:29] <lamont> like during gutsy
[05:29] <Hobbsee> and this is a belated gutsy build?
[05:30] <lamont> hppa still needs to build about 2000 packages that everyone else built in gutsy
[05:30] <Hobbsee> true
[05:30] <lamont> or feisty, or (in some really sad cases), edgy
[05:30] <Hobbsee> do you plan to import them in, or?
[05:30] <Hobbsee> oh dear.
[05:30] <Hobbsee> then again, there are some builds scheduled for hoary still, so...
[05:30] <StevenK> lamont: I can upload a fix0red ksocrat if you wish
[05:31] <lamont> I just happened to notice it because I was the last one to upload it, so I got the cranky-buildd mail
[05:31]  * lamont has no clue what ksocrat does, or why he should care, other than in the most general and non-specific of terms
[05:31] <lamont> (the caring that is.  no clue at all what it is/does...)
[05:31] <Hobbsee> Description: English/Russian and Russian/English Dictionary
[05:32] <Hobbsee>  Socrat is a simple English/Russian and Russian/English dictionary
[05:32] <Hobbsee>  written for Qt3/KDE3.
[05:32] <Hobbsee> right then
[05:32] <StevenK> Sounds like it's users number in ... wow, the tens
[05:32] <lamont> Hobbsee: I think that says something about how much I care, since apt-cache is beyond the limits atm.... :P
[05:33] <lamont> StevenK: oh, sure... rub in that it has more users than hppa/ubuntu
[05:33] <Hobbsee> lamont: i'd say "who cares about it in gutsy anyway", and ignore it
[05:33] <lamont> this is hardy
[05:33] <Hobbsee> oh
[05:33] <StevenK> Ha
[05:33] <lamont> it didn't make the cut for gutsy... they slammed the door on us.. :-)
[05:33] <Hobbsee> well, that's what i was thinking
[05:34] <lamont> but if StevenK uploads a new version, then everyone gets new love.  and the package will fail during autotest...
[05:34] <StevenK> It will?
[05:34] <lamont> hrm... maybe we can launch a new autotest run, just to help find all these wonderful new ftbfs packages that debhelper has created...
[05:34] <lamont> well, it doesn't build on hardy, so -autotest will ftbfs........
[05:34] <Hobbsee> lamont: wouldn't be a bad idea.
[05:35] <Hobbsee> then we can throw hopefuls at them
[05:35] <lamont> Hobbsee: but they're not Lions.
[05:35] <Hobbsee> sorry?
[05:36] <Hobbsee> well, true
[05:36] <lamont> I was thinking you were suggesting throwing hopefuls to the lions.
[05:37]  * lamont throws a new util-linux at the fire
[05:39] <Hobbsee> hehe
[05:39]  * Hobbsee smites the evil launchpad
[05:39]  * lamont remembers to build the ubuntu version of util-linux for his home machine, rather than the debian one
[05:40] <Hobbsee> what on *earth* has it done with my portal?  again1
[05:40]  * lamont is in the market for someone who understands autocrap, once he gets around to actually looking at nmap again
[05:40]  * Hobbsee points to StevenK
[05:40] <lamont> Hobbsee: I think you mean "smiteseses"
[05:40]  * lamont hates autocrap
[05:40]  * StevenK ducks out of the way of Hobbsee's pointing
[05:41] <lamont> StevenK: it's probably something simple/stupid
[05:41] <StevenK> I don't know much about autocrap, I try and avoid it.
[05:41] <lamont> git clone git://git.debian.org/~lamont/nmap.git and then figure out why the experimental branch doesn't like me.
[05:41] <lamont> StevenK: I guess I'm less successful in avoidance than you...
[05:41] <lamont> several of my packages use it
[05:45]  * lamont sleeps before he gets keyprints on his face
[05:45]  * Hobbsee replaces lamont's pillow with his keyboard
[05:45] <lamont> feh
[05:46] <StevenK> I can't see typing on a keyboard being very productive
[06:48] <MacSlow> Greetings everybody!
[06:48] <Burgundavia> hey MacSlow
[07:12] <dholbach> good morning
[07:13] <ion_> Good time of day.
[07:14] <dholbach> hi ion_
[07:14] <ion_> Hi
[07:26] <Dooms> hey can any of you guys watch this video i made? And yes im the girl
[07:26] <Dooms> http://youtube.com/watch?v=eXdkyAyOcGo
[07:53] <pitti> Good morning
[07:53] <dholbach> hey pitti
[08:00] <pitti> eek, my fonts in firefox are utterly ugly this morning
[08:00] <stgraber> moin
[08:00] <pitti> doko_: ^ your fontconfig merge?
[08:00] <pitti> hey stgraber
[08:36] <StevenK> Oh sigh, more fallout from this libgcrypt move
[08:37] <StevenK> Revenge!
[08:45] <pitti> StevenK: ?
[08:49] <pitti> eww -- does anyone know how I can get to a VT in current hardy?
[08:49] <mjg59> chvt ?
[08:50] <pitti> no, that doesn't work either
[08:50] <pitti> I get a black screen, and then it switches back to X
[08:50] <mjg59> Switches back to X, or X restarts?
[08:51] <pitti> no, just switches back
[08:51] <pitti> gnome session continues to work fine
[08:51] <mjg59> Hm. How odd.
[08:52]  * pitti tries it after ending the X session, bbl (need to test usplash)
[08:57]  * pitti blames consolekit
[08:57] <cjwatson> pitti: there's a bug linked from the hardy-alpha-1 release notes about that
[08:57] <cjwatson> I blame X personally
[08:58] <pitti> it works under gdm, and stops working when I'm logged in
[08:58] <pitti> cjwatson: ah, thanks
[08:58] <cjwatson> mjg59: I think X is catching the switchaway signal (as it should) and then switching to its own VT rather than the one it's been told to switch to, for some reason
[08:58] <cjwatson> but stracing X made my system hang so I can't get any further
[08:59] <cjwatson> I suppose it *could* be consolekit's fault, but why would switchaway signals be propagating up that far?
[08:59] <cjwatson> I was wondering if it was something to do with the kbd driver
[09:00] <mjg59> cjwatson: stracing should work, providing it's not from within X itself
[09:00] <mjg59> chvt should be sending the signal directly to the kernel
[09:00] <mjg59> At which point the kernel waits for X to release the console (which it does after restoring text mode)
[09:01] <cjwatson> mjg59: I did 'strace -f -o X.trace -s 1024 -p `pidof X`' from a pterm; why would that be any different from sshing in and doing it?
[09:01] <cjwatson> right, but X actually does the VT_ACTIVATE ioctl
[09:01] <mjg59> Not with chvt, surely?
[09:01] <cjwatson> oh, hm, possibly not
[09:02] <mjg59> chvt hits /dev/console directly
[09:02] <cjwatson> but it does have to do that RELDISP thing
[09:02] <mjg59> Yes - I wonder if that's not actually happening properly
[09:02] <mjg59> It shouldn't be able to trigger a switch back to itself
[09:03] <cjwatson> so what do you mean by stracing "not from within X itself"?
[09:03] <cjwatson> do you mean starting the strace while X isn't active?
[09:03] <mjg59> Either sshed in or at a console
[09:03] <mjg59> Did the strace hang immediately, or just when you tried to do something?
[09:03] <cjwatson> I have trouble understanding why this is any different from stracing with output sent to a file from an X terminal emulator
[09:03] <cjwatson> it hung all of X immediately
[09:04] <cjwatson> and there was no output in the file
[09:04] <cjwatson> it may have oopsed the kernel, I'm not sure
[09:04] <mjg59> Right. It ptrace()ed X, then pterm attempted to print the command line
[09:04] <cjwatson> oh
[09:04] <mjg59> Then it deadlocks
[09:04] <cjwatson> sigh, ok, fair point
[09:09] <cjwatson> mjg59: http://people.ubuntu.com/~cjwatson/tmp/X.trace (4MB) - that's from Ctrl-Alt-F1
[09:11] <cjwatson> no other process has its fd 4 (/dev/tty7) open
[09:12] <cjwatson> hmm, but console-kit-daemon does have /dev/console open
[09:13] <cjwatson> pitti: you're right
[09:13] <cjwatson> I can see console-kit-daemon doing:
[09:13] <cjwatson> 5523  ioctl(9, VIDIOC_G_COMP or VT_ACTIVATE, 0x7) = 0
[09:14] <mjg59> cjwatson: Yeah, looks like console-kit
[09:14] <cjwatson> and when killed, the switch works fine (apart from my consoles displaying nothing due to some unknown funtedness)
[09:14] <mjg59> X changes correctly, and then something else immediately reactivates its VT
[09:15] <cjwatson> so consolekit's purpose is to stop us getting to consoles? ;-)
[09:16] <mjg59> More secure that way
[09:20] <pitti> hm, we already had that bug when we introduced CK in gutsy IIRC
[09:20] <pitti> but Ian fixed it back then
[09:21] <mjg59> Looks like the change from ubuntu1 to ubuntu2?
[09:21] <cjwatson> I have 0.2.3-2ubuntu1
[09:21] <mjg59> 0.2.1-1foo, that is
[09:21] <cjwatson> ah
[09:23] <cjwatson> yes, we have the change in ubuntu1 (I think) but the change in ubuntu2 was dropped
[09:25] <cjwatson> somebody reported the same problem in gutsy, and I think bug 131751 is probably mixed up; I asked a question in comments to try to disambiguate
[09:25] <ubotu> Launchpad bug 131751 in xorg-server "Unable to switch Virtual Terminal with C-A-F[1-6] on Intel-based new laptop" [Undecided,New] https://launchpad.net/bugs/131751
[09:25] <cjwatson> if it looks separate, I'll try to disentangle things
[10:01] <lool> pitti: Fonts ugly for me too; fontconfig looks like the culprit indeed
[10:02] <ion_> Ditto
[10:03] <seb128> on my desktop fc-cache SIGSEGV since the update
[10:04] <doko_> cjwatson_: (the installer is the only upx-ucl-beta user) the upx-ucl-beta package is now just an empty dummy package, upx-ucl is now at version 3.01. can that be used directly in the installer?
[10:24] <cjwatson> doko_: I'll give it a try
[10:30] <pitti> seb128: not here on amd64, but fonts are still wrong
[10:30] <seb128> pitti: the crash looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452718
[10:30] <ubotu> Debian bug 452718 in fontconfig "ttf-opensymbol non-installable" [Serious,Open]
[10:31] <pitti> wohoo, glibc 2.7
[10:34] <thom> is 2.7 exciting?
[10:35] <doko_> seb128, lool: the new fontconfig now makes a difference between metric compatible fonts and other fonts; unsure where dejavu ends now. maybe not in metric compatible?
[10:38] <seb128> that sucks
[10:38] <seb128> bug #174373
[10:38] <ubotu> Launchpad bug 174373 in nautilus "[hardy] squares instead of text in nautilus" [Undecided,New] https://launchpad.net/bugs/174373
[10:38] <seb128> that's due to the fontconfig update, I had it too before restarting
[10:40] <seb128> the xchat-gnome taskbar text was replaced by squares
[10:42] <Riddell> pitti: could you look again at MainInclusionReportlibkarma next time you're going MIR?
[10:42] <doko_> lool: you're rpm uploader ... do you know if rpm should work with neoon >= 2.6?
[10:42] <doko_> Riddell: bug number?
[10:42] <Riddell> doko_: bug 89591
[10:42] <ubotu> Launchpad bug 89591 in amarok "Please package Amarok Rio Karma support (--with-libkarma)" [Wishlist,Confirmed] https://launchpad.net/bugs/89591
[10:43] <pitti> Riddell: yes
[10:43] <doko_> Riddell: please subscribe ubuntu-mir (I should post this to u-d-a ...)
[10:44] <Riddell> done
[10:59] <lool> doko_: I know we have a very outdated RPM
[10:59] <doko_> lool: debian as well?
[10:59] <lool> doko_: Presumably a newer RPM would
[10:59] <lool> doko_: Oh yeah, Debian as well
[11:00] <lool> Well the version is recent, but they stopped at 4.2
[11:00] <lool> Basically I'm not sure there's any consensus on which RPM base we should track anymore
[11:02] <lool> doko_: Newer rpm can build without neon
[11:02] <lool> doko_: Since 4.4.2.1
[11:02] <lool> But it seems they dropped the internal copy
[11:04] <doko_> hmm, for now I build with the current db4.6 and keep the neon that debian uses
[11:04] <lool> doko_: I think rpm called from apt or yum doesn't need neon that much, it seems to be used for some webdav stuff
[11:23] <doko_> googling for "suse gfxboot syslinux" points you to launchpad as the first entry ;) cjwatson: do you know an "suse upstream" location for gfxboot?
[11:24] <soren> doko_: It's in the most recent copyright.
[11:24] <soren> doko_: There's not a proper upstream place for it. We extract it from their srpm's.
[11:25] <soren> http://changelogs.ubuntu.com/changelogs/pool/main/g/gfxboot/gfxboot_3.3.39-0ubuntu1/gfxboot.copyright
[11:25] <cjwatson> what he said
[11:25] <cjwatson> I went and looked it up when soren asked a week or so ago :)
[11:26] <doko_> ahh, ok, will add that for syslinux
[11:27] <doko_> ohh, no. they only for 3.31 packages, debian has 3.53 ...
[11:30] <soren> http://ftp.kernel.org/pub/linux/utils/boot/syslinux/
[11:33]  * torkel hugs seb128. You are my hero!!! Thanks a lot!!! (re #173156)
[11:34] <seb128> torkel: you are welcome ;-) Thanks for testing the change
[11:34] <doko_> soren: well, yes, that's *without* the gfxboot patch =)
[11:35] <torkel> seb128: I had to. I don't like thunderbird :-)
[11:35] <mvo> what is the best practise for the "remove stop links" changes? do we submit those to debian?
[11:35] <soren> doko_: Oh, right.
[11:36] <doko_> emailed the maintainer
[11:39] <pitti> mvo: debian doesn't have 'multiuser' update-rc.d
[11:39] <pitti> and IMHO we should get rid of it, too, and replace it with LSB header parsing (Debian's sysvutils has support for that to some degree)
[11:40] <pitti> that's even in one of Keybuk's specs AFAIR
[11:40] <mvo> ok, thanks. so I will forward it for now
[11:52] <cjwatson> doko_: upx-ucl seems to throw an exception while trying to compress our kernels; that said, on looking at an older build log, apparently so did upx-ucl-beta. So I need to investigate some more.
[11:54] <cjwatson> it worked in http://buildd.debian.org/fetch.cgi?&pkg=debian-installer&ver=20070308&arch=i386&stamp=1173520790&file=log
[11:56] <soren> slangasek: Do you plan on doing the keepalived merge?
[11:57] <cjwatson> it broke in Dec 2006 when we switched to 2.6.20
[11:58] <cjwatson> so I guess we don't lose anything by switching to it ;-)
[11:58] <soren> :)
[12:05] <cjwatson> upx-ucl *is* trying - it just can't actually achieve worthwhile compression, so throws an exception
[12:05] <cjwatson> doko_: committed for next d-i upload
[13:59] <dholbach> where did read-edid move to in hardy?
[13:59] <dholbach> it seems its needed for BulletproofX, but not a strict depends somewhere and the read-edid package does not seem to be on hardy/amd64?
[14:01] <ogra> doesnt ddcprobe provide the same ?
[14:01] <dholbach> aha... does not exist on amd64
[14:01] <ogra> ah
[14:01] <dholbach> no BulletproofX for me?
[14:02] <ogra> xresprobe ?
[14:02] <ogra> i think that exists on amd64
[14:02] <dholbach> it does and it's installed
[14:02] <dholbach> but I guess it's not used for that purpose
[14:02] <ogra> not sure if it provides all read-edid gives you
[14:03]  * dholbach dpkg-reconfigures by hand
[14:05] <dholbach> other than having no lum, the new kernel seems fine :)
[14:06] <ogra> for me as well
[14:06] <ogra> i had to recompile vboxdrv though
[14:07] <ogra> since i use it extensively for ltsp and classmate development
[14:21] <cjwatson> I found that b43 was less stable than bcm43xx, although I wasn't sufficiently sure of this to file a bug
[14:21] <cjwatson> (I'm not in the London office enough to get a clear impression of the stability of my laptop's network connection with WPA there)
[14:23] <ogra> i havent even tried wireless yet ... booting and wired is fine though ...
[14:24] <ogra> and i had no lockups yet :)
[14:48] <lamont> cjwatson: given the debhelper changes, I think it makes sense to do a -autotest run, soonish... thoughts?
[15:49] <cjwatson> lamont: no complaints from me about more autotests
[15:57] <slangasek> soren: was planning to, yes.  It's worth bonus points, because upstream "fixed" the ftbfs in the latest version by adding a dep on a different kernel header that we aren't shipping...
[15:57] <soren> slangasek: I forgot what I asked you.. :)
[15:57] <slangasek> soren: the keepalived merge :)
[15:58] <soren> slangasek: Ah, right.
[15:58] <soren> slangasek: We're not shipping it in linux-libc-dev, or do we not have it all?
[16:01] <slangasek> soren: not in linux-libc-dev; it seems to be generated in the Linux upstream source, but I haven't checked too closely since this seems to be the only software on the planet that believes it's supposed to be exported
[16:05] <soren> slangasek: I'm not sure how uncommon that is. I doubt very many other pieces of software will benifit from the various iptables related headers that get to land in linux-libc-dev :)
[16:08] <slangasek> soren: it's not an iptables header that's missing, it's that keepalived wants UTS_RELEASE
[16:08] <slangasek> which everyone else gets by without just fine
[16:10] <soren> slangasek: Sure. I just meant that it's not uncommon to shove stuff into linux-libc-dev that only one software package will need.
[16:33] <soc> hi
[16:34] <soc> atm kernel 2.6.24 can't find the necessary microcode image for using my intel3946abg wlan wit iwlwifi?
[16:34] <soc> am i supposed to download that manually?
[16:34] <soc> or ist just a package in the repo missing?
[16:35] <ivoks> look for restricted modules
[16:35] <soc> can't fin one  ...
[16:35] <soren> ...it's not there yet, afair.
[16:35] <soc> ivoks: do you see it yet?
[16:35] <soc> ah ok thanks+
[16:35] <ivoks> i don't use hardy yet
[16:36] <soc> would it be possible to manually download it to test the functunality?
[16:36] <soc> btw, why doesn't sudo work without network?
[16:36] <ivoks> misconfigured /etc/hosts?
[16:37] <soc> didn't change anything
[16:37] <soc> what should i look for?
[16:37] <ivoks>  /topic :)
[16:37] <soc> btw, will users automatically migrated to pulseaudio, or will they have to decide that for themselves?
[16:39] <Hobbsee> automatically, i'd assume
[16:39]  * Hobbsee wonders when we get linux-ubuntu-modules
[16:39] <mekius> hey, trying to modify the default boot menu on the ubu livecd, where are the source files for the menu translations.  the tr and hlp files in the isolinux dir seem to be some compiled binary form
[16:40] <mekius> anyone know where these translation files are stored?
[16:41] <lamont> slangasek: linux-libc-dev is from the kernel, yes.
[16:41] <slangasek> lamont: that... wasn't the question? :)
[16:42] <lamont> heh
[16:42] <lamont> it was ancillary....
[16:42] <lamont> pitti: keescook: see http://bugs.debian.org/454554 re sudo passwd breaking emacs on gutsy et al
[16:43] <pitti> lamont: ah, cool, fixed upstream already
[16:43] <pitti> lamont: this looks pretty brittle, though :)
[16:45] <AlinuxOS> hello all dear people "OEM install (for manufacturers)" - remember that I translated that string before NonLanguagePackTranslationDeadline, but it doesn't compare in a main menu of Ubuntu 7.10. What should I do to solve that problem for the Hardy ?
[16:48] <mdz_> AlinuxOS: I believe cjwatson usually pulls in translations for the installer etc. around that time
[16:49] <cjwatson> AlinuxOS: it was marked fuzzy (= "needs review" in Rosetta, I think) in the export I did on 9th October, five days after the deadline
[16:49] <cjwatson> AlinuxOS: fuzzy strings don't get included
[16:49] <AlinuxOS> ah
[16:49] <AlinuxOS> cjwatson, sorry then...
[16:49] <cjwatson> mekius: they're in the gfxboot-theme-ubuntu source package
[16:50] <AlinuxOS> cjwatson, mdz_ thanks.
[16:51] <mekius> cjwatson: ok, will look into it
[16:51] <cjwatson> mekius: they're translated in Launchpad
[16:52] <mekius> "This theme does not include any help texts or logos itself"
[16:54] <cjwatson> mekius: you asked for menu translations, not help texts
[16:54] <cjwatson> the help texts are in debian-installer
[16:54] <cjwatson> it's a bit of a mess, I concede
[16:54] <ion_> debian\control, debian\rules? :-) (gnome-power-manager debian/changelog)
[16:56] <mekius> cjwatson: gah, i see
[16:57] <mekius> cjwatson: makes it a major pain to produce a derivate heh
[17:01] <AlinuxOS> cjwatson, https://bugs.edge.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/62849/comments/10  is it possible to fix that small-bug? It should shouldn't take a lot time. I would be very thankful!
[17:01] <ubotu> Launchpad bug 62849 in gfxboot-theme-ubuntu "Georgian (ka) letters are very crappy!" [Medium,In progress]
[17:02] <AlinuxOS> cjwatson, there is a small point/pixel in a wrong place in a letter "tz" = წ <- in Georgian.
[17:09] <m0dY> any idea why after an 'apt-get dist-upgrade' eth0 has change to eth1 ?
[17:18] <cjwatson> AlinuxOS: unifont done, pcf2bdf hates me but working on it
[17:18] <soc> hi
[17:18] <cjwatson> AlinuxOS: in future, please open a new bug rather than reopening an ancient one
[17:18] <soc> did someone experience that pulseaudio has quite some latency?
[17:19] <AlinuxOS> cjwatson, thank you. I'll do it!
[17:19] <soc> starting/pausing a song in amarok e.g. takes a bit more than 1 second
[17:21] <m0dY> what causes Ubuntu to change eth0 to eth1 for an ethernet controller ?
[17:22] <Nafallo> m0dY: races in which module gets loaded first if you have another controller that likes to be called ethX
[17:24] <m0dY> well, from what i can see there's only eth1+lo+sit0 now ! no eth0 at all..
[17:24] <cjwatson> AlinuxOS: (so gfxboot-theme-ubuntu not done yet, due to the pcf2bdf hatred, but shouldn't take too long ...)
[17:24] <Nafallo> that's a bit weird...
[17:25] <cjwatson> I wonder how I did this last time
[17:26] <AlinuxOS> cjwatson, I'll test everything for future Alpha2.
[17:26] <m0dY> Nafallo: it just happened after doing an apt-get dist-upgrade
[17:40] <lamont> GAH
[17:40] <lamont> so... when I'm building i386 binaries on powerpc... which value does DEB_HOST* get?
[17:45]  * soren smells a trick question
[18:01] <slangasek> lamont: DEB_HOST should be i386
[18:08] <lamont> thanks
[18:10] <slangasek> lamont: if you can't remember them, you can test with dpkg-architecture -a$foreign_arch :)
[18:10] <lamont> slangasek: rock
[18:11] <tkamppeter> pitti, hi
[18:44] <pitti> hi tkamppeter
[18:57] <cjwatson> pitti: debian-installer 20051026ubuntu36.12 uploaded to dapper-proposed
[18:58] <pitti> thanks
[19:00] <pitti> cjwatson: apt sources look good, BTW, no -proposed
[19:00] <pitti> in fact it's not even commented
[19:00] <pitti> (we didn't have it at that time yet, after all)
[19:03] <cjwatson> pitti: oh good
[19:03] <cjwatson> pitti: doesn't that mean it doesn't install the proposed kernel though?
[19:03] <cjwatson> pitti: at least when netbooting
[19:04] <cjwatson> I think netboot tests will probably not be valid until everything's in -updates :-/
[19:06] <cjwatson> elmo: ^--
[19:06] <elmo> \o/
[19:21] <tkamppeter> pitti, ping
[19:38] <pitti> cjwatson: re (sorry, was at dinner)
[19:38] <pitti> cjwatson: no, it does install the -proposed kernel, and -proposed lbm
[19:38] <pitti> netboot> yeah
[19:45] <geser> what's the best way to break a build-depends cycle?
[19:45] <geser> mig build-depends on gnumach-dev (source: gnumach) and gnumach build-depends on mig :(
[19:53] <geser> pitti: please give-back gnumail. Thanks.
[19:53] <pitti> geser: kicked
[19:54] <geser> pitti: do you know a way to break a build-depends cycle?
[19:55] <pitti> geser: how do you define that?
[19:55] <geser> mig build-depends on gnumach-dev (source: gnumach) and gnumach build-depends on mig :(
[19:55] <geser> and both are waiting on each other
[19:55] <pitti> geser: that's not a problem usually
[19:55] <pitti> but if they dep-wait on each other because the versions are too high, it is of coursee
[19:56] <pitti> geser: you have to find out if you can build either with the existing version of the other
[19:56] <pitti> geser: and if so, weaken the versioned build-depends
[19:57] <geser> both build-depends are unversioned
[19:58] <geser> we never got any of both build, they are sitting in depwait
[20:11] <geser> pitti: please give-back: gtkrsync haxe hmisc
[20:11] <pitti> geser: ah, that requires a manual bootstrap then (-> lamont)
[20:12]  * lamont grumbles at pitti
[20:12] <pitti> geser: given-back
[20:12] <pitti> lamont: not saying that you should do it, but maybe quickly explain how it works?
[20:12] <geser> lamont: could you please bootstrap mig and gnumach? Thanks :)
[20:12] <pitti> geser: do you really care that much? it's quite some work
[20:12] <lamont> infinity would be the target of choice... I'll probably get to it eventually....
[20:13] <lamont> as in sometime over christmas break, unless too much else gets dumped on me...
[20:13] <geser> pitti: not really, I try only to clear the list of FTBFS (http://qa.ubuntuwire.com/ftbfs/)
[20:13] <geser> if it's to much work, it can be ignored
[20:14] <infinity> pitti: Those requests should definitely go to me, now that I'm back.
[20:15] <pitti> oh, hey infinity; it's middle of the night for you, isn't it?
[20:15] <infinity> pitti: I can always enlist LaMont's help, if he feels like working for free, but it *is* my job. :)
[20:15] <pitti> heh, ok :)
[20:15] <infinity> pitti: No, no, I'm in Canada now!
[20:15] <pitti> but well, admittedly gnumach is an interesting academic project, but having it in universe is certainly something very few people will even notice
[20:16] <lamont> infinity: holler if you need anything - otherwise I'm hip deep atm
[20:16] <lamont> infinity: ogre$mumble needed love as well
[20:16] <lamont> I'll have to dig up the email'
[20:17] <lamont> infinity: email forwarded
[20:17] <lamont> to @u.c... iz good?
[20:19] <geser> pitti: please give-back: hg-buildpackage
[20:19] <pitti> done
[20:55] <geser> infinity: does the buildds still have the problem that they consider provided packages sufficient for versioned build-depends?
[21:02] <pitti> geser: why's that a problem? it has been a feature so far
[21:03] <geser> see http://launchpadlibrarian.net/10570879/buildlog_ubuntu-hardy-i386.libmail-box-perl_2.078-1_FAILEDTOBUILD.txt.gz
[21:05] <geser> pitti: perl-modules provides libtest-harness-perl which is also a seperate package and that package has a versioned build-depends on libtest-harness-perl
[21:05] <pitti> hm, real dependencies should be prefered
[21:05] <geser> afaik versioned (build-)dependencies don't work for provided packages
[21:05] <pitti> right, they don't
[21:05] <pitti> Provides: doesn't have versions
[21:06] <geser> yet the part that installs the B-D is happy with perl-modules but dpkg-buildpackage complains later
[21:08] <pitti> so that's buggy then
[21:22] <geser> has someone an idea why libtool looks now for /lib/libgcrypt.la?
[21:23] <TheMuso> geser: What package are you working on?
[21:23] <geser> libmrss http://launchpadlibrarian.net/10360063/buildlog_ubuntu-hardy-amd64.libmrss_0.18.0-2_FAILEDTOBUILD.txt.gz
[21:24] <geser> TheMuso: have you seen http://ubuntu.joejaxx.org/? :)
[21:24] <TheMuso> geser: Yes, but that doesn't count IMO.
[21:24] <TheMuso> geser: And, ahve you tried a simple rebuild of the package?
[21:25] <geser> TheMuso: yes
[21:25] <TheMuso> geser: I recently had a similar issue with gnunet, and gnunet-gtk. I had to put code into debian/rules for gnunet to clean the .la files. Check out clean-la.mk from cdbs to see what I mean.
[21:25] <geser> /bin/sed: can't read /lib/libgcrypt.la: No such file or directory
[21:26] <TheMuso> right.
[21:26] <TheMuso> libgcrypt had its .la file moved from /lib to /usr/lib.
[21:26]  * TheMuso has a look at the package.
[21:26] <geser> libmrss uses cdbs, so I simply include clean-la.mk?
[21:27] <TheMuso> geser: I think the problem here is one of libmrss' dependencies.
[21:28]  * TheMuso digs deeper.
[21:28] <StevenK> I daresay libtool is just taking the library path and s/.so/.la/ and then complaining bitterly.
[21:28] <StevenK> Stupid thing.
[21:29] <TheMuso> geser: Looks like something in the dep chain uses gcrypt, and still has stuff in its .la files that tell libmrss to try and find /lib/libgcrypt.la I think.
[21:31] <geser> libnxml.la references /lib/libgcrypt.la
[21:32] <geser> so simply rebuild libnxml and then libmrss?
[21:32] <TheMuso> geser: Rebuild libnxml0 but clean its .la files, and then rebuild libmrss
[21:32] <TheMuso> I'd try this in a chroot first, just to be sure it works.
[21:34] <geser> is using clean-la.mk from cdbs ok?
[21:35] <TheMuso> geser: IMO if the package doesn't use cdbs, manually dropping the code in debian/rules is sufficient.
[21:36] <geser> it uses cdbs
[21:38] <TheMuso> Ok, just include clean-la.mk.
[21:43] <geser> TheMuso: thanks, it builds now with the fixed libnxml
[21:45] <wasabi> oooh. scarey. All dbus apps just started crashing until I reinstalled libdbus-1-3
[21:49] <TheMuso> geser: np
[22:05] <pitti> poningru`: for your in-progress MIR, please use the standard template
[23:05] <lamont> keescook: I wonder... looking at vim... do we care that edgy backports is afflicted with whatever bug got fixed in ..ubuntu5.2???
[23:08] <keescook> lamont: generally the procedure is to request an updated backport
[23:09] <lamont> keescook: I just happened to notice... if you don't care, i don't either. :0)
[23:09] <keescook> :)
[23:09] <lamont> I mean, it's... backports...
[23:10]  * jdong looks at backlog
[23:10] <jdong> lamont: I'll deal with you for that comment after these 4 pages of chemistry finish themselves.
[23:10] <jdong> :D
[23:27] <Nafallo> jdong: new gajim ;-)
[23:28] <jdong> Nafallo: ok, first "discuss the differences in CFSE between square-planar and octahedral" complexes, and in return I'll deal with that ;-)
[23:29] <Nafallo> jdong: I think I will just file a bug :-)
[23:29] <jdong> Nafallo: sounds good ;-)
[23:32] <Nafallo> Bug #174558
[23:32] <ubotu> Launchpad bug 174558 in gutsy-backports "gajim_0.11.4-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/174558