[12:55] <lamont> Kamion: you around?
[01:16] <robtaylor_> mdz: how's the live-cd cloop fun coming on?
[01:18] <mdz> robtaylor: I squashed the big bug in Mataro, and then more or less took a holiday since
[01:18] <mdz> amu has been doing some work on it during that time
[01:31] <mdz> gah, workrave is busted
[01:32] <mdz> though it hasn't changed in forever
[01:45] <jdodson> jdub: who do i talk to about being mentored for "package maintainer" status.  the wiki mentions that as a suggestion.
[01:45] <jdub> jdodson: we haven't got a full-on mentorship program or anything, but you can always punt questions here while you're learning
[01:46] <jdub> jdodson: a good place to start is the debian new manitainer guide and fixing bugs in universe packages you like
[01:46] <jdodson> jdub: ok
[01:46] <jdodson> jdub: i volunteer on the ubuntu forums and wanted to help out as a maintainer.   
[01:47] <jdodson> jdub: thanks for the advice.
[01:48] <jdodson> jdub: do you do much with the gnome foundation anymore?  slashdot noted you were not in the last round of elections for the foundation.
[01:49] <jdub> i didn't run for election this year - i will write about that more at some stage.
[01:49] <jdodson> jdub: thats cool, when they mentioned it on slashdot, i did a good search and found out you were working for ubuntu.  
[01:50] <daniels> mdz: l-r-m is my first priority after xorg, so should be tomorrow by the time I've run it around all the buildds
[01:51] <daniels> mdz: (i also have an engagement tonight, so losing a couple of hours off today, making it up tomorrow, so probably won't quite get to a new upstream l-r-m, especially as it needs patches for nvidia)
[01:51] <mdz> daniels: great, thanks
[01:53] <daniels> lamont: can you please install a reasonable subset of build-depends on halley so I can get l-r-m on ia64 going?
[01:53] <daniels> mdz: oh, that's right
[01:53] <lamont> daniels: no
[01:53] <daniels> mdz: we'll have fglrx on amd64 soon enough, too
[01:53] <daniels> elmo_away: ping
[01:55] <lamont> libatomic-ops already has a patch in the bts for amd64 support... hrm.
[02:04] <lamont> mono friends.. mcs is still ftbfs
[02:06] <daniels> lamont: priority #6 or so
[02:09] <lamont> daniels: yeah - there's a build log for it now, for those who might care to loo,
[02:09] <lamont> k
[02:09] <daniels> lamont: cheers
[02:15] <daniels> lamont: so, with p.u.c/~lamont/daniels/, does xorg-6.8.1 contain the full build-tree?
[02:15] <daniels> i.e. can I just grab the files I need from there instead of grabbing the diff?
[02:16] <lamont> xorg-6.8.1 is the old one from ia64, IIRC
[02:17] <daniels> ahr, ta
[02:18] <lamont> people.ubuntu.com/~lamont/daniels/xorg_6.8.1-1ubuntu8.5.diff
[02:18] <lamont> is only 44kb
[02:19] <lamont> and is a diff -urN vs 1ubuntu8
[02:19] <daniels> ahr, ta
[02:28] <mdz> lamont: what happened with alsa-driver?
[02:28] <mdz> (and didn't this happen before?)
[02:29] <lamont> before was a 'just use debian' that I can't see how I would have asked for
[02:30] <lamont> this time, dunno - about to look at that
[02:30] <lamont> as well as 72 MB of diffs
[02:32] <daniels> mdz: btw, #2542 may never be solved
[02:32] <daniels> mdz: unfortunately with most cards, you need to probe for their amount of video ram
[02:32] <daniels> mdz: istr one ranging between 16 and 128MB with a single PCI ID
[02:35] <mdz> has anyone seen thom around?
[02:36] <mdz> daniels: probing for it would be no worse than what xresprobe already does
[02:37] <daniels> mdz: dude
[02:37] <daniels> mdz: probing for video RAM involves doing what the drivers do
[02:37] <daniels> open()ing /dev/mem and poking at random bits
[02:39] <Riddell> when running debuild -S on a package I get "cannot represent change to khtml/java/kjava.jar: binary file contents changed" is there a way to get round that?
[02:39] <daniels> mdz: the problem isn't with newer cards, because they typically have one PCI ID per configuration, which includes video RAM
[02:41] <daniels> Riddell: uuencode the new version, and unpack it over the top in your configure/build sequence, and either restore it or delete it in clean
[02:41] <Riddell> daniels: that sounds a bit over-complex to me, I can't just tell it to ignore that binary file?
[02:42] <daniels> Riddell: well, if you managed to do that, diff would ignore that binary file, and your changes would be lost
[02:42] <daniels> how did you change it, anyway?
[02:43] <Riddell> daniels: it's the konqueror java vulnerability, the updated kjava.jar file is from the "patch" (just a tarball) they made
[02:44] <sladen> Riddell: unzip the new jar and the old jar and compare the contentses
[02:44] <mdz> daniels: dude, xresprobe does this already
[02:44] <mdz> it lets the X server do its driver-specific magic and munges the log file
[02:44] <mdz> seems like the same could be done for video memory size
[02:44] <Riddell> sladen: I have the .java sources, but the .jar file is kept in CVS (and hence this patch) to stop people needing the java compiler to make khtml
[02:44] <daniels> mdz: it doesn't invoke the X server unconditionally, but I suppose it could be done, as much as I dislike the idea
[02:45] <sivang> mdz: does it allow for detection of high refresh rates on capable devices?
[02:45] <daniels> Riddell: right, so you need to uuencode it
[02:45] <mdz> daniels: it would be nicer if the server itself would fall back more sanely
[02:45] <daniels> sivang: that's already solved in xorg
[02:45] <sivang> daniels: I never managed to get my display to do 100hz...
[02:45] <daniels> mdz: well, it's trying its best to obey our command, to be fair
[02:45] <daniels> sivang: then you probably need to enter your sync ranges manually, because your monitor is lying
[02:45] <mdz> daniels: but we have to be way too specific in what we ask of it, IMHO
[02:46] <daniels> sivang: either that, or lower your resolution a bit
[02:46] <daniels> mdz: oh, agreed, the current infrastructure is total crap
[02:46] <daniels> mdz: but pretty much the only way to properly fix it is to start from scratch; the entire server infrastructure is terminally broken
[02:48] <mdz> calc: https://bugzilla.ubuntu.com/show_bug.cgi?id=4597
[03:13] <sivang> lamont: that bad? :)
[03:14] <lamont> sivang: I have NFC what drugs I was on when I did the upload
[03:25] <lamont> mdz: alsa-driver_1.0.7-2ubuntu2 uploaded, mutes on stop
[03:25] <mdz> lamont: does it also resurrect the patches which vanished?
[03:25] <lamont> yes
[03:25] <mdz> great, thanks
[03:25] <mdz> lamont: was that an overlooked _dropped.patch or something?
[03:25] <lamont> and kills the regressions that were in the patch
[03:26] <aj> Next week on CSI: "Grissom! About time you got here. Looks like drug addled youths have been on an NMUing spree again."
[03:26] <mdz> I was wondering if we should have a BIG RED FLASHING thing there if there are dropped patches
[03:26] <lamont> aj: lol
[03:27] <aj> lamont: stay tuned as Grissom finds a twiddled bit in the uploaded package, and proves that whoever did the NMU is an albino tiger from west africa!
[03:27] <lamont> mdz: I have NFC where the source for -2ubuntu1 came from
[03:28] <lamont> mdz: fortunately, all of the patches came in during the 1.0.5a-1 vs 1.0.5a-1ubuntu6 timeframe... I ported that patchset forward to 1.0.7-2
[03:28] <lamont> we may not have correctly cleaned up the mess from the previous borked merge.
[03:29] <lamont> all of the ubuntu uploads after 1.0.5a-1ubuntu6 say 'resync with debian'
[03:30] <lamont> if one of those has something in it that is more than a resync, then I just dropped it.. :-(
[03:30] <mdz> lamont: perhaps we should ask Keybuk to keep old MOM output around for cases like this
[03:31] <lamont> mdz: that could help.. I have been making use of the ubuntu and debian morgues
[03:31] <mdz> lamont: drop him an email, if you would
[03:32] <crimsun> what are the major changes for it?
[03:32] <crimsun> from the changelog, it seems like they're mostly 'unmute setting X'
[03:33] <mdz> crimsun: yeah, it's mostly just some changes to the init script
[03:33] <lamont> crimsun: that and changing the output format
[03:33] <lamont> (of the init script)
[03:33] <crimsun> yep, from 1.0.5a-1ubuntu1, gotcha.
[03:33] <mdz> I think the bugfix portions have been merged into Debian
[03:35] <crimsun> the modprobe stuff from 1.0.5a-1ubuntu5?
[03:37] <lamont> mail sent to scott, cc mdz
[03:37] <mdz> daniels: whycome my right Alt key stopped being Alt_R recently?
[03:37] <mdz> lamont: thanks
[03:37] <mdz> crimsun: yes
[03:37] <crimsun> mdz: I see a || true, so yes.
[03:39] <lamont> crimsun: current diff is only to control (depends), alsa-base.postinst, and alsa-base.alsa.init
[03:39] <lamont> and changelog, of course
[03:40] <crimsun> mdz: erk, apologies. I was looking at the ubuntu diff.
[03:40] <crimsun> lamont: right.
[03:42] <lamont> and actually, I think we might be able to lose the postinst piece
[03:43] <lamont> I fail to see the advantage to simply modprobing some modules during postinst...
[03:43] <lamont> they don't survive past the next reboot that way...
[03:47] <crimsun> also, the "mixer" in "pcm mixer seq" was redundant, because modprobing snd-pcm-oss pulls in snd-mixer-oss
[03:47] <lamont> well, /etc/modprobe.d/alsa-base does it now.
[03:48] <daniels> mdz: what is it now?
[04:05] <thully> Hi - I've reported some bugs in Hoary.  However, I don't think I'm going to run Hoary any more (I just don't have the time to deal with the bugs that come from it being an unstable distribution).  What should I do in Bugzilla about this?
[04:05] <mdz> daniels: ISO_Level3_Shift
[04:06] <daniels> mdz: ?!?
[04:06] <mdz> thully: that creates a difficult situation for us if we can't reproduce the bug
[04:06] <mdz> thully: if we can, then it's no problem
[04:06] <daniels> mdz: looks like you have ralt:lv3_shift somewhere
[04:06] <thully> Most of these bugs were reported some time ago
[04:06] <daniels> mdz: what's your gnome keyboard setup look like?  anything bong in xkboptions/xkbvariant/whatever?
[04:07] <mdz> daniels: like hell I do :-P
[04:07] <mdz>         Option          "XkbRules"      "xfree86"
[04:07] <mdz>         Option          "XkbModel"      "pc104"
[04:07] <mdz>         Option          "XkbLayout"     "dvorak"
[04:07] <daniels> i blame dvorak
[04:07] <mdz> no xkboptions, no xkbvariant
[04:07] <mdz> it worked fine until December sometime
[04:08] <mdz> now I'm back in xmodmap hell
[04:08] <daniels> if you just run sudo Xorg :1 -novtswitch -ac && xterm -display :1.0, and then run xev, does it give you Alt_R, or ISO_Level3_Switch?
[04:08] <daniels> could be some weird thing in the GNOEM applet
[04:08] <daniels> ugh
[04:08] <daniels> no-one deserves xmodmap
[04:09] <mdz> hey, -novtswitch comes in handy
[04:09] <thully> Is there any way to just remove my bugzilla account, or just remove myself from the bugs?
[04:09] <daniels> mdz: well, you'll still need to switch later
[04:09] <daniels> actually, there was no real point to -novtswitch here
[04:09] <daniels> but I use it a lot to test
[04:09] <mdz> yeah there was
[04:09] <mdz> I don't want it to switch, because I want to start the xterm first
[04:09] <daniels> sudo Xorg :1 -ac && xterm -display :1.0 && DISPLAY=:1.0 xev
[04:09] <mdz> and need to wait for the server to start up
[04:10] <daniels> ah yeah
[04:10] <daniels> if you do it with &, xterm usually waits
[04:10] <daniels> this is one thing the current server doesn't do horrifically badly :P
[04:10] <mdz> KeyPress event, serial 23, synthetic NO, window 0x400001,
[04:10] <mdz>     root 0x40, subw 0x0, time 96512, (44,118), root:(46,120),
[04:10] <mdz>     state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
[04:10] <daniels> mdz: that's on :1.0?
[04:11] <mdz> daniels: correct
[04:11] <mdz> so, doesn't look like GNOME's fault
[04:11] <mdz> lamont: yes, it should be set when libpaper1.config runs
[04:11] <mdz> you might need to source /etc/environment, not sure
[04:11] <mdz> Kamion would know
[04:13] <daniels> mdz: hm, so it does
[04:14] <daniels> something like bdn.
[04:14] <mdz> ./symbols/dvorak:    key <RALT>  {       [     Mode_switch,       Multi_key  ]        };
[04:14] <mdz> that's wrong, too, but an entirely different keysym
[04:15] <mdz> daniels: how can I ask xkb "wtf are you using"?
[04:15] <crimsun> (bd.)
[04:15] <daniels> mdz: setxkbmap -print, IIRC
[04:15] <mdz> xkb_keymap {
[04:15] <mdz>         xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
[04:15] <mdz>         xkb_types     { include "complete"      };
[04:15] <mdz>         xkb_compat    { include "complete"      };
[04:15] <mdz>         xkb_symbols   { include "pc/pc(pc104)+pc/dvorak"        };
[04:15] <mdz>         xkb_geometry  { include "pc(pc104)"     };
[04:15] <mdz> };
[04:15] <daniels>         xkb_symbols   { include "pc/pc(pc104)+pc/us+ctrl(nocaps)+compose(ralt)" };
[04:16] <daniels> yeah, so Mode_switch is what's forcing it into l3 in this case
[04:16] <mdz> daniels: bd.
[04:16] <daniels> mdz: bd?
[04:16] <mdz> daniels: 'b', 'd', '.' is xev on dvorak
[04:16] <mdz> us->dvorak
[04:16] <daniels> mdz: oh, right, ta
[04:17] <mdz> dvorak should have the same alt key definitions as us, IMO
[04:17] <daniels> mdz: hm, as far as I can tell, it's Always Been That Way
[04:17] <daniels> agreed
[04:17] <mdz> there seems to be a bunch of stuff in symbols/dvorak that has no business there
[04:17] <mdz> it should really only modify alpha and punctuation keys
[04:18] <mdz> anad yet it has entries for Escape, shift and crap in there
[04:18] <mdz> and
[04:18] <mdz> the right way for it to work is for dvorak to be a variant of a real keyboard layout
[04:19] <mdz> but xkb makes my eyes hurt
[04:19] <daniels> mdz: afaict, the canonical dvorak xkb definition has always done this
[04:19] <daniels> ! This file was automatically generated on Wed Nov  2 10:29:07 1994
[04:19] <daniels> ! by Ryszard Mikke with XKeyCaps 2.11;
[04:19] <daniels> ! Copyright 1991-1994 Jamie Zawinski <jwz@lucid.com>.
[04:19] <daniels> [...] 
[04:20] <mdz> daniels: I swear this behaviour changed in the past 30 days
[04:20] <daniels> ! The "Alt" key generates Mode_switch
[04:20] <mdz> a bit longer than that, potentially
[04:20] <mdz> my ~/.Xmodmap.old has keycode 113 = Alt_R
[04:20] <mdz> but I renamed that sometime around when I upgraded this box to pre-Warty
[04:21] <mdz> because it seemed to be unfucked
[04:21] <daniels> daniels@catsby:~/tmp/dvoraksucks/meh/etc/X11/xkb/symbols% grep Mode_switch dvorak
[04:21] <daniels> zsh: exit 1     grep Mode_switch dvorak
[04:21] <daniels> hm.
[04:22] <daniels> ah, hold on
[04:22] <mdz> what's that tree?
[04:22] <daniels> does it work if you do 'dvorak(basic)'
[04:22] <daniels> oh, sorry, ECONTEXT; that was xfree86
[04:22] <mdz> setxkbmap 'dvorak(basic)'?
[04:22] <mdz> don't bother?
[04:22] <daniels> setxkbmap -symbols 'dvorak(basic)'
[04:22] <daniels> or change it in xorg.conf and spawn a new server
[04:25] <mdz> daniels: dvorak(basic) gives me no alt keys, no windows keys, and one control key
[04:25] <mdz> (NoSymbol)
[04:26] <daniels> arse.
[04:26] <mdz> what I want to say is, I have a pc104 keyboard with a us layout, plus these bits changed for dvorak
[04:26] <daniels> mdz: try with us(pc104)+dvorak(basic)
[04:27] <mdz> omg
[04:27] <mdz> you are my hero
[04:27] <mdz> seems perfect
[04:27] <daniels> i sure am
[04:27] <daniels> do I get a pay rise? :)
[04:28] <mdz> better
[04:28] <mdz> you get a cooper's when I come to .au
[04:28] <daniels> ooo, shiny
[04:28] <sivang> mdz: what's a cooper? :)
[04:28] <mdz> supposedly it's a decent beer
[04:28] <sivang> mdz: american ? :)
[04:29] <mdz> australian
[04:30] <sivang> mdz: eh
[04:30] <sivang> mdz: why, supposedly?
[04:30] <daniels> mdz: i have five in my fridge; they are my preferred drop
[04:30] <daniels> mdz: (as long as it's the pale ale -- green label; the sparkling, which is red, isn't that great)
[04:30] <mdz> sivang: because I'm taking their word for it
[04:30] <mdz> having not tried it myself
[04:31] <daniels> it is very, very decent
[04:31] <sivang> hehe
[04:31] <sivang> daniels: was it monty python's that had a joke about non english/au beer? ;-)
[04:31] <lamont> is "decent beer" syntactically similar to "edible tripe"?
[04:32] <daniels> sivang: no, that was US beer
[04:32] <daniels> it's like making love on a canoe
[04:32] <lamont> daniels: in the canoe would be safer...
[04:32] <sivang> daniels: I was trying to be gentle :)
[04:33] <daniels> lamont: it's very close to water
[04:33] <lamont> daniels: ah, ok
[04:33] <sivang> lamont: http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus
[04:33] <daniels> (actually 'fucking close to water', but this is a family channel ;)
[04:33] <sivang> daniels: :)
[04:34] <mdz> jdub: ubuntu families
[04:34] <sivang> on freenode? 
[04:35] <daniels> mdz: no dude, grove street families
[04:38] <JanC> why drink only "decent" beer?
[04:38] <JanC> here in Belgium we have lots of fantastic beers   :-)
[04:45] <lamont> ENOSEB
[04:46] <thully> Is there a way to remove yourself from bugs you've reported on bugzilla, or remove yourself from bugzilla entirely - as I'm not going to have time to test hoary any more
[04:46] <davyd_> what does the package for Ubuntu CDs look like?
[04:46] <davyd_> and does it come from Switzerland?
[04:47] <lamont> thully: I think you can tell bz to never send you mail - which isn't quite the same thing, but close
[04:49] <thully> I wish Ubuntu had a "testing" distro like debian - so I could get updates but not have a huge risk of catastrophic system breakage
[04:50] <daniels> thully: with a six-month release cycle, it's pointless
[04:50] <lamont> thully: what daniels said
[04:51] <lamont> daniels: although I suppose that if we had 3x the people, we could have a release always in upstream-version-freeze, and release every 3 months.... :-)
[04:51] <lamont> but that's really getting silly
[04:51] <davyd_> what's the point, GNOME only releases every 6 months
[04:51] <lamont> davyd_: there's the rest of sid, too
[04:52] <lamont> s/sid/ubuntu-main/
[04:52] <davyd_> and we already spend half of that in freeze, I wouldn't want to spend any more
[04:52] <lamont> davyd_: and that's why I said 3x the people for 2x the releases/year.
[04:52] <lamont> it's well beyond the point of diminishing returns
[04:53] <davyd_> I am a big fan of 6 month releases
[04:53] <davyd_> but I wish feature freeze wasn't on Monday
[04:53] <thully> does that mean Thunderbird will be stuck at 0.9 if 1.0 isn't in by Mon?
[04:54] <thully> (in hoary)
[04:54] <lamont> davyd_: my box-o-cds says 'NL BREDA' for the last line of sender address.
[04:55] <lamont> which fits with my recollection that they ship from the netherlands
[04:55] <davyd_> thully: GNOME feature freeze, not Ubuntu
[04:55] <lamont> davyd_: feature freeze isn't monday.
[04:56] <davyd_> lamont: I don't have the box yet, I just got email from work saying mail had arrived for me
[04:56] <davyd_> lamont: it is for GNOME
[04:56] <lamont> davyd_: ah.  somehow that doesn't surprise me.
[04:57] <davyd_> lamont: what does that mean?
[04:57] <lamont> thully: after tomorrow they're not allowed to add new features to mozilla-thunderbird if they want to ship it in march
[04:57] <lamont> they're supposed to be fixing the bugs after taht date.
[04:57] <lamont> davyd_: ubuntu's upstream version freeze is this week as well.
[04:57] <davyd_> lamont: yeah, probably because it syncs with GNOME
[04:58] <lamont> given that the ubuntu release model is somewhat patterened off of gnome, there is little surprise in that
[04:58] <davyd_> guess who designed them both ;)
[04:58] <lamont> thully: since moz-thunderbird is coming through gnome (yes?), it has until march to be ready from hoary's perspective
[04:59] <davyd_> there are reasons they are similar
[04:59] <sivang> thully: I use hoary and apart from some trouble with gnome-applets now and then, I don't stumble into real serious trouble. [yet :)] 
[04:59] <thully> so - does anyone know to what this means to thunderbird 1.0 in hoary?
[04:59] <davyd_> sivang: what's wrong with the applets?
[04:59] <thully> It would be a shame if Hoary shipped with Thunderbird 0.9
[04:59] <lamont> thully: it means that thunderbird needs to meet the gnome schedule, assuming that it comes from there...
[04:59] <jdub> thully: unless we explicitly accept an update, it will stay at whatever version is released at UVF time
[05:00] <jdub> lamont: thunderbird is mozilla mail stuff, not gnome
[05:00] <lamont> jdub: so it doesn't come through gnome. check.
[05:00] <sivang> davyd_: eh, they are working great now :) I was just to note that this is still the biggest breakage I had, oh that and 2 weeks ago some with CUPS that got fixed
[05:00] <thully> Thunderbird 1.0 has been out for several weeks - but isn't in debian unstable yet
[05:01] <lamont> thully: is it even in debian experimental?
[05:01] <sivang> jdub: regarding country teams, what about the ubuntu-il mailing list? :)
[05:01] <jdub> given that 1.0 is already out (but just not in debian) it's reasonably likely that we'd accept a 1.0 package after UVF
[05:01] <jdub> sivang: haven't done it yet
[05:02] <thully> lamont: don't know about that
[05:02] <lamont> thully: nope/
[05:03] <thully> one question: Are the OpenOffice.org GNOME integration packages going to be included by default in Hoary?
[05:03] <lamont> thully: generally speaking, you can expect to see ubuntu ship with whatever the latest released code for FOO was 3 months prior to the release
[05:03] <lamont> thully: with gnome being the notable exception to that at this time.
[05:04] <lamont> thully: in specific, if there's a good case for taking a new upstream version after upstream version freeze, then it might make it through, depending on the apparent stability of it.
[05:04] <jdub> thully: they've been proposed for inclusion, yes.
[05:04] <thully> As i've installed from Array 2 and by default, these aren't included - making an extremely ugly default openoffice configuration
[05:04] <lamont> jdub: but will I get my ^*(_^&(B mouse focus fix in metacity, that's my question...
[05:05] <thully> Does laptop suspend support look to be on track?
[05:05] <jdub> lamont: more focus work still happening
[05:05] <lamont> jdub: but will it include strict-pointer-focus, that's the real question
[05:07] <lamont> jdub: (really not trying to troll, mind you)
[05:16] <JanC> anyone know what version of wxPython will be in hoary?
[05:18] <crimsun> 2.5.x will be in hoary/universe
[05:18] <daniels> thully: yes
[05:18] <crimsun> currently that's 2.5.3.2
[05:19] <thully> will it be configurable (suspend, that is)
[05:19] <daniels> thully: maybe
[05:21] <thully> If a GNOME applet is impossible, one solution that would allow suspend to be configured is to have each ACPI action (lid, sleep, powerbtn etc) call symbolic links to the actual suspend / hibernate / screen blank scripts
[05:21] <thully> then you just change the symlinks to change the settings
[05:25] <JanC> okay, that's good, because more and more programs & libraries that use wxPython need 2.5.x   :)
[05:26] <daniels> thully: a gnome applet will not be done in the time until hoary, unless someone writes it
[05:27] <daniels> thully: and you do realise that /etc/acpi/*.sh are conffiles, so they won't get overwritten if you modify them?
[05:30] <thully> I actually didn't modify these - I modified the files in /etc/acpi/events to call scripts in /etc/acpi/actions that are actually symlinks to the real suspend scripts
[05:30] <daniels> well, you can do that too.  and they won't get changed.  but the effect is the same.
[05:31] <thully> so, /etc/acpi/events/sleep calls /etc/acpi/actions/sleep.sh, which calle /etc/acpi/sleep.sh
[05:31] <thully> correction /etc/acpi/actions/sleep.sh points to /etc/acpi/sleep.sj
[05:31] <thully> sj=sh
[05:32] <thully> Why doesn't this work?  I've done this and it seems to work for changing suspend actions
[05:34] <daniels> what do you mean, 'why doesn't this work'?
[05:35] <thully> I'm a bit confused at what you were saying about conffiles - can you elaborate?
[05:38] <daniels> so, everything in /etc is registered as a configuration file
[05:38] <daniels> if you change it, your changes will be respected, and you won't lose them every update
[05:38] <daniels> so you can change /etc/acpi/lid.sh yourself if you want
[05:39] <thully> yes - I know - doing it the symlink way just makes it a bit cleaner and easier
[05:39] <daniels> after a fashion
[05:39] <thully> I was just a little confused when you were talking about "conffile"
[05:41] <thully> and what exactly you meant
[05:41] <bob2> 'conffile' is the name of the class of files that dpkg considers to be user-modifiable and will not fuck with
[05:42] <thully> Will Hoary be in a more stable state after UpstreamVersionFreeze?
[05:42] <lamont> thully: churn will certainly reduce
[05:42] <jdub> thully: stable meaning it won't change much, or do you mean robust?
[05:43] <thully> both, to an extent
[05:43] <jdub> it will stop changing to a large extent (gnome will continue to change)
[05:43] <jdub> because everything stops changing, bugs are more easily fixed, so it will become more robust
[05:45] <thully> Do you think it will be better than debian unstable in the stable-as-in-robust department - how about testing?
[05:45] <jdub> dude
[05:45] <crimsun> yes. It has a 3 month frozen period before release.
[05:45] <lamont> thully: instantly? of course not
[05:45] <jdub> it's going to be released in march as a preview and april as final supported
[05:46] <crimsun> hmm, march.
[05:46] <thully> OK
[05:46] <jdub> so if it's not releaseable by then, we will have serious problems
[05:47] <thully> daniels: will suspend be enabled by default?  Will the user be able to disable suspend?
[06:01] <lamont> jdub: new arrays?
[06:03] <lamont> I really wish our stupid web directory listing would show the mtime of files...
[06:03] <jdub> pulling a daily
[06:03] <jdub> for rsyncage
[06:25] <lamont> mdz: for giggles, 287614 should be imported, and applies to hoary (and probably warty...)
[06:26] <lamont> and is already imported.
[06:26] <lamont> sigh.
[06:33] <fabbione> morning
[06:34] <lamont> morning fabbione 
[06:36] <fabbione> ehhe
[06:36] <fabbione> night lamont 
[06:36] <lamont> 45 minutes to get to the failure... kinda boring
[06:36] <lamont> and the kids are back in school tomorrow, so I have to get up early again.
[06:36] <fabbione> welcome back to the real life ;)
[06:36] <lamont> heh
[06:37] <lamont> in addition to being an RC bug, gtkmm2.0 is holding up the majority of 111 d-w packages in stage 1
[06:38] <fabbione> actually... gtk2.0-bin or something like that is an issue for sparc too
[06:38] <fabbione> it doesn't install
[06:38] <lamont> gtkmm2.0 needs net access in order to build.
[06:38] <fabbione> argh
[06:39] <lamont> funny thing is that debian/rules has a "fix" for it, just not in the right place.
[06:39] <fabbione> lol
[06:39] <lamont> warty bug #5173, debian 287614
[06:40] <lamont> so I changed the place that is dying, plus the other possible place... in the morning (or if I wake up in the middle of the night), I'll try a build without the second one (or at least look at the log and see...)
[06:40] <fabbione> hmmm
[06:40] <lamont> hrm... maybe throttling the rsync of the iso to 8kbps was a bad plan.
[06:40] <lamont> 124 hours eta
[06:40] <fabbione> how could you build gnome-doc-utils?
[06:40] <fabbione> it fails here
[06:40] <fabbione> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd:166: parser error : XML conditional section not closed
[06:41] <lamont> built fine on my machine (which has no net access)
[06:42] <lamont> although if it's actually trying to go to www.oasis-open.org, that's an RC bug in debian.
[06:42] <fabbione> hmm i am getting errors installing Setting up libgtk2.0-bin (2.6.0-0ubuntu1) ...
[06:42] <fabbione> no i don't think it is
[06:42] <lamont> there's a 0ubuntu2
[06:43] <fabbione> of libgtk2.0 ?
[06:43] <lamont> don't think it's trying, or don't think it's a bug?
[06:43] <lamont> gnome-docutils
[06:43] <fabbione> even if it was trying my machine has net access
[06:43] <fabbione> yeah that one fails with that error
[06:43] <lamont> yes, but if the doc is bad on the website, and it's failing over gracefully with no net access...
[06:44] <fabbione> hmmm make sense
[06:45] <lamont> I wish python2.4 built on hppa (2.6.8) without me killing each of the thread tests..
[06:45] <fabbione> argh.. that sucks
[06:45] <lamont> stage 2 has 562 needs-build, 27 d-w
[06:45] <fabbione> dude.. let me try to give you a kernel
[06:45] <lamont> yeah - that's a factor in me saying that hppa ain't ready for hoary
[06:45] <lamont> yeah - need to get you a machine...
[07:01] <lamont> hrm.. 15minute build time... my bad
[07:18] <doko> good morning all!
[07:21] <fabbione> this is pure horror
[07:21] <fabbione> libgtk2.0-bin in chrootA doesn't install
[07:22] <fabbione> the same on chrootB that is a copy of chrootA installs fine
[07:22] <fabbione> difference is the console
[07:22] <lamont> lol
[07:24] <fabbione> lamont: you were right about gnome-doc-utils
[07:24] <fabbione> it tries to access the net if it can
[07:24] <lamont> that's a bug
[07:25] <fabbione> yup
[07:26] <fabbione> lamont: filing one
[07:26] <fabbione> lamont: can you check on one of your chroot if /usr/share/icons exists?
[07:27] <lamont> both stage1 and 2 have that directory present
[07:28] <fabbione> HMMM
[07:29] <fabbione> mine don't
[07:29] <fabbione> and that's apparently the reason why libgtk2.0-bin fails to install
[07:34] <lamont> interesting - I did nothing special to create it
[07:34] <lamont> sounds like yet-another-bug time
[07:35] <lamont> g'night
[07:35] <fabbione> probably a left over?
[07:35] <fabbione> i bootstrapped a new buildd chroot 2 days ago...
[08:15] <jdub> Kamion: when you're around -> pretty smooth hoary install from today, but didn't get an fb console (using an nvidia card on this machine).
[08:15] <jdub> Kamion: otherwise pretty smooth and, well, uneventful. ;-)
[08:18] <davyd_> jdub: so not like mine then ;)
[08:19] <davyd_> when I had to netcat UserDict onto my machine
[08:34] <jdub> Kamion: ... until the final packages are installed
[08:34] <jdub> Kamion: then i get a "type 'exit' to return to base-config" prompt
[08:34] <jdub> Kamion: which attempts to return, but doesn't ;)
[08:35] <jdub> Kamion: ah, nothing in the menu after "execute a shell".
[08:42] <fabbione> hey pitti
[08:42] <fabbione> Mr. DeRoot
[08:43] <pitti> Morning
[08:44] <pitti> fabbione: Hi Mr. Kernel patcher! :-)
[08:44] <fabbione> ehehhe
[08:45] <Treenaks> hmm.. do we enable the "Video" ACPI stuff in 2.6.10?
[08:46] <Treenaks> (ChangeSet@1.2131, 2005-01-02 11:45:13-08:00, torvalds@evo.osdl.org)
[08:51] <jdub> lamont: ubuntu-calendar* haven't gone in because we need james to accept them or something, right?
[08:54] <fabbione> Treenaks: k7-smp:CONFIG_ACPI_VIDEO=m
[08:54] <fabbione> Treenaks: and a changeset AFTET 24-12-2004 is mostlikely not in our tree
[08:54] <fabbione> AFTER
[08:54] <fabbione> Treenaks: full URL to the changeset?
[08:55] <crimsun> fabbione: another vote of confidence for linux-image-2.6.10-1-686-smp (2.6.10-3): finally ACPI works correctly.
[08:55] <bob2> how about swsusp?
[08:56] <crimsun> bob2: me? haven't tested.
[08:56] <fabbione> crimsun: cool
[08:56] <crimsun> (ACPI has never worked across 2.4 or 2.6 til now)
[08:57] <Treenaks> fabbione: uh.. don't know.. I'm reading the -bk6 changelog
[08:58] <Treenaks> fabbione: how do I find out?
[09:00] <fabbione> some website.. i think it's bitkeeper.com or something like that
[09:00] <bob2> linux.bkbits.net
[09:02] <Treenaks> fabbione: http://linux.bkbits.net:8080/linux-2.6/cset@1.2131?nav=index.html|ChangeSet@-2d
[09:02] <Treenaks> fabbione: even better, a diff: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41d84f49Gbzesf6EsPI73plRgr2MbQ
[09:03] <fabbione> yeah thanks
[09:03] <Treenaks> speaking of nasty one-liners: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41d832117seXnnx2qbN-FpUvnmLRuQ
[09:04] <fabbione> what's that about?
[09:04] <Treenaks> ipt_ECN checksum corruption
[09:05] <fabbione> yeah
[09:12] <pitti> sjoerd: hey, new hal upstream release
[09:12] <pitti> sjoerd: time for tarball.mk? :-)
[09:29] <pitti> lamont: here?
[09:29] <cartman> btw "UPLOADPENDING" status means that a new package will come to Hoary soon?
[09:29] <fabbione> pitti: he went to sleep a while ago
[09:29] <pitti> oh, ok
[09:29] <cartman> new version of a package that is
[09:30] <fabbione> cartman: yes. that fix that bug
[09:30] <fabbione> pendingupload btw ;)
[09:30] <cartman> fabbione: cool thanks
[09:30] <cartman> then daniels accepted my patch
[09:30] <fabbione> could be
[09:49] <froud> Hello, I am working in doc team. I would like to know if the "sounder" be using in the future or can we depreciate citation to it in the docs?
[09:50] <froud> 'sounder' will be used ..
[09:50] <Treenaks> 'array' for hoary, afaiki
[09:53] <froud> Treenaks, thanks. Can anyone confirm that the "sounder" will be used for  Ubuntu 5.04 (The Hoary Hedgehog): April 2005
[09:54] <fabbione> froud: "Array"
[09:54] <froud> sorry what does array mean?
[09:55] <crimsun> correct me if I'm wrong, but it's a codename
[09:55] <froud> ok so this is a name instead of sounder :-)
[09:55] <froud> cool
[09:55] <froud> thanks
[09:55] <Treenaks> no, a group of warthogs is  "a sounder of warthogs". a group of hedgehogs is an "array" of hedgehogs
[09:56] <crimsun> ah, there you go
[09:56] <Treenaks> afaaik
[09:56] <froud> Hmmm, very cute :-)
[09:56] <lifeless> Treenaks: spot on
[09:57] <froud> Hoi, lifeless said something. lifeless never does that on #ubuntu-docs
[09:57] <bob2> this is #ubuntu-devel 
[09:57] <froud> yes, but lifeless also tunes to  #ubuntu-docs. Ok going back to work, thanks
[10:34] <seb128> morning
[10:34] <mvo> hi seb128 
[10:35] <Treenaks> morning
[10:35] <pitti> Morning seb128, mvo
[10:35] <fabbione> hey seb128 
[10:35] <fabbione> seb128: totem is FTBFS
[10:36] <seb128> ok
[10:36] <seb128> let me catch up with the ton of mail of the night first :p
[10:37] <seb128> but thanks for noticing :)
[10:37] <mvo> morning pitti 
[10:37] <fabbione> now.. changeset will not be scary anymore ;)
[10:39] <seb128> grumpf, why does it try to link with libhal
[10:39] <seb128> oh, libnautilus-burn.la
[10:40] <Treenaks> totem can burn now?
[10:45] <seb128> no
[10:46] <seb128> this lib has also a part for the CD/DVD drives detection
[10:46] <seb128> and totem read CDs and DVDs
[10:46] <Treenaks> ah
[11:27] <davyd_> yay! 1kg of Ubuntu kds
[11:27] <davyd_> cds
[11:27] <Treenaks> davyd_: how many? ;)
[11:27] <davyd_> 19 or so
[11:27] <davyd_> I ordered enough for to give everyone at work one
[11:28] <davyd_> and some others who wanted them
[11:28] <davyd_> and have some spare to for when I do some presentations on GNOME 2.9 tech later on
[11:29] <ogra> mvo ?
[11:29] <mvo> ogra: ?
[11:29] <Treenaks> ogra? mvo?
[11:29] <ogra> how did your isdn tests go ?
[11:29] <ogra> *g* Treenaks
[11:29] <mvo> you notic that I login and out :)
[11:30] <mvo> well, not too bad. gnome-system-tools has basic isdn support (for capi cards) now (yeah!) but it's still a bit buggy 
[11:30] <ogra> ah, ok....i just dug up all my isdn fritz cards....so i'll have pci,pci2.0 and a ISA one at home tonight....
[11:30] <mvo> 2.6.10 still oops with mISDN
[11:30] <mvo> ogra: cool!
[11:30] <ogra> thats what i menat
[11:31] <mvo> I would love to hear if 2.6.10 breaks for you as well
[11:31] <ogra> so lets nail this down tonight....(got no isdn at work unfortunately
[11:31] <mvo> a ISA one? *urggghh*
[11:31] <ogra> hehe....from ancient times :)
[11:32] <ogra> but it should get tested too...i just have to find a board with ISA....thats a bit tricky
[11:32] <Treenaks> I have an ISA USR ISDN TA
[11:32] <mvo> ogra: tonight sounds cool, also we have a meeting and I will play some hockey in between. if I can't make it we will have to check it tomorrow (hope that's ok)
[11:32] <ogra> yep, sure
[11:33] <ogra> hehe
[11:33] <fabbione> mvo: can you send the info i asked you yesterday please?
[11:33] <mvo> dosn't microsoft call there web-proxy something with ISA?
[11:33] <fabbione> there are no updates on the mISDN cvs..
[11:33] <mvo> fabbione: yes
[11:34] <ogra> heh, do they ? (M$ ?)
[11:34] <Kamion> sheesh, I am so behind it's unbelievable
[11:34] <davyd_> mvo: Internet Security Architecture
[11:34] <ogra> haha
[11:34] <Treenaks> davyd_: the irony 8)
[11:34] <davyd_> actually, I seem to recall the world Accelleration is in their too
[11:35] <davyd_> *there
[11:35] <davyd_> perhaps its Internet Security and Accelleration Server
[11:35] <davyd_> I think that's correct
[11:35] <davyd_> it's an absolute whore
[11:36] <Treenaks> uh.. why is gluck.debian.org doing a HEAD / on my server?
[11:37] <robtaylor> mdz: amu: seen this? http://www.atconsultancy.nl/cowloop/ ?
[11:37] <Kamion> Treenaks: planet?
[11:37] <Treenaks> Kamion: I don't blog, so I'm not on planet
[11:42] <jdub> robtaylor: using dm seems like the saner solution
[11:42] <abelli> jdub: hi there
[11:43] <jdub> morning
[11:43] <jdub> :-)
[11:44] <thom> night jdub
[11:46] <fabbione> hey thom
[11:46] <thom> hey hey
[11:46] <davyd_> jdub: are you really going to sleep at 10pm?
[11:46] <Treenaks> gluck is  doing a HEAD / on "www.foodfight.org" every day around 10:35-10:40 UTC ... hmmm...
[11:47] <fabbione> mumble
[11:47] <fabbione> sort problem..
[11:47] <fabbione> http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.10-bk6.log
[11:47] <Treenaks> starting from 20-dec-04
[11:48] <fabbione> all Changeset in that file can be extracted with something like:
[11:48] <fabbione> cat patch-2.6.10-bk6.log |grep ^Change | cut -d "," -f 1 | cut -d "@" -f 2
[11:48] <fabbione> now..
[11:48] <fabbione> how do i sort the result?
[11:48] <fabbione> LC_ALL=C sort -rn -t\. -k1rn -k2nr -k3gr -k4nr
[11:48] <fabbione> sorts correctly the first 3 keys
[11:48] <fabbione> but not the 4th one...
[11:49] <fabbione> 1.2034.116.20
[11:49] <fabbione> 1.2034.116.2
[11:49] <fabbione> 1.2034.116.19
[11:49] <fabbione> and this is plain wrong...
[11:49] <fabbione> it should be like .20 .19 .2
[11:49] <fabbione> according to the numeric value...
[11:53] <fabbione> actually.. that's just plain wrong...
[11:53] <fabbione> also key3 is not sorted properly.... HMMMM
[11:53] <Treenaks> (ah, found the gluck thing:  http://people.debian.org/~djpig/urlcheck/devel.en)
[11:59] <crimsun> fabbione: ever looked at http://www.dt.e-technik.uni-dortmund.de/~ma/linux/kernel/lk-changelog.html ? That's what Linus & Marcelo use.
[12:01] <fabbione> crimsun: that's not what i need
[12:01] <fabbione> that script creates a changelog
[12:01] <crimsun> fabbione: just wondering you can pull the sorting logic from it
[12:01] <crimsun> wondering if^
[12:04] <seb128> daniels: "all bugs are gtk bugs", that's it ? :p (before reassigning a bug on gtk you could ask in which app that happens, perhaps that happens in a xterm too)
[12:05] <Treenaks> seb128: is this about the compose/i/j bug (Dutch "y") ? :)
[12:05] <seb128> yes
[12:05] <Treenaks> that should be fixed in the X compose map, and shouldn't GTK use that?
[12:06] <seb128> dunno but daniels has reassigned it too gtk
[12:06] <seb128> s/too/to/
[12:06] <Treenaks> hm.. I see
[12:06] <seb128> does it happen in a xterm ?
[12:06] <seb128> or the compose work in a xterm ?
[12:07] <seb128> BTW in gtk widgets you can change the compose method in the right click menu
[12:07] <seb128> Cedilla is the default here
[12:07] <seb128> perhaps you need to use the X one
[12:07] <seb128> or the Default
[12:08] <Treenaks> it doesn't work anywhere yet (except for the ctrl+shift+133 trick in GTK apps)
[12:08] <Treenaks> seb128: if I use the "X input method" I can use compose fine, it's just that that combination is not in the Xorg compose map yet
[12:08] <seb128> ok, so I reassign on Xorg instead of gtk
[12:08] <seb128> thanks
[12:09] <fabbione> ahhh even easier
[12:09] <fabbione> bk doesn't need 2 revisions to make a diff
[12:09] <fabbione> if only one is specified it assumes you want the diff with the previous one...
[12:11] <Treenaks> seb128: you could paste this IRC conversation as a comment on the bug..
[12:12] <seb128> Treenaks: already done
[12:12] <seb128> but thanks :p
[12:13] <mvo> ping amu
[12:14] <robtaylor> jdub: agreed.. just pointing it out ;)
[12:15] <thom> AAAARGH
[12:15] <thom> how can it be this hard to get a phone line reconnected
[12:16] <fabbione> thom: ahah poor you!
[12:16] <robtaylor> thom: in argentina it ttook 2 months =)
[12:16] <Treenaks> thom: they're hardware engineers..
[12:16] <fabbione> thom: wanna come here in dk for sometime?
[12:18] <thom> robtaylor: it's getting that way with BT
[12:18] <robtaylor> thom: ee
[12:18] <robtaylor> k
[12:18] <thom> robtaylor: requested Dec 1
[12:19] <robtaylor> thom: i assume the physical line is already there? ;)
[12:19] <thom> yup
[12:20] <robtaylor> heh. my (rather new) flat doesn't even have that. i've decided that it just isn't worth having a landline =)
[12:20] <thom> previous tenants had it disconnected when they moved out, just want it turned back on *sigh*
[12:20] <thom> robtaylor: dsl is rather critical when working from home ;-)
[12:21] <robtaylor> thom: ah, yeah i forget most people have to use copper ;)
[12:22] <thom> yeah, the free wifi stuffs in london don't make it out to us, sadly
[12:23] <Treenaks> thom: ... yet?
[12:23] <robtaylor> thom: naa, i'm in cambridge - i've got a connetion to Cambridge Broadband's Cotares network..
[12:23] <thom> Treenaks: dunno if ever
[12:23] <thom> ahh
[12:25] <seb128> elmo: pike7.2 sync please
[12:26] <robtaylor> thom: do BT actually have an excuse?
[12:26] <seb128> fabbione: #5188 ?? I've a network connection and it does FTBFS ... any detail ?
[12:26] <thom> robtaylor: they're BT... think they need one? :-(
[12:27] <thom> oooh, a human!
[12:32] <pitti> elmo: please sync nasm, tiff, tetex-bin
[12:34] <fabbione> seb128: it simply should never depends on a network... 
[12:34] <fabbione> seb128: if you remove the net it will build
[12:34] <seb128> it build with the net here !
[12:34] <fabbione> so the resulting package can be mangled either by fetching from the net or reverting to the local default
[12:35] <seb128> hum, ok, let me look on the package
[12:35] <seb128> do you know what it gets by the net ? a dtd ?
[12:35] <fabbione> sec...
[12:36] <seb128> you could have past a build log or something like that in the BR :p
[12:36] <robtaylor> seb128: ugh, thats pretty damm ugly =)
[12:36] <fabbione> seb128: i have the entire log.. you know that...
[12:37] <seb128> yeah, and I've a bug without any details, you know that ? :)
[12:38] <fabbione> seb128: we all know you have mental power
[12:39] <seb128> shuuush, that's a secret :p
[12:42] <ogra> fabbione: probably its also multiple personalitys....nobody can work _this_ fast
[12:46] <fabbione> ogra: i think he is like the "One million dollar man" with cybernetic fingers to type faster
[12:46] <thom> it doesn't take much typing to reassign all your bugs to Xorg ;P
[12:46] <ogra> yep, thats what i always think....its simply impossible for one person to match this many tasks....
[12:47] <fabbione> thom: ahha
[12:50] <fabbione> hey trukulo 
[12:50] <trukulo> hi fabbione 
[12:51] <trukulo> i'm learning to make good debs :P
[12:51] <trukulo> fabbione: bon appetite
[12:52] <fabbione> trukulo: that's good :-)
[12:52] <fabbione> thanks ;)
[12:52] <trukulo> but i'm getting crazy with manpages :P
[12:53] <ogra> trukulo use pbuilder and lintian.....helped me a lot to get my packages clean
[12:54] <trukulo> i use lintian (not pbuilder, yet)
[12:54] <trukulo> problem is i've included manpages
[12:54] <Kamion> jdub: *any* help with fb console problems is appreciated; at the moment I'm assuming kernel bugs
[12:55] <trukulo> but don't know why they aren't included
[12:55] <ogra> trukulo where do you put them ?
[12:55] <trukulo> i'm making graveman package, a frontend in gtk2 for cdrecord
[12:55] <trukulo> ogra: EVERYWHERE !!! i'm getting crazy
[12:55] <ogra> trukulo: hmm, you should read the mailing list....
[12:55] <trukulo> i put them on debian directory
[12:55] <trukulo> i use to read it
[12:55] <ogra> trukulo: i already did graveman last week
[12:56] <trukulo> i'm making this for sarge :)
[12:56] <ogra> ah, ok...
[12:56] <crimsun> in debian/$package/man/* ? are you calling dh_installman?
[12:56] <trukulo> just commenting fabbio
[12:56] <trukulo> ah, one thing
[12:56] <crimsun> err
[12:56] <crimsun> debian/$package/usr/man/*
[12:56] <trukulo> graveman doesn't work well in warty with your package
[12:56] <Kamion> usr/share/man please, never usr/man
[12:56] <ogra> trukulo: you should put it in the debian subdir....
[12:57] <trukulo> i'm calling it
[12:57] <trukulo> i did
[12:57] <crimsun> Kamion: err, yes.
[12:57] <crimsun> Kamion: dunno why I left out share
[12:57] <trukulo> i've read mantainer guide, lintian explanations, docs...
[12:57] <Kamion> if you're using debhelper, set DH_VERBOSE=1 to see what it's doing
[12:57] <ogra> trukulo: it does work fine for me....as long as nobody sends bugs to me, i must assume its working for others too
[12:57] <jdub> Kamion: it sat for a moment 'waiting for /dev/fb/0'
[12:57] <trukulo> ogra: do you use scsi emulation?
[12:57] <ogra> trukulo: nope
[12:58] <ogra> trukulo: thats deprecated in 2.6
[12:58] <trukulo> problem is in my computer, graveman (of your package) doesn't recognize cdrecorder
[12:58] <Kamion> jdub: yeah, same bug as I see in places
[12:59] <Kamion> jdub: check whether /proc/fb has any content once the UI starts up
[12:59] <ogra> trukulo: i wrote a lengthy mail about that particular prob....i'm also in contact with the graveman author about that....
[12:59] <trukulo> me too, my package for sarge is in his page
[12:59] <trukulo> i didn't read that email, i'll look on mailing archives
[01:00] <ogra> trukulo: change the dev= line in your ~/.graveman/graveman.conf to the actual device name
[01:00] <Treenaks> c
[01:00] <Treenaks> argh
[01:00] <ogra> trukulo: like: dev=/dev/hdc (if your writer is hdc)
[01:00] <trukulo> oh, ok ogra
[01:01] <trukulo> it's not elegant, but i supose as it's a frontend of cdrecord, it's the only way
[01:01] <jdub> Kamion: at the risk of bringing up an old discussion, how about 'base' instead of 'server'? :)
[01:01] <ogra> trukulo: i would _love_ to patch the nautilus-cd-burner detection stuff in there....it uses hal and seems to work perfectly 
[01:01] <trukulo> yeah, using libburn isn't it?
[01:01] <jdub> Kamion: nothing in /proc/fb when the choose language screen is up
[01:02] <ogra> trukulo: nope.....just cdrecord...but it detects with hal
[01:02] <Kamion> jdub: talk to Mark, the name is his choice, I was overruled.
[01:02] <jdub> Kamion: what was your suggestion?
[01:02] <ogra> trukulo: i tried something similat with mrburns.....works quite well there
[01:02] <Kamion> I'm pretty fed up of having installer stuff dictated to me :-/
[01:02] <ogra> similar
[01:02] <jdub> (server at least implies ubuntu can do server)
[01:02] <Kamion> jdub: custom was my name
[01:02] <jdub> yeah
[01:03] <Kamion> jdub: /proc/fb> kernel bug then
[01:03] <Kamion> (probably ... vesafb sucks)
[01:03] <trukulo> ogra: that woudl be great
[01:03] <jdub> fbcon is loaded
[01:03] <Kamion> jdub: I bet there's an error message in syslog about vesafb
[01:03] <jdub> as is vesafb
[01:03] <Kamion> vesafb appears not to necessarily fail to load when it should
[01:05] <trukulo> ogra: and it would be very well to include graveman.desktop and graveman.png too
[01:05] <ogra> trukulo: is already in my package ;)
[01:05] <jdub> found:
[01:05] <jdub> vesafb: probe of vesafb0 failed with error -6
[01:05] <trukulo> ogra: superb
[01:06] <ogra> trukulo: and a postinstall that makes it the default burning app in g-v-m
[01:06] <jdub> ogra: that sounds ugly
[01:06] <ogra> trukulo: ....and changes it back with prerm to nautilus if you uninstall.....
[01:07] <ogra> jdub: it was the quick hack for impatient ppl, before i had the time to make a .desktop file....i'll consider removing it again
[01:07] <jdub> ogra: packages shouldn't really futz with other packages stuff :-)
[01:08] <trukulo> ogra: what i sugest to sylvain, is to add a "directory add" button
[01:08] <trukulo> i know it's in the menu
[01:08] <ogra> jdub:  i'll keep it in mind...even gconf is so tempting to do such things...they are so easy
[01:09] <jdub> ;)
[01:09] <Kamion> jdub: I get the same
[01:13] <ogra> trukulo: if you would like to take over the package, just garb it from my src repo...deb-src http://www.grawert.net/ubuntu/ warty universe
[01:13] <ogra> grab even
[01:14] <fabbione> vesafb problem????
[01:14] <trukulo> thanks ogra, but i'm doing this essencially for learning
[01:14] <fabbione> it must be a GTK bug
[01:14] <trukulo> :) so i want ALL the problems and no easy solutions
[01:15] <ogra> trukulo: heh, me too....but the packaging graveman probs are solved for me.....now the patching graveman probs start ;)
[01:18] <robtaylor> carlos: pingetty-pong?
[01:18] <carlos> robtaylor: hey, ;-)
[01:19] <carlos> robtaylor: I was trying to ask you where the hell your arch archive was hosted but I found it yesterday (finally)
[01:19] <robtaylor> carlos: hey :) strange that there's no listing, sure i made it with -l. oh well, i'll fix this as soon as i get home :)
[01:19] <carlos> happy new year :-D
[01:19] <robtaylor> carlos: heh, strange you couldnt find it in irc logs =)
[01:19] <carlos> robtaylor: yeah
[01:20] <carlos> robtaylor: you should add it to the supermirror list
[01:20] <robtaylor> carlos: yeah will do. The only reason i havn't is I thought jblack was working on automagic supermirroring..
[01:21] <robtaylor> (for sourcecontrol.net)
[01:22] <trukulo> ogra: yes, but i'm not a programmer :)
[01:24] <robtaylor> carlos: so what are you thinking of using it for at uni?
[01:31] <trukulo> ogra: i think we need three things for graveman
[01:31] <trukulo> 1) format cdrw option
[01:31] <trukulo> 2) "add directory" button on gui
[01:31] <carlos> robtaylor: I need to do a development to finish my studies and the project I planned to do has disappear so I'm thinking on accessd 
[01:31] <trukulo> 3) hal drive recognising
[01:32] <trukulo> carlos: accessd ?
[01:32] <carlos> trukulo: a project rob & I are developing
[01:33] <trukulo> carlos: what is about?
[01:33] <carlos> authentication and priviledge elevation
[01:34] <trukulo> like sudo?
[01:34] <trulux> hey pitti
[01:34] <trukulo> (remember i'm a little membrillo)
[01:34] <pitti> Hi trulux 
[01:34] <pitti> trukulo: -hardened kernel works fine on ppc!
[01:35] <trukulo> pitti: you mean trulux?
[01:35] <pitti> trukulo: yes, sorry
[01:35] <carlos> trukulo: something like that, but without setuid bit
[01:35] <trukulo> carlos: umm, cool
[01:35] <pitti> seb128: can you please tell me again to teach xchat a sane autocompletion?
[01:36] <pitti> seb128: s/to/how to/
[01:36] <carlos> pitti: I'm not sure if I will be able to attend todays meeting :-(
[01:36] <seb128> set completion_amount 0
[01:36] <pitti> seb128: ah, thanks
[01:36] <carlos> pitti: how long will be it?
[01:36] <pitti> carlos: neither meeting?
[01:36] <pitti> carlos: we have both the regular TB and the hoary goals meeting
[01:36] <carlos> pitti: tonight one
[01:37] <pitti> carlos: okay, maybe we can discuss it right now
[01:37] <pitti> carlos: I actually wanted to know about the status of automatic translation deb generation
[01:37] <pitti> carlos: is this possible right now?
[01:37] <trulux> pitti, great
[01:38] <trulux> there are no major arch issues
[01:38] <carlos> pitti: Rosetta is not going to do automatic debs
[01:38] <trulux> in fact
[01:38] <trulux> ;)
[01:38] <carlos> pitti: what's your ide?
[01:38] <carlos>  /s/ide/idea/
[01:38] <pitti> trulux: framebuffer is still broken on i386, but works fine on ppc
[01:39] <pitti> carlos: we need a server that daily pulls new pos from rosetta, builds an update deb (if anything changed) and puts it into the archive
[01:39] <carlos> pitti: we could prepare an URL with a package of .po files
[01:39] <carlos> for every hoary package
[01:40] <carlos> so you could do it automatically
[01:40] <carlos> is that enough?
[01:40] <pitti> carlos: I think the rosetta server should already decide which files were touched since the last pull
[01:40] <pitti> carlos: otherwise you will have a lot of redundant traffic
[01:40] <pitti> carlos: is that possible?
[01:40] <carlos> yes, we know that
[01:41] <carlos> well, we know last time it was touched
[01:41] <carlos> we need then a way to say "it was merged into main stream on ...."
[01:41] <pitti> carlos: the interface could be an URL where you can download all po that were touched on a given day
[01:42] <pitti> carlos: http://rosetta/updates/20050110/ or so
[01:42] <carlos> so you will get all translations  updated since 20050110 ?
[01:42] <carlos> ok, it sounds better
[01:42] <pitti> no, all translations updated _at_ 20040110
[01:43] <carlos> hmmm
[01:43] <pitti> I don't want older ones
[01:43] <pitti> oh yes
[01:43] <pitti> newer ones are okay, too :-)
[01:43] <elmo> pitti/seb128: done
[01:43] <pitti> elmo: thanks
[01:43] <seb128> thanks
[01:43] <pitti> elmo: I sent you an email about this a while ago, you can disregard that now
[01:43] <carlos> pitti: it's easier for me that way, so I don't need to store the exported time
[01:43] <pitti> carlos: right
[01:44] <carlos> I think it's doable
[01:44] <pitti> carlos: so, this URL delivers all PO files whose modified time stamp is younger/equal than the URL given one
[01:44] <carlos> but it should be done for product
[01:44] <carlos> the export process is not fast
[01:44] <carlos> and you could get a timeout
[01:44] <pitti> carlos: you mean per-package?
[01:44] <carlos> yes
[01:45] <pitti> carlos: this would mean a lot of additional GET requests
[01:45] <carlos> yes
[01:45] <pitti> but I think it should work
[01:45] <pitti> carlos: another idea
[01:45] <carlos> I need to do some checks, I think stub told me that we could start serving a zip stream while we export new data at the same time
[01:45] <pitti> carlos: http://rosetta/cgi-bin/get-updates?date=20050110
[01:46] <carlos> if that works, I could give you only one file with all po files
[01:46] <pitti> ^ this will deliver the list PO file URLs
[01:46] <pitti> okay, ZIP stream sounds cool, too
[01:46] <pitti> if that is not possible, then I think the CGI script that gives me the URL list of new PO files is fine, too
[01:47] <carlos> pitti: yes, it's another option
[01:47] <carlos> pitti: we need also to agree on the directory structure you want/need
[01:47] <pitti> carlos: well, I don't really care
[01:47] <pitti> carlos: it should avoid too many small GET requests
[01:48] <pitti> carlos: it should only transmit changed po files
[01:48] <carlos> if I give you a zip with all po files
[01:48] <pitti> carlos: and I must be able to tell which package a po file belongs to
[01:48] <carlos> you need to know if a es.po is from synaptic or nautilus...
[01:48] <pitti> ^ that's point 3 :-)
[01:48] <carlos> ok
[01:48] <pitti> the zip file could contain the po files in per-package directories
[01:49] <pitti> as long as above three conditions are met, I don't think that the concrete structure/transport format matters too much
[01:49] <pitti> so I would set up a nightly cron job which pulls the pos and assembles update debs
[01:49] <carlos> pitti: the "problem" is that usually a product in rosetta does not maps directly to a Debian/Ubuntu package
[01:50] <pitti> carlos: ugh, why not?
[01:50] <fabbione> hey elmo
[01:50] <azeem> happy new year, ubuntu dudes
[01:50] <pitti> azeem: happy new year to you!
[01:51] <pitti> carlos: my Cannelonis are ready, see you in half an hour :-)
[01:51] <carlos> pitti: ok, see you later
[01:51] <trukulo> bon apetite pitti 
[01:57] <sjoerd> pitti: oh, great timing from davidz then :) (hal upstream release)
[02:04] <fabbione> cya later for the meeting
[02:08] <elmo> hey fabbione 
[02:08] <lamont> jdub: I expect so
[02:09] <lamont> pitti: yes?
[02:15] <pitti> lamont: Morning
[02:15] <pitti> lamont: postgresql FTBFS, probably because build-dep mmv is missing
[02:16] <lamont> gah.  nuke mmv usage from the source
[02:16] <pitti> lamont: mmv is universe currently, but shouldn't it be germinate'd to main automatically?
[02:16] <lamont> it's a _USELESS_ waste of packaging
[02:16] <Kamion> mmv's nice
[02:16] <Kamion> for users, at least
[02:16] <pitti> I agree, mmv is very nice
[02:16] <lamont> I'll grant for users.
[02:16] <azeem> it's quite un-unixy though
[02:16] <Kamion> not seeded though
[02:16] <lamont> but in debian/rules?  come on.
[02:17] <pitti> Kamion: I thought it should get in via germinate?
[02:17] <pitti> lamont: it's not in debian/rules
[02:17] <pitti> lamont: its used in an obscure upstream source patch
[02:17] <pitti> lamont: of course I can modify it not to use mmv
[02:18] <pitti> lamont: it is used to properly rename the sections of manpages
[02:18] <lamont> promotion from universe to main has a manual step, and I would hope that elmo would scream before promoting mmv.
[02:18] <pitti> lamont: not a big deal, but I decided to eventually get it right
[02:19] <pitti> lamont: well, I remove it again for now
[02:19] <lamont> not because it's insecure, but because it's silly. :-)
[02:19] <pitti> lamont: why do you think it's silly?
[02:19] <pitti> lamont: having the functionality just with mv, sed, for, and tr is ugly
[02:20] <lamont> ISTR it was ftbfs on one architecture back when, and it struck me as a very non-sensible API
[02:21] <lamont> bind9? was using it at the time, in a way that was trivial to recode without it
[02:21] <lamont> I freely admit that there could be use cases where it makes more sense
[02:21] <Kamion> pitti: yeah, what lamont said, germinate will *say* it's in main but that doesn't immediately make it so
[02:22] <pitti> Kamion: well, okay, I change the patch to do without mv
[02:22] <pitti> mmv, that is
[02:22] <pitti> Kamion: btw, it used mmv for ages, but the build-dep was missing
[02:22] <lamont> heh
[02:23] <fabbione> lamont. later :-)
[02:25] <lamont> Kamion: email sent
[02:25] <lamont> fabbione: I'll build that chroot once I'm back on.
[02:27] <jdub> ahr, d'oh
[02:27] <jdub> can't stay awake
[02:42] <mjg59> fabbione: You were looking for me last night?
[03:31] <stockholm> Kamion: did we talk about config file rewriting (especially concerning slapd.conf) for transparent upgrading of backends?
[03:31] <stockholm> Keybuk insists it was you  and not him
[03:33] <Kamion> backends?
[03:33] <Kamion> it may not have been him but I don't remember it being me either
[03:33] <stockholm> ok
[03:33] <stockholm> to bad.
[03:43] <daniels> seb128: there are two bugs
[03:43] <daniels> seb128: one is on X, the other GTK.
[03:43] <seb128> daniels: there is not even a gtk app mentionned in this bug
[03:43] <daniels> seb128: i added ij (U0133) and IJ (U0132) to the X compse map, but that doesn't matter
[03:44] <Keybuk> GTK+'s compose map needs an overhaul
[03:44] <daniels> so now if I right-click in gedit, hit Input Methods, and select X Input Method, I can compose ij and IJ with multi-key
[03:44] <daniels> seb128: but, stupidly, GTK's default mapping is *not* this, and has its own compose handling
[03:44] <seb128> ok, so that's good
[03:44] <Treenaks> you mean  and  ;)
[03:44] <daniels> seb128: the table is in gtk/gtkimcontextsimple.c
[03:44] <daniels> Treenaks: (yeah, can't be arsed restarting gnome-terminal, and my utf8-fu is broken for irc anyway)
[03:45] <daniels> seb128: so { GDK_Multi_key, GDK_i, GDK_j, 0, 0, 0x0133 }, needs to be added to the table, presumably
[03:45] <seb128> ok
[03:45] <daniels> but that didn't work when I was trying something else, so I dunno if it will be any good
[03:45] <daniels> so I've fixed my bug, now you get your half :)
[03:45] <seb128> you could provide some details in the bugs
[03:45] <Keybuk> there's a huge patch for gtk/gtkimcontextsimple.c in Bugzilla that adds a few hundred new mappings
[03:46] <Keybuk> (GNOME Bugzilla, that is)
[03:46] <seb128> ie: giving the xorg fix so I can apply it to test gtk :p
[03:46] <Treenaks> Keybuk: what's wrong with using the X mapping by default?
[03:46] <Keybuk> Treenaks: I've no idea why GTK+ has it's own default input method
[03:46] <Keybuk> http://bugzilla.gnome.org/show_bug.cgi?id=155010
[03:46] <Keybuk> ^ that's quite sexy too
[03:47] <seb128> yep, I was just reading this one
[03:47] <seb128> who is taking care of this part of gtk ? owen ?
[03:47] <daniels> i wasn't just blindly reassigning to gtk to annoy you, y'know :)
[03:48] <seb128> yeah, but you could have added some details :)
[03:48] <Keybuk> yeah, Owen seemed to think this all belongs in some super-shared-common-IM-method
[03:49] <seb128> http://bugzilla.gnome.org/show_bug.cgi?id=88639
[03:55] <elmo> straw poll: what do folks do for laptops and their mail domain?  I set mine to a random mail domain I own/control, but what does anyone do who doesn't do that?
[03:56] <Kamion> I use the house domain
[03:56] <lamont_r> elmo: ditto
[03:56] <Kamion> er, not literally "house"
[03:56] <lamont_r> Kamion: not familiar with .house... :-)
[03:56] <Treenaks> .local?
[03:56] <Kamion> .lab.dotat.at actually
[03:57] <elmo> I wonder what folks who don't have a handy mail domain are meant to do tho?
[03:57] <elmo> (other than: get one)
[03:57] <Keybuk> elmo: I use the name of the laptop when it's at home
[03:57] <azeem> I am using SMTP-auth to get my mail delivered by my MSP, if you mean that
[03:58] <Treenaks> I set my laptop postfix to use my own server as a smarthost (using SASL and TLS).. and it adds "@foodfight.org" to unqualified addresses
[03:58] <lamont_r> interesting... my house appears to have dropped off the net.
[03:58] <Treenaks> lamont_r: again?
[03:58] <Treenaks> lamont_r: (press F10?)
[03:58] <lamont_r> Treenaks: well, it is cold and snowing today
[03:59] <Treenaks> and USA ;)
[03:59] <lamont_r> nah - not the F1 borkage.  the '18 miles of 802.11 is sometimes flaky' borkage
[03:59] <Treenaks> ah
[03:59] <sivang> anybody seens silbs here?
[04:01] <lamont_r> last night, I noticed that rsync does integer math for % as well...
[04:02] <Treenaks> that's bad?
[04:02] <lamont_r> that is, it doesn't say 1% until > 1%, rather than for anything from .5-1.5
[04:02] <lamont_r> not necessarily
[04:05] <lamont_r> Treenaks: the f1-b0rkage only affects email.  the wifi-and-weather b0rkage is more complete.
[04:06] <Treenaks> lamont_r: so it seems (No route to host)
[04:06] <lamont_r> yeah
[04:06] <lamont_r> it's really foggy and cold out there - that'll mess with things
[04:06] <Treenaks> so now  the real lamont is gone we can gossip about him!
[04:06] <daniels> elmo: could you please sync docbook-xml?
[04:06] <lamont_r> heh
[04:08] <elmo> done
[04:08] <daniels> elmo: cheers
[04:08] <elmo> how evil would it be to use foo.local for mail fqdn's for a laptop?
[04:08] <daniels> elmo: also, could I please get linux-headers-2.6.10-* on davis, halley, and concordia?
[04:09] <elmo> gar, I need history exclusion so that commands with the words 'halt' or 'reboot' don't get stored in there
[04:09] <daniels> elmo: as well as libxxf86misc-dev, libxtst-dev, libxxf86vm-dev, libxinerama-dev and libqt3-mt-dev on concordia
[04:14] <robtaylor> hey, out of interest, when do the selection of core packages for hoary freeze?
[04:15] <ogra> http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
[04:15] <Kamion> technically it froze some time ago
[04:15] <ogra>  November 29th, SeedFreeze ?
[04:16] <Kamion> that'd be the one
[04:17] <fabbione> mjg59: yes... 
[04:17] <sivang> and UVF is 12th Jan right?
[04:17] <fabbione> mjg59: LKML: [PATCH]  swsusp: properly suspend and resume *all* devices <- do we need that?
[04:18] <elmo> daniels: done
[04:18] <fabbione> elmo: *cough*sparc*cough* :P
[04:19] <robtaylor> Kamion: i noticed that, hence why i ask :)
[04:19] <daniels> elmo: cheers dude
[04:19] <elmo> fabbione: right
[04:22] <fabbione> whooooo! this 8 lines bash script to parse bk output is so raaad!
[04:22] <fabbione> i can get to see upstream changes almost as fast as they commit
[04:22] <lamont_r> fabbione: ENOTPYTHON?
[04:22] <lamont_r> bitkeeper
[04:22] <sivang> lamont_r: tnx
[04:23] <fabbione> lamont_r: not for cd linux-2.6; bk pull and a couple of grep
[04:23] <lamont_r> fabbione: anything besides kernel-wedge and build-essential for that chroot?
[04:23] <lamont_r> and l-s b-d's of course
[04:23] <fabbione> as output i get each single changeset in a separate diff -ru file
[04:23] <fabbione> lamont_r: no. only kernel-wedge from ubuntu
[04:23] <fabbione> all the others do not matter
[04:24] <lamont_r> you're going to want to dpkg-buildpackage, no?
[04:24] <fabbione> hmmm yes
[04:24] <lamont_r> ok
[04:24] <pitti> mvo: ping
[04:24] <fabbione> they have included UML support in 2.6.11
[04:25] <pitti> fabbione: hey, finally?
[04:25] <pitti> fabbione: it took me a while to get UML running for 2.6.7 back then
[04:26] <lamont_r> fabbione: any xen patches?
[04:26] <daniels> christ svn is slow
[04:26] <daniels> it's almost making arch look good :P
[04:26] <mvo> pitti: pong
[04:27] <fabbione> pitti: it looks like a tons of patches went in in bk7
[04:28] <fabbione> lamont_r: checking...
[04:28] <fabbione> apparently no
[04:28] <elmo> I don't think of all xen is getting merged any time soon, there's been lots of discussion over it
[04:29] <lamont_r> elmo: yeah, figured that part.
[04:29] <Kamion> daniels: highly server-dependent - you using bdb or fsfs?
[04:29] <lamont_r> it's almost as bad for part of it to get merged, depending on the speed of both sides, and how ugly the split between accepted and not is...
[04:31] <fabbione> elmo: btw did you get the mail from doko for the gcc ppc64?
[04:31] <fabbione> i am holding a bunch of patches for ppc64 kernel
[04:31] <elmo> fabbione: no?
[04:32] <fabbione> elmo: Subject: powerpc chroot
[04:32] <elmo> fabbione: sent when/where to?
[04:33] <azeem> "But the only free GNU/Linux distro I know of is UTUTO" -- Richard Stallman
[04:37] <fabbione> elmo: you and me
[04:37] <fabbione> elmo: elmo@c.c
[04:37] <daniels> Kamion: dunno, whatever Overfiend uses
[04:38] <fabbione> daniels: hmm i don't have problem with svn on necrotic....
[04:39] <lamont_r> azeem: I don't think he's referring to us - we include non-free stuff, you see.
[04:39] <azeem> lamont_r: he doesn't know I guess - jdub once told him you were not
[04:39] <lamont_r> azeem: it's not in main, but it's available
[04:39] <daniels> fabbione: getting diffs is arse-slow
[04:40] <azeem> yeah, I know. But RMS is incredibly slow on news in the Free Software world
[04:40] <daniels> i'll tell you exactly how long it's taken, once it finishes
[04:40] <daniels> which could be any time from now until 2016 :P
[04:40] <fabbione> ahhaha
[04:40] <fabbione> daniels: are you sure you are not on a 28.8k modem?
[04:40] <daniels> yeah :)
[04:41] <Keybuk> sivang: it would be more accurate to describe the current situation as "software patents discouraged"
[04:41] <lamont_r> azeem: www.ututo.org
[04:41] <azeem> oh
[04:42] <sivang> Keybuk: ok :) noted.
[04:42] <lamont_r> and rms is visiting them
[04:42] <azeem> lamont_r: I honestly though he forgot the spelling :)
[04:42] <azeem> thought
[04:42] <lamont_r> nah - he's better than tat
[04:42] <lamont_r> that
[04:43] <fabbione> lamont_r: did you notice that your cupsys upload is FTBFS?
[04:44] <lamont_r> azeem: the question comes down to: do you want to include only free software in the distribution, or do you want it to "just work" for users.
[04:44] <lamont_r> the first one is great once you own the market, until then, users will just install windows.
[04:44] <lamont_r> fabbione: sigh
[04:45] <daniels> fabbione: a bit over 5 minutes to do a single diff.
[04:45] <azeem> lamont_r: well, I thin restricted is a nice idea, dunno whether multiverse has anything interesting in it to warrant its existence
[04:45] <fabbione> daniels: can you give me the command?
[04:45] <fabbione> i want to check from here
[04:46] <azeem> lamont_r: in any case, I just thought it was a nice typo, didn't want to start a non-free discussion :)
[04:46] <daniels> fabbione: svn diff -r 2011:2017
[04:46] <lamont_r> fabbione: WTF is there a patch patching the debian directory?  GAH!
[04:46] <daniels> lamont_r: that's not fabbione's fault, to be fair
[04:47] <lamont_r> daniels: I know that
[04:47] <fabbione> daniels: i didn't take it personally...
[04:47] <lamont_r> worst part is that one of us added it.
[04:47] <daniels> heh
[04:47] <Keybuk> yeah, people who make patches that do that should be hung, drawn and quartered
[04:47] <Keybuk> *eyes pitti with the meat cleaver in hand*
[04:48] <lamont_r> Keybuk: how did you know I was gonna accuse him?
[04:48] <fabbione> Keybuk: using dpatch is so easy to get caught in that shit...
[04:48] <fabbione> no guys you are all wrong
[04:48] <fabbione> it's GTK FAULT!
[04:49] <Keybuk> to be honest, I'm pretty unhappy with patching the source tree in general
[04:49] <pitti> if cupsys had a sane way of patching in the new japanese stuff (instead of doing weird things in debian/rules and with uudecode), I wouldn't have to do these weird things in the first place...
[04:49] <lamont_r> Keybuk: dpatch or otherwise?
[04:49] <Keybuk> lamont_r: patches in debian/patches patching the .orig.tar.gz
[04:49] <fabbione> Keybuk: hey.. that's cool.. you can get to maintain the kernel with no patches :-)))
[04:49] <Keybuk> you end up with debris in .diff.gz, or worse, non-functioning patch or unpatch targets
[04:50] <lamont_r> Keybuk: ah, that complaint
[04:50] <Keybuk> (or amusing patches-containing-themselves)
[04:50] <pitti> lamont_r: if you want to directly modify debian/, then please do further syncs yourself
[04:50] <Keybuk> fabbione: doesn't the kernel use a dbs-style patches-patch-a-tarball
[04:50] <lamont_r> pitti: plan o
[04:50] <fabbione> Keybuk: no. dpatch
[04:50] <lamont_r> plan to
[04:50] <fabbione> Keybuk: see quotes
[04:50] <pitti> lamont_r: after spending hours to sync cupsys I just had to separate the ubuntu changes into their own patches
[04:50] <fabbione> Keybuk: i would love to make it dbs...
[04:50] <pitti> lamont_r: this makes it _much_ easier
[04:51] <Keybuk> pitti: m-o-m seemed to sync cupsys ok to me
[04:51] <lamont_r> debian/cupsys.init.d just doesn't change that much
[04:51] <pitti> Keybuk: when I synced it back then, it was a mess
[04:51] <pitti> Keybuk: OTOH the current packaging is a mess in itself
[04:52] <pitti> Keybuk: so it cannot get much worse by patching 
[04:52] <Keybuk> which reminds me
[04:53] <Keybuk> elmo: when you get a free moment or two, could you look over my proposal at http://www.dpkg.org/NewSourceFormat and be critical?
[04:56] <fabbione> i can't even get to connect to dpkg.org
[04:57] <mdz> tech board meeting starting in #ubuntu-meeting
[04:57] <lamont_r> fabbione: works for me
[04:59] <mjg59> fabbione: Yeah
[04:59] <mjg59> fabbione: We probably want the O(n) swsusp stuff, too
[05:01] <lamont_r> pitti: so WTH do I use to edit ubuntu-init.d.patch?
[05:01] <fabbione> daniels: it took 10 minutes here
[05:01] <fabbione> daniels: i will talk with OF
[05:01] <daniels> fabbione: so it's not just my modem ;)
[05:01] <pitti> lamont_r: copy the source tree and use diff -u?
[05:01] <daniels> fabbione: this is merging back all the relevant debian changes (typo fixes) to xorg
[05:01] <pitti> lamont_r: sorry, with a proper packageing system (like dbs or cdbs+tarball) you get better tools
[05:03] <lamont_r> pitti: it uses cdbs
[05:03] <Keybuk> fabbione: I think thom's IPv6 route has gone down, so you probably have to wait for timeout and fallback to IPv4 :p
[05:04] <fabbione> Keybuk: make sence
[05:06] <daniels> mjg59: ping
[05:06] <mjg59> daniels: Yo
[05:07] <daniels> mjg59: so, how's vbetool coming along?  if it still uses x86emu, wouldn't mind stealing it to do ddc probes at some point in time so we can get ddc over vbe on amd64
[05:07] <fabbione> mjg59: yeah but i lost the mail with the patch O
[05:07] <mjg59> fabbione: Haha
[05:07] <fabbione> mjg59: can you forward it to me again?
[05:07] <mjg59> I'll try to dig that out at some point
[05:08] <fabbione> thanks
[05:08] <mjg59> daniels: vbetool is basically done, but doesn't use x86emu
[05:08] <mjg59> I could probably write a small layer that munges lrmi stuff onto x86em
[05:08] <daniels> mjg59: ahr.  weren't you doing one with x86emu at some stage, or have I been smoking too much of the good stuff again?
[05:08] <mjg59> video_post used x86emu, but Mike Harris said that vm86 mode was less crackful
[05:09] <daniels> ah, right
[05:09] <daniels> yeah, vm86 is less cracktastic
[05:09] <daniels> but about 100% less amd64-friendly
[05:10] <daniels> if you don't have time, i'll probably have to get to it sometime pre-hoary, so I'll do it before then
[05:10] <mjg59> It's pretty easy to do, you just need to replace the lrmi calls with x86emu ones
[05:10] <daniels> mmm
[05:10] <fabbione> daniels: it took me only 49 seconds now to do the same diff
[05:10] <mjg59> Oh, and you ought to get in touch with scisoft and try to find out if there's a newer version of x86emu that they can provide
[05:10] <fabbione> (after i stopped saturating my bw)
[05:10] <daniels> fabbione: weird
[05:11] <daniels> fabbione: my bandwidth is untouched, this aside
[05:11] <mjg59> The one on their ftp site is ancient, and xfree and xorg have both diverged in different directions
[05:11] <daniels> (well, I have the Ubuntu mirror trickling in at 15kb/sec, but this is a >1.5MBit line)
[05:11] <daniels> mjg59: the one in X.Org was allegedly from Kendell and SciTech
[05:11] <mdz> doko: if you are available, please /join #ubuntu-meeting
[05:11] <daniels> (i.e. one of the 6.7 items was resyncing x86emu from upstream)
[05:11] <daniels> but yeah, I'll probably give him another poking
[05:12] <mjg59> Ok, in that case grabbing it is probably the best bet
[05:12] <daniels> yah
[05:12] <mjg59> Oh, I need to figure out why vbetool vbemode get returns wrong stuff
[05:12] <mjg59> But I think that's probably me fucking up with the specs
[05:13] <daniels> heh
[05:13] <daniels> i was agonising for ages over why the dtimings in ddcprobe were broken
[05:13] <daniels> thinking i'd screwed up the formula
[05:13] <daniels> but once I threw away the code to get it out of the EDID block and rewrote it, it was fine
[05:19] <daniels> hm, have to be up in 3.5 hours.
[05:25] <daniels> 'night
[05:35] <lamont_r> fabbione: your chroot is ready.  dchroot sid
[05:35] <fabbione> lamont_r: cool. i will start on it tomorrow
[05:35] <lamont_r> thanks
[05:38] <lamont_r> fabbione: well, dchroot -c sid, or just plain 'dchroot'. 
[05:38] <fabbione> lamont_r: ehhee.. did you install distcc ???
[05:39] <lamont_r> in the chroot?
[05:39] <fabbione> ggg was mentioning it.. or otherwise ccache
[05:39] <fabbione> yeah
[05:39] <fabbione> if there is space i would prefer ccache
[05:39] <lamont_r> uh, yeah.  and ccache in a second
[05:40] <lamont_r> just chain the 2 together.. :-)
[05:40] <fabbione> i am not sure you actually can...
[05:40] <fabbione> but anyway make-kpkg doesn't fork
[05:41] <fabbione> that's why i prefer ccache
[05:42] <lamont_r> fabbione: ccache installed
[05:43] <lamont_r> ggg is mostly doing 'make', not make-kpkg
[05:43] <fabbione> yeah that's why....
[06:02] <mdz> is workrave fucked for anyone else?
[06:02] <ogra> doe that thing still exist ?
[06:02] <ogra> does even
[06:04] <ogra> oh....confused it with workman :)
[06:08] <lamont_r> hell.  hoary goals meeting is right on top of 'pick up the kids'
[06:09] <thom> mdz: i can try upgrading, but my laptop is basically ~mataro level hoary right now
[06:13] <lamont_r> well, maybe 'proud' overstates it a bit.
[06:28] <mdz> thom: welcome back
[06:29] <thom> mdz: thanks, kinda. i'm on my parents dialup curreently :(
[06:38] <mdz> elmo: I think we're about due for a seed/archive resync
[06:52] <pitti> elmo: is there a i386 hoary dchroot out there with linux-tree-2.6.10 installed?
[06:55] <pitti> mvo: have fun
[06:55] <mvo> I will :)
[06:55] <mvo> see you later pitti (and the others)
[06:55] <pitti> mvo: I look forward to go to Taekdowndo again after four weeks :-)
[06:55] <mvo> I wonder if I will manage to hit the ball after 4 weeks without any practise :)
[07:02] <thom> urk, speaking of seeds i need to write that BOF up and update the seed lists
[07:04] <elmo> mdz: hum? I did one this morning
[07:04] <mdz> thom: "so, about those pending seed updates" is on the agenda :-)
[07:04] <elmo> pitti: err, possibly not, I think the i386 machine got morphed into the librarian
[07:04] <thom> mdz: heh
[07:04] <elmo> I'll look into creating another one
[07:04] <mdz> elmo: oh, good.  I hadn't bothered checking since last night
[07:04] <pitti> elmo: okay, thanks
[07:06] <elmo> pitti: what was the final consensus on mmv ?
[07:06] <pitti> elmo: I change the patch to do without
[07:06] <mdz> pitti: you don't have an i386 hoary chroot?
[07:06] <pitti> mdz: i have
[07:07] <pitti> mdz: my desktop is hoary i386
[07:07] <elmo> pitti: I'm not particularly fussed either way
[07:07] <pitti> mdz: but compiling the full suite of i386 kernels takes veeery long on my machine
[07:07] <mdz> pitti: using ccache?
[07:07] <pitti> elmo: I know that it is not a nice solution, but it was a quick fix for Debian
[07:08] <pitti> mdz: doesn't work, because each kernel has different processor targets
[07:08] <pitti> mdz: no problem, after all
[07:08] <pitti> mdz: I can do it on my server, too
[07:08] <mdz> pitti: eh?
[07:08] <pitti> mdz: -k7, -686, -386 and so on
[07:08] <mdz> pitti: yes, but once you've built them all once, you have them in cache
[07:08] <mdz> assuming the cache is large enough
[07:08] <pitti> mdz: but as soon as I change a configuation option I have to rebuild anyway
[07:09] <pitti> mdz: as I said, it's not a big problem
[07:09] <pitti> mdz: I have amd64 and ppc chroots
[07:09] <pitti> mdz: and I can do i386 on my own
[07:09] <mdz> pitti: when you only change a configuration option, ccache should be a big win
[07:09] <pitti> mdz: sure, might be worth a try
[07:10] <mdz> pitti: I use it all the time
[07:10] <pitti> mdz: me too, for other projects
[07:10] <mdz> especially for the kernel
[07:10] <pitti> mdz: what is required to make it work for the kernel?=
[07:10] <pitti> mdz: it is not automatically used for me if I build the kernel
[07:10] <mdz> pitti: nothing
[07:10] <mdz> oh
[07:10] <mdz> I use PATH=/usr/lib/ccache:$PATH
[07:10] <wasabi_> I need to be educated on the ubuntu version names. I see ubuntu1,2 are added at the end. This makes debchange behave right, and the versioning work.
[07:10] <pitti> mdz: me too
[07:10] <mdz> so, for everything
[07:10] <wasabi_> What if *I* wanted to fork my own package.
[07:10] <mdz> works for me with the kernel
[07:11] <wasabi_> 1.2-0ubuntu1me1
[07:11] <wasabi_> ?
[07:11] <mdz> wasabi_: this is a difficult question
[07:11] <pitti> mdz: hmm, I look into this again
[07:11] <pitti> mdz: oh right, now my ~/.ccache is 1.6 GB :-)
[07:11] <pitti> mdz: it was empty the last time I looked. My fault
[07:11] <wasabi_> I think ubuntu1me1 will work out right, if it's alphabatized...
[07:11] <azeem> wasabi_: why not ubuntu1.1?
[07:11] <wasabi_> Im not sure what happens in the processing if I add another . to the version
[07:11] <mdz> wasabi_: if you want it to be greater than ubuntu1, but less than ubuntu1.2, yes, that's what you want
[07:11] <wasabi_> oh. does that work?
[07:11] <azeem> dunno :)
[07:12] <mdz> wasabi_: it's just a matter of choosing a version number which compares the way you want.  you can test it with dpkg --compare-versions
[07:12] <mdz> wasabi_: but things get complicated when you consider that there are already multiple versioning schemes in use, in Debian and in Ubuntu
[07:13] <mdz> brb, reboot
[07:13] <mdz> seb128: hmm, System->Logout is hanging for a long time
[07:14] <mdz> seb128: the System menu is still highlighted, but there is no logout dialog yet
[07:14] <seb128> it's going to pop up in 30s
[07:14] <pitti> Ubuntu - nothing for the impatient :-)
[07:14] <seb128> you probably have an app which registred in the session in a wrong way
[07:14] <mdz> hmm
[07:15] <mdz> this happened on my last logout, too
[07:15] <seb128> not easy to find which one
[07:15] <mdz> it has been 2 minutes and it is still not up
[07:16] <mdz> I am not running anything strange in this session
[07:16] <mdz> the same things I always do
[07:16] <seb128> there is a timeout, I thought it was 30s, perhaps 1min
[07:16] <mdz> gnome-terminal, gaim, firefox, xchat
[07:16] <seb128> these apps have not changed for week
[07:16] <mdz> 3 minutes now
[07:16] <seb128> neither gnome-session
[07:16] <seb128> hum
[07:16] <mdz> hmm
[07:16] <mdz> gnome-session is not running
[07:16] <mdz> I imagine that is not normal
[07:16] <ogra> fabbione: hisax oopses...mvo is right....
[07:17] <mdz> so now my panel is hung due to the menu still being active
[07:17] <seb128> mdz: nop, not normal
[07:17] <seb128> not normal at all
[07:17] <mdz> seb128: I am using a session which I saved a long time ago (warty timeframe), could that be a factor?
[07:18] <mdz> do I need to re-create it?
[07:18] <seb128> should not
[07:18] <seb128> you can try to move ~/.gnome2/session away
[07:18] <seb128> just to see if that helps
[07:18] <mdz> how do I get out of my current mess?
[07:19] <mdz> zap the X server?
[07:19] <seb128> what's hanging ?
[07:19] <seb128> the panel ?
[07:19] <mdz> I can't log out; System menu is still highlighted
[07:19] <mdz> and gnome-session doesn't seem to be running
[07:19] <seb128> killall gnome-panel
[07:19] <seb128> that's weird
[07:19] <mdz> try logging out again?
[07:19] <seb128> yep
[07:20] <mdz> oh, gnome-session is running
[07:20] <seb128> but you are sure that session is not running ?
[07:20] <mdz> it is called x-session-manager
[07:20] <mdz> second attempt to logout is hanging also
[07:20] <seb128> $ ps ax | grep session
[07:20] <seb128>  4392 ?        Ss     0:00 /usr/bin/gnome-session
[07:20] <mdz> mdz       7162  0.0  0.4  18548  8796 ?        Ss    2004   0:02 x-session-manager
[07:21] <mdz> lrwxrwxrwx  1 root root 22 2004-11-30 15:34 /etc/alternatives/x-session-manager -> /usr/bin/gnome-session
[07:21] <seb128> how do you start your session ? 
[07:21] <seb128> gdm ?
[07:21] <mdz> logging into gdm
[07:21] <mdz> I must be using 'default system session' or whatever, rather than GNOME
[07:21] <seb128> what happen if you run gnome-session-save ?
[07:22] <seb128> probably yes
[07:22] <mdz> it exits instantly
[07:22] <seb128> and creates ~/.gnome2/session ?
[07:22] <mdz> err
[07:22] <mdz> my gnome-terminal became unresponsive
[07:22] <mdz> I launched a new gnome-terminal, and that is unresponsive too
[07:22] <mdz> my keystrokes do nothing
[07:22] <mdz> other applications are fine, though
[07:22] <seb128> WTF
[07:23] <mdz> I launched an xterm from a text console
[07:23] <mdz> ~/.gnome2/session does not exist
[07:23] <seb128> ok, so it doesn't save correctly ... something running is broking it
[07:24] <mdz> I wonder if it's workrave
[07:24] <mdz> my workrave is fucked
[07:24] <mdz> I have no idea why
[07:24] <mdz> oh, hey, there is a dialog open
[07:24] <mdz> these windows do not support "save current setup" etc.
[07:25] <seb128> saying what ?
[07:25] <mdz> it opened behind a window
[07:25] <mdz> I closed it, and got a dialog saying that my session was saved
[07:25] <mdz> and I can talk to gnome-terminal again
[07:25] <seb128> ok
[07:25] <mdz> and ~/.gnome2/session exists
[07:25] <mdz> that dialog should probably open on top, considering that it freezes everything
[07:26] <seb128> yep, one more candidate for #3159
[07:26] <mdz> I killed workrave, it is not running at all
[07:26] <ogra> i think i read about a metacity focus bug anywhere last week
[07:26] <mdz> so that can't be it
[07:27] <mdz> seb128: anything else I can try before killing X?
[07:27] <seb128> not really
[07:27] <mdz> ok, brb
[07:31] <seb128> mdz: something registred wrongly in the session and fucked it probably, killing the app doesn't help (the session waits for some informations that the app should provide or something like that ... killing the app doesn't help to get them)
[07:34] <mdz> seb128: I noticed something strange; in the Add to Panel dialog, the Add button has a '+' on it, but when I highlight one of the applets to add it, the '+' disappears and the button just reads [    Add ] 
[07:35] <seb128> yep, that's #4999 (gtk bug, fixed upstream now)
[07:38] <mdz> ah, thanks
[07:39] <mdz> I wonder if workrave will work again now
[07:42] <pitti> mdz: I should return 5 minutes before 2200 UTC
[07:42] <mdz> seb128: hmm, workrave works again
[07:42] <mdz> seb128: I wonder if these two things were related
[07:43] <mdz> seb128: the logout dialog works properly also
[07:43] <seb128> no idea
[07:44] <seb128> I hate this kind of bugs, most of the time that's impossible to find the root
[07:44] <seb128> ogra: for what ?
[07:44] <ogra> for breakage like not bringing windows to front if they should have been....for probs with workrave at the same time.....
[07:45] <ogra> sounds suspicious like a WM prob
[07:48] <mdz> ogra: I think I agree with you
[07:48] <mdz> the workrave problems seemed WM-related, now that I think about it
[07:49] <mdz> it would hang at exactly the time when it should have opened a window
[07:49] <mdz> i.e., when the timer ran down
[07:50] <ogra> it probably has opened a window.....behind another like gnome session did.....and blocked the desktop ....
[07:50] <seb128> that's not a metacity bug
[07:50] <seb128> that's an app bug
[07:50] <seb128> the app has to update its timestamp
[07:51] <abelli> seb128: do you know anything about the kb's layout thing?
[07:53] <seb128> oups, sorry, I've forgotten the other chan
[07:53] <seb128> better to highlight me :p
[07:54] <ogra> seb128: even if i program a gtk window as popup i have to update a timestamp to get my focused win to top ?
[07:54] <seb128> you have to specify than the app has to take the focus yes
[07:55] <seb128> that's the principe of the "focus stealing prevention"
[07:55] <seb128> = don't steal the focus if not needed
[07:55] <lamont> hrmpf.  gonna have to get another fan
[07:55] <seb128> and the way to do that is to not steal the focus if an app doesn't ask for it
[07:56] <ogra> sure, but i thought it is a property i set in the sourcecode.....(especially for a blocking app like the "save apps that are not session aware" or workrave)
[07:56] <seb128> http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html
[07:56] <seb128> read this for details
[07:57] <ogra> thnks :)
[07:57] <seb128> that's some code example and all the details
[07:57] <seb128> np
[08:01] <ogra> hmm, i understand the focus thing, but it still doesnt explain why "on top" windows dont get on top (i.e. my gaim windows pop up above all others, they just dont grab the focus...
[08:01] <ogra> )
[08:02] <ogra> and thats a WM thing imho
[08:03] <mdz> ogra: I don't think it had a window open; I killed it and restarted it
 it opened behind a window
 I closed it, and got a dialog saying that my session was saved
[08:03] <mdz> ogra: that was the gnome-session-save window
[08:03] <mdz> workrave didn't open anything
[08:03] <ogra> thats what i'm talking about....
[08:04] <ogra> workrave too...but in first place i meant this message from you...
[08:05] <seb128> ogra: the app define if the dialog if toplevel or not
[08:05] <seb128> s/if toplevel/is toplevel/
[08:07] <ogra> yup
[08:07] <seb128> so I don't get why you think that's a wm bug
[08:07] <mdz> the workrave dialogs always stay on top
[08:07] <mdz> and even so, I looked around
[08:07] <mdz> workrave was somehow in a very broken state
[08:07] <mdz> and also the logout functionality
[08:07] <mdz> both were fixed when I restarted
[08:09] <ogra> seb128: becaues the WM is the app that recives the definition....and if more then one app is behaving faulty in this direction i would suspect the reciever here, not the sender
[08:09] <seb128> ogra: the app has to said if the dialog should take the first plan/the focus
[08:10] <seb128> gnome-session doesn't do that correctly
[08:10] <seb128> metacity has nothing to do with that
[08:10] <ogra> k
[08:33] <Kamion> 411? heads-up?
[08:34] <cartman> is there a way to see packages in "pendingupload" state?
[08:36] <seb128> select the pendingupload state in the bugzilla search form ?
[08:36] <cartman> that should work. thanks
[08:38] <lamont> Kamion: US-ism: 411 is the phone number for directory assistance, aka "information"
[08:42] <Kamion> lamont: aha
[08:43] <lamont> Kamion: it's one of those "only popular in marketing circles" kind of phrases
[08:49] <wasabi_> How in the world can ant be in multiverse, when a ton of it's build-deps are
[08:49] <wasabi_> aren't that is
[08:50] <Kamion> hm? multiverse's dependencies and build-dependencies are allowed to be in other components
[08:50] <Kamion> unless you mean *reverse* build-dependencies
[08:50] <lamont> wasabi_: the builddeps can be in main, restricted, universe, or multiverse
[08:50] <Kamion> and the answer to that is that dep/build-dep closure is only enforced for main and restricted
[08:56] <lamont> Kamion: debian contrib/ went into universe?  or only as requested?
[08:56] <elmo> contrib -> multiverse
[08:56] <elmo> +what we could of non-free
[09:04] <wasabi_> well... it's not in any of em
[09:04] <wasabi_> ant 1.6 is in multiverse, but it's missing a ton of deps... that I can see anyways
[09:04] <elmo> ant is in multiverse, it just didn't build
[09:04] <wasabi_> and some how, one of it's binaries (ant itself) is missing... or I can't find it. Or Im stupid.
[09:05] <wasabi_> Just trying to rebuild it. ;0
[09:05] <wasabi_> guess I could just grab it all from hoary and backport it, if it works there. =/
[09:05] <wasabi_> nope.
[09:06] <Treenaks> yay! more seb-slapping ;)
[09:07] <ogra> huh ?
[09:08] <Treenaks> ogra: he came in. slapped seb, and left.. must've been a hoary user ;)
[09:08] <ogra> i saw it .... :)
[09:10] <wasabi_> There should totally be some sort of .revoke file for archive uploads.
[09:11] <mdz> lamont: marketing circles and 12-year-old girls
[09:11] <Treenaks> s/and/of/ ?
[09:11] <ogra> Treenaks: i was wondering if mark is in .za .......
[09:12] <lamont> mdz: hadn't encountered the second case.
[09:13] <lamont> this person was "working on compiling postfix on another linux distro"
[09:13] <mdz> lamont: maybe a regional difference
[09:13] <lamont> yeah - mostly a bi-coastal thing, iirc
[09:13] <mdz> Kamion: when a bug turns out to be a duplicate of a Debian bug, I just add the deb<num> alias, which imports the comments from debbugs and links it for debzilla
[09:14] <lamont> mdz: awesome thing to know
[09:15] <mdz> yeah, should be much easier than nagging me to import bugs
[09:15] <mdz> since I was in the habit of importing bugs myself, I didn't think to do it this way until I saw doko do it
[09:16] <sladen> mjg59: regarding your note from the other day, what were you saying about framebuffer during hibernate/resume?
[09:17] <mjg59> Oh, yeah
[09:17] <mjg59> Ok. We have framebuffer issues.
[09:17] <abelli> quit
[09:17] <mjg59> Before any userland code is run, the kernel will try to printk "Back to C"
[09:17] <sladen> mjg59: riiight.  You were saying it might be possible
[09:17] <lamont> mdz: so basically, you're a copy cat?   I'm shattered. :-)
[09:18] <mjg59> This is likely to confuse vesafb
[09:18] <lamont> mdz: mind you, I'd have never thought of it either
[09:18] <sladen> mjg59: what's the 'Back to C' for?  is that C as in the language, or C as in the processor state/
[09:18] <mjg59> C as in the language - it gets printed once we're back in the kernel
[09:18] <sivang> mjg59: when I snap my laptop from the suspend, it does produce some kernel messages now in text mode but never goes back to X properly, that is it starts it up and screen=blank, and I disabled the framebuffer in the Xorg conf.
[09:19] <mjg59> sivang: And you've tried pressing keys?
[09:19] <mdz> isn't the mono VM called "CLR"?
[09:19] <mdz> the mono packages say "CLI"
[09:19] <sivang> mjg59: yes
[09:19] <mjg59> What happens if you suspend from a text console?
[09:19] <sladen> mdz: clr == runtime  cli == interpreter (?)
[09:19] <sivang> mjg59: it never displays the text messages, and nothing happend.
[09:19] <mjg59> sivang: ?
[09:19] <ogra> sladen: are you still the man for the cpufreq detect stuff ?
[09:19] <sivang> mjg59: the sleep.sh work only from within Xorg
[09:20] <mjg59> sivang: In what way?
[09:20] <mjg59> Does anything appear in dmesg?
[09:20] <sladen> mdz: sorry, cli == infrastructure
[09:20] <sivang> mjg59: in a way that I can see the kernel messages when it awakens
[09:20] <mdz> ah
[09:20] <Kamion> mdz: oh, it does that automatically?
[09:20] <sladen> ogra: what issue are you having?
[09:20] <mjg59> sivang: It sleeps but doesn't resume?
[09:20] <Kamion> mdz: rock
[09:21] <sivang> mjg59: yes, as opposed to sleeping from Xorg in which it resumes into some text messages and get stucks.
[09:21] <mjg59> sivang: That's very odd. The first thing the sleep script does is switch to a text console.
[09:21] <sivang> mjg59: when I do it from a text console when  Xorg is not running, it won't resume in a way that I can see the kernel messages again.
[09:21] <ogra> sladen: looks like the speedstep modules are all compiled without the coppermine option....they all complain about "no such option" 
[09:21] <Kamion> Keybuk: there were a load of changes to doc/manual/build/ in debian-installer that got dropped with the latest merge (20041227); how come they didn't show up in a -dropped file?
[09:21] <mjg59> sivang: What hardware is this?
[09:21] <ogra> sladen: but your script uses it on all my coppermines just fine here ;)
[09:22] <Keybuk> Kamion: I don't know ... will have to look
[09:22] <Kamion> Keybuk: some of them appeared, but the cases where the files to which the patches applied had been moved didn't get -dropped files
[09:22] <mjg59> sladen: The only framebuffer we stand any real chance with is vesafb
[09:22] <sladen> ogra: that was from an unconfirmed report I had.  you can pass  relax_check=1  to force it try regardless of whether it finds the correct magic or not
[09:22] <Keybuk> interesting ... could be a bug :)
[09:22] <sivang> mjg59: ergh, don't ask :)
[09:22] <mjg59> sivang: It's difficult to help otherwise
[09:22] <Keybuk> I definitely didn't take into account the patch failing because the file didn't exist
[09:22] <Keybuk> maybe it doesn't notice
[09:22] <mjg59> sladen: Well, with the possible exception of vga16fb
[09:22] <sivang> mjg59: I will have all details for you later tonight if you'll still be online.
[09:22] <mjg59> sladen: What level of framebuffer functionality do you want?
[09:22] <mjg59> sivang: Yeah, should be
[09:22] <sladen> mjg59: I'm fine with vesafb the PC99 & legacy specs /require/ a VESA interface that can do 800x600x256 anyway
[09:23] <sivang> mjg59: k.
[09:23] <ogra> sladen: i just wanted to point it out... if its a option you can set by make menuconfig and has probably been forgotten.....
[09:23] <mjg59> sladen: Problem with vesafb is that it doesn't actually use the vbe calls to do the screen setup
[09:23] <sladen> mjg59: s/legacy/& free/
[09:23] <mjg59> Which breaks on some hardware
[09:23] <sladen> mjg59: oh geeze, why ever not?  surely that's what interfaces are for
[09:23] <mjg59> Oh, no, hang on
[09:23] <mjg59> I'm thinking of vga16fb
[09:24] <mjg59> vesafb should work fine
[09:24] <mjg59> But it still doesn't call things neatly
[09:24] <mjg59> If you ask what vesa mode you're in on a vesafb console, it'll say "3", which is 80x25 text mode
[09:26] <mjg59> So the issue is basically the following:
[09:26] <mjg59> 1) We need to get the video hardware back into the state that vesafb is expecting
[09:26] <mjg59> 2) We need to make sure vesafb doesn't explode everything first
[09:26] <sladen> mjg59: while we're on the subject, what is the bios=irq doing;  is that called the BIOS to configure IRQ routeing instead of ACPI or is it just leaving the mapping as it was found
[09:27] <sladen> mjg59: stupid question, can we unmodprobe and re modprobe vesafb?
[09:28] <mjg59> sladen: Linux used to enable interrupts even if hardware hadn't asked for them to be routed
[09:28] <mjg59> That worked fine over suspend/resume
[09:29] <sladen> mjg59: ''vesafb0 does not have a release() function and needs to be fixed''
[09:29] <mjg59> Now it only does so if asked, which /should/ work fine over suspend/resume, except that the /old/ state of the interrupt router was restored, without the hardware configuration actually being changed
[09:29] <mjg59> sladen: rmmod/modprobe will "work" as in stuff won't necessarily break, but it's unlikely to actually /do/ anything
[09:30] <mjg59> pci=routeirq restores the old behaviour, which works round it
[09:30] <mjg59> But there's a better patch that actually does the interrupt setup properly
[09:30] <sladen> righto
[09:30] <mjg59> I'll make sure it goes into the 2.6.10 stuff
[09:30] <sladen> pci=routeirq != irq=bios ?
[09:30] <mjg59> Correct
[09:31] <sladen> oh ''better patch'', good good
[09:31] <mjg59> If we're lucky, having stuff printed to vesafb while it's in the wrong state won't actually break anything
[09:31] <mjg59> But that's not too good a hope
[09:32] <sladen> mjg59: well, if it doesn't work, that's called a bug and can be fixed until the point that it does
[09:32] <mjg59> Ok. In that case, we want to do the following:
[09:33] <mjg59> Work out what VESA mode we're in. Save the state using a VBE call. Suspend. Resume. POST the video. Restore the state. Possibly then restore the mode, though we /may/ not need that.
[09:34] <mjg59> At that point, if we're lucky, vesafb is alive again.
[09:34] <mjg59> Though we may not have X at this stage.
[09:36] <mjg59> Oh, this is probably unneeded for swsusp - the bootloader will have put things in the right mode for us
[09:38] <Kamion> mjg59: vesafb doesn't currently work on several bits of hardware I have
[09:38] <Kamion> d-i has to fall back to vga16fb
[09:40] <mjg59> Kamion: Mm? d-i never uses vesafb
[09:40] <Kamion> it SO does
[09:40] <mjg59> It's either vga16fb or nothing
[09:40] <mjg59> It so doesn't
[09:40] <Kamion> incorrect, sorry
[09:40] <Kamion> it certainly tries
[09:40] <Kamion> perhaps it never succeeds, but :)
[09:40] <mjg59> It tries to modprobe it, but syslinux never passes the kernel a mode=
[09:40] <Kamion> ah, so we agree vociferously then
[09:41] <mjg59> So if you have any framebuffer at any point during the install, it's vga16fb
[09:41] <Kamion> I thought you meant it never even tried
[09:41] <Kamion> can we fix that in syslinux?
[09:41] <mjg59> Which breaks on various bits of hardware, because it programs stuff directly
[09:41] <mjg59> No idea, I'm afraid
[09:42] <mjg59> I'd guess so - it should just be an option in syslinux.cfg
[09:42] <Kamion> I don't think many d-i hackers actually know about this, because we wouldn't be using vesafb if it never worked
[09:42] <Kamion> did it work in 2.4 perhaps?
[09:42] <mjg59> Nope
[09:42] <Kamion> hmph
[09:42] <mjg59> vesafb as a module can /only/ work if the bootloader has set up the video mode already
[09:43] <mjg59> wakeup.S in the kernel records the video mode, and vesafb checks that when it's inserted
[09:43] <Kamion> do you happen to know roughly where grub does this? I can't see it
[09:44] <wasabi_> So how do I go to get ant in multiverse imported properly?
[09:44] <Kamion> vga= maybe?
[09:44] <wasabi_> It builds with all free stuff now I believe.
[09:44] <fabbione> Keybuk: you here?
[09:45] <mjg59> Yeah, vga=
[09:45] <Kamion> wasabi_: can we get the Debian maintainer to move it to main if it builds with entirely free code? that would be great for all concerned
[09:45] <mjg59> I can't remember if that'll work as a kernel boot paramater or not
[09:45] <wasabi_> Kamion: Hmm. I'll do some research.
[09:46] <mjg59> Kamion: vga=0x301 should give a 640x480x256 colour screen
[09:47] <Kamion> syslinux *appears* to try the same kind of stuff grub does
[09:47] <mjg59> But there'll be no output whatsoever until vesafb is modprobed
[09:47] <mjg59> Just a black screen for a while
[09:47] <Keybuk> fabbione: yup
[09:47] <Kamion> oh, I see
[09:47] <fabbione> Keybuk: i read the newsource proposal... 
[09:47] <mjg59> Oh, might be vga=301
[09:47] <fabbione> Keybuk: wanna talk about it?
[09:48] <mjg59> Uh. vga=769 
[09:48] <sladen> mjg59: that functionality needs moving from the kernel-commandline to insmod innovocation so that initrd can select it
[09:48] <mjg59> (hex->decimal)
[09:48] <Keybuk> yeah, gimme a few seconds though
[09:48] <mjg59> sladen: Can't.
[09:48] <fabbione> Keybuk: since it's time for changes perhaps we can enanche also other bits
[09:48] <sladen> mjg59: cya?
[09:48] <mjg59> It's not vesafb that does the mode change. It's the bootloader.
[09:49] <sladen> mjg59: YOU.  ARE.  KIDDING.
[09:49] <mjg59> Haha. No.
[09:49] <Kamion> vga=769 works here, and I get vesafb in d-i. interesting.
[09:50] <Kamion> except I get a red screen rather than the blue one
[09:50] <Keybuk> Kamion: ok, fixed that bug :p
[09:50] <Kamion> Keybuk: thanks
[09:50] <Keybuk> fabbione: right, ready
[09:50] <Keybuk> lay into me, baby :p
[09:50] <mjg59> Kamion: That ought to actually make things work better on the machines where vga16fb doesn't work
[09:50] <fabbione> Keybuk: ahaha
[09:51] <fabbione> Keybuk: i think the layout is ok, and i would instead enforce the control files in the top level directory.
[09:51] <fabbione> Keybuk: since it kills debian/, the presence or not of that directory can act as a flag for old and new format
[09:51] <mjg59> sladen: To do the mode change in kernel, you need to make real mode calls. There's no vm86 support.
[09:52] <Keybuk> fabbione: that's a reasonable idea, actually
[09:52] <mjg59> And there's no decent interface in the kernel to make real mode calls
[09:52] <fabbione> Keybuk: also.. since we are developing a new layout.. i would add a dirctory parallel to build-tree
[09:52] <fabbione> Keybuk: that i would call src-dep-unpack.
[09:52] <Kamion> is this a Mark-inspired proposal?
[09:52] <mjg59> Kamion: Arguably, vga=769 ought to be the default
[09:52] <Keybuk> oh?  what would you put in that?
[09:52] <fabbione> Keybuk: rationale: a good bunch of packages shares the same source...
[09:53] <fabbione> Keybuk: why not introducing a Build-Dep: src:foo (>= 2.0-2) ?
[09:53] <fabbione> Keybuk: that directory will contain the source for foo unpacked and patched
[09:53] <Kamion> I think that should be a different field name, not an overloading
[09:53] <Keybuk> fabbione: my theory on that was that you'd just share the same file in the tarball
[09:53] <Kamion> Source-Depends: is the traditional name used in proposals for that field
[09:54] <fabbione> Kamion: sure.. i am just firing the ideas.. improvements are more than welcome :-)
[09:54] <Keybuk> feel free to comment on the Wiki as well
[09:54] <fabbione> Keybuk: not another wiki account please!
[09:54] <mjg59> sladen: So, uh, suggestions for how we do this sanely? :)
[09:54] <Keybuk> Kamion: not exactly, the debian directory fell out with my own plans -- but it'd certainly keep Mark happy :p
[09:55] <fabbione> Keybuk: i am not sure how you want to share the same tarballs
[09:55] <Kamion> yers
[09:55] <fabbione> Keybuk: i might have a package (like Xprt) that needs some code on its own and Xorg source....
[09:55] <fabbione> Keybuk: how would the layout  looks like?
[09:56] <Keybuk> interesting, I hadn't realised there was that requirement
[09:56] <Kamion> gcc-ssp might be a good test case too
[09:56] <Keybuk> it'd want the patched Xprt source?
[09:56] <fabbione> well this is one that pops to my mind...
[09:56] <Kamion> or binutils-hmwhateverthehellitis
[09:56] <Keybuk> uh, Xorg source even
[09:57] <fabbione> Keybuk: Xprt is really a special case.. but it touches a corner case.. it needs xfree86+patches and xprg from xorg patched...
[09:57] <fabbione> Keybuk: yes.. i am talking about source...
[09:57] <fabbione> + the normal Build-dep
[09:57] <Keybuk> it'd cause a huge increase in the amount of disk space you'd need for those packages (if you were building both anyway)
[09:57] <fabbione> and yes.. also what Kamion said... gcc+ssp is another more common case
[09:57] <fabbione> or the kernel+PAX
[09:58] <fabbione> Keybuk: no.. in the specific there is no need to build all of X to get Xprt...
[09:58] <Keybuk> yeah, but if you were building X anyway, you'd have to unpack X twice
[09:58] <fabbione> Keybuk: but if all the source is not there, some extensions are not compiled...
[09:58] <Keybuk> another thing to do would be to require source-depends are unpacked alongside
[09:58] <Keybuk> so for each, check that ../<package>-<version>/build-tree exists
[09:59] <fabbione> Keybuk: that's why you need a special dir where to unpack them
[09:59] <fabbione> but it's not your problem to unpack them
[09:59] <sladen>           /* Video mode selection support. What a mess!  */
[09:59] <sladen>           /* NOTE: Even the word "mess" is not still enough to
[09:59] <sladen>              represent how wrong and bad the Linux video support is,
[09:59] <sladen>              but I don't want to hear complaints from Linux fanatics
[09:59] <sladen>              any more. -okuji  */
[09:59] <fabbione> you only need to do the apt-get source dance in there
[10:00] <fabbione> or something similar considering that you might not have net access at build time
[10:00] <fabbione> but that can be worked out easily
[10:01] <fabbione> and it would still be the top level source responsability to unpack the Source-Build-Dep
[10:01] <fabbione> that's not a dpkg or whatever problem
[10:01] <Keybuk> *nods*
[10:01] <fabbione> so you are not binded to have a unpacked/patched target in debian/rules.. and all the problems that comes with it
[10:02] <fabbione> does it make any sence to you?
[10:02] <fabbione> actually..
[10:02] <fabbione> do i make sence?
[10:03] <fabbione> Keybuk: also.. have a very well defined format for the patches...
[10:03] <Keybuk> the current proposal just has an unpack target to unpack tarfiles and apply patches
[10:03] <fabbione> like they must apply with patch -p1 to the source
[10:03] <Keybuk> I've been considering instead going with a list of instructions
[10:03] <fabbione> yeah.. i read it...
[10:04] <fabbione> but my original request was to add a directory where to do certain stuff.. like Source-Build-Dep :-)
[10:04] <fabbione> if that's standardize we will not see 1000 of different implementations later
[10:04] <fabbione> that will require another change to get fixed
[10:05] <fabbione> leading to a more complete and adopted standard ;)
[10:05] <Keybuk> yeah, I know :)
[10:05] <Kamion> I have a suspicion that if you restrict patch formats too much you'll see reimplementations, but I can see the benefits of requiring -p1
[10:05] <fabbione> boys.. this crack is good... anybody wants a bit?
[10:05] <Kamion> but it does mean that people can't always just take patches from upstream verbatim and drop them in
[10:06] <fabbione> Kamion: -p1 was an example.. it can -p2 or -p0 or whatever
[10:06] <sladen> mjg59: have you seen the raw Hercules (0xb800) debugging in acpi/wakeup?
[10:06] <fabbione> Kamion: otherwise let's define a patch header...
[10:06] <mjg59> sladen: Yeah. It's a bit sick.
[10:06] <fabbione> Kamion: like #!/usr/bin/patch -p$X
[10:06] <fabbione> # mandatory header that explain wtf is the patch about
[10:06] <fabbione> # origin
[10:07] <fabbione> # notes:

