=== doko [doko@dsl-082-082-190-115.arcor-ip.net] has joined #ubuntu-devel [12:55] Kamion: you around? === ogra [~ogra@p508EBC96.dip.t-dialin.net] has joined #ubuntu-devel === mirak [~mirak@AAubervilliers-152-1-13-160.w82-121.abo.wanadoo.fr] has joined #ubuntu-devel [01:16] mdz: how's the live-cd cloop fun coming on? [01:18] robtaylor: I squashed the big bug in Mataro, and then more or less took a holiday since [01:18] amu has been doing some work on it during that time === jdodson [~jdodson@63-230-173-38.ptld.qwest.net] has joined #ubuntu-devel [01:31] gah, workrave is busted [01:32] though it hasn't changed in forever [01:45] jdub: who do i talk to about being mentored for "package maintainer" status. the wiki mentions that as a suggestion. [01:45] 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] jdodson: a good place to start is the debian new manitainer guide and fixing bugs in universe packages you like [01:46] jdub: ok [01:46] jdub: i volunteer on the ubuntu forums and wanted to help out as a maintainer. [01:47] jdub: thanks for the advice. [01:48] 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] i didn't run for election this year - i will write about that more at some stage. [01:49] jdub: thats cool, when they mentioned it on slashdot, i did a good search and found out you were working for ubuntu. [01:50] 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] 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] daniels: great, thanks === lamont ponders whether libatomic-ops should be set to i386 ia64 in PaS, or if it makes sense to work on porting it to ppc/amd64 [01:53] 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] mdz: oh, that's right [01:53] daniels: no === lamont has no root on halley [01:53] mdz: we'll have fglrx on amd64 soon enough, too [01:53] elmo_away: ping [01:55] libatomic-ops already has a patch in the bts for amd64 support... hrm. [02:04] mono friends.. mcs is still ftbfs [02:06] lamont: priority #6 or so [02:09] daniels: yeah - there's a build log for it now, for those who might care to loo, [02:09] k [02:09] lamont: cheers [02:15] lamont: so, with p.u.c/~lamont/daniels/, does xorg-6.8.1 contain the full build-tree? [02:15] i.e. can I just grab the files I need from there instead of grabbing the diff? [02:16] xorg-6.8.1 is the old one from ia64, IIRC [02:17] ahr, ta === lamont generates a diff [02:18] people.ubuntu.com/~lamont/daniels/xorg_6.8.1-1ubuntu8.5.diff [02:18] is only 44kb [02:19] and is a diff -urN vs 1ubuntu8 [02:19] ahr, ta === lamont needs to go buy a fan for his computer rack tonight === oxymor00n [sec@195-70-100-213.dyn.salzburg-online.at] has joined #ubuntu-devel [02:28] lamont: what happened with alsa-driver? [02:28] (and didn't this happen before?) [02:29] before was a 'just use debian' that I can't see how I would have asked for [02:30] this time, dunno - about to look at that [02:30] as well as 72 MB of diffs === AndyFitz [~andy@220-245-97-227-qld-pppoe.tpgi.com.au] has joined #ubuntu-devel [02:32] mdz: btw, #2542 may never be solved === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-devel [02:32] mdz: unfortunately with most cards, you need to probe for their amount of video ram [02:32] mdz: istr one ranging between 16 and 128MB with a single PCI ID [02:35] has anyone seen thom around? [02:36] daniels: probing for it would be no worse than what xresprobe already does [02:37] mdz: dude [02:37] mdz: probing for video RAM involves doing what the drivers do [02:37] open()ing /dev/mem and poking at random bits [02:39] 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] mdz: the problem isn't with newer cards, because they typically have one PCI ID per configuration, which includes video RAM [02:41] 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] daniels: that sounds a bit over-complex to me, I can't just tell it to ignore that binary file? [02:42] Riddell: well, if you managed to do that, diff would ignore that binary file, and your changes would be lost [02:42] how did you change it, anyway? [02:43] daniels: it's the konqueror java vulnerability, the updated kjava.jar file is from the "patch" (just a tarball) they made [02:44] Riddell: unzip the new jar and the old jar and compare the contentses [02:44] daniels: dude, xresprobe does this already [02:44] it lets the X server do its driver-specific magic and munges the log file [02:44] seems like the same could be done for video memory size [02:44] 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] 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] mdz: does it allow for detection of high refresh rates on capable devices? [02:45] Riddell: right, so you need to uuencode it [02:45] daniels: it would be nicer if the server itself would fall back more sanely [02:45] sivang: that's already solved in xorg [02:45] daniels: I never managed to get my display to do 100hz... [02:45] mdz: well, it's trying its best to obey our command, to be fair [02:45] sivang: then you probably need to enter your sync ranges manually, because your monitor is lying [02:45] daniels: but we have to be way too specific in what we ask of it, IMHO [02:46] sivang: either that, or lower your resolution a bit [02:46] mdz: oh, agreed, the current infrastructure is total crap [02:46] 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] calc: https://bugzilla.ubuntu.com/show_bug.cgi?id=4597 === lamont pukes at the alsa-driver upload [03:13] lamont: that bad? :) [03:14] sivang: I have NFC what drugs I was on when I did the upload [03:25] mdz: alsa-driver_1.0.7-2ubuntu2 uploaded, mutes on stop [03:25] lamont: does it also resurrect the patches which vanished? [03:25] yes [03:25] great, thanks [03:25] lamont: was that an overlooked _dropped.patch or something? [03:25] and kills the regressions that were in the patch === lamont needs to not work on alsa when he's being distracted by a BOF [03:26] Next week on CSI: "Grissom! About time you got here. Looks like drug addled youths have been on an NMUing spree again." [03:26] I was wondering if we should have a BIG RED FLASHING thing there if there are dropped patches [03:26] aj: lol [03:27] 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] mdz: I have NFC where the source for -2ubuntu1 came from [03:28] 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] we may not have correctly cleaned up the mess from the previous borked merge. [03:29] all of the ubuntu uploads after 1.0.5a-1ubuntu6 say 'resync with debian' [03:30] if one of those has something in it that is more than a resync, then I just dropped it.. :-( [03:30] lamont: perhaps we should ask Keybuk to keep old MOM output around for cases like this [03:31] mdz: that could help.. I have been making use of the ubuntu and debian morgues [03:31] lamont: drop him an email, if you would [03:32] what are the major changes for it? [03:32] from the changelog, it seems like they're mostly 'unmute setting X' [03:33] crimsun: yeah, it's mostly just some changes to the init script [03:33] crimsun: that and changing the output format [03:33] (of the init script) [03:33] yep, from 1.0.5a-1ubuntu1, gotcha. [03:33] I think the bugfix portions have been merged into Debian [03:35] the modprobe stuff from 1.0.5a-1ubuntu5? [03:37] mail sent to scott, cc mdz [03:37] daniels: whycome my right Alt key stopped being Alt_R recently? [03:37] lamont: thanks [03:37] crimsun: yes === lamont screams, bangs head on table [03:37] mdz: I see a || true, so yes. [03:39] crimsun: current diff is only to control (depends), alsa-base.postinst, and alsa-base.alsa.init [03:39] and changelog, of course [03:40] mdz: erk, apologies. I was looking at the ubuntu diff. [03:40] lamont: right. [03:42] and actually, I think we might be able to lose the postinst piece [03:43] I fail to see the advantage to simply modprobing some modules during postinst... [03:43] they don't survive past the next reboot that way... === lamont drops that patch [03:47] also, the "mixer" in "pcm mixer seq" was redundant, because modprobing snd-pcm-oss pulls in snd-mixer-oss [03:47] well, /etc/modprobe.d/alsa-base does it now. [03:48] mdz: what is it now? === thully [~thully@151.144.199.172] has joined #ubuntu-devel [04:05] 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] daniels: ISO_Level3_Shift [04:06] mdz: ?!? [04:06] thully: that creates a difficult situation for us if we can't reproduce the bug [04:06] thully: if we can, then it's no problem [04:06] mdz: looks like you have ralt:lv3_shift somewhere [04:06] Most of these bugs were reported some time ago [04:06] mdz: what's your gnome keyboard setup look like? anything bong in xkboptions/xkbvariant/whatever? [04:07] daniels: like hell I do :-P [04:07] Option "XkbRules" "xfree86" [04:07] Option "XkbModel" "pc104" [04:07] Option "XkbLayout" "dvorak" [04:07] i blame dvorak [04:07] no xkboptions, no xkbvariant [04:07] it worked fine until December sometime [04:08] now I'm back in xmodmap hell [04:08] 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] could be some weird thing in the GNOEM applet [04:08] ugh [04:08] no-one deserves xmodmap [04:09] hey, -novtswitch comes in handy [04:09] Is there any way to just remove my bugzilla account, or just remove myself from the bugs? [04:09] mdz: well, you'll still need to switch later [04:09] actually, there was no real point to -novtswitch here [04:09] but I use it a lot to test [04:09] yeah there was [04:09] I don't want it to switch, because I want to start the xterm first [04:09] sudo Xorg :1 -ac && xterm -display :1.0 && DISPLAY=:1.0 xev [04:09] and need to wait for the server to start up [04:10] ah yeah [04:10] if you do it with &, xterm usually waits [04:10] this is one thing the current server doesn't do horrifically badly :P === lamont ponders 4674 - what's the best way to get the locale, and is it even set on initial install before libpaper1.config runs? [04:10] KeyPress event, serial 23, synthetic NO, window 0x400001, [04:10] root 0x40, subw 0x0, time 96512, (44,118), root:(46,120), [04:10] state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, [04:10] mdz: that's on :1.0? [04:11] daniels: correct [04:11] so, doesn't look like GNOME's fault [04:11] lamont: yes, it should be set when libpaper1.config runs [04:11] you might need to source /etc/environment, not sure [04:11] Kamion would know [04:13] mdz: hm, so it does === lamont will pester Kamion when he sees him next === daniels attempts to remember the Dvorak sequence for 'xev'. [04:14] something like bdn. [04:14] ./symbols/dvorak: key { [ Mode_switch, Multi_key ] }; [04:14] that's wrong, too, but an entirely different keysym [04:15] daniels: how can I ask xkb "wtf are you using"? [04:15] (bd.) [04:15] mdz: setxkbmap -print, IIRC [04:15] xkb_keymap { [04:15] xkb_keycodes { include "xfree86+aliases(qwerty)" }; [04:15] xkb_types { include "complete" }; [04:15] xkb_compat { include "complete" }; [04:15] xkb_symbols { include "pc/pc(pc104)+pc/dvorak" }; [04:15] xkb_geometry { include "pc(pc104)" }; [04:15] }; [04:15] xkb_symbols { include "pc/pc(pc104)+pc/us+ctrl(nocaps)+compose(ralt)" }; [04:16] yeah, so Mode_switch is what's forcing it into l3 in this case [04:16] daniels: bd. [04:16] mdz: bd? [04:16] daniels: 'b', 'd', '.' is xev on dvorak [04:16] us->dvorak [04:16] mdz: oh, right, ta [04:17] dvorak should have the same alt key definitions as us, IMO [04:17] mdz: hm, as far as I can tell, it's Always Been That Way [04:17] agreed [04:17] there seems to be a bunch of stuff in symbols/dvorak that has no business there [04:17] it should really only modify alpha and punctuation keys === lamont tries to figure out which package creates /etc/kernel-img.conf [04:18] anad yet it has entries for Escape, shift and crap in there [04:18] and [04:18] the right way for it to work is for dvorak to be a variant of a real keyboard layout [04:19] but xkb makes my eyes hurt [04:19] mdz: afaict, the canonical dvorak xkb definition has always done this [04:19] ! This file was automatically generated on Wed Nov 2 10:29:07 1994 [04:19] ! by Ryszard Mikke with XKeyCaps 2.11; [04:19] ! Copyright 1991-1994 Jamie Zawinski . [04:19] [...] [04:20] daniels: I swear this behaviour changed in the past 30 days [04:20] ! The "Alt" key generates Mode_switch [04:20] a bit longer than that, potentially [04:20] my ~/.Xmodmap.old has keycode 113 = Alt_R [04:20] but I renamed that sometime around when I upgraded this box to pre-Warty [04:21] because it seemed to be unfucked [04:21] daniels@catsby:~/tmp/dvoraksucks/meh/etc/X11/xkb/symbols% grep Mode_switch dvorak [04:21] zsh: exit 1 grep Mode_switch dvorak [04:21] hm. [04:22] ah, hold on [04:22] what's that tree? [04:22] does it work if you do 'dvorak(basic)' [04:22] oh, sorry, ECONTEXT; that was xfree86 [04:22] setxkbmap 'dvorak(basic)'? [04:22] don't bother? [04:22] setxkbmap -symbols 'dvorak(basic)' [04:22] or change it in xorg.conf and spawn a new server [04:25] daniels: dvorak(basic) gives me no alt keys, no windows keys, and one control key [04:25] (NoSymbol) [04:26] arse. [04:26] what I want to say is, I have a pc104 keyboard with a us layout, plus these bits changed for dvorak [04:26] mdz: try with us(pc104)+dvorak(basic) [04:27] omg [04:27] you are my hero [04:27] seems perfect [04:27] i sure am [04:27] do I get a pay rise? :) [04:28] better [04:28] you get a cooper's when I come to .au [04:28] ooo, shiny [04:28] mdz: what's a cooper? :) [04:28] supposedly it's a decent beer [04:28] mdz: american ? :) [04:29] australian [04:30] mdz: eh [04:30] mdz: why, supposedly? [04:30] mdz: i have five in my fridge; they are my preferred drop [04:30] mdz: (as long as it's the pale ale -- green label; the sparkling, which is red, isn't that great) [04:30] sivang: because I'm taking their word for it [04:30] having not tried it myself [04:31] it is very, very decent [04:31] hehe [04:31] daniels: was it monty python's that had a joke about non english/au beer? ;-) [04:31] is "decent beer" syntactically similar to "edible tripe"? [04:32] sivang: no, that was US beer [04:32] it's like making love on a canoe === lamont could never stand beer.... [04:32] daniels: in the canoe would be safer... [04:32] daniels: I was trying to be gentle :) [04:33] lamont: it's very close to water [04:33] daniels: ah, ok [04:33] lamont: http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus [04:33] (actually 'fucking close to water', but this is a family channel ;) [04:33] daniels: :) [04:34] jdub: ubuntu families [04:34] on freenode? [04:35] mdz: no dude, grove street families [04:38] why drink only "decent" beer? [04:38] here in Belgium we have lots of fantastic beers :-) [04:45] ENOSEB [04:46] 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] what does the package for Ubuntu CDs look like? [04:46] and does it come from Switzerland? [04:47] thully: I think you can tell bz to never send you mail - which isn't quite the same thing, but close [04:49] 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] thully: with a six-month release cycle, it's pointless [04:50] thully: what daniels said [04:51] 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.... :-) === sensebend [~sensebend@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-devel [04:51] but that's really getting silly [04:51] what's the point, GNOME only releases every 6 months [04:51] davyd_: there's the rest of sid, too [04:52] s/sid/ubuntu-main/ [04:52] and we already spend half of that in freeze, I wouldn't want to spend any more [04:52] davyd_: and that's why I said 3x the people for 2x the releases/year. [04:52] it's well beyond the point of diminishing returns [04:53] I am a big fan of 6 month releases [04:53] but I wish feature freeze wasn't on Monday [04:53] does that mean Thunderbird will be stuck at 0.9 if 1.0 isn't in by Mon? [04:54] (in hoary) [04:54] davyd_: my box-o-cds says 'NL BREDA' for the last line of sender address. [04:55] which fits with my recollection that they ship from the netherlands [04:55] thully: GNOME feature freeze, not Ubuntu [04:55] davyd_: feature freeze isn't monday. [04:56] lamont: I don't have the box yet, I just got email from work saying mail had arrived for me [04:56] lamont: it is for GNOME [04:56] davyd_: ah. somehow that doesn't surprise me. [04:57] lamont: what does that mean? [04:57] thully: after tomorrow they're not allowed to add new features to mozilla-thunderbird if they want to ship it in march [04:57] they're supposed to be fixing the bugs after taht date. [04:57] davyd_: ubuntu's upstream version freeze is this week as well. [04:57] lamont: yeah, probably because it syncs with GNOME [04:58] given that the ubuntu release model is somewhat patterened off of gnome, there is little surprise in that [04:58] guess who designed them both ;) [04:58] thully: since moz-thunderbird is coming through gnome (yes?), it has until march to be ready from hoary's perspective [04:59] there are reasons they are similar [04:59] 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] so - does anyone know to what this means to thunderbird 1.0 in hoary? [04:59] sivang: what's wrong with the applets? [04:59] It would be a shame if Hoary shipped with Thunderbird 0.9 [04:59] thully: it means that thunderbird needs to meet the gnome schedule, assuming that it comes from there... === lamont ponders what thunderbird is... [04:59] thully: unless we explicitly accept an update, it will stay at whatever version is released at UVF time [05:00] lamont: thunderbird is mozilla mail stuff, not gnome [05:00] jdub: so it doesn't come through gnome. check. [05:00] 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] Thunderbird 1.0 has been out for several weeks - but isn't in debian unstable yet [05:01] thully: is it even in debian experimental? [05:01] jdub: regarding country teams, what about the ubuntu-il mailing list? :) [05:01] 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] sivang: haven't done it yet [05:02] lamont: don't know about that [05:02] thully: nope/ [05:03] one question: Are the OpenOffice.org GNOME integration packages going to be included by default in Hoary? [05:03] 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] thully: with gnome being the notable exception to that at this time. [05:04] 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] thully: they've been proposed for inclusion, yes. [05:04] As i've installed from Array 2 and by default, these aren't included - making an extremely ugly default openoffice configuration [05:04] jdub: but will I get my ^*(_^&(B mouse focus fix in metacity, that's my question... [05:05] Does laptop suspend support look to be on track? [05:05] lamont: more focus work still happening [05:05] jdub: but will it include strict-pointer-focus, that's the real question [05:07] jdub: (really not trying to troll, mind you) === sensebend [~sensebend@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-devel === thully [~thully@151.144.199.172] has left #ubuntu-devel ["Leaving"] === thully [~thully@151.144.199.172] has joined #ubuntu-devel [05:16] anyone know what version of wxPython will be in hoary? [05:18] 2.5.x will be in hoary/universe [05:18] thully: yes [05:18] currently that's 2.5.3.2 [05:19] will it be configurable (suspend, that is) [05:19] thully: maybe [05:21] 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] then you just change the symlinks to change the settings [05:25] okay, that's good, because more and more programs & libraries that use wxPython need 2.5.x :) [05:26] thully: a gnome applet will not be done in the time until hoary, unless someone writes it [05:27] thully: and you do realise that /etc/acpi/*.sh are conffiles, so they won't get overwritten if you modify them? [05:30] 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] well, you can do that too. and they won't get changed. but the effect is the same. [05:31] so, /etc/acpi/events/sleep calls /etc/acpi/actions/sleep.sh, which calle /etc/acpi/sleep.sh [05:31] correction /etc/acpi/actions/sleep.sh points to /etc/acpi/sleep.sj [05:31] sj=sh [05:32] Why doesn't this work? I've done this and it seems to work for changing suspend actions [05:34] what do you mean, 'why doesn't this work'? [05:35] I'm a bit confused at what you were saying about conffiles - can you elaborate? [05:38] so, everything in /etc is registered as a configuration file [05:38] if you change it, your changes will be respected, and you won't lose them every update [05:38] so you can change /etc/acpi/lid.sh yourself if you want [05:39] yes - I know - doing it the symlink way just makes it a bit cleaner and easier [05:39] after a fashion [05:39] I was just a little confused when you were talking about "conffile" [05:41] and what exactly you meant [05:41] 'conffile' is the name of the class of files that dpkg considers to be user-modifiable and will not fuck with === sensebend [~sensebend@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-devel [05:42] Will Hoary be in a more stable state after UpstreamVersionFreeze? [05:42] thully: churn will certainly reduce [05:42] thully: stable meaning it won't change much, or do you mean robust? [05:43] both, to an extent [05:43] it will stop changing to a large extent (gnome will continue to change) [05:43] because everything stops changing, bugs are more easily fixed, so it will become more robust [05:45] Do you think it will be better than debian unstable in the stable-as-in-robust department - how about testing? [05:45] dude [05:45] yes. It has a 3 month frozen period before release. [05:45] thully: instantly? of course not [05:45] it's going to be released in march as a preview and april as final supported [05:46] hmm, march. [05:46] OK [05:46] so if it's not releaseable by then, we will have serious problems [05:47] daniels: will suspend be enabled by default? Will the user be able to disable suspend? === jdub begins the hoary cd download treadmill... [06:01] jdub: new arrays? [06:03] I really wish our stupid web directory listing would show the mtime of files... [06:03] pulling a daily [06:03] for rsyncage === lamont likes that idea, although is ubuntu mirror is still 75 files behind [06:25] mdz: for giggles, 287614 should be imported, and applies to hoary (and probably warty...) [06:26] and is already imported. [06:26] sigh. [06:33] morning [06:34] morning fabbione === lamont decides to go to bed and finish fixing gtkmm2.0 tomorrow morning [06:36] ehhe [06:36] night lamont [06:36] 45 minutes to get to the failure... kinda boring [06:36] and the kids are back in school tomorrow, so I have to get up early again. [06:36] welcome back to the real life ;) [06:36] heh [06:37] in addition to being an RC bug, gtkmm2.0 is holding up the majority of 111 d-w packages in stage 1 [06:38] actually... gtk2.0-bin or something like that is an issue for sparc too [06:38] it doesn't install [06:38] gtkmm2.0 needs net access in order to build. [06:38] argh [06:39] funny thing is that debian/rules has a "fix" for it, just not in the right place. [06:39] lol [06:39] warty bug #5173, debian 287614 [06:40] 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] hmmm [06:40] hrm... maybe throttling the rsync of the iso to 8kbps was a bad plan. [06:40] 124 hours eta [06:40] how could you build gnome-doc-utils? [06:40] it fails here [06:40] http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd:166: parser error : XML conditional section not closed [06:41] built fine on my machine (which has no net access) [06:42] although if it's actually trying to go to www.oasis-open.org, that's an RC bug in debian. [06:42] hmm i am getting errors installing Setting up libgtk2.0-bin (2.6.0-0ubuntu1) ... [06:42] no i don't think it is [06:42] there's a 0ubuntu2 [06:43] of libgtk2.0 ? [06:43] don't think it's trying, or don't think it's a bug? [06:43] gnome-docutils [06:43] even if it was trying my machine has net access [06:43] yeah that one fails with that error [06:43] yes, but if the doc is bad on the website, and it's failing over gracefully with no net access... [06:44]