[12:08] <DonDiego> siretart: hi
[12:08] <DonDiego> siretart: we talked at linuxtag..
[12:09] <mjg59> Kamion: The failure is because we've written a gpt partition table and grub wants to install into the mbr
[12:10] <mjg59> So those patches on their own won't fix that
[12:10] <gnomefreak> anyone know why libgmime before tomboy upgrade is libgmime2.1 and after is libgmime-2.0-2. that seems its going down in version number
[12:10] <DonDiego> slomo: Rathann tells me that you are working on the debian package for ubuntu?
[12:10] <mjg59> Kamion: We need to decide what to do about the partition table trouble
[12:10] <DonDiego> siretart: weren't you working on the mplayer package as well?
[12:11] <DonDiego> siretart: or other multimedia packages?
[12:11] <slomo> DonDiego: mplayer? yes, we both work on it
[12:11] <DonDiego> ah
[12:11] <slomo> and both on other multimedia related packages too ;)
[12:11] <slomo> why?
[12:11] <DonDiego> i'm an mplayer developer
[12:11] <DonDiego> i was looking over your package
[12:11] <mjg59> Kamion: On the other hand, we probably need the grub patch anyway, so feel free to throw that in
[12:11] <zul> mjg59: i could have swore that grub patch made it in to the grub merge from debian
[12:11] <DonDiego> wait, i'll paste you the log of my conversation with Rathann in private..
[12:12] <siretart> DonDiego: hi
[12:12] <DonDiego> hi
[12:13] <slomo> DonDiego: did you already paste it?
[12:13] <siretart> DonDiego: I touched the mplayer package, yes. currenlty, I'm more focusing on the xine-lib pacakge, though
[12:13] <mjg59> zul: Quite possible
[12:13] <DonDiego> just a sec
[12:13] <slomo> siretart: could you update liba52 from cvs in the next days? it has many fixes from mplayer... at least that's what i was told
[12:14] <DonDiego> oh, they merged our patches?
[12:14] <Fujitsu> mjg59, can you please tell me what happened with bug #54188? You set it to Fix Released, but the fix never appeared.
[12:14] <siretart> slomo: okay, I'll add it to my todo list
[12:14] <slomo> DonDiego: Rathann said it
[12:14] <Rathann> I thought they did...
[12:14] <DonDiego> slomo, siretart, please /join #mplayer-packaging
[12:14] <geser> Fujitsu: I assume it's because mjg59 set distribution to unstable
[12:14] <Rathann> I think someone wrote it in our mailing list...
[12:15] <Fujitsu> Ah, so he did.
[12:15] <Fujitsu> That would do it.
[12:16] <geser> at least the changelog entry in the bug mentions unstable instead of edgy
[12:16] <Fujitsu> geser, yeah, I noticed...
[12:16] <mjg59> Oh, that would be why
[12:17] <mjg59> I suck
[12:17] <Fujitsu> I made that mistake once... Hobbsee attacked me with her long stick of DOOM for it.
[12:17] <Fujitsu> SOmebody just noted in the incorrect resolution bug that it no longer worked.
[12:18] <Fujitsu> It'd be really nice if Soyuz actually informed people if they uploaded stuff like that, I hear it just silently drops it.
[12:21] <Kamion> Fujitsu: I believe that's been fixed (possibly not deployed yet), with the exception that invalid signatures still don't trigger a mail
[12:21] <Kamion> I think they're being paranoid about only mailing people once they have an authenticated reason to do so
[12:21] <Fujitsu> OK...
[12:22] <Fujitsu> 'cause I had an upload once that had unstable as the distribution, and I was most mystified when it ceased to appear anywhere.
[12:22] <Kamion> zul: if you want to check, that'd be good
[12:23] <Fujitsu> mjg59, have you still got the source for that upload?
[12:27] <mjg59> Fujitsu: No
[12:27] <Fujitsu> mjg59, shall I redo it?
[12:28] <mjg59> Sure
[12:29] <Fujitsu> I was in the middle of doing it anyway when I discovered that bug.
[12:44] <LaserJock> Kamion: would doing chmod 640 after dh_fixperms in edubuntu-menus make you happy enough?
[12:44] <Kamion> sure
[03:14] <bddebian> Howdy folks
[03:24] <nictuku> bddebian, hi
[03:24] <bddebian> Hello nictuku
[05:27] <Fujitsu> :(
[05:28] <ogra> :(
[05:28] <Fujitsu> A week later...
[05:28] <ogra> yeah
[05:31] <whiprush> ogra: how's your head?
[05:31] <Fujitsu> D:
[05:31] <ogra> whiprush, fine 
[05:31] <ajmitch> hey whiprush 
[05:32] <whiprush> hey aj
[05:32] <ogra> whiprush, i had only 3 beers down there
[05:32] <whiprush> I didn't drink, my head is mostly ringing from the sonic sweetness of it all
[05:32] <whiprush> mdz: Wish You Were Here
[05:32] <ogra> well, my ears are :)
[05:33] <ajmitch> whiprush: you going to the ohio linuxfest?
[05:33] <whiprush> ajmitch: yessir.
[05:33] <ajmitch> nice
[05:33] <whiprush> ajmitch: talking about all this integration stuff that's suddenly popular.
[05:33] <ajmitch> what a surprise
[05:33] <whiprush> ajmitch: in fact I got a mail today from a proprietary company asking if I would pimp their integration products.
[05:34] <whiprush> I'm like ... "uhhh ... no."
[05:34] <ajmitch> whiprush the superstar
[05:34] <whiprush> ajmitch: I'm mostly here for the partying, not the superstardom. :p
[05:34] <ajmitch> heheh :)
[05:35] <ogra> whiprush, see ... i told you so ;)
[05:36] <ogra> your a celebrity
[05:36] <ogra> *you're
[05:36] <bddebian> HMM
[05:37] <whiprush> heh
[06:44] <fabbione> morning
[06:45] <Hobbsee> hey fabbione 
[06:45] <Capt_Blood_Ponin> arrr
[06:46] <Fujitsu> Yar.
[06:47] <jdub> hey fabbione 
[06:48] <jdub> fabbione: i forgot to ask - should i reboot to test the md/uuid stuff, or hasn't a fix landed?
[06:48] <fabbione> yo yo
[06:48] <fabbione> jdub: yes the fix is there. 
[06:48] <fabbione> you can reboot if you want
[06:48] <jdub> rock!
[06:48] <jdub> ok
[06:48] <jdub> maybe now is an ok time ;)
[07:04] <fabbione> jdub: did it work?
[07:05] <jdub> fabbione: haven't rebooted :)
[07:05] <fabbione> tsk
[07:05] <jdub> fabbione: (my irc client is on the machine to be rebooted, for reference)
[07:05] <jdub> :)
[07:05] <fabbione> ah ok
[07:20] <mdz> whiprush: had a great time I hope?
[07:20] <fabbione> hey mdz
[07:20] <mdz> morning fabio
[07:20] <whiprush> mdz: there are no words.
[07:20] <fabbione> how you doing?
[07:21] <mdz> fabbione: sweaty
[07:21] <mdz> I just played volleyball for 2 hours
[07:21] <fabbione> ehe
[07:21] <fabbione> mdz: we still have a pending phone call.. what about in 10/12 hours when you wake up?
[07:22] <mdz> fabbione: or now
[07:22] <fabbione> mdz: it's better later..
[07:23] <mdz> my brain works better at night anyway
[07:23] <fabbione> if you don't mind
[07:24] <fabbione> i am not awake enough yet..
[07:24] <mdz> ok
[07:25] <mdz> one of us will always be off our rhythm :-)
[07:25] <fabbione> hmm we can also make it even later.. i don't mind
[08:27] <Kagou> hi
[08:28] <jdub> Fujitsu: yay! thanks for the 915 fixage
[08:28] <jdub> now we just have to get the sucker in the desktop seed
[08:31] <Fujitsu> jdub, that'd be nice.
[08:31] <Fujitsu> jdub, I noticed it myself when I installed edgy a while back, but thought little of it.
[08:31] <Fujitsu> Then I realised that it should have automatically configured, after somebody commented on that bug.
[08:32] <Fujitsu> It'd be really nice if it'd get promoted at least :(
[09:03] <ph8`> Mithrandir:  ping?
[09:07] <jdub> ever since i started using edgy from a non-upgrade edgy install
[09:07] <jdub> vim has been bollocks
[09:07] <jdub> and that's with 'vim'
[09:07] <jdub> not vim-tiny
[09:07] <jdub> my alternatives seem to be correct
[09:07] <jdub> but it doesn't automagically detect gzip files
[09:08] <jdub> and it doesn't do syntax highlighting correctly
[09:09] <Fujitsu> jdub, mine works fine.
[09:10] <Mithrandir> ph8`: hiya
[09:10] <jdub> Fujitsu: did you upgrade?
[09:10] <ph8`> n/m now mate, the amd64 iso appeared ;)
[09:10] <Fujitsu> jdub, no.
[09:10] <ph8`> did the kernel build in the end?
[09:10] <Hobbsee> hey Mithrandir 
[09:11] <Mithrandir> hiya Hobbsee 
[09:11] <jdub> Fujitsu: dpkg -l | awk '/vim/ {print $2}' ... ?
[09:11] <jdub> $ dpkg -l | awk '/vim/ {print $2}'
[09:11] <jdub> vim
[09:11] <jdub> vim-common
[09:11] <jdub> vim-runtime
[09:11] <jdub> vim-tiny
[09:11] <jdub> 
[09:12] <Fujitsu> I've got those + vim-gnome, vim-gui-common and vim-latexsuite, but they won't matter.
[09:12] <fabbione> jdub: what about dpkg -l vim* ?
[09:13] <fabbione> jdub: you awk lover
[09:13] <jdub> fabbione: too much noise for irc pastage
[09:13] <matiu> How can I install libglib2.0-dev ?
[09:13] <dholbach> good morning
[09:13] <matiu> It seems to be depending on a non-existant package... is it the same for others ?
[09:13] <Fujitsu> Heya dholbach.
[09:13] <dholbach> hey Fujitsu
[09:14] <Kamion> epends: libglib2.0-0 (= 2.12.3-1ubuntu1), libc6-dev | libc-dev, pkg-config (>= 0.14.0)
[09:14] <Kamion> looks ok ...
[09:14] <dholbach> matiu: do you have any other apt sources in your sources.list?
[09:14] <Kamion> (morning)
[09:14] <matiu> just dapper standard...
[09:14] <Mithrandir> ph8`: the new kernel was just uploaded, so no, there's not a new kernel on the ISOs
[09:14] <matiu> I had other before, but I've done lots of apt-get update's since removing them
[09:14] <Kamion> what error message do you get when you try to install it?
[09:14] <matiu> libglib2.0-dev: Depends: libglib2.0-0 (= 2.10.2-1ubuntu3) but 2.10.3-0ubuntu1 is to be installed
[09:15] <matiu> but 2.10.2-1ubuntu3 seems to not exist
[09:15] <jdub> hrm, this is interesting
[09:15] <jdub> when doing :syntax on once vim is loaded, i get:
[09:15] <jdub> Error detected while processing /usr/share/vim/vim70/syntax/syntax.vim:
[09:15] <jdub> line   42:
[09:15] <jdub> E216: No such group or event: filetypedetect BufRead
[09:15] <jdub> 
[09:15] <Fujitsu> Er, that's odd!
[09:16] <Fujitsu> Good idea.
[09:16] <Hobbsee> matiu: did you install something like xgl?
[09:16] <Kamion> matiu: 2.10.2-1ubuntu3 is the version in dapper; 2.10.3-0ubuntu1 is the version in dapper-updates
[09:17] <jdub> same thing with no vimrc!
[09:17] <Kamion> matiu: you'll probably get a better error message if you now try 'apt-get install libglib2.0-dev libglib2.0-0' to see why it doesn't want to upgrade libglib2.0-0
[09:17] <Kamion> and then iterate until it tells you the actual problem :)
[09:17] <matiu> Kamion: same message
[09:18] <matiu> Perhaps i don't have dapper-updates in my sources
[09:18] <matiu> I have dapper-updates main restricted
[09:19] <Kamion> BenC_: next kernel upload, could you please build nvram in on powerpc? (I filed a bug about that - it stops ybin working on fresh installs)
[09:19] <matiu> ah! dapper-updates, is only in there with deb-src
[09:19] <matiu> thanks Kamion
[09:19] <Kamion> yup, that would do it - np
[09:19] <ph8`> Mithrandir: eep? :/ The one ben uploaded yesterday (that was broken) isn't there then? How about tomorrow?
[09:20] <Mithrandir> ph8`: the one uploaded yesterday failed to build.
[09:21] <ph8`> right - but today's was ok?
[09:21] <Mithrandir> I don't know, it hasn't been built yet.
[09:21] <ph8`> ah ok
[09:21] <ph8`> if it builds ok, it will go into tomorrow's isos?
[09:21] <Mithrandir> yes
[09:21] <ph8`> fantastic
[09:21] <ph8`> cheers
[09:22] <Kamion> yeah, that happens automatically
[09:23] <jdub> $ ls /etc/vim/
[09:23] <jdub> total 8.0K
[09:23] <jdub> -rw-r--r-- 1 root root 2.3K 2006-07-23 04:05 vimrc
[09:23] <jdub> -rw-r--r-- 1 root root  774 2006-07-23 04:05 vimrc.tiny
[09:23] <jdub> 
[09:23] <jdub> doesn't appear to be upgrade related issues as noted by numerous posts on google
[09:25] <matiu> I have a package, that I'd like to get into ubuntu
[09:25] <matiu> How do I do it?
[09:25] <Kamion> start at #ubuntu-motu
[09:25] <dholbach> matiu: join #ubuntu-motu
[09:29] <Kamion> infinity: is the stacked-filesystems stuff ready for deployment?
[09:47] <carlos> Riddell: hi, would be possible that the changes to kdebase to extract the .pot files that you did for Dapper are not applied to Edgy?
[09:47] <carlos> Riddell: https://devpad.canonical.com/~andrew/paste/fileTECbIl.html
[09:48] <carlos> Riddell: that's a list of templates that weren't imported last night because had some msgid that are not using ASCII encoding but with the encoding field doesn't say that is UTF-8
[09:48] <pitti> Good morning
[09:48] <carlos> Riddell: would be possible to set all KDE .pot files as being UTF-8 by default so we don't get this error anymore?
[09:49] <Riddell> carlos: you'll need to /msg me the password for that
[09:49] <carlos> Riddell: ASCII is a subset of UTF-8 so it should not be a problem
[09:49] <carlos> Riddell: same as chinstrap's website
[09:49] <Riddell> I have no idea what that is :)
[09:49] <carlos> Riddell: I see ;-)
[09:51] <Riddell> carlos: I've added that to my ToDo list for the day
[09:52] <carlos> Riddell: ok, thanks
[09:52] <Riddell> although it should all be the same as in dapper, buy maybe I missed the UTF8 conversion out
[09:54] <carlos> Riddell: just extract all them as UTF-8 so you don't need to maintain the list of .pot files that need it
[09:56] <Riddell> yes
[10:01] <seb128> iwj: hi. Do you know about bug #61160?
[10:01] <Ubugtu> Malone bug 61160 in totem "totem cannot be build (xpidl compiler not found)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61160
[10:13] <seb128> Riddell: do you have any objection to build poppler with splash again?
[10:16] <Riddell> seb128: remind me again what that is
[10:17] <seb128> Riddell: there is a splash and a cairo backend, but I think it's glib specific, the qt backend always use splash or something like that
[10:18] <seb128> Riddell: just checking with you before making the change in case that would be an issue for kubuntu but it's probably not ;)
[10:18] <Riddell> seb128: so long as it doesn't touch the qt side I don't mind at all
[10:18] <seb128> Riddell: ok, good
[10:19] <Riddell> seb128: just make sure it doesn't add new dependencies to the qt package I guess
[10:20] <seb128> Riddell: will do
[10:24] <seb128> Riddell: 
[10:24] <seb128> configure: error: Qt4 development libraries not found
[10:24] <seb128> See `config.log' for more details.
[10:25] <seb128> Riddell: you didn't add a Build-Depends to poppler for qt4 apparently, is that on purpose?
[10:25] <Riddell> hmm, I'm sure I did
[10:25] <seb128> Riddell: maybe you modified debian/control instead of debian/control.in?
[10:26] <Riddell> oh, control.in evilness
[10:26] <seb128> Riddell: I'll fix that, what Build-Depends are required?
[10:26] <Riddell> libqt4-dev should be the one
[10:26] <seb128> ok, thank you
[10:32] <fabbione> hey mvo 
[10:32] <mvo> hey fabbione, thanks for your bugreport
[10:32] <fabbione> mvo: when you get a minute could you look at bug 61225 please?
[10:32] <Ubugtu> Malone bug 61225 in gnome-app-install "[EDGY]  fails to upgrade" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61225
[10:32] <fabbione> ah perfect.. you already did :)
[10:32] <fabbione> no problem at all
[10:33] <mvo> fabbione: I already uploaded a new version that may fix the issue. i'm not 100% sure though
[10:33] <mvo> the trouble is that I seem to be unable to reproduce it on my upgrade testing machine
[10:33] <fabbione> mvo: that was on a normal desktop
[10:33] <mvo> how do you test this?
[10:33] <fabbione> oh ok
[10:33] <fabbione> mvo: just normal apt-get upgrade..
[10:33] <fabbione> running as root
[10:34] <fabbione> no DISPLAY set
[10:34] <mvo> thanks, I will test this myself then. I have a non-interactive dist-upgrader here but it apparently gets the ordering right :/
[10:35] <fabbione> mvo: i don't think it's an ordering problem
[10:35] <fabbione> the error appears even if it is the last thing to upgrade
[10:36] <mvo> fabbione: interessting. can you run "/usr/sbin/update-app-install" on the (mostely upgraded) system? does that give you the same error
[10:37] <fabbione> mvo: yes.. same error
[10:37] <fabbione> machine updated 1 hour ago
[10:37] <fabbione> i can try another upgrade.. assuming there is anything
[10:37] <mvo> fabbione: what versions of python-xdg, python-gtk2, python-gobject are installed?
[10:38] <mvo> fabbione: that looks like its a problem with the system somehow. does python -c 'import gobject' work?
[10:39] <fabbione> python-xdg: 0.15-1.1ubuntu1, python-gtk2_2.10.1-0ubuntu1_i386.deb, python-gobject_2.12.1-0ubuntu2_i386.deb
[10:39] <fabbione> all installed
[10:39] <fabbione> python -c 'import gobject'
[10:39] <fabbione> Traceback (most recent call last):
[10:39] <fabbione>   File "<string>", line 1, in ?
[10:39] <fabbione>   File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 30, in ?
[10:39] <fabbione> 
[10:39] <fabbione> ImportError: No module named _gobject
[10:41] <mvo> fabbione: right, so something with python is not working ... could you please try removing "python2.4-imaging"?
[10:41] <fabbione> Note, selecting python-imaging for regex python2.4-imaging
[10:42] <fabbione> mvo: same error
[10:42] <mvo> fabbione: in the same file?
[10:42] <fabbione> python -c 'import gobject'
[10:42] <fabbione> Traceback (most recent call last):
[10:42] <fabbione>   File "<string>", line 1, in ?
[10:42] <fabbione>   File "/usr/lib/python2.4/site-packages/cairo/__init__.py", line 30, in ?
[10:42] <fabbione> ImportError: No module named _gobject
[10:44] <ajmitch> hm, there are a few bugs filed that looked similar but aren't 
[10:45] <mvo> fabbione: do you have *.so files under /usr/lib/python-support/python-gobject ?
[10:45] <fabbione> python-gobject# ls
[10:45] <fabbione> python2.4  python2.5
[10:45] <fabbione> there is a so for each dir
[10:45] <fabbione> |-- python2.4
[10:45] <fabbione> |   `-- gtk-2.0
[10:45] <fabbione> |       `-- gobject
[10:45] <fabbione> |           `-- _gobject.so
[10:46] <mvo> hm, looks good 
[10:46] <ajmitch> and /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so
[10:46] <ajmitch> ?
[10:47] <fabbione> i guess ajmitch just found the problem
[10:47] <fabbione>  4 lrwxrwxrwx 1 root root    76 2006-09-17 10:46 _gobject.so -> p????Y???u?c?Ts?k???Nf??????EK?F??j??.?b?U???t?2??W??U???Jj???>U1Fm??{?F??"?j?JL????^??g`W?U?m?{???^?VcC???????ne?G?????w?Gc??kp??O????y?%?.?Q?t??C:}?P?am???vCi?t?Ri?????*?:???_???????9??????P?I???~c??L?d:??z???7w???????q+??g????? ?] =??|z?$*?P?U??????????',}B?=jU??????????oJ??w??*?dxU??? ??
[10:47] <mvo> I suspect its something related to the new python-central and that this one is upgraded too late. could you please try reinstalling python-gobject. if that fixes the issue, its a ordering porblem
[10:47] <mvo> fabbione: what is that?
[10:47] <fabbione> this is FS corruption
[10:47] <ajmitch> fabbione: that doesn't quite look right :)
[10:47] <mvo> aha
[10:48] <azeem> fabbione tries to exploit my irssi
[10:48] <fabbione> ok.. later
[10:55] <seb128> Riddell: obviously you added a binary package to debian/control too, do you still have that change locally? could you put it somewhere online?
[10:56] <Riddell> oh crivvens, that will have been wiped too, hang on
[10:56] <Riddell> seb128: http://kubuntu.org/~jriddell/tmp/control
[10:56] <Riddell> hopefully libpoppler1-qt4.install and libpoppler-qt4-dev.install won't have been killed by control.in
[10:57] <Riddell> seb128: by the way I heard there may be a new poppler release today
[10:57] <seb128> Riddell: that control doesn't list a -qt4 package
[10:59] <Riddell> seb128: reload
[11:00] <fabbione> mvo: ping?
[11:00] <mvo> fabbione: pong
[11:01] <fabbione> mvo: it looks like that /var/lib... etc is not shipped in packages.. how can i regerate it's contents?
[11:01] <fabbione> regenerate
[11:02] <dholbach> fabbione: /var/lib/ what is that? something with python-support?
[11:02] <fabbione> yes
[11:02] <mvo> fabbione: try reinstalling the python-gobject package
[11:02] <fabbione> dholbach: see above..
[11:02] <fabbione> mvo: that was not the only package corrupted
[11:02] <fabbione> mvo: there were several 
[11:02] <dholbach> seb128, doko: is this part of the python-support problem we talked about some days ago?
[11:02] <seb128> Riddell: ok, looks correct now, ta
[11:02] <seb128> dholbach: I doubt of it
[11:03] <dholbach> hmh mh
[11:03] <mvo> fabbione: doko will know how to mass re-generate that
[11:03] <fabbione> found it
[11:06] <fabbione> mvo: thanks.. you can close the bug :)
[11:06] <fabbione> update-python-modules -v -b -i -a -f <-
[11:07] <mvo> fabbione: thanks
[11:08] <Hobbsee> mvo: thanks for your recent bugfix of gtk2-engines :)
[11:08] <Hobbsee> mvo: x2
[11:08] <mvo> Hobbsee: cheers
[11:08] <Hobbsee> mvo: took me ages to figure out what on earth was going on :P
[11:09] <seb128> what was the bug about?
[11:09] <dholbach> missing conflicts replaces
[11:09] <seb128> those errors are pretty obvious usually no?
[11:09] <dholbach> you only noticed it from upgrades from dapper to now
[11:09] <dholbach> because they reintroduced dummy packages etc
[11:10] <seb128> I mean the message is clear about file existing to the different packages no?
[11:10] <dholbach> and I merged them without noticing
[11:10] <seb128> and I thought mvo did fix that one on friday ;)
[11:11] <mvo> seb128: I did, but I was fooled by control vs. control.in
[11:11] <seb128> ah, yet another one
[11:12] <seb128> mvo: you should document to changelog what files you are modifying :p
[11:12] <seb128> would make easier to spot errors like that ;)
[11:12] <mvo> seb128: I usually do (unless the changes are trivial *cough*)
[11:12] <seb128> hehe
[11:12] <mvo> seb128: the vmware-modules package has a nice #THIS FILE IS AUTOGENERATED" header in the control ....
[11:13] <seb128> mvo: oh, we can use comments to debian/control?
[11:13] <seb128> I didn't know
[11:13] <seb128> could be an idea, right ;)
[11:14] <simira> mvo: u-m just seems to just load "list of changes" forever... 
[11:14] <mvo> simira: it may have crashed :( can you see something in .xmessages?
[11:15] <mvo> seb128: well, when auto-generating debian/control on the buildds they remove the comment again :)
[11:15] <seb128> ah, k
[11:16] <simira> I have no .xmessages, .xsession-errors says nothing
[11:16] <simira> mvo: I'm lying
[11:16] <mvo> simira: don't do that :)
[11:17] <mvo> its a sin!
[11:24] <janimo> Gloubiboulga: hi
[11:32] <iwj> seb128: bug 61160> I'm afraid I don't know anything about that.  It wasn't a change we made; I could check to see if it was something Debian did but I doubt it.
[11:32] <Ubugtu> Malone bug 61160 in totem "totem cannot be build (xpidl compiler not found)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61160
[11:32] <iwj> So I think it's a decision by upstream.
[11:32] <seb128> iwj: if that's upstream it puts us in a delicate position
[11:32] <seb128> iwj: it means we have to start using xulrunner and promote it to main
[11:33] <iwj> Let me look at the build tree.  I assume it must built it.
[11:33] <seb128> ok, thank you
[11:34] <seb128> iwj: 
[11:34] <seb128> "  * debian/firefox.install: Don't install xpt_link, xpt_dump, xpidl,
[11:34] <seb128>     xpicleanup, xpcshell nor regxpcom. They are of no use to firefox users and
[11:34] <seb128>     are provided with xulrunner anyway. (Closes: #362190)
[11:34] <seb128>  -- Mike Hommey <glandium@debian.org>  Sun, 20 Aug 2006 19:49:25 +0200"
[11:34] <seb128> iwj: from the package changelog
[11:34] <iwj> Ah.
[11:34] <iwj> OK, well I can undo that.
[11:34] <seb128> iwj: we probably want that reverted for Ubuntu
[11:34] <seb128> thank you
[11:34] <iwj> NP.
[11:34] <iwj> I should have read that changelog really.
[12:15] <Mithrandir> mvo: is there a way to tell the tool which pops up when you insert a cd with debs on that you would like to never ever be annoyed by it again?
[12:18] <bluto> Mithrandir: System --> Preferences --> Removable drives and media --> Multimedia --> untick "Play audio CD discs when inserted" or choose a different command from the drop-down.
[12:18] <bluto> ?
[12:19] <Mithrandir> bluto: it's a) not a CD I'm putting in, and b) it's not an audio CD.
[12:20] <bluto> yeah, sorry
[12:20] <mvo> Mithrandir: it should not nag you once the cd was added via apt-cdrom/synaptic etc
[12:20] <mvo> Mithrandir: I could add a preference to never act on CDs though (if you insert a lot of different CDs)
[12:21] <Mithrandir> mvo: well, I have this habit of making live cds, you see..
[12:21] <Mithrandir> mvo: I never ever use the graphical tools for managing my packages or sources anyway, so it would be good if I could tell it to go away.
[12:23] <mvo> Mithrandir: if you never ever use a graphical tool you may just remove update-notifier from your session
[12:24] <Mithrandir> mvo: I tried, but it came back, iirc.  And I lost the "reboot required" notifications that way.
[12:24] <mvo> right
[12:24] <mvo> I make a note to add a preference for you
[12:24] <Mithrandir> thanks.
[12:24] <seb128> looks like a gconf-key option candidate ;)
[12:24] <mvo> rigth
[12:24] <bluto> heh
[12:24] <Mithrandir> sure, I'm happy with putting it into my list of commands I run when I create a new account.
[12:41] <Kamion> argh, the gtkmm documentation is so hopelessly incomplete
[12:42] <Kamion> http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1OptionGroup.html <-- yeah, thanks for all the details :-/
[12:46] <dholbach> Kamion: file:///usr/share/doc/libglibmm-2.4-dev/reference/html/classGlib_1_1OptionContext.html might help
[12:46] <dholbach> oh no sorry
[12:46] <dholbach> it's the same
[12:47] <Kamion> using the glib documentation helps, but I shouldn't have to; pygtk gets this right
[12:47] <dholbach> *nod* :-/
[12:49] <Kamion> it isn't just a missing build option somewhere? I never quite understood how the pygtk documentation was produced
[12:53] <pitti> slomo: what was the bug again where apport picked the wrong package? (mono instead of the app)
[12:53] <slomo> pitti: pick a random bug that was assigned to mono first :P https://launchpad.net/distros/ubuntu/+source/tomboy/+bug/61238
[12:54] <pitti> slomo: ah, thanks
[12:54] <ajmitch> pitti: like anything that uses mono :)
[12:55] <slomo> someone please make LP faster again :P
[12:55] <ajmitch> where /proc/$pid/exe is a symlink to /usr/bin/mono
[12:56] <Fujitsu> slomo, it's not just me?
[12:56] <pitti> ajmitch: hm, 0.20 should have already fixed that actually
[12:57] <pitti> ajmitch: at least it fixed it for shell and python
[12:57] <pitti> will try it out here with tomboy
[12:57] <ajmitch> I haven't had a recent creash to try it on
[12:57] <slomo> pitti: it definitely isn't for mono :(
[12:57] <slomo> ajmitch, pitti: tomboy as panel applet is a good candidate ;)
[12:57] <ajmitch> I have to find some clear panel space first :)
[12:58] <pitti> slomo, ajmitch: ah, I know the reason
[12:58] <slomo> pitti: you might also want to look at banshee... at does evil magic with setting the process name (and some other mono applications do this too now) but exe is still a symlink to /usr/bin/mono
[12:58] <pitti> slomo, ajmitch: /proc/pid/status Name: says 'tomboy', but it executes Tomboy.exe
[12:59] <slomo> pitti: same for banshee then... "Name: banshee" which is executed via /usr/bin/banshee and calls mono with /usr/lib/banshee/banshee.exe
[01:00] <pitti> slomo: yeah, the problem is that it is exec'ed by a shell script
[01:00] <ajmitch> which is cli policy
[01:00] <pitti> so it's hard to find out what the name actually is
[01:00] <pitti> maybe I should just special-case mono
[01:00] <ajmitch> mono is pretty special :)
[01:01] <slomo> pitti: dpkg -S /usr/bin/`grep ^Name /proc/$pid/status | cut -d: -f2` or something like that maybe? :)
[01:02] <pitti> hm, I'll think about it
[01:03] <ajmitch> slomo: that'd slow down apport even more :)
[01:03] <slomo> ajmitch: it calls dpkg -S or something similar anyway
[01:03] <pitti> yeah, that part is not the problem
[01:04] <ajmitch> ah right
[01:04] <pitti> I'll probably check for $Name in /bin, /sbin, /usr/bin, /usr/sbin
[01:04] <slomo> pitti: which $name is probably better
[01:04] <slomo> and if it starts /usr/local break
[01:04] <pitti> slomo: I don't have an environment in apport
[01:05] <slomo> oh
[01:05] <slomo> ok :)
[01:05] <pitti> it's called directly by the kernel
[01:05] <pitti> right now I check if /proc/status' Name matches the basename of the second command line arg
[01:05] <ajmitch> slomo: you saw that bug 60114 had /usr/local/lib/banshee/banshee.exe ? :)
[01:06] <Ubugtu> Malone bug 60114 in banshee "Banshee crashes" [Untriaged,Needs info]  http://launchpad.net/bugs/60114
[01:06] <ajmitch> I think that could warrant a reject :)
[01:07] <slomo> ajmitch: done, thansk for spotting :)
[01:08] <Fujitsu> They filed a bug about a locally compiled one... That's most impressive.
[01:09] <ajmitch> Fujitsu: it's common, especially if they forgot they had an old version lying round
[01:09] <Fujitsu> How silly.
[01:09] <infinity> Happens all the time.
[01:09] <slomo> and this bug was assigned to "mono" so the guy probably thought it was a bug in mono that his own banshee crashed *shrug*
[01:09] <infinity> More fun is tracing crashes in packaged binaries to them being linked with hand-installed libraries.
[01:09] <infinity> Which also happens all the time.
[01:10] <Fujitsu> Fun fun fun.
[01:26] <bluto> any chance someone could triage bug #58469
[01:26] <Ubugtu> Malone bug 58469 in linux-source-2.6.17 "via-rhine net card stopped working in 2.6.17" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58469
[01:26] <bluto> (please)
[01:41] <gnomefreak> bluto: did you try 2.6.17-7 kernel?
[01:42] <pitti> hi tkamppeter 
[01:57] <Seveas> Kamion, elmo, CC meeting in T minus 3 minutes
[01:57] <elmo> doh
[01:59] <tkamppeter> pitti, hi
[02:00] <bluto> gnomefreak: yes, latest kernel
[02:09] <bluto> gnomefreak: did a tcpdump and can see the bootp requets going from the client but nothing arrives at the server
[02:12] <doko_> tkamppeter: ping
[02:12] <mvo> Mithrandir: I have working task support for apt-get, the only problem now what to do if two conflicting packages are in the same task (e.g. libgl1-mesa-glx and libgl1-mesa-swx11)
[02:14] <mvo> infinity: same question for you. what should apt-get installtask do if  two conflicting packages are in the same task (e.g. libgl1-mesa-glx and libgl1-mesa-swx11)
[02:15] <BenC> Kamion: re: nvram/ppc, will do
[02:17] <tkamppeter> hi doko_
[02:18] <doko_> tkamppeter: did you see my query?
[02:18] <doko_> Kamion: please approve openoffice.org for dapper-proposed
[02:20] <tkamppeter> No, doko_, probably I entered the channel too late.
[02:21] <tkamppeter> doko_, I have seen it now.
[02:23] <Mithrandir> mvo: blowing up would be fine.
[02:23] <Mithrandir> hmm, upstart doesn't seem to reread its files from event.d?
[02:26] <mvo> Mithrandir: blowing up is what it is doing now. if that is fine I will do some more testing and merge then
[02:27] <infinity> mvo: Fail.
[02:27] <Mithrandir> mvo: yeah, I'm happy with that.  It's just like an uninstallable package, really.
[02:30] <mvo> infinity, Mithrandir: cool, thanks
[02:45] <TomB|> .
[02:52] <infinity> mplayer: symbol lookup error: mplayer: undefined symbol: a52_resample
[02:54] <elmo> what's a good wirelss PCMCIA/cardbus card that works with free drivers in Ubuntu?
[02:54] <jdub> infinity: damn. puts a damper on pr0n time.
[02:54] <slomo> infinity: known problem... i'll work on it this night
[02:54] <elmo> I use to use Cisco aeronet stuff, but that became atheros under the hood
[02:54] <jdub> really? man. slackers.
[02:55] <tseng> intel really needs to expand their wifi business into other form factors
[02:55] <Kamion> elmo: I tend to use netgate.com
[02:56] <Kamion> who still do prism 2.5 stuff
[02:56] <infinity> elmo: All things netgate, as Kamion says.
[02:56] <infinity> Great for building home APs too.
[02:56] <slomo> infinity: i guess i'll just switch back to the bundled ffmpeg, i don't have the time to port parts of mplayer to the public API of liba52
[02:57] <infinity> slomo: I can get by with totem for now, if you want to fix it right...
[02:57] <infinity> slomo: It would appear that my pr0n and totem get along, more or less.
[02:58] <slomo> infinity: lately everything except some streams worked fine with totem-gst for me ;)
[02:59] <infinity> slomo: Yeah, it seems much improved.  Still behaves a bit sketchier than mplayer at times, though (well, when mplayer works at all)
[03:01] <elmo> man their website is slummy
[03:01] <Mithrandir> mjg59: I'm probably incompetent or something, but I'm unable to get usplash on the live cd to do anything useful when run by hand from the command line.  It never updates the display.
[03:02] <fatalerror> elmo: ping
[03:02] <elmo> fatalerror: ?
[03:03] <fatalerror> elmo: may I /msg you for a server-related "thing"?
[03:03] <ajmitch> infinity: would you be able to arrange a test build of universe in the future & supply build results so we can clean up failures?
[03:03] <elmo> fatalerror: sure?
[03:05] <mjg59> Mithrandir: Uh. How so?
[03:05] <infinity> elmo: Yeah, their site is sketchy, but I assure you they're above board and have always shipped me quality products.
[03:06] <infinity> ajmitch: We're going to have to work out how we plan to do that this time around, since the soyuz spec we originally wrote up for this doesn't appear as though it'll make it on time. :/
[03:06] <ajmitch> right
[03:06] <infinity> elmo: Will we be able to abuse wanna-build one last time for the mass-rebuild mess?
[03:07] <Mithrandir> mjg59: I run usplash -c & sleep 3 ; usplash_write PROGRESS 50 ; sleep 1; usplash_write PROGRESS 70 and it doesn't change the progress bar at all.
[03:07] <Kamion> infinity: oh, how's stacked-filesystems deployment coming along?
[03:07] <elmo> infinity: -ECONTEXT
[03:07] <Kamion> Mithrandir: usplash_write's argument syntax sucks
[03:07] <infinity> Kamion: Should have it fully tested on the buildds tomorrow.
[03:07] <Kamion> Mithrandir: you need to do usplash_write 'PROGRESS 50'
[03:07] <Kamion> etc.
[03:07] <Mithrandir> Kamion: gah, I suck, then
[03:07] <Kamion> I ran into that last week
[03:07] <infinity> elmo: mass test rebuilds of edgy.  Was meant to happen in soyuz, that spec's delayed.  We'll need to do it in wanna-build. :/
[03:08] <Mithrandir> Kamion: hooray, that works.
[03:08] <Mithrandir> I should fix that.
[03:08] <fabbione> infinity: what arches are you going to fireup?
[03:08] <elmo> infinity: with the one buildd per arch?  rock on.  erm, so yeah, that's a little problematic
[03:08] <infinity> fabbione: The primary arches, at least.  If you want to to sparc privately again, that won't hurt my feelings.
[03:08] <elmo> infinity: the machine that was running the test archive, became archive.canonical.com \o/
[03:09] <infinity> elmo: Hah.  Awesome.
[03:09] <fabbione> infinity: hem.. sparc is primary last i checked.. :)
[03:09] <fabbione> infinity: i was only wondering if you want to offload your machines, then i can do it here
[03:09] <Kamion> archive.canonical.com is not exactly that busy though ...?
[03:09] <infinity> fabbione: Well, for -server anyway. :)
[03:09] <fabbione> infinity: yeps.. 
[03:09] <Kamion> (I'd have thought. It has hardly anything in it.)
[03:09] <fabbione> infinity: but try to explain that (easily) to w-b :)
[03:09] <elmo> Kamion: yeah, but dak installs don't play nice together, or they do, but it's too easy to break things and/or use the wrong one
[03:09] <infinity> fabbione: But, yeah, we need to do the test on i386 at least, but if you want to fire up sparc and spare my buildd, I won't complain.
[03:09] <Kamion> ah
[03:09] <elmo> it's been done obviously (klecker), but I'd prefer to avoid it
[03:10] <elmo> so i need to find another .5Tb capable machine to put it on
[03:10] <fabbione> infinity: ok, i can do that tomorrow probably.
[03:10] <mjg59> desrt: Ok, so this is very likely not going to work, but:
[03:11] <infinity> fabbione: That'd rock.
[03:11] <mjg59> desrt: Can you try putting a call to acpi_early_init in init/main.c above calibrate_delay()?
[03:11] <fabbione> infinity: i think i still have the old setup on the SAN :)
[03:11] <infinity> fabbione: If you could make the IMAP folder directly available to ajmitch, so he can filter out universe results at his leisure, that would be even cooler.
[03:11] <fabbione> infinity: i just need to update it
[03:11] <mjg59> desrt: Or alternatively, for now, just a hack that sets SCI_EN (like your ICH7 quirk)
[03:15] <fabbione> infinity: yeah i can do that too
[03:15] <fabbione> infinity: the imap setup didn't change a bit
[03:16] <fabbione> infinity: it has only been collecting spam over the past months
[03:18] <Mithrandir> mjg59: would you be unhappy if I made usplash_write concatenate any arguments it got so it can only be used for one command per invocation?
[03:19] <mjg59> Mithrandir: I don't have any great objection
[03:19] <matthewrevell> Hello - anyone seen keybuck today?
[03:21] <ajmitch> fabbione: any access is fine, we'll have a lot to do anyway :)
[03:21] <fabbione> ajmitch: it's a very shared imap folder :) nothing more
[03:21] <ajmitch> fine by me, procmail can sort through it all
[03:21] <imbrandon> matthewrevell: my /lastlog shows the last time keybuk was talking awas yesterday at 1400 CST
[03:22] <imbrandon> but it might not be 1000000% acurate ;)
[03:22] <matthewrevell> imbrandon: Thanks :) It's the best I've got to go on.
[03:22] <matthewrevell> imbrandon: Supposed to be meeting him tonight, so if anyone spots him, can you prod him to mail me :)
[03:23] <imbrandon> matthewrevell: sure
[03:23] <matthewrevell> thanks!
[03:40] <Nafallo> Keybuk: morning, o archive admin :-)
[03:40] <Keybuk> heyhey
[03:41] <Hobbsee> hi Keybuk 
[03:43] <bddebian> Howdy folks
[03:48] <bddebian> doko: ping?
[03:49] <finalbeta> Perhaps not the place, but would like confirmation. Any person with a laptop running ubuntu edgy (gnome). When closing the laptop screen the setting, do nothing/blanck screen both blanck the screen and end the current session for me.
[03:50] <fabbione> Keybuk, mjg59: ping?
[03:50] <mjg59> fabbione: Yes?
[03:50] <fabbione> guys do you have any idea when we will get text output in usplash?
[03:50] <Keybuk> fabbione: the plan is for no next output?
[03:50] <Keybuk> boot without "quiet"
[03:51] <mjg59> Keybuk: We still need fsck output
[03:51] <fabbione> Keybuk: what happens when there is an fsck for huge disks?
[03:51] <fabbione> yeah exactly
[03:51] <Keybuk> fabbione: that will be fixed before beta freeze
[03:51] <Keybuk> I have it working here, I think, but want to give it some more testing
[03:51] <fabbione> Keybuk: ok.. i was just wondering what was the plane..
[03:51] <fabbione> Keybuk: i also found a couple of things that would be nice to have in upstart, but i will file bugs either later or tomorrow
[03:52] <fabbione> Keybuk: like the option to force fsck on the next reboot. IIRC sysvinit had it.
[03:52] <finalbeta> I hope the file check will be diffrend then in dapper, forcing you to wait on houre with no progress bar looking at a blinking _
[03:52] <fabbione> mjg59, Keybuk: thanks for the info tho.
[03:52] <Keybuk> fabbione: it never worked in sysvinit
[03:52] <Keybuk> which is why I never copied the code
[03:53] <Keybuk> somebody forgot the root filesystem wasn't writable, etc.
[03:53] <Keybuk> fabbione: the plan is easy, just output messages to /dev/console and with an "URGENT" text to usplash
[03:53] <fabbione> Keybuk: i also have a strange behaviour on normal installations.. ctrl+alt+del on text brings "nowhere"
[03:53] <Keybuk> "nowhere" ?
[03:53] <fabbione> it brings me to a # prompt
[03:54] <mjg59> Keybuk: So I think I worked out why there was that "clear" in usplash
[03:54] <fabbione> type exit to go out but it doesn't really do anything
[03:54] <Keybuk> mjg59: oh?
[03:54] <Keybuk> fabbione: hmm, you have /etc/event.d/control-alt-delete ?
[03:54] <fabbione> Keybuk: standard install
[03:54] <mjg59> Keybuk: We switch away from usplash so we can change the console font
[03:54] <fabbione> Keybuk: so it should be there
[03:54] <mjg59> Keybuk: That looks ugly if there's anything on the screen, so we cleared the screen before doing so
[03:55] <Keybuk> mjg59: right, but the console font is now changed correctly even if usplash is running
[03:55] <mjg59> Keybuk: Yeah
[03:55] <fabbione> Keybuk: anyway, nothing urgent or important..  i will file proper bugs for that
[03:55] <Kamion> mjg59: which reminds me, I had a theory for why that sleep 1 was there; I think it's waiting for usplash to open the fifo for reading
[03:55] <mjg59> Kamion: Ah
[03:55] <mjg59> Entirely possible
[03:55] <Keybuk> fabbione: if you could run "sudo initctl events" on the console and then press ctrl-alt-del that'd be helpful
[03:56] <Kamion> Keybuk: not really
[03:56] <Kamion> Keybuk: I had to make it call setupcon afterwards; it didn't work while usplash was running, for no reason I could determine
[03:56] <Kamion> the normal setupcon during boot isn't enough
[03:56] <Kamion> but yes, changing the console font doesn't need to switch vt any more
[03:57] <Mithrandir> Keybuk: on the live cd, upstart doesn't seem to notice when files in /etc/event.d are changed.  As in, I stop tty6, change the tty6 file, start tty6 and the old one is started.
[03:57] <fabbione> Keybuk: ok. i will do that. i can't reboot right now
[03:59] <infinity> mvo: Does apt-ftparchive re-order fields when it generates Packages.gz?
[03:59] <infinity> mvo: (I'm pretty sure the answer is yes, but it leads to the next question...)
[03:59] <mvo> infinity: IIRC yes
[04:00] <Kamion> mvo: libstdc++5
[04:00] <mvo> aha
[04:00] <infinity> mvo: If so, can we hack it to place X-Original-Maintainer: immediately after Maintainer:, instead of putting it after the description?
[04:00] <Kamion> desktop: * libstdc++5 [i386]     # doko: requested from some closed source applications
[04:00] <Kamion> why does that field have the X-?
[04:00] <Keybuk> Mithrandir: that doesn't surprise me, actually -- I guess the same's true for udev?
[04:00] <mvo> Kamion: thanks
[04:00] <Keybuk> inotify and unionfs are known to be unfriendly
[04:00] <Mithrandir> Keybuk: no idea about udev.
[04:00] <infinity> Kamion: Because it's a non-standard field?  If we want to define it as a standard field, I guess we could drop the X-
[04:00] <Kamion> there's already an XB- syntax in control files to produce an unofficially-defined field
[04:01] <Mithrandir> Keybuk: well, shouldn't it reload it when I stop and start it?
[04:01] <Kamion> but the result of that in the binary control file drops the XB-
[04:01] <Kamion> and nobody ever does XB-X-
[04:01] <Keybuk> the inotify events would be coming for entirely different files
[04:01] <infinity> Kamion: Err, it's meant to be XB-?  See I had that spec up for ages, and no one corrected that.
[04:01] <Kamion> infinity: XB- is what you put in debian/control
[04:01] <Kamion> infinity: in DEBIAN/control, the XB- gets dropped
[04:02] <Kamion> (and XS- for source, XC- for changes)
[04:02] <Kamion> for examples, see Installer-Menu-Item, Python-Provides
[04:02] <Keybuk> Mithrandir: reloading job files on stop may make some amount of sense
[04:02] <Mithrandir> Keybuk: and since it's init, I can't just tell it "reload the files, you fool" by hammering it with a signal and restarting it..
[04:02] <infinity> Kamion: Yeah, I just read that bit of policy.  Argh.  I'm not sure if I specced it as X- or if mdz did, but blame one or both of us, since I don't think anyone else ever read that spec closely.
[04:03] <mvo> infinity: I can add the reqruired reodering, no problem, just let me know the final name :p
[04:03] <Hobbsee> Keybuk: you're on the CC, arent you?
[04:03] <Hobbsee> Keybuk: or is it only Kamion?
[04:03] <infinity> Kamion: So, I suppose I should change pkgbinarymangler to use XB-, and we'll have a mix in the Packges file of X-O-M and O-M... :/
[04:04] <jdong> slomo: ping
[04:04] <Kamion> Hobbsee: Keybuk is not
[04:04] <Kamion> infinity: yeah
[04:04] <infinity> Kamion: Thanks for the heads-up.
[04:04] <Hobbsee> Kamion: ah right. 
[04:04] <Kamion> sorry, I should have mentioned this earlier, but never remembered to
[04:05] <imbrandon> mvo ping , dholbach  said i should show you soemthing ..... http://pastebin.ca/176190
[04:05] <infinity> Kamion: S'ok, I should have known, being the policy nazi that I am, I just skipped right past that bit, apparently.
[04:05] <Kamion> I only really know because the installer uses that feature quite a lot.
[04:05] <Keybuk> Mithrandir: actually, you could do that -- but sending HUP to init seems wrong
[04:05] <Keybuk> which is why I used inotify in the first place
[04:06] <dholbach> mvo: Hehe, I told him to ask you if his apt was not behaving.
[04:06] <Keybuk> but yes, I can see how that might not work with unionfs :p
[04:06] <Mithrandir> Keybuk: it rereads everything on HUP?
[04:06] <Keybuk> Mithrandir: no, doesn't do anything on HUP
[04:06] <Keybuk> but it oculd
[04:06] <Mithrandir> it'd be useful.
[04:07] <mvo> imbrandon: fresh knot3 install? known problem
[04:07] <infinity> Kamion: So, when does the XB- get stripped?  By dpkg-deb, or by apt-ftparchive?
[04:07] <imbrandon> mvo: yea fresh knot 3
[04:07] <Kamion> dpkg-gencontrol
[04:07] <mvo> imbrandon: the trouble is that if you remove kubuntu-desktop it thinks all dependencies can be freed as well
[04:07] <infinity> Kamion: Ahh, according to policy, I'd assume by dpkg-deb (since it claims the binary has the stripped version)
[04:07] <jdong> mvo: does autoremove REALLY need to bug you every time you do anything in apt?
[04:07] <imbrandon> mvo: okies, just thought i would poke you dholbach  thought you might like to see it
[04:07] <jdong> mvo: I personally think autoremove should only tell you about those packages when you invoke apt-get autoremove
[04:07] <Kamion> infinity: it does - dpkg-gencontrol is responsible for generating DEBIAN/control which dpkg-deb tars up into the .deb
[04:08] <imbrandon> mvo: yea things like xserver-xorg i'd rather not remove
[04:08] <imbrandon> ;)
[04:08] <infinity> Kamion: Oh, then I should use the unstripped variety completely, if we don't want the XB-...
[04:08] <mvo> jdong: it is important to show it for now so that people test it and we get reports like the one from imbrandon :)
[04:08] <infinity> Kamion: Cause I'm editing it right before dpkg-deb is called.
[04:08] <infinity> Kamion: In the dpkg-deb wrapper.
[04:08] <Kamion> infinity: right, sounds sensible
[04:08] <mvo> imbrandon: we are working on it currently (and it should be fixed soon)
[04:08] <jdong> mvo: ah, ok, but when edgy releases, autoremove will stop nagging me, right? ;-)
[04:08] <imbrandon> mvo: ok cool, thanks
[04:08] <infinity> Kamion: Err, use the stripped variety even.  Gar.  Brain.  Not working.
[04:09] <imbrandon> mvo: wnt me to stick that paste somewhere more perminate ( like in a txt file on my websever ) or you guys got in under wraps ? 
[04:09] <mvo> jdong: I'm not decided yet, I personally find it very useful. 
[04:09] <Kamion> infinity: I parsed it as "stripped" anyway :)
[04:10] <mvo> imbrandon: thanks, no need for this. we are aware of the problem
[04:10] <imbrandon> ok
[04:10] <jdong> mvo: it can be bothersome, especially if you build up a big list...
[04:10] <mvo> jdong: how big is the list for you?
[04:10] <jdong> mvo: around 15 or so packages
[04:10] <infinity> Kamion: Right, so there's no valid reason to have the X*- syntax at all, it's just for debian/control, so it's obvious in the source?
[04:10] <jdong> some of which are indeed legitimate
[04:10] <infinity> Kamion: (ie: we don't want X- stuff in the archive for any reason?)
[04:10] <Keybuk> Mithrandir: that would be a worthy bug (inotify and unionfs not friends) though :)
[04:11] <jdong> mvo: like autoclean doesn't give a huge list of packages you can purge from /var/cache every time you run apt-get install.... why should autoremove? ;-)
[04:11] <jdong> mvo: maybe just saying the number of packages that can be autoremoved is a good compromise?
[04:12] <Kamion> infinity: it's just that no other unofficial fields have X-, so it looks weird
[04:12] <mvo> jdong: the difference is that (assuming autoremove works correctly) there is no reason to keep any package around that is listed there
[04:12] <Kamion> I think the X*- syntax is to prevent typoes in standard field names
[04:13] <jdong> mvo: the same can be said about autoclean, right?
[04:13] <infinity> Kamion: http://cerberus.0c3.net/~adconrad/argh.diff
[04:13] <infinity> Kamion: Sane?
[04:13] <infinity> Kamion: (don't comment on the sed line if it makes you cry)
[04:14] <Kamion> infinity: nothing wrong with that sed line, except that I always have to look up exactly what \ does inside "" so I tend to use \\ there
[04:14] <Kamion> (but it's obviously already working, so)
[04:15] <Kamion> infinity: yeah, seems fine
[04:15] <Kamion> infinity: as a bonus, it's now possible to write XB-Original-Maintainer in debian/control to override pkgbinarymangler, instead of XB-X-Original-Maintainer
[04:15] <Keybuk> somebody left a "set -x" in the initramfs ;)
[04:16] <infinity> Kamion: That would cause a build failure currently, actually, but that was for my own paranoia's sake (making sure I don't run the thing twice in a row somewhow)
[04:16] <infinity> Kamion: Once I'm sure it's workin fine (and it certainly seems to be), being able to override it from the source may be kinda cool, yeah.
[04:17] <Keybuk> mjg59: local-premount/suspend ... one of yours?
[04:18] <mvo> jdong: valid point. still, I think we need it at least for another couple of weeks
[04:18] <mvo> to get debugging feedback
[04:18] <jdong> mvo: yeah, that sounds good :)
[04:19] <infinity> Kamion: Hrm.  I could make that change now.  Do you see any value in it, other than the "hey, cool" factor?
[04:19] <mvo> jdong: please nag me then again :) I could add a "apt-mark unmarkauto --all" or something like this if you think there is room for this
[04:20] <Kamion> infinity: not really
[04:20] <jdong> mvo: will do
[04:20] <infinity> Kamion: Figured. :)
[04:21] <mvo> infinity: I'm preparing a new apt upload right now anyway, so if you need that rewrite ordering thing, I can quickly add it for you
[04:22] <infinity> mvo: Right, what we want then is to have "Original-Maintainer" sort directly after "Maintainer"
[04:22] <infinity> mvo: I can worry about getting that backported for drescher later.
[04:26] <mvo> infinity: added, I'm doing some basic testing now
[04:26] <infinity> mvo: Danke.
[04:29] <infinity> Kamion: new kernel and lrm accepted, BTW, if you want to do a d-i ABI bump.
[04:32] <infinity> Kamion: I can do the seeds, if you like.
[04:34] <infinity> seb128: Around?
[04:35] <infinity> seb128: Any idea why poppler just grew two new binary packages?
[04:36] <slomo> infinity: Riddell activated the qt4 bindings iirc
[04:36] <infinity> slomo: So now we have "qt" bindings and "qt4" bindings?.. That seems a bit odd.
[04:37] <slomo> qt3 and qt4... what's odd about this? :)
[04:37] <infinity> The part where I'm not sure why we care about qt3?  But alright.
[04:38] <slomo> kpdf iirc
[04:38] <Keybuk> infinity: we only care about qt3 at the moment
[04:38] <Keybuk> qt4 is the crackful one, no?
[04:38] <tseng> i thought almost all of our stuff was qt3
[04:38] <jdong> infinity: qt3 is more important than qt4 right now
[04:38] <infinity> Oh, we haven't switched yet.  Check.
[04:39] <infinity> Hobbsee: I could ask the same of you.
[04:39] <Hobbsee> infinity: true that.
[04:39] <Hobbsee> but i'm not actually doing any work
[04:40] <infinity> I do my best work when I'm not supposed to be doing any.,
[04:40] <infinity> There, no more binaries in NEW.
[04:40] <Nafallo> infinity: you are away with reason: gone for the evening :-)
[04:41] <infinity> Nafallo: Yeah, I lied.
[04:41] <infinity> Nafallo: That was hours ago.  I came back.
[04:41] <Nafallo> workaholic! :-)
[04:41] <Hobbsee> infinity: true that
[04:41] <Nafallo> Keybuk: when do you plan to start doing the syncs? :-)
[04:42] <mvo> infinity: new apt uploaded, we need to change the livecd build script then to use apt-get installtask 
[04:42] <Keybuk> Nafallo: currently doing them
[04:42] <infinity> mvo: Will do.
[04:42] <infinity> mvo: Does it work? :)
[04:42] <Nafallo> Keybuk: nice, I think there is some new binaries in erlang for infinity to get in ;-).
[04:42] <infinity> mvo: Actually, wait.
[04:42] <infinity> mvo: Why a new action, instead of a syntax addition to "install"?
[04:43] <infinity> mvo: That means I can't install both a package and a task in the same run. :/
[04:43] <Keybuk> Nafallo: there are no NEW binaries
[04:43] <Nafallo> Keybuk: oki. I thought erlang-nox would be new, since the package has never actually built with them added :-).
[04:43] <Nafallo> AFAICS
[04:45] <Nafallo> s/package/source/ above of course.
[04:45] <mvo> infinity: this simplies the implementation quite a bit. but I could look at this again
[04:47] <Keybuk> Nafallo: syncs often result in new, yes
[04:49] <keescook> mornin'
[04:49] <pitti> hey keescook 
[04:49] <keescook> hiya pitti
[04:52] <infinity> mvo: Well, we were really hoping to be able to do the same thing we do with either apt+metapackages or aptitude+tasks, which is to install "package package package {metapackage|task}" all in one run.
[04:52] <infinity> mvo: It becomes somewhat more interesting when you realise that we sometimes hack around dependency resolution issues by specifying explicit packages before the metapackage/task to make sure we get what we want. :)
[04:54] <mvo> infinity: what would the synatx look like? apt-get install pkg --task task --task task2? 
[04:54] <infinity> mvo: Hence why Mithrandir originally suggested an aptitude-like "apt-get install package1 package2 ~ttask1 ~ttask2" syntax (or similar)
[04:54] <infinity> mvo: Syntaz isn't so important to me, so long as it's doable.
[04:54] <infinity> mvo: Syntax, even.
[04:55] <Keybuk> From: Alana <martin.pitt@ubuntu.com>
[04:55] <Keybuk> pitti: and I thought you were joking about wearing dresses
[04:56] <mvo> infinity: ok, I have another look at this then (if the current stuff is not good enough)
[04:56] <infinity> Kamion: Kernel ABI bump committed and merged to all seeds, BTW.  Nothing left but the d-i bump, which I know you like to do yourself. :)
[04:56] <dholbach> pitti: HAHAHA
[04:56] <Kamion> infinity: go ahead, if you like - this CC meeting is draining my attention
[04:57] <infinity> mvo: Well, I'm not sure about "not good enough" without rewriting some bits and testing it, but I think we'd be happier if we could do it on an "install" line.
[04:58] <infinity> mvo: I know the install line already has some sketchy parsing to deal with the "package-" and "package+" syntax, so stapling this on might not be TOO painful.
[05:00] <mvo> infinity: yeah, I could consider "apt-get install task*" or some similar obscource char
[05:00] <infinity> mvo: Something that's not a shell metacharacter might be nice. :)
[05:01] <infinity> mvo: task^ maybe.
[05:01] <mvo> infinity: sounds ok to me
[05:01] <mvo> does anyone why the emacs font looks so bad with latest edgy?
[05:02] <infinity> It's a plot by the disciples of vi.
[05:03] <zul> infinity: yes...yes it is
[05:03] <mvo> don't talk about vi, my vim folds changelogs now by default and won't tell me how to unfold them
[05:03] <thom> mvo: { or }
[05:03] <infinity> mvo: What thom said, or just smack space on a folded bit.
[05:04] <infinity> (or pretty much any key, actually)
[05:04] <thom> i do hate folds though
[05:04] <thom> must work out if i can turn them off globally
[05:04] <Kamion> mvo: set foldlevel=1000
[05:05] <seb128> infinity: what slomo said, I just fixed the previous upload for that
[05:05] <thom> Kamion: thanks
[05:05] <mvo> thanks
[05:07] <infinity> seb128: Yeah, got it sorted.
[05:13] <Spads> zul: ping
[05:15] <zul> Spads: pong
[05:15] <lastnode> imbrandon, ping?
[05:16] <Spads> zul: got time to chat about xen?
[05:16] <zul> sure..
[05:34] <Keybuk> crimsun: ping?
[05:35] <Keybuk> unping
[05:36] <imbrandon> lastnode: pong
[05:55] <icecrash> hi
[05:56] <mvo> infinity: ok, tasks with "taskname^" done
[06:13] <desrt> mjg59; arf.  what are you thinking?
[06:14] <carlos> Riddell: hi, I think all kde-i18n-XX packages failed to build, are you aware of that?
[06:15] <Riddell> carlos: erk
[06:15] <carlos> Can't open perl script "admin/am_edit": No such file or directory
[06:15] <carlos> make[1] : *** [Makefile.in]  Error 1
[06:15] <carlos> make[1] : Leaving directory `/build/buildd/kde-i18n-es-3.5.4'
[06:15] <carlos> make: *** [build-stamp]  Error 2
[06:15] <carlos> http://librarian.launchpad.net/4308142/buildlog_ubuntu-edgy-i386.kde-i18n-es_4%3A3.5.4-0ubuntu2_FAILEDTOBUILD.txt.gz
[06:16] <Riddell> they built for me damnit
[06:16] <carlos> Riddell: I didn't get any translation so I checked German and Spanish ones
[06:16] <carlos> and both failed, so I guess that's the reason for the lack of translations
[06:51] <Kamion> doko: sorry, I forgot about openoffice.org - done now
[07:00] <doko_> Kamion: thanks
[07:01] <doko_> anybody seen "Input/output error"'s after the last upgrade? installed the new gzip, then every other command/action fails ...
[07:01] <elmo> doko: err, for stable?
[07:02] <desrt> mjg59; SCI_EN is disabled when the system boots
[07:02] <desrt> mjg59; setting it results in an immediately hard lock
[07:02] <doko_> elmo: the errors? no for edgy
[07:03] <elmo> doko: ok - was just worried, there's just been a gzip USN ;)
[07:04] <slomo> Keybuk: does syncing from debian/testing or syncing an older version than what is in debian/unstable work or is a "fakesync" needed?
[07:04] <Keybuk> slomo: it can work, provided you can find the source somewhere
[07:04] <Keybuk> if you want to sync from testing, say so explicitly
[07:04] <Keybuk> if you want an older version, find it on snapshot.debian.net, and request a sync from there
[07:04] <slomo> Keybuk: ok, perfect :) the version i want is in testing
[07:05] <slomo> Keybuk: what about the debian-multimedia syncs? any ETA for them?
[07:07] <doko_> great, dpkg segfaults now after a reboot :-/
[07:07] <Keybuk> slomo: NEVER
[07:07] <Keybuk> actually, seriously, it's a sync from a random FTP location that we don't (yet) trust
[07:08] <Keybuk> it needs someone like me or Kamion to sit down and read every line of code there, etc. and decide whether it's a trustable place
[07:09] <slomo> Keybuk: it's in no way worse than marillat (and he is involved with that project) before and we synced stuff on request from there too. and for all the stuff i requested syncs we already had a version by marillat
[07:10] <imbrandon> marillat runs debian-mm doesnt he
[07:10] <slomo> afaik together with others, yes
[07:11] <Keybuk> slomo: right, but it needs someone to get out from behind the sofa and check it
[07:11] -CIA-7:#ubuntu-devel- [GLOBAL]  USE #FREENET TO DOWNLOAD CHILD PORN ANONYMOUSLY!
[07:11] -CIA-7:#ubuntu-devel- Beu and Rez, Sitting in a tree, K.I.S.S.I.N.G.!
[07:12] <imbrandon> thanks Keybuk  i was just aobut to /op
[07:12] <imbrandon> was looking away
[07:12] <Keybuk> anyhoo, off to jono's for a bit -- back later
[07:13] <imbrandon> wow backport bug fixed, woot, thanks for processing those Keybuk ( curious are you gonna do the NEW queue for dapper/edgy today ? )
[07:13] <imbrandon> okies guess not ;) thanks
[07:13] <imbrandon> ;P
[07:13] <Keybuk> imbrandon: yes, when I get back
[07:13] <Keybuk> already did some of it
[07:13] <imbrandon> ok cool, you rock ;)
[07:13] <mjg59> Keybuk: #30335 - erm?
[07:13] <desrt> mjg59; should i try initialising acpi or is it the same as setting sci_en?
[07:14] <mjg59> One case is the mmc subsystem loading mmc_block, the other is a card needing to load the driver that corresponds to the sd slot
[07:14] <mjg59> Keybuk: they're two different (though similar) problems
[07:14] <mjg59> desrt: The bit I'm interested in is setting sci_en
[07:14] <desrt> mjg59; look up ^^
[07:15] <desrt> flipping SCI_EN on before delay loop calibration -> hard lock
[07:15] <mjg59> desrt: Oh, sorry, I see
[07:15] <desrt> at that point in the boot that register is all-zero
[07:15] <mjg59> Try doing acpi_early_init (or whatever) then
[07:15] <desrt> i hope that function doesn't mind being called twice :)
[07:15] <mjg59> Oh, it probably will
[07:15] <mjg59> But it'll be interesting debugging
[07:15] <desrt> not if it crashes before i get a dmesg :p
[07:16] <mjg59> I'm wondering whether getting into SCI mode earlier will avoid the timing problem
[07:16] <Keybuk> mjg59: they're the same -- kernel doesn't export a modalias for mmc, so drivers can't be autoloaded
[07:17] <Keybuk> anyway, gone
[07:19] <desrt> mjg59; calling acpi_early_init from calibrate_delay -> panic
[07:20] <mjg59> desrt: Ok
[07:20] <desrt> mjg59; i tried to find the SMRAM
[07:20] <desrt> to see if i could get inside of it and figure out how its twisted little mind works
[07:20] <desrt> thus far i've failed
[07:22] <desrt> on 'rsm' the processor loads a bunch of data from a table at a location that is stored at a fixed offset from the SMBASE register
[07:22] <desrt> one of those table elements is the new value for the SMBASE register
[07:22] <desrt> so unless the SMRAM region moves around all the time, you should see there's a word in the system memory which points at the physical address 0xf7[something]  less than itself
[07:23] <desrt> i found one such word... but it wasn't even aligned
[07:23] <desrt> so it seems unlikely
[07:24] <desrt> i wish apple documented their products as well as intel did :(
[07:27] <desrt> mjg59; wrote writes the code that runs on SMI?  is it part of apple's BIOS or part of the ICH7?
[07:27] <mjg59> The BIOS, I believe
[07:27] <desrt> its functionality seems like it would be pretty extremely tightly coupled to the ICH7
[07:27] <desrt> like all of these 'legacy usb' modes that it would have to support, etc
[07:33] <jdong> Rejected:
[07:33] <jdong> k3b: Version newer than that in BACKPORTS. 0.12.17-1ubuntu3~dapper1 >= 0.12.16-1ubuntu3~dapper1
[07:33] <jdong> imbrandon: soyuz is fixed, huh?
[07:34] <imbrandon> it accepted amarok and konvo, and keybuck and cprov say so 
[07:34] <Kamion> no, the fix was committed but hasn't yet been deployed
[07:34] <Kamion> 'bzr revno' on the soyuz codeline on drescher is older than the fix; I think Keybuk was wrong to set it to Fix Released
[07:35] <Kamion> could also be that the fix was incorrect I guess
[07:36] <jdong> imbrandon: so it accepted amarok and konvo?
[07:37] <imbrandon> https://launchpad.net/distros/ubuntu/dapper/+source/amarok/2:1.4.3-0ubuntu6~dapper1
[07:37] <imbrandon> ^^ look , yup
[07:37] <imbrandon> and -0ubuntu2~dapper1 was already there
[07:37] <jdong> imbrandon: yeah, I see it under dapper-changes
[07:38] <jdong> imbrandon: then why didn't k3b go through? :P
[07:38] <imbrandon> lemme look
[07:42] <imbrandon> dunno , dpkg --compare-versions says its fine , but the error you pasted thinks 16 is bigger than 17 ( nat the same error as before )
[07:42] <imbrandon> not*'
[07:43] <jdong> imbrandon: huh? it clearly says 17 is greater than 16
[07:43] <jdong> 0.12.17-1ubuntu3~dapper1 >= 0.12.16-1ubuntu3~dapper1
[07:44] <imbrandon> Version newer than that in BACKPORTS  <-- states 16 is bigger than 17
[07:44] <jdong> imbrandon: no, that says 17 is newer than that (16) in backports
[07:45] <imbrandon> anyhow, i dunno, it is marked fixed , accepted all but that one
[07:45] <jdong> it is identical to the error last time
[07:45] <jdong> I reopened the bug ticket
[07:45] <jdong> maybe give it another shot and hope we get lucky :P
[07:45] <imbrandon> ...
[07:45] <jdong> argh, both archive guys left, didn't they?
[07:46] <Nafallo> jdong: yes :-P
[07:46] <imbrandon> its not an archive problem , soyuz
[07:46] <jdong> imbrandon: i know, i was gonna ask them to try the backport again, see if it was just a timing issue
[07:46] <Nafallo> soyuz might be better discussed in #launchpad then? :-)
[07:47] <imbrandon> Nafallo: yes , kinda my point ;)
[07:47] <imbrandon> i'm thinking its something wrong with THAT one backport thoughas the others seem to go though
[07:47] <carlospc> There will be much hardware that will work in edgy but won't work on dapper? I'm looking "hardware support" around LTS definition but i'm not sure... any clues?
[07:48] <jdong> carlospc: there's certainly going to be some new drivers in Edgy not currently in dapper, sure
[07:48] <jdong> tifm21xx for one
[07:48] <cprov> jdong: imbrandon: bug fix for bug #58144 wan't released
[07:49] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,Fix committed]  http://launchpad.net/bugs/58144
[07:49] <jdong> cprov: ah, ok, keybuk's fault then.... :)
[07:49] <jdong> cprov: then how did imbrandon's amarok package get through?
[07:50] <cprov> jdong: did the amarok failed before ?
[07:50] <carlospc> jdong: well, supose that the distro it's for a government, would you choose dapper or edgy? I'm worry about the new hardware that the government would buy...
[07:50] <jdong> cprov: amarok succeeded before; k3b failed before
[07:51] <jdong> carlospc: well, what kind of hardware are you looking at? Dapper's hardware support is fairly comprehensive
[07:51] <jdong> carlospc: personally, I'd feel more comfortable deploying dapper...
[07:53] <cprov> jdong: I see, amarok_1.4.2-0ubuntu2~dapper1 got in before and now amarok_1.4.3-0ubuntu6~dapper1 worked too
[07:53] <carlospc> jdong: that's the problem, i don't know. But the last year we have a huge problem, we was basing our distro on breezy, and some intel chipset weren't supported...
[07:53] <carlospc> jdong: and we had to buy 2000 computers... but there weren't any seller that sold 2000 computers of a chipset that worked on breezy
[07:53] <carlospc> that was a huge problem
[07:54] <jdong> carlospc: well, for now, if you are looking at Core 2 Duo's or Intel 965 chipset, you're gonna have trouble with dapper
[07:54] <jdong> carlospc: in fact, I don't think Edgy supports 965 fully yet either... lots of those changes are in 2.6.18
[07:54] <carlospc> ouch
[07:54] <jdong> carlospc: but if you can figure out what types of hardware you need support for, the kernel guys are usually quite flexible about adding support in
[07:55] <jdong> (both dapper and edgy)
[07:55] <jdong> carlospc: http://kerneltrap.org/node/7020
[07:55] <jdong> that kernel trap thread has some of the changesets needed for 965 support
[07:55] <carlospc> that would be the way
[07:56] <jdong> I did a quick git tree search for dapper and edgy, not all of those are in ubuntu kernels
[07:57] <jdong> carlospc: I'd recommend launchpadding linux-source-2.6.17 and linux-source-2.6.15 and link that kerneltrap thread
[07:57] <jdong> I don't see anything that'd prevent ubuntu from getting those patches backported
[07:57] <jdong> and i965 support is quite important for both releases, IMO
[07:57] <carlospc> Ok, thanks a lot
[07:57] <desrt> mjg59; btw.   about the xorg crashing thing
[07:58] <desrt> mjg59; the real kick in the pants about that bug is i diff'd the file in which the crash occurs to its equivalent version from dapper
[07:58] <desrt> mjg59; no changes.
[07:58] <carlospc> We have a developer team, may be our efforts should go in that direction
[07:58] <desrt> mjg59; (cept an extra #include, probably to fix a warning)
[07:58] <jdong> carlospc: if you do file the report, subscribe me to it... I'm interested in buying some core 2 duos in the future, so I'd want to know too :)
[07:58] <carlospc> jdong: thanks a lot!
[07:58] <mjg59> desrt: Yeah, it'll be the reinit code that's called on VT switches
[07:59] <mjg59> There's something there that tries to soft-boot the card under certain circumstances
[07:59] <carlospc> jdong: ok
[07:59] <desrt> and the soft-boot disables the ring buffer
[07:59] <mjg59> No, the soft-boot probably just fucks shit up
[08:00] <desrt> the problem is caused by a software timer noticing that the hardware hasn't advanced the ringbuffer in the past little while
[08:00] <desrt> (and panicking)
[08:01] <zyga> hi everyone
[08:01] <popey> mjg59: if you have a moment, any chance you could triage bug 58469 or otherwise smack me with a cluebat?
[08:01] <Ubugtu> Malone bug 58469 in linux-source-2.6.17 "via-rhine net card stopped working in 2.6.17" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58469
[08:03] <mjg59> popey: Looks like an interrupt problem
[08:03] <mjg59> It's probably the VIA interrupt quirks madness
[08:03] <mjg59> Can you try the latest 2.6.17?
[08:05] <popey> mjg59: I am on 2.6.17-7-386 and have tried -generic also
[08:07] <jdong> mjg59: the 2.6.17-8 upload that was supposed to fix via quirks hasn't landed on download mirrors yet
[08:07] <LaserJock> Kamion: I uploaded a new and improved edubuntu-menus to NEW for our reviewing pleasure ;-)
[08:07] <crimsun> jdong: yes it has.
[08:07] <popey> ah, ok, I'll be patient for that then
[08:07] <LaserJock> s/our/your/
[08:07] <popey> if that is a suspect
[08:07] <jdong> crimsun: I haven't been able to pull it from archive.ubuntu.com
[08:07] <crimsun> jdong: considering I've been running it for roughly 15 minutes, I'd say it's available.
[08:08] <mjg59> popey: Yeah, wait for -8
[08:08] <jdong> crimsun: hmm, you're right, they're in there, but dist-upgrade doesn't pull them in
[08:08] <popey> shall I update the bug mjg59 ? 
[08:08] <popey> is it a duplicate of something else?
[08:08] <mjg59> Once you've tried -8, yeah
[08:08] <mjg59> Not sure if it's a dupe
[08:08] <popey> ok
[08:08] <crimsun> jdong: -meta isn't updated.
[08:08] <mjg59> I don't follow most of the kernel bugs too closely
[08:08] <jdong> crimsun: ah, ok
[08:08] <popey> thanks for your time, appreciated
[08:09] <Treenaks> mjg59: what is used for mode switching nowadays?
[08:10] <mjg59> What sort of mode switching?
[08:10] <Treenaks> mjg59: graphics mode, on boot (before X does it)
[08:10] <mjg59> I don't really understand the question
[08:11] <Treenaks> mjg59: I have 2 machines that display garbage on boot, instead of a nice flashy usplash. I think it's because [the thing that switches video modes]  doesn't do it correctly.
[08:11] <jdong> Treenaks: you mean the workaround for intel chipsets, or more like what usplash does?
[08:11] <Treenaks> (one has an ATi builtin chip, the other is an NVidia 6600)
[08:11] <mjg59> Treenaks: It's your video BIOS
[08:12] <Treenaks> mjg59: hm. suck. any way to force usplash to use a sane mode?
[08:12] <mjg59> It uses sane modes
[08:12] <Treenaks> (saner?)
[08:13] <Treenaks> mjg59: how do I know which mode it's trying to set?
[08:13] <mjg59> Check /etc/usplash.conf
[08:13] <Treenaks> 1280x800
[08:13] <Treenaks> (native flat panel resolution)
[08:14] <_ion> Here usplash tries to use 1024x768 and then just dies because screen initialization fails for some reason. It'd be nice if it had a fallback to 640x480 or 640x400.
[08:15] <Treenaks> _ion: how does it look when it dies? because it looks almost the same on my Ati and my nvidia..
[08:15] <_ion> It just exits.
[08:16] <Treenaks> _ion: no garbledness?
[08:16] <_ion> There's a blank tty with the normal virtual console resolution. Alt-F1 etc. work as expected.
[08:16] <_ion> Not at all.
[08:16] <Treenaks> hmm
[08:21] <popey> mjg59: perhaps further evidence - if I leave network cable out mouse is okay, if I plug it in the usb mouse goes sluggish, but trackpad is fine
[08:22] <Treenaks> popey: that sounds _bizarre_
[08:22] <popey> definately sounds interrupty
[08:28] <tseng> Treenaks: might have meant via cpus
[08:29] <Treenaks> tseng: I have those too
[08:29] <Treenaks> tseng: (epia boards)++
[08:29] <HiddenWolf> Treenaks is our resident via groupie
[08:29] <Treenaks> nah
[08:33] <jdong> how do I temporarily deactivate apport?
[08:33] <jdong> like I KNOW a web page I'm going to will make firefox segfault
[08:33] <tseng> stop the service
[08:33] <jdong> tseng: oh, that's easy :)
[08:33] <jdong> heh
[08:33] <zul> heh the via patch was reversed
[08:33] <Mithrandir> or echo /bin/true > /proc/sys/kernel/crashdump-helper
[08:33] <ScreaminIke> uhm. can i make a feature request in this room?
[08:35] <cprov> imbrandon: ping
[08:35] <jdong> ScreaminIke: I typically try that... and get yelled at for it :)
[08:35] <jdong> ScreaminIke: YMMV
[08:40] <LaserJock> ScreaminIke: it would kinda depend on the feature, most feature requests should be turned into specifications, I believe
[08:41] <LaserJock> others are bugs and should go to Launchpad
[08:44] <popey> zul: the via interrupt wierdness patch?
[08:47] <zul> yep..
[08:48] <zul> afaik
[08:48] <Kamion> LaserJock: specifications should be used when the feature is complicated and/or affects several different bits of the system
[08:48] <Kamion> i.e. requires design
[08:48] <Kamion> just because it's a feature request as such doesn't mean it needs a specification - nor necessarily vice versa, even
[08:49] <Kamion> there are some specs that are there to fix complicated bugs
[08:50] <popey> zul: any clues why?
[08:51] <zul> popey: well it broke alot of peoples computers i believe
[08:51] <popey> :(
[08:51] <popey> mine is broke :(
[08:55] <carlos> Riddell: about the .pot files missing the UTF-8 encoding tag, would you fix also other templates from kdeaccesibility and kdelibs?
[08:55] <Riddell> carlos: sure
[08:55] <carlos> Riddell: thanks
[08:58] <LaserJock> Kamion: good point
[08:59] <AndrewLee> mdz: Hi, could you please take a look on bug #57081? A lot of users are waitting for this update.
[08:59] <Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
[09:03] <mdz> AndrewLee: freeflying and I have an ongoing email conversation about this, but it is difficult to understand his explanation of the problem
[09:04] <mdz> AndrewLee: whatever the approach we take, it must be implemented and tested in development before we even consider an update for dapper
[09:04] <mdz> and that doesn't seem to have happened yet
[09:04] <AndrewLee> mdz: It's broken in dapper now.
[09:05] <mdz> AndrewLee: that is what the two of you have said, though I'm surprised this wasn't noticed in the months prior to dapper's release
[09:05] <AndrewLee> mdz: It's well tested in Debian for a long time.
[09:05] <AndrewLee> mdz: I did noticed the ubuntu member in Taiwan. but seems he didn't do anything on it.
[09:06] <Kamion> AndrewLee: for dapper, the relevant fix needs to be isolated and backported (all the conversation on the bug is about dropping a new upstream version into dapper, which we generally try very hard to avoid)
[09:06] <AndrewLee> mdz: I am the maintainer of the package in Debian, and ubuntu also list my name and email as the package maintainer, so I got a lot of users's complains
[09:07] <Kamion> much like stable release updates in Debian; you'd get a "no" answer to a request to drop in a new upstream version there too, generally
[09:07] <mdz> AndrewLee: I apologize for that; the maintainer field will be fixed automatically the next time the package is built
[09:07] <AndrewLee> Kamion: I know, but how to make me away from the bug reports? Ubuntu listed my name on that....
[09:07] <Kamion> AndrewLee: as mdz says
[09:07] <Kamion> with the next build, it'll be Maintainer: ubuntu-devel@lists.ubuntu.com, Original-Maintainer: you
[09:08] <Kamion> if you know the package well, is there any chance you could identify the patch needed?
[09:08] <AndrewLee> Kamion: Users cannot use it is a big problem, hope you can solve it and use your way.
[09:09] <Kamion> we realise that broken packages are a big problem, but (particularly due to recent events) we are being extremely cautious about stable release updates
[09:10] <AndrewLee> Kamion: I felt so sad to hear this kind of shit, I notice ubuntu member before dapper released, but the bug is still there until now.
[09:10] <mdz> AndrewLee: I've added some information to the bug explaining how to proceed
[09:10] <Kamion> I haven't seen the conversation between mdz and freeflying (and mdz, feel free to tell me to shut up if I've missed something relevant), but nobody's saying "we shouldn't fix this"; we just want to know how to fix it in the least risky way for us.
[09:10] <Kamion> note that Ubuntu membership just recognises significant and sustained contributions to the project; it doesn't guarantee that a particular bug will get fixed
[09:11] <Kamion> (in time for a particular release)
[09:11] <AndrewLee> mdz: Users cannot use for typing Chinese, it's big problem just like you cannot type your mother language...
[09:11] <mdz> the best thing to do with a bug is to file it in launchpad, that way it is recorded
[09:13] <mdz> AndrewLee: thank you for that information.  is there a problem with the information I added to the bug?
[09:13] <AndrewLee> Kamion: if it's really a Linux for human beings...how could you make users cannot type their mother language...
[09:13] <mdz> AndrewLee: scim-chewing in Ubuntu was last changed in April, two months before the release.  it was freeflying himself who made the change, and is now saying that it is broken
[09:13] <AndrewLee> mdz: I did, but I didn't get ant answer since 2006-09-08 20:03:52 CST
[09:14] <AndrewLee> mdz: I did notice them before dapper released.
[09:16] <mdz> AndrewLee: in April, freeflying changed the configuration in scim-chewing in Ubuntu.  5 months later in September, I received an email saying that this configuration is wrong and needs to be reverted.  It was not until 15 minutes ago that the bug report was brought to my attention.  I've now added instructions to the bug explaining how to work toward a solution.
[09:16] <mdz> AndrewLee: is there anything further I can offer to help?
[09:27] <AndrewLee> mdz: It's too complicated to explain such mess, I think ubuntu was wrong since the im-switch integration.
[09:28] <AndrewLee> mdz: And for scim-chewing 0.2.1 was a known bug in upstream, they got the problem solved on 0.3.x
[09:29] <AndrewLee> mdz: And dapper took the buggy 0.2.1 with a messed im-switch configuration
[09:29] <AndrewLee> mdz: So that become two problems and both made users cannot type Chinese.
[09:34] <imbrandon> cprov: pong
[09:35] <cprov> imbrandon: hi, did you requested sync-source from amarok in backports or did you uploaded it ?
[09:35] <imbrandon> cprov: what do you mean? i requested the backport AND uploaded the edgy version
[09:36] <imbrandon> cprov: keybuk did the actual backport though afaik
[09:37] <jdong> cprov: ubuntu-archive does the actual backporting; imbrandon and I are the human filters deciding what gets sent to them for backporting
[09:37] <cprov> imbrandon: right, so that's why is was accepted, it didn't pass throught the buggy code we refered before (and is fixed in RF4066)
[09:38] <imbrandon> hrm i'm not following 
[09:38] <jdong> cprov: I don't think imbrandon did a manual upload backport for amarok
[09:39] <jdong> it should've passed through the buggy code just like the k3b backport
[09:39] <cprov> jdong: imbrandon: ok, I was just curious how the amarok version was accepted in backports (code is really broken as I described)
[09:39] <imbrandon> no i uploaded it to edgy normaly, then keybuk did sync-source when i "approved" the backport
[09:39] <imbrandon> hrm i dunno how it got through heh it went through the same process as k3b afaik
[09:40] <jdong> cprov: yeah, that makes me scratch my head, too
[09:40] <cprov> jdong, imbrandon: can't you do the same procedure for k3b ? it sounds like a good & safe workaround
[09:40] <jdong> cprov: it's the same procedure to our knowledge though
[09:40] <imbrandon> cprov: they were / are done the same way
[09:40] <jdong> cprov: we didn't do anything different
[09:40] <imbrandon> right
[09:41] <Kamion> s/sync-source/backport-source/
[09:41] <Kamion> sync-source doesn't do backports
[09:41] <Kamion> I need to send backport-source to the Soyuz guys, I know
[09:41] <cprov> Kamion: do you have this variation of the script ? 
[09:42] <Kamion> cprov: it's not a "variation", it's more or less completely different
[09:42] <imbrandon> hrm it might be k3b is the only thing holding up, i was about to file one for konversation ( thats already there also ) Kamion you wannt backport-source it and see if its just k3b ?
[09:42] <Kamion> backporting generates a new source package
[09:42] <Kamion> it's in ~lp_archive/bin/ on drescher
[09:42] <Kamion> it's just a port of elmo's old mia.py tool to Soyuz
[09:42] <cprov> Kamion: uhmm, it makes me curious ;)
[09:42] <Kamion> sure, that's why I say I've been meaning to send it to you
[09:42] <jdong> imbrandon: the only difference I see between k3b and amarok is that k3b ftbfs'ed while amarok had binaries in dapper-backports
[09:42] <Kamion> but it doesn't affect this bug - backport-source generates a source package which we dump into the sync queue, just like syncs
[09:43] <Kamion> jdong: that's highly relevant
[09:43] <jdong> imbrandon: IIRC konvo also failed build, so I predict it'll get rejected, too :)
[09:43] <Kamion> at least to binary accepts
[09:43] <jdong> Kamion: interesting... we might be getting somewhere :)
[09:44] <imbrandon> jdong: that probably should have been in the bug report heh
[09:44] <Mez> I presume this is a backports discussion ?
[09:44] <jdong> Mez: yep
[09:44] <Kamion> although actually wasn't the amarok reject a source reject?
[09:44] <imbrandon> mez yea
[09:44] <cprov> uhm, the same bug exists in binary world
[09:44] <Kamion> in which case never mind me
[09:44] <Kamion> cprov: yeah, I know
[09:44] <imbrandon> Kamion: no amarok went through
[09:44] <Kamion> oh
[09:44] <imbrandon> thats the puzzling part
[09:45] <cprov> see https://launchpad.net/+builds/+build/247050, succesfully build, but no binaries
[09:45] <cprov> built, too
[09:45] <imbrandon> Kamion: can you try to backport the new konv ( it needs it anyhow and i was about to file ) and we'll see if its becouse the old backage ftbs
[09:45] <Kamion> right, that's why I wasn't backporting amarok
[09:46] <Kamion> imbrandon: no, I'm not going to attempt any backports until the fix for this bug is rolled out
[09:46] <Kamion> if Keybuk had asked I would have suggested the same thing
[09:46] <imbrandon> cprov: no binarys ?
[09:46] <Kamion> imbrandon: for amarok
[09:46] <jdong> imbrandon: the binaries get sucked into a black hole :)
[09:47] <cprov> when we roll the fix we can recover them 
[09:47] <Kamion> 18:13:54 INFO    amarok: Version newer than that in BACKPORTS. 2:1.4.3-0ubuntu6~
[09:47] <imbrandon> ok , sounds like a plan , man this gets more intersting by the minute ;)
[09:47] <Kamion> dapper1 >= 2:1.4.2-0ubuntu2~dapper1
[09:47] <Kamion> ^-- binary reject
[09:47] <jdong> ooh, binary reject
[09:48] <jdong> so it accepted a newer source if no binaries exist
[09:48] <jdong> no, sorry, meant reject
[09:48] <Kamion> oh I don't know, I'm not investigating this tonight
[09:48] <jdong> but if binaries exist, it accepts a source but rejects newly built binaries
[09:48] <imbrandon> theres a fix in the works thats all that matters
[09:48] <jdong> fascinating, confusing, and definitely calls for aspirin :)
[09:48] <jdong> cprov: what's the ETA on rollout?
[09:49] <cprov> the code line in drescher is really messy, let try to cherrypick the fix experimentally in another codeline, if it works we can request kiko/mdz permission to roll it out
[09:49] <imbrandon> kk
[09:50] <cprov> jdong: we are working to rool major feature til the end of this week, but not promises ...
[09:50] <jdong> k
[09:51] <jdong> whoa, hey cool, mplayer is completely not working now
[09:51] <jdong> yay!
[09:51] <_ion> jdong: Yeah. There's a bug report about it.
[09:52] <jdong> _ion: yeah, I see it now
[09:55] <Nafallo> jdong: AFAIK slomo said it was harder than that.
[09:55] <jdong> Nafallo: I was afraid of that :)
[09:55] <slomo> jdong: a rebuild will make it work again partially but won't fix it completely
[09:55] <jdong> ever since I moved from gentoo this whole recompiling thing isn't as magical anymore :)
[09:56] <slomo> Nafallo: feel free to fix it yourself if you have some free time today, i have to care about something else now ;)
[09:56] <jdong> slomo: what exactly is a partially working mplayer? ;)
[09:57] <jdong> as long as mencoder can use the xvid and lavc codecs I'm happy
[09:57] <slomo> jdong: exploding on ac3 decoding... other than that it should work fine
[09:57] <Nafallo> slomo: new banshee? :-)
[09:57] <slomo> Nafallo: yes
[09:57] <jdong> slomo: k, works for me :)
[09:57] <Nafallo> slomo: hehe, prio ;-)
[09:59] <pitti> yay python 2.5
[10:26] <Burgwork> Kamion, you around to chat quickly about evand?
[10:27] <Kamion> Burgwork: sure
[10:32] <slomo> infinity: iirc you care about apache2... apache2-dev is uninstallable on the buildds for some reason: http://librarian.launchpad.net/4316188/buildlog_ubuntu-edgy-i386.mod-mono_1.1.17-1_FAILEDTOBUILD.txt.gz
[10:47] <cprov> Kamion: imbrandon: jdong: fix for bug #58144 rolled out experimentally, can you submit a backport candidate ?
[10:47] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,Fix committed]  http://launchpad.net/bugs/58144
[10:49] <imbrandon> Kamion: is the only one with the privlages to actualy pipe it though
[10:49] <imbrandon> cprov: ^
[10:50] <cprov> imbrandon: upload, it will seat in unapproved queue, which is already a big win 
[10:50] <Kamion> ! no it's not
[10:50] <Kamion> I don't want dapper-backports hitting unapproved - that's just extra work
[10:51] <cprov> Kamion: uhm, ok ...
[10:51] <imbrandon> no we dont upload to dapper backports
[10:51] <Kamion> and distro policy is not to have people uploading backports by hand in general
[10:51] <imbrandon> yea
[10:51] <Kamion> cprov: I mean, I don't want sync-queue backports to hit unapproved
[10:51] <Kamion> cprov: if anyone uploads to it by hand, that should hit unapproved, definitely
[10:51] <imbrandon> we just file the reports and test them
[10:51] <Kamion> but when we punt it through the sync queue, it should go straight to new/accepted
[10:52] <ajmitch> Kamion: want any more info added to bug 59001 ?
[10:52] <imbrandon> right ... well if you want one to test i can file a request for konversation or we can retry amarok
[10:52] <Ubugtu> Malone bug 59001 in Ubuntu "sync zope packages" [Untriaged,Needs info]  http://launchpad.net/bugs/59001
[10:52] <cprov> Kamion: fine by me, fix is rolled, let me know if it works as expected or not.
[10:53] <Kamion> I'll do amarok
[10:53] <imbrandon> Kamion: kk
[10:53] <Kamion> hmm, no, amarok source worked
[10:53] <Kamion> was it k3b that got source-rejected?
[10:53] <imbrandon> yea
[10:53] <imbrandon> amarok on the binarys got rejected
[10:53] <imbrandon> k3b source
[10:54] <kmon_> Hi. Can someone be kind enough to tell me the login details of knot cd 3. I can't login in console mode and X doesn't start.... I'm trying to get some info to squash a bug.
[10:54] <Kamion> ajmitch: that's great, thanks
[10:54] <imbrandon> kmon_: ubuntu / ubuntu
[10:54] <Kamion> kmon_: whatever you entered during installation - there's no default user/password
[10:54] <Kamion> kmon_: unless you mean the live CD, in which case what imbrandon said
[10:54] <imbrandon> Kamion: livefs
[10:54] <kmon_> imbrandon: It doesn't work
[10:55] <Kamion> it's supposed to start with the ttys already logged in though
[10:55] <Kamion> then you're hosed :)
[10:55] <imbrandon> hrm true
[10:55] <kmon_> Kamion: ubuntu/ubuntu doesn't work
[10:55] <Kamion> I expect that the CD or the drive is a bit buggered
[10:55] <Kamion> kmon_: the image or the drive is faulty beyond reasonable repair, then, I think
[10:55] <kmon_> I've tried on both the x86 and amd64 live cds
[10:55] <Kamion> this is sadly quite common
[10:55] <imbrandon> kmon_: username : ubuntu password: ubuntu not ubuntu/ubutnu
[10:55] <Kamion> drive lenses often get dirty
[10:56] <imbrandon> yea
[10:56] <kmon_> imbrandon: typo, sorry
[10:56] <imbrandon> bad cdrom drive likely
[10:56] <imbrandon> err dirty
[10:56] <Kamion> kmon_: sorry if that seems overly quick to jump to conclusions, but I've dealt with several dozen such bugs lately
[10:56] <kmon_> with both isos?
[10:56] <kmon_> Kamion: ok
[10:57] <kmon_> I'll see if I can get another cd to test
[10:57] <Kamion> kmon_: it's possible for the *drive* to be unable to read CDs in general
[10:57] <Kamion> not a matter of the CD
[10:57] <imbrandon> kmon_: drive
[10:57] <Kamion> another CD is worth trying of course
[10:57] <kmon_> ...
[10:57] <Kamion> but this has happened to me, I'm not making it up - a drive cleaning kit bought from an electronics shop worked wonders
[10:58] <kmon_> I'll try with another computer I have
[10:58] <Kamion> yes, that's worth trying
[10:58] <kmon_> I'll tell you in a few seconds....
[10:58] <imbrandon> specialy the livecd as it wont mess anything up
[10:58] <imbrandon> only out some uptime ;)
[10:59] <Kamion> doko: I'd still like you to add information about the Ubuntu changes being overridden in those ada syncs to the bug
[10:59] <Kamion> doko: I don't know if you told me on IRC, but if you do that, I'll lose it
[11:00] <kmon_> Kamion: same problem on my other computer
[11:01] <kmon_> now, the only chance is that *both* cd's I've used to burn the x86 and amd64 isos are broken...
[11:01] <imbrandon> strange, are you sure the cd burner burned it correctly ? md5s matched
[11:02] <kmon_> imbrandon: haven't tested, that's on my next test
[11:02] <Kamion> do a CD integrity check from the boot menu
[11:02] <Kamion> we did test the knot-3 images before release - if it were a daily build I'd be more inclined to suspect breakage in the image itself
[11:02] <Kamion> of course it could still be that, but need to eliminate hardware first
[11:02] <kmon_> ok
[11:03] <Kamion> then, try sticking 'single' on the end of the boot options (F6 from the boot menu)
[11:03] <kmon_> I'm trying yet another cd drive
[11:03] <Kamion> can't remember what that does on the live CD but with any luck it'll get you to a root prompt you can use to debug stuff
[11:03] <kmon_> Kamion: thanks
[11:04] <imbrandon> Kamion: it does , i had to use it when i borked a upstart install ( without upstart-sysv-compat ) reciently
[11:04] <imbrandon> heh
[11:04] <imbrandon> or should say it /should/
[11:04] <Kamion> ok, k3b worked this time, I think
[11:04] <Kamion> anyway, bed
[11:04] <imbrandon> Kamion: gnight
[11:04] <imbrandon> thanks ;)
[11:05] <kmon_> bye
[11:05] <imbrandon> cprov: ping
[11:05] <cprov> imbrandon: pong
[11:05] <imbrandon> heh looks like k3b worked he said, is there a way to recover the amarok, or does it need to be redone
[11:07] <cprov> imbrandon: there is a way, I think you can ask infinity to do so.
[11:07] <imbrandon> ko , sounds great, thanks for pushing the fix, you rock
[11:08] <cprov> imbrandon: thanks, it was already too late ;)
[11:08] <kmon_> imbrandon: the check cd test has finished but didn't tell me anything at all, instead it booted into gnome
[11:08] <imbrandon> kmon_: looks like a good thing
[11:09] <kmon_> then if the cd shows the login problem on both drives and the check cd didn't report any problem....
[11:09] <kmon_> I think I have a bug
[11:09] <kmon_> :)
[11:10] <imbrandon> possibly, this is a knot 3 cd right, i thought you said you couldent start X
[11:11] <kmon_> I have 2 machines
[11:11] <kmon_> X doesn't boot on my laptop
[11:11] <kmon_> I'm using my desktop now
[11:12] <kmon_> anyway
[11:12] <kmon_> if single mode works
[11:12] <imbrandon> hrm ok i'm missing the problem , sorry i've tired, whats the root issue ?
[11:12] <kmon_> Ill use it to get the bug details
[11:12] <kmon_> there are different issues here
[11:13] <kmon_> one is that on both amd64, x86 knot cd 3 login through the console doesn't work
[11:13] <kmon_> I mean, ubuntu / ubuntu doesn't work
[11:13] <kmon_> then, the other issues are things I'm trying to debug in my laptop
[11:13] <imbrandon> you did check caps lock etc correct ? sorry i must ask
[11:13] <kmon_> errrr
[11:14] <kmon_> I think so ;)
[11:14] <imbrandon> heh
[11:14] <kmon_> arrrg
[11:14] <kmon_> another boot
[11:15] <kmon_> now
[11:15] <kmon_> wait
[11:15] <kmon_> yes, NO caps lock
[11:15] <imbrandon> ok kmon_ i'm sorry to cut this in the middle there might be someone awake still in here or better in #ubuntu , if not meet us back in here in about ~12 hours
[11:15] <imbrandon> ok , just checking
[11:15] <imbrandon> sometimes we all make booboo's ;)
[11:16] <kmon_> I don't care much about the login issue if single mode works
[11:16] <kmon_> I should have thought about it, but here is also late....
[11:16] <imbrandon> yea single should drop you to a root console
[11:16] <kmon_> I think it's a common practice to debug things late at night
[11:16] <kmon_> :)
[11:16] <imbrandon> ;)
[11:16] <kmon_> anyway...
[11:16] <kmon_> thanks for your help
[11:17] <kmon_> I'm off to try the single mode
[11:17] <imbrandon> yea collect a bit of info i'll be glad ( or someone ) to help out when i wake
[11:17] <imbrandon> ciao
[11:17] <kmon_> bye
[11:19] <siretart> gnarf. why don't we have ffmpeg in main :/
[11:58] <dholbach> see you tomorrow