[10:07] <thom> can't we just use dpatch? (/me runs away)
[10:07] <Keybuk> dpatch is evil
[10:07] <Keybuk> patches should *not* be shell scripts
[10:07] <thom> seriously though, storing some metadata in the patch would seem more reasonable than mandating a patch level
[10:08] <sladen> mjg59: not to mention if you happen to have a SCSI controller there
[10:08] <fabbione> Keybuk: no no.. i don't want shell scripts...
[10:08] <lamont_r> bandwidth. yum
[10:08] <fabbione> Keybuk: but you can still add a metadata to define the level
[10:08] <daniels> Keybuk: no, they should be vi scripts, or ed scripts
[10:08] <Keybuk> then the question comes, how do we put metadata for the tar files?
[10:09] <Keybuk> daniels: you know diff can create ed scripts, right? :p
[10:09] <fabbione> Keybuk: what kind of metadata do you need from the tar file?
[10:09] <fabbione> md5sum? sha1? size? MANIFEST?
[10:09] <Keybuk> fabbione: name under build-tree (for multiple tar files), origin, notes, etc.
[10:09] <mjg59> sladen: We should probably strip them, I guess. They do nothing of any use and they might break stuff.
[10:09] <daniels> Keybuk: yeah
[10:10] <thom> my brain just suggested uuencoding the tar balls and embedding them in xml
[10:10] <fabbione> Keybuk: extensions to contents?
[10:10] <fabbione> Keybuk: where there is an automatically generated part and a manual one for unpacking....
[10:11] <fabbione> or whatever operation you would like to do
[10:11] <fabbione> thom
[10:11] <fabbione> HAHAHA
[10:11] <Keybuk> thom: perhaps a holiday?
[10:11] <thom> Keybuk: no, i think those are bad for me
[10:13] <fabbione> Keybuk: how would you address the flavour problem with one single build-tree directory?
[10:13] <fabbione> Keybuk: like we do for apache now... we unpack and patch in build-tree
[10:14] <fabbione> than we clone the dir N times and apply specific patches to each tree
[10:14] <fabbione> and then we build...
[10:14] <thom> then we cross our fingers and pray
[10:14] <Keybuk> fabbione: unpack the tarball multiple times under build-tree and apply different patch sets to it
[10:14] <fabbione> no actually.. that would be addressed in Source-Build-Dep
[10:15] <fabbione> because i could make the common package
[10:15] <Keybuk> fabbione: you'd split the source package?
[10:15] <fabbione> and upload the 3 different flavour source-dep on it
[10:15] <fabbione> also
[10:15] <fabbione> all solutions are valid...
[10:16] <fabbione> we will lose on very small upstream sources....
[10:16] <fabbione> like the ones that comes out with one 300B .c file...
[10:16] <Keybuk> for those you'd have to "cd pkg-ver/build-tree" rather than pkg-ver
[10:16] <Keybuk> basically debian/ and ./ get flipped
[10:16] <fabbione> putting it in a tar.gz would increase the size ;)
[10:16] <Keybuk> aren't they already in .tar.gz ?
[10:17] <Keybuk> there's only one lunatic I can think of who uploads 0-byte .orig.tar.gz with all the package in the .diff.gz
[10:17] <fabbione> Keybuk: ahahhahahaha
[10:17] <fabbione> Keybuk: nahh i was thinking to these upstream that do not ship a tar.. but a single 200 bytes .c file
[10:18] <fabbione> because Debian has sources like this....
[10:18] <Keybuk> there's no loss over the existing source format though
[10:18] <Keybuk> you still have to stick the .c file in a tarball
[10:18] <fabbione> probably a few bytes of overhead..
[10:20] <fabbione> anyway.. very small detail...
[10:20] <fabbione> ~<jvw>   libxerces2-java_2.6.2-1warty0.diff.gz
[10:20] <fabbione> in debian incoming?
[10:21] <jvw> fabbione: yeah... but there was a problem with it
[10:21] <jvw> fabbione: so it wasn't accepted
[10:21] <fabbione> i really don't think it is coming from any of us
[10:21] <fabbione> since we don't use the warty extension since ages..
[10:21] <jvw> aborted by a confused ubuntu developerer?
[10:21] <fabbione> probably we had 2/3 packages that way
[10:21] <Kamion> we'd be unlikely to be working on libxerces2-java anyway
[10:21] <fabbione> jvw: when was that?
[10:22] <jvw> just in
[10:22] <Kamion> jvw: I don't see that file anywhere in newraff's queue
[10:22] <fabbione> nope.. that's definetely not from us
[10:22] <Kamion> oh, upload queue
[10:23] <lamont_r> jvw: who signed the changes?
[10:23] <Kamion> ENOCHANGES
[10:23] <jvw> .changes is missing I see on second thought
[10:23] <Kamion> there's a .dsc, but it's only readable by debadmin because it's in the upload queue
[10:26] <Keybuk> we wouldn't use either "warty" or "0"
[10:29] <fabbione> mjg59: 5162 <- can you look at this bug?
[10:30] <mjg59> fabbione: It's pretty much as it says - the vesafb probe fails, but it doesn't return -ENODEV (or whatever)
[10:31] <Kamion> -ENXIO
[10:31] <fabbione> mjg59: let me rephrase.. can you cook up a patch for it? ;)
[10:32] <mjg59> fabbione: Haha
[10:32] <Kamion> I'm not *totally* convinced it worked properly even in 2.6.8.1 looking at the source; it's hard to tell
[10:32] <fabbione> Kamion: i don't even want to go there :-)
[10:32] <Kamion> it's not high-priority because I've worked around it now
[10:32] <fabbione> that code is so.. hmmm interesting...
[10:32] <mdz> Keybuk: we did use 'warty' for a time
[10:32] <Kamion> (so downgrading)
[10:33] <Keybuk> mdz: only very briefly, and not on that package
[10:34] <mdz> Kamion: I can't even find that error in the 2.6.10 source tree
[10:34] <mdz> jvw: there are folks who have started to maintain repositories of backports for Warty; it's possible that they mis-uploaded
[10:35] <Kamion> mdz: drivers/base/bus.c
[10:35] <Kamion> search for 'probe of'
[10:35] <jvw> mdz: backports?! And you release every 6 monhts...
[10:35] <fabbione> Kamion: we are going to switch to 2.6.10 anytime soon anyway....
[10:35] <jvw> *sigh*, people are never happy, it seems...
[10:36] <Kamion> fabbione: from the source it looks to me like it will have exactly the same problem.
[10:36] <fabbione> jvw: people are happy when you can serve them a slice of your butt.. slaugthed very thin and close to the bone (like we say in italy)
[10:36] <Kamion> you can see it in drivers/base/bus.c, it just throws away the error
[10:36] <fabbione> Kamion: i will look at it as soon as a bit more awake...
[10:36] <mdz> jvw: yeah, I didn't say it was sensible :-)
[10:36] <Kamion> like I say, not urgent
[10:36] <fabbione> i have approx 210 patches pending to review for the kernel + hppa
[10:37] <lamont_r> jvw: yes, backports.
[10:37] <fabbione> and an increasing amount of bug numbers....
[10:37] <lamont_r> the same people ask "when will that be in warty"
[10:37] <lamont_r> fabbione: you know where to get the current hppa kernel from?
[10:37] <jdub> hi all
[10:37] <mjg59> mdz: I think that error is only in Xu's patch
[10:37] <fabbione> lamont_r: bitkeeper?
[10:38] <mdz> mjg59: it looks like it's part of the vanilla sources, just in a much more generic place than I expected
[10:38] <mjg59> Ah, ok
[10:38] <fabbione> bbk in 10 minutes...
[10:38] <fabbione> time to put my gf to bed...
[10:39] <lamont_r> cvs.parisc-linux.org.
[10:39] <lamont_r> let me find the url for you
[10:39] <mjg59> Bleah. It'll be because Herbert hasn't worked out what fb drivers need in the device model, or something.
[10:40] <lamont_r> fabbione: http://cvs.parisc-linux.org/download/linux-2.6
[10:45] <ogra> fabbione: hisax oopses here too.... :(
[10:45] <ogra> fabbione: no ksymoops.....but i can send a dmesg, lsod, lspci as you like.....
[10:46] <ogra> +m
[10:46] <ogra> jdub :)
[10:46] <mdz> lamont_r: I swear that mcs build log wasn't there when I looked
[10:46] <lamont_r> mdz: heh
[10:46] <mdz> ogra: ksymoops is obsolete; the kernel decodes the stack now
[10:47] <ogra> mdz: so where do i find something helpful then to send to fabio 
[10:49] <fabbione> lamont_r: thanks.. i really really needed another RCS for the kernel :-)
[10:49] <fabbione> ogra: ok.. i will check the mISDN site again.. but last time there were no updates...
[10:50] <ogra> fabbione: anything i can do to help ?
[10:50] <fabbione> ogra: you will help me testing :-)
[10:50] <ogra> yep :)
[10:50] <mvo_> ogra: isdn stuff?
[10:50] <fabbione> i don't have such card.. so i will need to build some stuff and test
[10:50] <ogra> mvo_: ahh, great, youre back :)
[10:51] <mvo_> yes, in time for the meeting :)
[10:51] <lamont_r> moof
[10:51] <ogra> it oopses with both pci cards i have here....in one or two weeks i probably can get a teles and a sedlbauer too
[10:52] <fabbione> ogra: afaics there is only one error in the module init code
[10:52] <fabbione> lamont_r: that patch is BIG
[10:53] <lamont_r> fabbione: yeah.
[10:53] <fabbione> and it touches some bits of common code...
[10:53] <pitti> Hi guys
[10:53] <seb128> lamont: could you kick totem build ?
[10:53] <lamont_r> about 20k or so of it is from the last week or two
[10:53] <lamont_r> seb128: kick how?  is it d-w?
[10:53] <fabbione> it's 172K .gz
[10:54] <lamont_r> mdz: that log file arrived at 02:26 london time
[10:54] <seb128> lamont_r: dunno, it FTBFSed this morning
[10:54] <seb128> lamont_r: libnautilus-burn-dev was missing a dep on libhal-dev, I've fixed that
[10:55] <seb128> now I need a totem kick :p
[10:55] <mdz> Hoary devel meeting in #u-m in 5 minutes
[10:57] <Kamion> oh, arse, need food
[10:57] <lamont_r> ah, so kick == retry.  got it
[10:57] <Kamion> can you cope with me being ~10 minutes late?
[10:58] <mdz> Kamion: as long as you bring some food for the rest of us ;-)
[10:58] <Kamion> ah, the old dcc sendmatter
[10:59] <fabbione> lamont_r: some bits of this patch will need rework.
[10:59] <fabbione> i can't apply it as is for all arches
[10:59] <lamont_r> fabbione: no surprise there... :-(
[11:00] <fabbione> even if dpatch supports patching per arch...
[11:00] <fabbione> i need to think about it
[11:00] <fabbione> --- LINUS_2_6_10/mm/shmem.c     2004-12-24 16:36:00.000000000 -0700
[11:00] <fabbione> +++ CVS2_6_10_PA5/mm/shmem.c    2004-12-04 00:03:09.000000000 -0700
[11:00] <fabbione> -static void shmem_truncate(struct inode *inode)
[11:00] <fabbione> +/* static gcc-3.3 OPD bug - GGG */ void shmem_truncate(struct inode *inode)
[11:00] <mdz> meeting starting
[11:00] <fabbione> stuff like that...
[11:08] <Simira> seb128: I have some serious problems with Gnome (GDM, I think), and no clue about what causes it
[11:08] <seb128> like ? since when ?
[11:09] <Mithrandir> Simira: I doubt it's gdm, actually.  More like gnome-panel, nautilus and any other gnome components completely freezing?
[11:10] <Simira> seb128: I told you some time ago as well. Since middle of Dec., I think. When I log in, nothing happens (the login disappears, and I get only a blank blue screen), or else I get a desktop but no menus.
[11:10] <Simira> very irritating
[11:10] <Simira> I've tried logging in in failsafe mode and other (all session alternatives), but it's still the same
[11:10] <seb128> really weird
[11:11] <Simira> sometimes reboot works. Sometimes not.
[11:11] <Gaaruto> hi all
[11:11] <Simira> killing all user processes doesn't work
[11:11] <Mithrandir> ogra, seb128: I guess this is not meeting material; it will still have to go through NEW though.
[11:11] <Mithrandir> Simira: doesn't pkill -u simira work?  Used to, didn't it?
[11:11] <Mithrandir> or is that just when I'm looking? ;P
[11:12] <seb128> Mithrandir: http://lists.debian.org/debian-gtk-gnome/2005/01/msg00007.html
[11:12] <seb128> there is a link to the package
[11:12] <Simira> Mithrandir: no, it doesn't work, mostly. It has happened, yes.
[11:12] <Gaaruto> i would like to know when the debian installer will be available for ubuntu, and if that will be on hoary or an other ?
[11:12] <seb128> Mithrandir: probably just a matter to upload them ...
[11:13] <Mithrandir> seb128: yeah, I have that patch already.  I've been running with those packages since mataro.
[11:13] <seb128> oh ok
[11:13] <Mithrandir> Gaaruto: Ubuntu already uses the Debian installer.
[11:13] <Mithrandir> seb128: I'll just check that they still look fine and upload to hoary.
[11:13] <seb128> Mithrandir: feel free to close #3959 if you upload :)
[11:13] <seb128> thanks
[11:13] <Simira> seb128: I got a fairly heavy update today though (last two days), it might work now.
[11:14] <seb128> ok, let me know, but I don't have any really idea on the problem
[11:15] <Simira> seb128: I'll try make some more out of it if it still doesn't work. I know the feedback is hopeless, but I can't see anything that should cause it.
[11:16] <Kamion> what a strange question
[11:17] <Mithrandir> seb128: I've seen similar problems if dbus/hald is upgraded -- gnome needs to be slain before I can continue working.
[11:17] <seb128> still ?
[11:17] <seb128> I've turned the hal option to off in gnome-vfs 10 days ago
[11:18] <Mithrandir> ok, my upgrading has been spotty since then, since the DSL here is _sucky_, I'll tell you if I see it again
[11:18] <Keybuk> seb128: what did "the hal option" do?
[11:18] <seb128> ok, thanks
[11:18] <seb128> Keybuk: cool name and icons for the devices mainly
[11:18] <seb128> = not a lot according to the bugs going with it :p
[11:19] <Keybuk> ah, that explains why my cool name and icons vanished then
[11:20] <sid77> hi
[11:22] <Simira> Mithrandir: will you try to kill me if I run a little upgrade just now? Just a small one?
[11:23] <fabbione> Simira: i was just kidding before..
[11:23] <Mithrandir> Simira: what is "small"?
[11:24] <Mithrandir> Simira: I surely won't kill you, but I might come down and be a bit angry.  This line _SUCKS_. :/
[11:24] <fabbione> when Mithrandir offered to maintain thunderbird.. my first tought was.. Simira uses it ;)
[11:24] <Mithrandir> heh
[11:25] <Mithrandir> Simira: do you, atm?
[11:25] <Simira> fabbione: actually not. She still struggles with Evolution and sticks mostly to Outlook Express when things should work effective.
[11:25] <Simira> Mithrandir: nope
[11:25] <Simira> just some updates synaptic wanted that apt didn't, for some reawson
[11:25] <Simira> *updates*
[11:26] <Simira> Mithrandir: another three mins ok
[11:27] <Mithrandir> Simira: paaain
[11:27] <thom> lamont_r: LSB bugs heading your way
[11:28] <lamont_r> thom: thanks
[11:28] <lamont_r> much
[11:28] <thom> enjoy ;-)
[11:51] <jdub> Kamion: can't set up degraded raid1 arrays in warty installer?
[11:52] <Kamion> I'd be surprised
[11:52] <jdub> yeah, it really wants two devices
[12:05] <thom> 26 frickin' firefox bugs. blah
[12:07] <daniels> 26?!? luxury!