[12:01] <mdz> enrico: please don't wait any further, we are under release pressure
[12:01] <enrico> thom: nothing too bad, I'll probably ask you to have a look at them just to see if we got the categories right.  Plus, the docs don't actually show up in Yelp's TOC
[12:01] <mdz> it is much easier to make progress once it is in the archive
[12:01] <enrico> mdz: ok, I can upload now.  Is there a wiki page with the procedure?  (like, a dput snippet?)
[12:01] <thom> enrico: you're runnign scrollkeeper-update in postinst?
[12:01] <mdz> enrico: yes, on DeveloperResources
[12:01] <enrico> thom: I'm calling dh_scrollkeeper and hoping it does the right thing
[12:02] <enrico> mdz: thanks!
[12:03] <Kamion> mdz: do I remember correctly that you asked Mithrandir about the utf8-migration-tool build failure?
[12:03] <Kamion> mdz: it's trivial to fix, I have a patch
[12:03] <seb128> sivang: better with the gnome version ?
[12:03] <seb128> sivang: the standard one should display something about gnome components
[12:03] <mdz> Kamion: yes, I did.  is he away or something?  he has not been around much
[12:03] <mdz> Kamion: feel free to fix it
[12:06] <sivang> seb128: une minute, checking with a fresh source
[12:06] <enrico> should I use ubuntu in the version number even if the package is not in Debian?
[12:08] <mdz> enrico: no
[12:08] <mdz> I updated the instructions on the wiki to reflect that, about 10 seconds after I mentioned the page
[12:09] <enrico> mdz: :)
[12:09] <enrico> mdz: uploading now
[12:09] <mdz> enrico: if you give me the names of the binary packages, I'll add them to the supported seed
[12:10] <enrico> mdz: ubuntu-docs, ubuntu-quickguide, ubuntu-faqguide
[12:10] <enrico> ubuntu-docs contains the about ubuntu and release notes
[12:11] <enrico> ubuntu-quickguide is cool and reviewed for Hoary
[12:11] <sivang> seb128: Merci beaucoup! That was it! How can I be aware of this nex time?
[12:11] <enrico> I'm waiting for plovs to tell us something about the up-to-dateness of the faqguide (bugzilla #6789)
[12:11] <thom> mdz: do you have any problem with removing apm from everyting that's not i386?
[12:11] <seb128> dunno, the gtk version should display some messages about it
[12:11] <sivang> seb128: well, it didn't. what are the differences?
[12:12] <mdz> thom: does apm not work at all on amd64?
[12:12] <seb128> sivang: you are asking the difference between gtk and gnome ?
[12:12] <mdz> or is it irrelevant because amd64 systems are all new enough to use ACPI?
[12:12] <enrico> the quickguide is like 95%  finished and reviewed
[12:12] <sivang> seb128: hrm I'll msg you for clarity
[12:12] <seb128> sivang: the gtk version has the gtk widgets, the gnome the gtk and gnome ones
[12:12] <thom> mdz: everything i've seen suggests the latter
[12:12] <sivang> seb128: ah ok :)
[12:12] <mdz> thom: go for it
[12:12] <enrico> Worst case, we release with ubuntu-docs and ubuntu-quickguide only
[12:13] <sivang> seb128: thanks again, really.
[12:13] <seb128> np
[12:13] <mdz> thom: hmm, though
[12:13] <mdz> thom: has ubuntu-meta been fixed to recognize that syntax?
[12:13] <Kamion> mdz: I think I did so
[12:14] <enrico> mdz: uploaded.
[12:14] <thom> well, that's just [i386]  right; certainly there are other examples but i'll suck it and see
[12:14] <Kamion> ubuntu-meta (0.18) hoary; urgency=low
[12:14] <Kamion>   * Improve update to handle architecture-specific seed entries.
[12:14] <mdz> yep, looks like you did
[12:15] <mdz> thom: should be fine, then
[12:15] <Kamion> mdz: utf8-migration-tool> dunno. fixed.
[12:16] <thom>  > > > Umm, I dont think so.  apm does not exist on amd64, cannot exist and
[12:16] <thom> > > > > never will exist.  Please back this out.
[12:16] <thom> someone seems pretty sure
[12:19] <thom> (interestingly, inotify never caused me any problems on amd64)
[12:20] <schweeb> that gnome-app-installer thing is a pretty neat idea guys
[12:20] <schweeb> I commend thee
[12:27] <daniels> mdz: yeah, -0.2 has -x in .config.in and .postinst.in; -1 doesn't
[12:28] <mdz> daniels: -1 should be good to upload, then.  my upgrades were fine
[12:30] <daniels> mdz: ok
[12:33] <daniels> mdz: uploaded, I'm gone for about 6 hours now
[12:35] <pitti> night everybody
[12:36] <sivang> pitti: night!
[12:38] <thom> Kamion: desktop/powerpc: Skipping package apmd (not for this architecture) (you rock, as usual)
[12:38] <trulux>  blt-common fam gnome gnome-core-devel gnome-cpufreq-applet gnome-desktop-environment gnome-devel libbonoboui2-dev
[12:38] <trulux>   libeel2-dev libfam0c102 libgnome-desktop-dev libgnome2-dev libgnomeui-dev libgnomevfs2-dev libgtop2-4 libnautilus2-2
[12:39] <trulux>   libnautilus2-dev libopenh323-1.13.2 libpanel-applet2-dev libpt-1.6.3 libsoup2.0-dev libxslt1-dev nautilus-media
[12:39] <trulux>   python-fixedpoint python-gtkextra python-mpz trashapplet
[12:39] <trulux> being removed
[12:39] <trulux> in dist-upgrade to Hoary
[12:39] <trulux> this is suspicious
[12:39] <trulux> also, libgtksourceview couldn't get installed  because it was trying to overwrite a file from other pkg
[12:39] <trulux> anyone knows about this?
[12:40] <kent> schweeb, i was thinking the opposite earlier today. gnome-app-installar is in Program->system tools  and does nothing that synaptic doesn't, and synaptic is in another place in the menu. It seems weird to have a small synaptic substitute in another place in the menu. Its just confusing to have two places to install programs from.
[12:41] <mvo> kent: we got a lot of report that people find synaptic confusing. all this libraries and strange applications all over the place.
[12:43] <schweeb> kent: what mvo said.  gnome-app-installer provides users with a view of how GNOME would think of the apps, rather than how apt sorts the apps.  plus it doesn't show you all the bazillion deps that most people don't need to know about to install an app
[12:44] <schweeb> it's kinda similar to windows' add/remove programs thinger... but more useful, and with apt tied in
[12:48] <tseng> anyone working on packaging clearlooks?
[12:48] <jdub> tseng: it's already in universe
[12:48] <tseng> jdub: man, you rock.
[12:48] <jdub> tseng: i uploaded 0.3 the other day
[12:48] <jdub> hrm
[12:48] <Kamion> thom: glad to hear it ;)
[12:48] <jdub> but it is not
[12:48] <jdub> elmo: ping
[12:48] <tseng> maybe in NEW
[12:48] <Kamion> thom: at the moment I mostly just sway, hard training this week
[12:48] <jdub> maybe elmo hasn't processed NEW yet
[12:49] <thom> Kamion: heh, learning how to do high kicks on slippery floors?
[12:50] <Kamion> fortunately the dojo floor is quite non-slippery
[12:50] <thom> but how will you then learn to cope with hotels?
[12:50] <thom> your life may depend on it!
[12:50] <Kamion> better balance :-)
[12:51] <thom> *g*
[12:54] <thom> seb128: btw, metacity changing windows when something pops up is really freaking weird
[12:55] <lamont> mdz: you want me to fix the -x in the config and then upload that?
[12:55] <mdz> lamont: daniels already did
[12:55] <seb128> thom: "changing windows" ?
[12:55] <thom> seb128: desktops, i mean
[12:55] <lamont> woot
[12:55] <mdz> lamont: do you have some convenient way that you can be notified when kdelibs has been built?  once it's done, kdepim needs to be retried
[12:55] <thom> if something becomes active on another desktop
[12:56] <seb128> thom: is that new with today's upload ?
[12:56] <lamont> mdz: kinda sorta
[12:56] <mdz> lamont: can you do a manual dep-wait or something?
[12:56] <lamont> I'll kick it
[12:56] <lamont> yeah - manual dep is what it'll get
[12:56] <thom> seb128:     - when receiving a _NET_ACTIVE_WINDOW message, switch to the desktop
[12:56] <thom>       where the window is located before activating instead of moving the
[12:56] <thom>       window to the current desktop.
[12:56] <thom> in .21
[12:56] <seb128> oh
[12:56] <seb128> when does that happen ?
[12:56] <seb128> I've not noticed :)
[12:57] <mdz> Kamion: how much work remains on your end to build Kubuntu CDs, once all of the packages are in main (should happen tomorrow)
[12:57] <thom> seb128: open a Netwrok Servers window, change desktop, open it again
[12:58] <lamont> seb128: bug-buddy ftbfs
[12:58] <seb128> lamont: k, thanks
[12:58] <lamont> pitti: curl same thing
[12:59] <seb128> thom: network server like in network:/// ?
[12:59] <mdz> pitti isn't here
[12:59] <thom> seb128: Places/Network Server
[12:59] <seb128> right
[01:00] <seb128> doesn't change the desktop here
[01:00] <thom> does here
[01:00] <thom> it's totally freaky
[01:00] <thom> anyway, sleep
[01:02] <lamont> mdz: depwaiterd
[01:02] <seb128> 'night thom
[01:03] <jdub> mdz: (all of kde is going in main, or just libs and friends?)
[01:03] <mjg59> Anyone here on PPC?
[01:04] <mdz> jdub: everything used in kubuntu
[01:04] <mdz> lamont-away: thanks
[01:05] <jdub> mdz: hrm.
[01:06] <mdz> jdub: which has already been ANDed with a security/supportability review conducted by the Kubuntu team, Martin Pitt, myself and others from ubuntu-devel over the past few weeks
[01:06] <jbailey> mjg59: I am.
[01:06] <tritium> mjg59, I have a PPC I can ssh into if you need...
[01:08] <mdz> amu, Riddell, haggai: will Kubuntu use polypaudio?
[01:09] <jdub> kubuntu has to use arts atm
[01:10] <Kamion> mdz: basically a matter of checking over all uses of $DIST and replacing some of them with $PROJECT-$DIST, I think
[01:11] <mdz> Kamion: does it make sense at all for kubuntu to have a supported seed at this point?
[01:11] <seb128> jdub: you big freak, stop flooding my log files with audio stuff
[01:12] <jdub> seb128: ;)
[01:12] <seb128> :)
[01:12] <mjg59> jbailey: Running ubuntu?
[01:12] <Kamion> mdz: they might want some stuff in supported that isn't there already from Ubuntu, but I certainly don't think it makes any sense for them to duplicate our supported seed
[01:12] <jbailey> mjg59: Yeah.  It's my primary box.  Pegasos2.
[01:12] <Kamion> s/in supported/in main/
[01:13] <tritium> Does anybody have a multi-binary python package that uses cdbs?  If so, I'd like to see how you setup your debian/rules file.
[01:13] <mdz> Kamion: right, at this point, anything they want in main should be added to desktop, live or ship
[01:13] <mjg59> jbailey: Hoary?
[01:13] <jbailey> mjg59: Yes, dear.
[01:13] <mjg59> And if so, latest kernel?
[01:13] <mdz> Kamion: I suppose germinate would get unhappy if I just deleted supported from the kubuntu archive, though, yes?
[01:13] <Kamion> mdz: correct. I haven't made the seed structure distro/suite-specific yet.
[01:13] <mjg59> jbailey: Any chance that you could test suspend-to-disk? :)
[01:14] <jbailey> mjg59: ii  linux-image-2. 2.6.10-24      Linux kernel image for version 2.6.10 on Pow
[01:14] <Kamion> (similarly I suspect current germinate won't work too well with warty seeds, oops)
[01:14] <tseng> mjg59: i tested it via the gnome logout screen
[01:14] <tseng> mjg59: i get some hd activity, then a blank screen
[01:14] <tseng> power never goes to off or standby
[01:14] <mjg59> jbailey: Yeah, that one should have it
[01:15] <jbailey> mjg59: I've never tried it.  Lemme save everything. =)
[01:15] <mjg59> tseng: Could you disable USE_DPMS in /etc/default/acpi-support ?
[01:15] <tseng> mjg59: sure
[01:15] <mjg59> jbailey: Heh. Yes, you probably want to sync as well
[01:15] <mjg59> tseng: This was on x86, right?
[01:15] <tseng> yeah
[01:15] <mdz> Kamion: currently, kubuntu has a supported seed which doesn't make much sense for kubuntu-in-ubuntu-main (it removes the gnome stuff and adds kde stuff)
[01:15] <seb128> 'night
[01:15] <mjg59> jbailey: You'll need to have RESUME set in your initrd
[01:15] <tseng> i edieted acpi-support in the past, should i purge and reinstall?
[01:16] <schweeb> tseng: what laptop you got?
[01:16] <tseng> dell 600m
[01:16] <schweeb> tseng: I'll be workin on gettin my i8200 workin later
[01:16] <tseng> trying again, brb
[01:16] <amu> mdz: no, the kdeguys told me at weekend it will come with kde 4
[01:17] <jbailey> mjg59: Yeah, the auto-detection of the resume is still on my TODO list.  Although I did have the evil idea of instead of auto detecting it at install time, that it might be fun to autodetect the swap partition at bootup time.
[01:17] <jbailey> mjg59: Install time is probably better for Hoary.
[01:17] <mdz> amu: ok, I was just merging the seed changes for kubuntu
[01:17] <mjg59> jbailey: Yeah
[01:17] <mjg59> tseng: Might be an idea, yeah
[01:18] <jbailey> Never thought the first time I did suspend-to-disk would be on a desktop machine. =)
[01:18] <Kamion> mdz: *nod*
[01:19] <amu> mdz: it will be gstreamer in feature
[01:19] <tseng> mjg59: yeah I believe you are right.
[01:19] <sivang> jbailey: it's working on a desktop machine? wooha I need try this here with my -smp kernel :)
[01:19] <jbailey> mjg59: So for now, do I just poke the major:minor into /sys/power/resume ?
[01:19] <tseng> mjg59: i think i was just not waiting long enough, it seems to take a few minutes to completely shut down
[01:19] <jbailey> sivang: I have not yet tested it.
[01:20] <sivang> jbailey: ah
[01:20] <tseng> mjg59: hard to judge if something is happening when the screen is off. thanks for the tip
[01:20] <mjg59> jbailey: Yeah, but make sure that the initrd has it set as well, otherwise it won't resume
[01:22] <schweeb> mjg59: couldn't you also set it on the kernel command line?
[01:23] <mjg59> schweeb: Yeah, but that's a pain on the pegasos (well, on the pegasos I, at least)
[01:24] <schweeb> ah
[01:25] <lamont_r> moof
[01:26] <jbailey> mjg59: Appears to work from a text console, trying from X.
[01:27] <Kamion> lamont_r: when's the next kernel upload planned?
[01:28] <Kamion> lamont_r: was kinda wondering if I could squish nfs-modules udebs into it ...
[01:28] <jbailey> mjg59: Works just ducky from X, too.
[01:29] <lamont_r> Kamion: I think it's planned for thursday, give or take
[01:29] <lamont_r> when is preview freeze, I wonder...
[01:29] <jbailey> mjg59: I had to do it twice in X, though.  The first time it didn't power off.  I think because I touched a key.
[01:29] <mjg59> jbailey: Oh, fucing rock
[01:29] <Kamion> lamont_r: Wednesday
[01:29] <lamont_r> because it should be before that
[01:29] <lamont_r> could be tomorrow
[01:29] <jbailey> mjg59: The box cheerfully turned off and everything.
[01:29] <mjg59> Kamion: It'd be cool if you could test suspend-to-disk on PPC too
[01:29] <mjg59> jbailey: That's excellent
[01:30] <Kamion> mjg59: will do tonight, just burning a CD now
[01:30] <mjg59> jbailey: So we can support suspend to disk and ram on most Apple laptops, and to disk on the rest of PPC
[01:30] <mjg59> Well, except G5s
[01:30] <lamont_r> Kamion: I think t-bone is working on merging everything together, and then I'll do the commit tomorrow evening/wed AM ish
[01:31] <jbailey> I'll get install time post inst to do put the swap partition in first thing tomorrow then.
[01:31] <mjg59> jbailey: Is that done before the kernel is installed?
[01:31] <mjg59> s/installed/configured/
[01:31] <jbailey> I'm guessing it would have to be.
[01:31] <Kamion> lamont_r: I'll get you a baz branch with the changes I'd like to have
[01:32] <mjg59> jbailey: Ok, cool
[01:33] <lamont_r> awesome - actually, poke t-bone with the branch name
[01:33] <lamont_r> --pre25--2.6.10 is there to start from
[01:34] <Kamion> lamont_r: oh, t-bone is merging and then you're merging from him?
[01:34] <lamont_r> yeah - he's going to put it all together, and then I'm going to do the actual commit and build of test images
[01:35] <lamont_r> something to do with write access to the tree... :-(
[01:36] <lamont_r> and he may or may not still need some baz tutorial help
[01:41] <jbailey> mjg59: Hmm.  This might be imperfect, can I /msg you a flood?
[01:41] <Kamion> lamont_r: you'll want to install kernel-wedge 1.25.1ubuntu4 when it appears
[01:42] <lamont_r> Kamion: ok. hopefully it'll be in the archive before 02:00 london time??
[01:42] <lamont_r> then it's automatic on the buildd's, you see..
[01:42] <Kamion> lamont_r: I just uploaded it, so should be
[01:43] <lamont_r> cool
[01:43] <mdz> anyone know about aspell?
[01:43] <mjg59> jbailey: Sure
[01:43] <mdz> there are a bunch of RC bugs imported from Debian regarding the aspell 0.60 transition
[01:44] <Kamion> mdz: ah, Mithrandir was at FOSDEM, that would explain it
[01:44] <mdz> I intend to close them all unless we are going to be forced to update to 0.60 at some point in the future (i.e., by GNOME)
[01:44] <mdz> Kamion: aha
[01:44] <jbailey> mjg59: 'kay, lemme just reboot first so it doesn't fill up my logs.  Basically the scanner keeps disconencting and reconnecting.
[01:44] <jbailey> (usb)
[01:46] <zul> lamont_r: that build with include the atapi cd-rom stuff
[01:46] <zul> oh sata
[01:52] <mjg59> jbailey: Yeah, you probably want to rmmod the USB stuff before suspend and modprobe it afterwards
[01:53] <jbailey> mjg59: Oy, really?
[01:53] <mjg59> Yeah, the USB suspend support is still crack
[01:53] <jbailey> rmmod'ing usb means losing my keyboard.
[01:53] <mjg59> Check out the stuff in acpi-support on x86. We'll need to do something similar for ppc.
[01:54] <jbailey> mjg59: Hmm.  Is there a bug on that I can cc: myself on?  I don't imagine that I'd look at that in the next couple of days.
[01:54] <mjg59> Not that I know of - we've just worked around it on x86
[02:12] <tseng> its valid to tell people to report bugs upstream if it doesnt seem to be a packaging issue, correct?
[02:12] <tseng> gentoo was a little crackful about keeping bugs because so many upstreams hate on gentoo users
[02:13] <zul> heh and how
[02:23] <Kamion> eek, synaptic's sources.list editor doesn't let me add arbitrary repositories any more?
[02:23] <Kamion> that sucks
[02:24] <jdub_> Kamion: you're probably capable of adding them yourself though :)
[02:24] <mjg59> Is the list of changes between the preview release and Hoary final going to be kept and made publically available?
[02:24] <Kamion> sure, I am, but it's a retrograde step
[02:24] <mjg59> (solves all sorts of I tried this but it sucked/ate my cat/molested my wife issues)
[02:24] <Kamion> mjg59: hoary-changes is archived
[02:25] <jdub_> Kamion: (btw, just hit custom)
[02:25] <jdub_> why is pulling anal retentive stuff out that users don't understand a retrograde step?
[02:26] <mjg59> Kamion: It'd be nice if there was a summary page for the final release
[02:26] <Kamion> 'cos users add custom repositories for third-party applications all the time
[02:26] <Kamion> we want to encourage third-party vendors to set up apt repositories, right?
[02:27] <jdub_> sure, but we won't be encouraging users to enter them manually
[02:27] <Kamion> ah, custom, ok, I didn't see that
[02:27] <Kamion> I stand corrected :)
[02:27] <jdub_> and one look at that dialogue shows you it shouldn't be there
[02:27] <Kamion> (it's in a kind of strange place in the dialog ...)
[02:28] <Kamion> I guess I should resign myself to it getting harder and harder to use my nice local mirror
[02:28] <jdub_> Kamion: vi /etc/apt/sources.list is as hard as it has ever been
[02:28] <tseng> wb luis_
[02:28] <Kamion> there was a period when it was relatively easy with synaptic :)
[02:28] <tseng> luis_: for your next livecd run, muine is now in hoary universe. have fun
[02:29] <tseng> luis_: please drop anything you got from my webspace
[02:29] <jdub> raw tseng power!
[02:29] <tseng> :)
[02:30] <zul> mdz: missing proc_name for 3w-9xx will go in the uplaod after this one
[02:30] <mdz> zul: thanks
[02:31] <luis_> tseng: will do, thanks
[02:34] <tseng> np luis_, will have to try your cd one of these days
[02:35] <Kamion> hmm, one miiillion deprecation warnings in system-config-kickstart. better fix those.
[02:39] <Kamion> update-manager is really sweet
[02:43] <Kamion> mjg59: if you wait five minutes I'll be able to tell you whether s-t-d on my powerbook works
[02:43] <Kamion> OTOH you may be able to wait until tomorrow :)
[02:57] <mdz> lamont_r: kdelibs built an hour ago, but kdepim hasn't yet
[03:06] <lamont_r> mdz: it's building on terranova (i386) and others
[03:10] <mdz> lamont_r: thanks
[03:11] <Kamion> mjg59: hmm. even after a certain amount of hacking to make all the power scripts exit zero, pbbuttonsd doesn't seem to be sending the machine to s-t-d.
[03:11] <lamont_r> mdz: was already building, that is
[03:11] <mdz> lamont_r: interesting; has it really been building that long?
[03:13] <Kamion> hm, except maybe it isn't pbbuttonsd's responsibility
[03:13] <Kamion> what actually does the final step of making a system suspend?
[03:13] <lamont_r> kdelibs is a 80 minute build, and kdepim is about the same
[03:18] <mdz> Kamion: on i386, /etc/acpi/sleep.sh
[03:19] <mdz> Kamion: in theory I think powermanagement-interface is supposed to abstract this, but at the moment it seems to be acpi-specific
[03:19] <mdz> Kamion: if you find out, please update powermanagement-interface :-)
[03:24] <Kamion> mdz: see the source; powermanagement-interface does have pmu support
[03:24] <Kamion> hm, suspended but didn't come back up; perhaps if I were intelligent I'd make the hibernate script finish off by calling resume
[03:25] <Kamion> mdz: however, pbbuttonsd doesn't seem to have a triggerable action for "suspend to disk", only TAG_GOTOSLEEP which == suspend-to-ram
[03:25] <Kamion> pmi works fine for suspend-to-ram, though
[03:29] <mdz> Kamion: oh, I see.  I didn't notice it was arch: any
[03:30] <mdz> Kamion: maybe pmi should trigger the swsusp itself, then?
[03:33] <Kamion> mdz: no, it needs to be in pbbuttonsd so that it can work if you change the coveraction or keyaction to suspend-to-disk
[03:33] <Kamion> or in some package that installs scripts into /etc/power/
[03:45] <zul> mdz: you know that vfat synchronous support mandrake has a patch that we could use
[03:48] <mdz> zul: oh, interesting
[03:49] <jdub> ooh
[03:49] <zul> ill test it out
[03:49] <zul> and they use the same inotify we use in -23
[03:49] <mdz> the one that broke GNOME?
[03:50] <zul> good point
[03:50] <tseng> have you diffed them?
[03:50] <zul> not yet
[03:50] <tseng> or just looked at version string
[03:50] <zul> version string
[03:50] <jdub> seb was saying their inotify issues are resolved
[03:50] <jdub> i might check up on their gamin package
[03:53] <zul> mandrake's inotify is different from ours
[03:55] <Kamion> lamont-away: where's that --pre25--2.6.10 branch you mentioned?
[03:56] <tseng> huh..
[03:56] <tseng> i can only find rpms
[03:56] <zul> ftp://fr2.rpmfind.net/linux/MandrakeCooker/10.2/SRPMS/main/
[03:56] <tseng> hm of course
[03:56] <Kamion> lamont-away: oh, never mind, I'm stupid
[03:57] <zul> the inotify patch is the same from kernel.org though
[04:00] <tseng> jdub: http://getsweaaa.com/~tseng/gamin-0.0.24-inotify017.patch is in the srpm
[04:00] <lamont> Kamion: glad you found it.\
[04:00] <jdub> wow, they're shipping 0.17?
[04:01] <tseng> zul can speak for whats in the kernel
[04:01] <tseng> ive not looked
[04:02] <zul> jdub: this is what they have in the kernel http://zulinux.homelinux.net/ubuntu/kernel/FS18_inotify-0.18-rml-2.6.10-16.patch
[04:02] <jdub> hrm
[04:02] <tseng> zul: ill apply their patch to gamin and try to boot with inotify
[04:02] <tseng> hows that
[04:03] <zul> that would be good
[04:03] <Kamion> lamont: so if I mail a merge request to<EMAIL_ADDRESS>will that reach the right people?
[04:03] <tseng> sending to pbuilder now
[04:04] <zul> Kamion: yes
[04:04] <lamont> yes
[04:04] <tseng> errored out, win
[04:05] <tseng> In file included from gam_inotify.c:38:
[04:05] <tseng> local_inotify.h:23: error: `INOTIFY_FILENAME_MAX' undeclared here (not in a function)
[04:05] <zul> Kamion: eventually all three of us will be able to do an upload
[04:06] <tseng> but thats the only patch they apply to 0.0.24
[04:07] <zul> gimme a sec.
[04:07] <zul> lets try google
[04:07] <tseng> Patch0: interface with inotify 0.17 (not 0.18 yet)
[04:07] <Kamion> zul: ok, sent
[04:07] <zul> great..
[04:15] <wasabi> so how's nfsv4 coming?
[04:16] <zul> uhhhh...
[04:16] <zul> its not really going anywhere
[04:16] <wasabi> =(
[04:21] <zul> there is alot on the plate right now as it is
[04:29] <tseng> 'server/gam_poll.c: try to avoid the /media/ mount problem in 0.0.24'
[04:29] <tseng> this is one of our issues I believe
[04:30] <tseng> hm inotify 0.19 support was added on Feb 10
[04:30] <tseng> which was before .24.. looks like the mandrake patch actually is reverting to .17
[04:30] <tseng> that makes sense now
[04:32] <tseng> zul: know anything about 0.19?
[04:32] <tseng> zul: im feeling brave
[04:34] <Kamion> jdub: moderation of my message to kernel-team@ would be handy
[04:34] <Kamion> if you could
[04:35] <lamont> mdz/jdub around?
[04:35] <jdub> yeah
[04:35] <lamont> so inotify...
[04:35] <lamont> if we drop that back to .17 to match gamin, that's almost certainly a kernel abi event.
[04:35] <lamont> thoughts on that front?
[04:35] <tseng> lamont: im going to test .19 here
[04:35] <tseng> if no one has yet
[04:35] <lamont> tseng: that'd be way cool
[04:36] <tseng> fetching linux-source atm
[04:36] <jdub> lamont: i don't think it's worth falling back
[04:36] <tseng> gamin looks to support .19 in 0.24
[04:36] <lamont> ok.  we know that 17->18 was an abi bump.  18->19 may be as well.
[04:36] <tseng> ill remove .18 and zuls no-default patch and drop in .19
[04:37] <lamont> jdub: so the question is, if it is an abi bump to go to .19, do we want to do that the day before preview freeze?
[04:37] <lamont> also, I need mdz/jdub to tell me to go ahead and cause an rsyncability-event for amd64's livecd (since it doesn't have garbage collection, and therefore grows over time...)
[04:38] <Kamion> lamont: that last can be after preview freeze, can't it?
[04:38] <lamont> Kamion: anytime people want
[04:38] <tseng> oh jeez
[04:38] <lamont> it's literally simply the case of me removing the previous day's image
[04:38] <tseng> there are a bunch of inotify patches
[04:38] <jdub> lamont: i'm coming around to the idea that we should ship without inotify turned on by default, but we should endeavour to have a working version.
[04:38] <tseng> mind if i just patch my sources by hand?
[04:39] <lamont> tseng: given a working inotify, it'd be nice if it matched some combination of upstream patches... but working is even better... :-)
[04:42] <zul> tseng: i couldnt get 0.19 to compile
[04:42] <tseng> I dont understand the split up patches, but i rm *inotify* and dropped mine in
[04:42] <zul> well the latest 0.19
[04:42] <tseng> we'll see
[04:43] <tseng> im guessing it compiles for at least rml and whoever wrote the code for gamin
[04:43] <jdub> john mccutcheon
[04:43] <drbyte> tseng: daniel veillard. it seems to work for fedora/rawhide (compiles, runs). though we're seeing regression with usb thumb drives being locked
[04:44] <jdub> drbyte: fedora isn't shipping inotify
[04:44] <tseng> locked on unmount?
[04:44] <drbyte> jdub: no, but gamin has inotify support. even though the abi might change, dv's gotten some steam from arjanv
[04:44] <tseng> or just not catching the file alteratioin on mount
[04:44] <jdub> tseng: fedora uses dnotify, so gets the file usage on removable drives problem
[04:44] <tseng> I see, right
[04:45] <jdub> drbyte: i think you missed a bit of the conversation or something :)
[04:45] <drbyte> jdub: possibly. reading scrollup now
[04:45] <tseng> drbyte: we've been having issues with inotify .18 and gamin .24 causing a hardlock on startup
[04:45] <mdz> lamont: kernel ABI change should probably be OK before preview if we stage the update elsewhere first, and synchronize things so that we don't build broken CDs
[04:45] <tseng> is the crux of the issue
[04:46] <tseng> looking to fix one of the components and happily move forward
[04:46] <jdub> we should just jump to 0.19 and leave it off by default
[04:46] <tseng> zul just said it didnt compile on last trial
[04:46] <lamont> mdz: so you're saying before preview freeze, or before preview?
[04:46] <jdub> can anyone else process NEW?
[04:46] <tseng> jdub: im doing my own test atm
[04:47] <mdz> lamont: after array 6, before preview (during preview freeze)
[04:47] <mdz> jdub: no
[04:47] <jdub> d'oh
[04:47] <mdz> lamont: but in the specific case of inotify, re-enabling it at that point doesn't seem very wise
[04:47] <lamont> mdz: so don't bump ABI with tomorrow's upload, but OK to include a new inotify patch post preview-freeze (after array 6), but leave inotify disabled by default.
[04:47] <lamont> right?
[04:47] <mdz> without serious hoary-external testing
[04:48] <lamont> yeah - it's default state wants to stay off until after hoary ships
[04:48] <mdz> lamont: that sounds reasonable, yes.  we just shouldn't create kernel churn right now, when we'll be preparing Array 6 tomorrow
[04:48] <lamont> very true
[04:49] <lamont> zul: sound good to you on the inotify front?
[04:49] <zul> yep..sounds good to me
[04:50] <tseng> whats this crack about having 30 00list's?
[04:50] <zul> welcome to the world of ubuntu kernel
[04:51] <tseng> does it actually read all these?
[04:51] <lamont> tseng: for reasons unknown, yes.
[04:51] <lamont> but it unapplies all of the ones older than the last one, too.
[04:52] <zul> then there are directories like linux-source-2.6.10-2.6.10-1 etc
[04:52] <lamont> it's to warm up the heads on the disk for serious compile work
[04:52] <tseng> oh the -X is the revisions
[04:52] <tseng> so i want -24
[04:52] <lamont> actually, it'll wind up being linux-source-2.6.10-2.6.10 when unpacked, or are you talking about inside the unpacked source/
[04:52] <lamont> "?
[04:53] <zul> inside the unpacked source
[04:53] <tseng> linux-source-2.6.10-2.6.10/debian/patches
[04:53] <tseng> is where im currently hitting the crack pipe
[04:53] <lamont> find  debian/patches/ -type d
[04:53] <lamont> debian/patches/
[04:53] <lamont> debian/patches/.arch-ids
[04:53] <lamont> must be in the building source.
[04:53] <jdub> tseng: coming to UDU?
[04:53] <lamont> and what really matters there is the debian/build directory
[04:54] <tseng> jdub: nope, sorry
[04:54] <zul> tseng: if you just want to compile for 686 you have to modify the flavours in the debian/rules to say 686
[04:54] <tseng> i dont have a fulltime job atm, no chance for that sort of plane ticket
[04:54] <tseng> zul: eh, ok
[04:55] <tseng> it failed anyway
[04:55] <zul> you should come to ols then :)
[04:56] <jdub> tseng: what's your day job atm?
[04:56] <zul> did you turn the patch into dpatch?
[04:56] <wasabi> damn this wiki
[04:57] <tseng> jdub: only working part time atm for my uncle.. hoping to scare up some employment interest with my talk at a linux security conference on Saturday.
[04:57] <tseng> zul: ya
[04:57] <jdub> tseng: rawk
[04:57] <tseng> im still farked in some 00list
[04:58] <jdub> sa-learn is slow
[05:00] <tseng> sa is overdue for a rewrite in C
[05:04] <tseng> 00list proper must be generated on each pass
[05:08] <lamont> 00list proper is generated each loop, yes
[05:09] <tseng> from 00list-X where X = revision?
[05:09] <lamont> yes
[05:09] <dholbach> morning
[05:09] <lamont> and, if present, from 00list-X.${ARCH}
[05:09] <tseng> because i removed references to inotify .17 in -24
[05:09] <tseng> and they are sitll reappearing in 00list
[05:10] <tseng> which is causing the entire process to go nowhere fast
[05:10] <wasabi> archive question. I am working on Java packaging. I have a TON of cyclic dependencies.
[05:10] <wasabi> many layers deep. Luckily, they are arch-indep.
[05:10] <wasabi> what can be done?
[05:11] <zul> you could not use java :)
[05:11] <wasabi> okay, no java for ubuntu.
[05:11] <wasabi> i can live with that!
[05:12] <zul> i dont like java
[05:19] <tseng> obviously :)
[05:21] <zul> well if you had to modiy a crappy groupware written in java you would too
[05:24] <zul> night
[05:24] <tseng> cya zul
[05:28] <lamont> wasabi: if you get it down to a list of 'take these debs from here, use them to build all these, and then rebuild everything, I can make that happen
[05:28] <lamont> but it needs to happen soonish...
[05:28] <wasabi> it's not for hoary.;
[05:28] <wasabi> not a chance. =)
[05:29] <lamont> that is, to get it into the archive (eventually), I'll want the minimum set of packages to break the circular dependency.  Then we build everything twice (for my sanity), and the second round is what goes in the archive
[05:30] <wasabi> k.
[05:30] <wasabi> http://www.ubuntulinux.org/wiki/EclipsePackaging
[05:30] <wasabi> =(
[05:30] <lamont> which reminds me. time to go do mass give-backs on i386 and amd64
[05:31] <dholbach> daniels: thanks for fixing xvfb-run :-)
[05:34] <tseng> ah I'm stupid
[05:35] <tseng> seems to go happily along if I make a new -25
[05:47] <ogra> night
[05:48] <dholbach> night ogra
[06:09] <jdub> uh oh
[06:09] <jdub> beagle 0.0.7
[06:31] <darkfusion> I would like to report a problem with my compact flash reader, where should I start?
[06:32] <schweeb> bugzilla
[06:34] <dholbach> or the mailing list<EMAIL_ADDRESS>[06:34] <darkfusion> the problem is that I don't know to file against the kernel/hal/gnome-volume-manager
[06:35] <darkfusion> there is alot of stuff going on but I am not sure what is broken.
[06:35] <dholbach> this is more a  #ubuntu -question
[06:35] <darkfusion> I asked but no one responded, I guess I will try again
[06:36] <dholbach> the mailing list then is maybe a better place
[06:36] <dholbach> darkfusion: good luck with it
[06:42] <dholbach> bye
[06:46] <ficusplanet> Hey everyone.  Is there a reason that dbus-0.23.1 isn't being uploaded to hoary?  Would it break feature freeze?  I ask because it is required for the two most recent versions of beagle.
[06:50] <jdub> ficusplanet: daniels was going to do it; not sure where it's at.
[06:51] <ficusplanet> jdub: Thanks.  I was just making sure it hadn't slipped through the cracks.
[06:51] <jdub> he may have decided not to do it, mind
[06:52] <crimsun> dbus-0.23.2 in sid corrects the api & abi breakage between .1 and .2
[06:52] <ficusplanet> jdub: I trust your/other ubuntu devs judgment on that stuff.  Just had the itch to play with beagle and noticed the discrepancy.
[06:52] <jdub> crimsun: probably worth the sync and merge.
[07:50] <trulux> dpkg: error al procesar /var/cache/apt/archives/libgtksourceview-common_1.1.92-0ubuntu1_all.deb (--unpack):
[07:50] <trulux>  intentando sobreescribir `/usr/share/gtksourceview-1.0/language-specs/nemerle.lang', que est tambin en el paquete libgtksourceview-cil
[07:50] <trulux> the upgrade is broken
[07:50] <trulux> bye
[08:02] <daniels> dhnp
[08:30] <kagou> hi
[08:40] <pitti> Morning
[08:43] <mdz> morning
[08:43] <jdub> hello, derooter! :)
[08:44] <pitti> well, no derooting tasks for Hoary any more :-)
[08:45] <jdub> Ubuntu 5.04: Not Rooted Anymore
[08:59] <ajmitch> pitti: hoary is 100% secure, then? ;)
[09:00] <pitti> ajmitch, jdub: no :-( we don't want to mess anything up for Hoary any more
[09:00] <ajmitch> ah..
[09:08] <bob2> mmm, setting up ubuntu servers is a pleasure
[09:11] <Treenaks> bob2: how so?
[09:12] <bob2> all the apt love of a Debian server plus recent packages lovingly security fixed by our own mr pitt.
[09:13] <jdub> i'm running hoary on my linode ;)
[09:13] <bob2> hah
[09:13] <Treenaks> jdub: did you see the photoshop contest links I sent? :)
[09:14] <jdub> hrm, no?
[09:14] <bob2> jdub: it's a 6 month release cycle, dude
[09:14] <bob2> control your hand-on-the-cvs-up-button urge
[09:14] <jdub> and someone needs to test server stuff
[09:14] <jdub> i am someone
[09:14] <jdub> i test server stuff
[09:20] <bob2> hm
[09:20] <bob2> aptitude wants to slurp tons of random stuff in every time I run on
[09:25] <jdub> elmo: ping
[09:35] <seb128> pitti: morning
[09:35] <pitti> Hi seb128
[09:35] <seb128> pitti:
[09:35] <seb128> Mar  1 09:31:45 localhost hal.hotplug[5156] : timout(10000 ms) waiting for /bus/pci/slots
[09:35] <seb128> Mar  1 09:31:45 localhost pci.agent[7484] : Bad PCI agent invocation
[09:35] <pitti> bah, the current live CD still has a broken keyboard setup
[09:35] <seb128> :(
[09:36] <pitti> hmm
[09:41] <pitti> daniels: is it known that the live CD still sets up a pc104/us layout even for de_DE.UTF-8?
[10:22] <daniels> pitti: using xorg 6.8.2-1?
[10:22] <pitti> daniels: the powerpc live CD as of yesterday night
[10:23] <pitti> daniels: i. e. old version
[10:24] <daniels> pitti: anything older than 6.8.2-1 will be broken; the next livecd to get built (20050301, maybe 20050302) will have it
[10:25] <pitti> daniels: ah, cool. Then I test this again
[10:25] <pitti> then hopefully the icons will work again, too
[10:27] <seb128> pitti: the icons are fixed with the new gtk
[10:27] <pitti> seb128: yes, I saw that
[10:27] <pitti> great
[10:28] <pitti> seb128: although I still don't understand why a cache is put below /usr
[10:28] <daniels> pitti: cool.  20050301 shound do it
[10:28] <daniels> should, even
[10:28] <mvo> seb128: mind if I upload a new gksu with different locking?
[10:29] <seb128> mvo: not at all, you are welcome to fix any GNOME bug :)
[10:29] <mvo> seb128: I guess there are enough of them for everyone :)
[10:29] <daniels> seb128: every bug is a GNOME bug!
[10:30] <seb128> daniels: so you are welcome to fix any bug you want :)
[10:30] <jdub> as long as it's black
[10:30] <jdub> black as my heart
[10:30] <seb128> oh jdub is here
[10:31] <seb128> so I can say that again
[10:31] <seb128> STOP FLOODING :p
[10:31] <jdub> heh
[10:32] <seb128> jdub: BTW about the debugging stuff, is that better than making -dbg packages ?
[10:32] <seb128> I've not read the whole thread yet
[10:32] <jdub> lamont: heh, i've had soft_bounce = yes on my linode for the last few days. oops.
[10:32] <jdub> seb128: we'll have to do both
[10:34] <jdub> seb128: well, no, we want to do -dbg regardless; the other stuff is a new idea, and would be a cool bonus if we feel it's worth it.
[10:34] <seb128> k
[10:34] <seb128> BTW I'm really happy to have a nautilus-dbg
[10:34] <jdub> yeah?
[10:35] <seb128> we get some nice backtrace upstream now
[10:35] <jdub> been useful? :)
[10:35] <jdub> rockign
[10:35] <seb128> when we get a nautilus crash from hoary I ask for the bt with nautilus-dbg
[10:35] <seb128> and apparently that works better for users than asking to build a debug version :)
[10:36] <seb128> we should really do a full -dbg archive aside
[10:36] <jdub> ywah
[10:37] <jdub> btw, are our -dbg packages separate dbg data, or full dbg builds?
[10:38] <seb128> dbg datas
[10:38] <seb128> thanks to dh_strip
[10:38] <seb128> (it uses objcopy)
[10:39] <jdub> rad
[10:39] <Treenaks> seb128: hm, can I get a debug-version of gst-plugins that way as well?
[10:39] <seb128> no
[10:39] <Treenaks> hm
[10:39] <Treenaks> then I'll recompile :)
[10:39] <seb128> speak about extra -dbg in the archive and elmo will track you down :p
[10:40] <jdub> ;-)
[10:40] <seb128> I would like to have -dbg for evolution too
[10:40] <seb128> bah
[10:40] <torkel> daniels: I will try to find some time to verify that #4343 is really fixed this time, later today
[10:40] <seb128> we really wants to set this -dbg tree
[10:40] <jdub> seb128: we'll make it happen at UDU :)
[10:41] <seb128> ROCK
[10:41] <seb128> the other jeff really wants it too
[10:41] <seb128> so if we need some cdbs magic ... :)
[10:41] <jdub> heh
[10:42] <seb128> but that's probably some buildd magic in this case
[10:42] <seb128> ah ah
[10:42] <jdub> so<EMAIL_ADDRESS>is not a valid sender address
[10:42] <jdub> so i no longer get forum-posted mails to the lists
[10:42] <jdub> ;-)
[10:43] <jdub> net win or net loss?
[10:43] <jdub> you be the judge ;)
[10:43] <jdub> 'course it might just get me booted off the list, too
[10:43] <thom> i think the forums should be banned from the devel list in fact, tbh
[10:43] <jdub> readonly?
[10:43] <thom> yes
[10:44] <Treenaks> jdub: readonly shouldn't be a problem.. then it's Just Another Archive
[10:44] <Treenaks> (with some fancy forum features)
[10:44] <thom> if people want to post they can damn well subscribe
[10:44] <jdub> also, fiordland doesn't have rdns
[10:44] <thom> nope
[10:46] <thom> http://guilinux.com/reviews.php?op=showcontent&id=20
[10:49] <jdub> thom: firefox has some "pass download requests to external manager" thing now, doesn't it?
[10:51] <daniels> agreed wrt forums->ubuntu-devel gate
[10:51] <daniels> torkel: word, thanks
[10:52] <pitti> daniels: is https://bugs.freedesktop.org/show_bug.cgi?id=1920 fixed in the latest Hoary packages?
[10:53] <daniels> oh my god
[10:53] <daniels> pitti: no.  sigh.
[10:53] <pitti> daniels: this also needs new warty packages, I'm afraid
[10:53] <daniels> FRIG
[10:53] <pitti> damn xpm bugs
[10:53] <pitti> and needs a whole lot of other package updates :-(
[10:53] <daniels> at this point, it would just be easier to surgically remove xpm support from every single package we have
[10:54] <daniels> and kick xpm the hell out of the archive
[10:54] <jdub> mdz: i told dbcw about omshell; he's cautiously interested
[10:54] <daniels> that's, what, the 11th patch now?
[10:54] <jdub> dcbw
[10:54] <pitti> daniels: can you do the warty update for x? I'll do all other packages
[10:56] <daniels> pitti: what sort of timeframe?  i'm exhausted tonight (been sleeping on and off all day), so it probably won't happen for 24h or so
[10:56] <pitti> daniels: no worries
[10:56] <daniels> cool
[10:56] <pitti> daniels: let's say hoary should be fixed by the preview release
[10:56] <pitti> daniels: and warty within a week?
[10:56] <bob2> lamont: what's with the control characters in /usr/share/doc/postfix/VIRTUAL_README.gz?
[10:57] <daniels> pitti: ok, i'll try
[10:57] <pitti> daniels: at least this time the patch is easy
[10:57] <pitti> daniels: I still remember the mess with the previous xpm patch
[10:57] <daniels> yeah
[10:57] <daniels> where we got up to the 7th or 8th version
[10:58] <daniels> As I mentioned before along with my first review. This is just the tip of the
[10:59] <daniels> iceberg... unfortunately. There are more values from untrusted sources (image
[10:59] <daniels> files) which are used carelessly in loops and asignments.
[10:59] <daniels> :\
[10:59] <pitti> daniels: would it make sense for hoary to remove xpm library support from X at all?
[11:00] <pitti> daniels: oh no, half a gazillion packages depend on it
[11:00] <pitti> daniels: so this waits for the massive X split then
[11:01] <daniels> pitti: unfortunately gtk and stuff depends on it
[11:01] <daniels> i think gecko as well
[11:01] <daniels> but if we could easily remove xpm support from those apps, then it is SERIOUSLY worth considering
[11:04] <daniels> pitti: you know what -- I think it's doable
[11:04] <pitti> daniels: you mean to package libxpm separately?
[11:05] <daniels> pitti: i mean to put libxpm in universe for hoary
[11:05] <pitti> daniels: hm, that would already be a step forward
[11:06] <pitti> and it should be hoaryable
[11:06] <daniels> yes
[11:06] <daniels> it touches -- groff, xpdf, and a couple of others
[11:23] <jdub> hah
[11:23] <jdub> woops
[11:23] <jdub> february is rather short, isn't it? ;)
[11:23] <Treenaks> LOL
[11:24] <rburton> haha
[11:24] <Treenaks> jdub: maybe you should break out the cron too :P
[11:25] <jdub> :)
[11:30] <jdub> jdubtv! -> http://node.waugh.id.au:8800/
[11:31] <maswan> jdubpr0n?
[11:31] <Mithrandir> maswan: we'll GRAB his bandwith. :)
[11:31] <Mithrandir> I should probably add some sound as well
[11:31] <Treenaks> Mithrandir: to MithrandirTV?
[11:32] <Mithrandir> Treenaks: no, just so I can hear what he's saying and stuff
[11:32] <Mithrandir> I don't broadcast myself.
[11:32] <Treenaks> Mithrandir: ah on the receiving end
[11:32] <Mithrandir> yup
[11:32] <Mithrandir> jdub: the buffering seems to be a bit tight -- never above 12-ish percent in totem
[11:32] <rburton> whoa, zoomed in jdub
[11:33] <Treenaks> with fadey edges!
[11:33] <Mithrandir> indeed
[11:34] <Treenaks> Guest Stars!
[11:35] <Mithrandir> and the sound is a bit low
[11:36] <Mithrandir> I want a decent way to mix multiple streams so I can tune their volumes since right now, jdub isn't noisy enough.
[11:37] <sivang> jdub: is this you?
[11:38] <sivang> morning all!
[11:40] <rburton> man jdub is nuts
[11:40] <Treenaks> rburton: what else is new
[11:40] <pitti> Hi sivang
[11:40] <rburton> Treenaks: erm. yeah, sorry for the useless statement
[11:41] <rburton> :)
[11:42] <Treenaks> rburton: :P
[11:43] <sabdfl> anybody else finding the 6.8.2 Xorg packages cause problems?
[11:44] <Mithrandir> sabdfl: sorry I didn't answer you about the amd64 and ooo2 stuff, but my network connection at FOSDEM was spotty at the best.
[11:44] <Mithrandir> sabdfl: I don't know what the current state of ooo2 and amd64 is, but if it builds and works, it should work fine on ia64 as well, I'd imagine.
[11:45] <sabdfl> Mithrandir: it's not building on either
[11:45] <sabdfl> if you can get it to build on amd64 it will probably go straight through on ia64 and t-bone will love you
[11:45] <sivang> pitti: Hi Martin! :)
[11:46] <Mithrandir> sabdfl: I can take a look, but no promises.
[11:46] <sabdfl> so the new X packages work for everyone else but me? *grumble*
[11:46] <sabdfl> Mithrandir: np
[11:46] <sivang> sabdfl: I havn't upgraded since yesterday, doing now and will test also on the dell lappie, what machiens have you tried?
[11:46] <sabdfl> desktop box, fglrx driver
[11:46] <sabdfl> was working very nicely with previous packages
[11:47] <sivang> sabdfl: eh, then I have Nvidia, sorry :-/
[11:47] <Treenaks> sabdfl: did the fglrx drivers get updated along with X?
[11:47] <smurfix> sabdfl: I vahe a laptop with fglrx, will try asap
[11:47] <smurfix> s/vah/hav
[11:48] <smurfix> pitti: It gets worse. My desktop has an ati 700 with nonstandard wiring, neither fglrx nor radeonfb work with it
[11:48] <smurfix> 9700
[11:49] <sabdfl> ati laptops are often customised beyond the point that the public drivers will work
[11:49] <smurfix> sabdfl: true -- radeonfb doesn't work on the laptop :-/
[11:50] <daniels> smurfix: hmm, does the standard radeon driver for X work with it?
[11:50] <sabdfl> ah... comes up fine with open source ati driver, but not with fglrx
[11:50] <daniels> sabdfl: hmm, fglrx's broken with yours
[11:50] <mjg59> smurfix: Hm. Radeonfb is no great loss.
[11:50] <daniels> ah shit.  i really hope we don't have to update fglrx mid-freeze; can't think of anything that's changed there.
[11:50] <smurfix> daniels: "it" == desktop or laptop?
[11:50] <sabdfl> daniels: fglrx was working perfectly yesterday, i was going to mail you and say "wow"
[11:50] <daniels> smurfix: the one you were complaining was broken
[11:50] <sabdfl> very fast
[11:50] <daniels> sabdfl: heh :) well, if it doesn't work with 6.8.2, i'll roll packages with the new version
[11:51] <sabdfl> daniels: good work onthe opengl front, btw, was that you?
[11:51] <martink> Mithrandir, upstream has patches to make ooo2 build on amd64 <http://blog.janik.cz/archives/2005-02-27T11_12_36.html> but it's not usable. And a successful amd64 port != ia64 port. There are assembler parts that need to be hand written for each c++ compiler abi
[11:51] <smurfix> daniels: The standard driver is broken on the laptop, no display
[11:51] <daniels> sabdfl: which opengl stuff?
[11:51] <mjg59> sabdfl: Suspend to disk on Apple seems to work
[11:51] <daniels> sabdfl: i've done a lot of stuff recently
[11:51] <sabdfl> seems to auto-detect whether or not the ATI opengl will work, and use that, otherwise uses Mesa
[11:52] <daniels> smurfix: oh wow, that's pretty impressive.  could you please send along an Xorg.0.log and xorg.conf?
[11:52] <daniels> sabdfl: sadly I can't take the credit; that was ATI
[11:52] <smurfix> daniels: on the desktop, both drivers give me really funky display artefacts which unfortunately are not conducive to doing actual work :-/
[11:52] <Mithrandir> martink: why does OOO have hand-written assembler?  That's just _wrong_
[11:52] <daniels> smurfix: ack
[11:52] <smurfix> daniels: I'll
[11:52] <sabdfl> Mithrandir: yowser
[11:52] <smurfix> ... do that
[11:53] <mjg59> sabdfl: So we've got some degree of suspend support on all Apple laptops, and suspend to RAM on most of them
[11:53] <martink> Mithrandir, somewhere deep inside its component system it does weird stuff with C++ virtual function tables
[11:53] <Mithrandir> martink: it's wrong, I'm sure. :)
[11:56] <daniels> holy shit, major bugzilla bustage
[11:57] <daniels> jdub: check out the submitter name in https://bugzilla.ubuntu.com/show_bug.cgi?id=7019
[11:57] <Treenaks> nice one
[11:58] <jdub> ouch :)
[11:58] <jdub> justdave: https://bugzilla.ubuntu.com/show_bug.cgi?id=7019
[12:03] <d3vic3> heh
[12:03] <lu|cookie> are you sure the submitter didn't actually put that as their name?
[12:04] <jdub> jdubtv is back up
[12:05] <d3vic3> jdubtv ?
[12:05] <seb128> jdub: we should move evince in ship
[12:06] <Treenaks> jdub: hoary should have a "jdubtv" bookmark of some kind by default.. or a default "recently used" entry
[12:06] <smurfix> sabdfl, daniels: the new X with fglrx works fine on my laptop.
[12:06] <jdub> seb128: ship?
[12:06] <jdub> d3vic3: http://node.waugh.id.au:8800/
[12:06] <seb128> jdub: ship seed ?
[12:06] <jdub> seb128: ship implies supported :)
[12:07] <seb128> jdub: you don't want to support evince ?
[12:07] <seb128> jdub: dude
[12:07] <jdub> seb128: from my pov, we should either ship it in desktop or not support it :)
[12:07] <seb128> if you want to take me here, desktop and default viewer :p
[12:08] <jdub> it's very tempting
[12:08] <seb128> xpdf is ugly
[12:08] <seb128> c'mon
[12:08] <daniels> isn't gpdf the default in hoary?
[12:08] <seb128> type3 fonts/gpdf, bong
[12:08] <seb128> daniels: nop
[12:08] <luis_> yeah
[12:09] <luis_> I assume you've tested that in evince?
[12:09] <daniels> wack
[12:09] <seb128> yep
[12:09] <seb128> evince rocks
[12:09] <Astharot> 'morning
[12:09] <daniels> xpdf is pretty hideous, really
[12:09] <daniels> and doesn't it use lpr for printing?
[12:09] <Treenaks> daniels: it uses "please enter a command here" for printing
[12:09] <pitti> does evince support fullscreen?
[12:09] <daniels> luis_: when i got the original bug report, that certainly wasn't the name, so either bz mangled it, or they did (badly)
[12:10] <seb128> pitti: yep
[12:10] <daniels> Treenaks: whoohoo!
[12:10] <pitti> cool
[12:10] <seb128> pitti: F11
[12:10] <smurfix> Gaah
[12:10] <jdub> seb128: hrrrrrrrrmrmrmrmr
[12:10] <seb128> jdub: bah, starts evince and xpdf and look
[12:10] <smurfix> daniels: "startx -- -layout test :1" starts an X server on :1 but then runs the Gnome session stuff on :0
[12:11] <seb128> jdub: how can we ship _that_ :p
[12:11] <smurfix> daniels: The good part is that the ati driver now works on the laptop
[12:14] <seb128> libtool: link: cannot find the library `/usr/lib/libhowl.la'
[12:14] <seb128> graaaah
[12:14] <luis_> daniels: query for other bugs where that user has commented, see if they are busted too
[12:14] <seb128> removing libhowl from libgnomevfs2 breaks other stuffs
[12:15] <seb128> is there something to do to fix that out of rebuilding the differents lib with the new gnomevfs ?
[12:15] <Mithrandir> seb128: sounds like said other stuff is built with old, broken libtools.
[12:15] <jdub> seb128: -Wl,--as-needed :-)
[12:15] <jdub> seb128: nothing else you can do, given the depends
[12:16] <Mithrandir> seb128: so probably not, no.
[12:16] <seb128> jdub: I'm tempted to do that
[12:16] <daniels> smurfix: cool.  as for the gnome stuff, yeah, that's wack.  you just can't run two gnome sessions as the same user on the same machine.
[12:16] <mvo> pitti: do you know of any compatibility issues of the langpacks with python-gettext? I have some strange issues here that some strings are not translated when they are in the locale-langpack directory (but work fine in the normal locale-directory)
[12:16] <pitti> mvo: are they present in both directories?
[12:16] <smurfix> daniels: is that related to the multihead stuff? 'Cause it worked before
[12:16] <pitti> mvo: does python-gettext use libintl from glibc or its own implementation?
[12:17] <mvo> pitti: no idea
[12:17] <jdub> seb128: will we have the switched Preferences and Administration in the next panel?
[12:17] <daniels> smurfix: nope, totally unrelated -- I've never been able to start two GNOME sessions as the same user on the same machine.  ask jdub :)
[12:17] <mvo> pitti: I'll check.
[12:18] <pitti> mvo: strace
[12:18] <pitti> mvo: that'll display you the files it looks for
[12:18] <seb128> jdub: today or tomorrow yep, today is a busy day
[12:18] <seb128> jdub: I've these howl issues
[12:18] <seb128> jdub: and they just changed the libwnck soname ... nice :/
[12:18] <seb128> jdub: so probably tomorrow
[12:19] <seb128> time to package the new tarballs, fix howl depends and migrate to the new wnck
[12:19] <mvo> pitti: looks in both dirs and find the mo file in the langpack dir
[12:20] <jdub> seb128: boh!
[12:21] <mvo> pitti: it still makes a differences, some strings in locale-langpack are not translated even if the mo file is exactly the same. any idea what could cause that?
[12:21] <pitti> mvo: hmm, odd. It can correctly open the mo file?
[12:22] <mvo> pitti: strace looks fine and a lot of the messages are translated it seems
[12:22] <pitti> mvo: hmm, hard to tell without the code and mo files
[12:23] <pitti> Kamion: just wanted to update the seeds
[12:23] <pitti> Kamion: baz update -> "trouble reading checksum file for<EMAIL_ADDRESS>[12:23] <pitti> Kamion: any idea?
[12:33] <pitti> Kamion: sorted it out, nevermind
[12:38] <pitti> elmo_: I updated the language packs. There are three new languages requiring NEW love, I already seeded them. (not urgent, though)
[12:44] <mvo> pitti: just checked the python source, the gettext module is implemented independently from the libc gettext implementation
[12:44] <pitti> mvo: so python-gettext needs the same patch
[12:45] <mvo> pitti: yes, where is your original patch archived? I would like to use the same logic
[12:47] <pitti> mvo: p.u.c/~pitti/ubuntu-altlocaledir.dpatch
[12:47] <pitti> mvo: I extracted this dpatch from the glibc sources
[12:48] <mvo> pitti: thanks
[12:48] <pitti> seb128: evince is b0rken. Whenever I open the menu, cpu goes to 100% and the program hangs
[12:50] <seb128> bt please
[12:50] <seb128> no such bug in the BTS or bugzilla
[12:51] <pitti> seb128: shall I file it in gnome's? it's universe, so ours is not appropriate
[12:51] <seb128> should be main
[12:51] <seb128> can you get a backtrace on http://rafb.net/paste/ ?
[12:51] <pitti> seb128: it's universe
[12:51] <jdub> pitti: seb has wishful thinking
[12:51] <seb128> pitti: yeah, but I want it as the default viewer
[12:52] <seb128> pitti: so I care about the bugs, universe or not
[12:53] <pitti> seb128: hmm, I know what's wrong. A few seconds after startup, it begins to generate preview images
[12:54] <Kamion> pitti: what was it?
[12:54] <pitti> Kamion: a missing public key in my keyring. The message could be a little less misleading though...
[12:54] <seb128> pitti: you start it on a document ?
[12:54] <pitti> seb128: yes
[12:54] <seb128> oh
[12:54] <seb128> so different issue :)
[12:54] <seb128> pdf file ?
[12:55] <seb128> xpdf handles it fine ?
[12:55] <pitti> seb128: yes, the preview generation was started a little later after displaying the first page
[12:55] <pitti> seb128: but that's awful
[12:55] <pitti> seb128: with a 153 page diploma thesis, previews take a minute
[12:55] <pitti> seb128: yes, xpdf does it fine
[12:56] <seb128> you don't need to use the preview pane
[12:56] <pitti> seb128: even if I switch to "contents" (from preview) immediately, it still generates previews
[12:56] <seb128> and you can switch the pane to "index"
[12:56] <seb128> close it :p
[12:56] <seb128> BTW can you put the pdf somewhere ?
[12:56] <seb128> I want to try here
[12:56] <Kamion> pitti: hah
[12:57] <pitti> seb128: bah, it is totally unresponsive
[12:57] <pitti> seb128: I put it on p.u.c
[12:57] <seb128> thanks
[12:58] <pitti> seb128: p.u.c./~pitti/diplom.pdf
[12:58] <seb128> just tried on a 110 pages pdf here
[12:58] <seb128> takes ~2s to make the thumbnailing
[12:58] <seb128> "You don't have permission to access /~pitti/diplom.pdf on this server."
[12:59] <pitti> seb128: if I just start "evince" without a document, and then open it from the menubar, then I don't have a preview pane,but still the CPU rattles
[12:59] <pitti> seb128: fixed
[01:00] <seb128> ~4s to make the whole thumbnailing here
[01:00] <seb128> for the 134 pages
[01:00] <seb128> there is an issue on your box, can you get a bt ?
[01:00] <pitti> seb128: no, I deactivated the preview pane, now it does not appear any more, but it still takes ages
[01:00] <seb128> do you have message in the logs ?
[01:00] <pitti> seb128: nothing on stdout
[01:01] <seb128> have you just installed it ?
[01:01] <pitti> seb128: I'm on a Duron 1.3, not the fastest thing out ther
[01:01] <pitti> seb128: yes, installed 5 minutes ago
[01:01] <seb128> killall gconfd-2 ?
[01:01] <seb128> perhaps that's a config issue
[01:03] <pitti> seb128: tried that. preview generation still lasts over 1 minute
[01:03] <seb128> and it eats CPU without opening a document ?
[01:03] <pitti> seb128: it opens the document
[01:03] <seb128> when you launch "evince" it opens a document ?
[01:03] <pitti> seb128: but clicks, scrolls, etc. are delayed by several seconds (unresponsive)
[01:04] <pitti> seb128: no, I launched "evince diplom.pdf"
[01:04] <seb128> k
[01:04] <seb128> and I you close the preview pane
[01:04] <seb128> and restart it
[01:04] <Kamion> mjg59: so you said that suspend-to-disk works on Apples; how did whoever it was get the userspace support set up?
[01:04] <seb128> is it slow ?
[01:04] <pitti> seb128: however, same thing if I just start "evince" and open the file from the menu
[01:05] <mjg59> Kamion: In what way?
[01:05] <pitti> seb128: as I said, even if the pane is disabled, it still genreates the previews (it shouldn't)
[01:05] <mjg59> Kamion: At the moment, you need to do it by hand
[01:05] <pitti> seb128: -> it is still slow and unresponsive
[01:05] <seb128> pitti: right, please fill a bug upstream :)
[01:05] <pitti> seb128: okay, I do
[01:06] <seb128> thanks
[01:08] <pitti> seb128: already there: #165413, and even more #166825
[01:09] <seb128> k, right
[01:09] <seb128> so I guess we will stick with xpdf for hoary :/
[01:10] <pitti> seb128: well, other than that it's quite nice, and even more, it's translatable (which xpdf isn't)
[01:10] <seb128> yeah :)
[01:10] <pitti> seb128: so if we could just disable thumbnails, it would be a nice thing
[01:10] <seb128> and it uses the gnome-pritting system
[01:10] <seb128> printing
[01:10] <Kamion> mjg59: that's what I meant; any hints? :)
[01:11] <Kamion> mjg59: I tried echoing disk to /sys/power/state from a power script, and my machine certainly suspended, but didn't resume
[01:12] <mjg59> Kamion: You need the resume argument set in /etc/mkinitrd/mkinitrd.conf and to regenerate your initrd
[01:13] <Kamion> ok
[01:15] <mjg59> If you've got any USB devices, you'll also want to unload the USB modules before suspend and reload them on resume
[01:24] <zul> morning
[01:24] <seb128> elmo_: here ?
[01:27] <rburton> hm, the hoary gmime-cil packages don't want to work
[01:31] <Keybuk> thom: fix firefox
[01:44] <Mithrandir> Keybuk: libtool makes me want to stab myself.
[01:44] <Keybuk> Mithrandir: want to maintain it?
[01:44] <Keybuk> that's how I felt when I started
[01:44] <Mithrandir> do I look totally crazy, insane and out of my mind?
[01:45] <Mithrandir> it's convoluted three times within itself.
[01:45] <Mithrandir> it's just wrong and evil
[01:45] <Keybuk> actually, yes
[01:46] <Keybuk> you do
[01:46] <Mithrandir> *sigh* :)
[01:46] <Mithrandir> I'm not taking it.
[01:47] <Mithrandir> I'm making you a multiarch patch, though
[01:47] <Keybuk> aww
[01:47] <Keybuk> I'll have to sweet-talk vorlon then I guess
[01:48] <Mithrandir> it doesn't need to go into sarge
[01:48] <Mithrandir> (or hoary)
[01:50] <Keybuk> NMU it in :P
[01:51] <Mithrandir> anything using multiarched libtoolised libs will have to be relibtoolised anyhow.
[01:55] <Mithrandir> sys_lib_dlsearch_path_spec=" /lib/i386-linux /usr/lib/i386-linux /usr/X11R6/lib/i386-linux /lib64/i386-linux /usr/lib64/i386-linux /usr/X11R6/lib64/i386-linux"
[01:55] <Mithrandir> muhahahahah
[02:05] <Mithrandir> Thou shall not work outside version controlled directories.
[02:05] <daniels> hear hear
[02:05] <Mithrandir> (especially not when getting dirty with libtool)
[02:07] <Simira> hey! The only you're allowed to get dirty with is me!
[02:09] <thom> Keybuk: there's nothing wrong with firefox
[02:09] <daniels> thom: is that why you use epiphany?
[02:09] <thom> daniels: not true any more
[02:09] <daniels> wow-ee
[02:11] <Mithrandir> Simira: not that kind of dirty.  Just my hands, dear.
[02:11] <dholbach> hi
[02:11] <jdub> thom: ...?
[02:12] <Simira> Mithrandir: dirty hands, eh?
[02:13] <thom> jdub: ?
[02:23] <Keybuk> thom: I'm getting pop-unders!
[02:23] <Keybuk> fix it! fix it! fix it!
[02:23] <thom> Keybuk: IZ GTK BOOG
[02:24] <sivang> thom: for sure :)
[02:24] <zul> Keybuk i can see thom postal
[02:24] <thom> well, metacity probably
[02:24] <daniels> thom: totally
[02:24] <Keybuk> is firefox bug for not blocking them in the first place :)
[02:24] <thom> pfft
[02:24] <daniels> i wish seb would fix gtk's input method so it would get the keymap out of the d-i selection also
[02:24] <thom> i get no popup
[02:24] <thom> s
[02:24] <Keybuk> itv-f1.com is the most annoying example
[02:24] <daniels> having all these bugs assigned to xorg for xkb is totally lame
[02:25] <Keybuk> thom: read the news, someone figured out a way round the pop-up blocker and suddenly everyone's doing it :-/
[02:25] <daniels> Keybuk: wfm hth hand kthxbye
[02:25] <thom> Keybuk: sorry, no popups here
[02:25] <daniels> 'Firefox prevented this site from opening a popup window.  Click here for options...'
[02:25] <mvo> ping doko
[02:26] <Keybuk> hmm, ok; ignore that one :)  that one was in my allowed list
[02:26] <Keybuk> but there was other sites that do it now :(
[02:26] <thom> rofl
[02:26] <thom> lamer :P
[02:26] <doko> mvo: pong
[02:27] <Keybuk> thom: fix rpm :p
[02:27] <daniels> Keybuk: fix hct :P
[02:27] <thom> Keybuk: clear it with mdz
[02:28] <Keybuk> daniels: is fixed :)  will be a new release in a couple of weeks
[02:29] <daniels> Keybuk: where's the couple of weeks come from if it's already fixed, eh?
[02:29] <Keybuk> daniels: sourcerer
[02:30] <Keybuk> want that to be finished this week, so source package imports can happen
[02:40] <Keybuk> From: 	Debian Installer<EMAIL_ADDRESS>[02:40] <Keybuk> torkel: 	Rob Weir<EMAIL_ADDRESS>Rob Weir<EMAIL_ADDRESS>[02:40] <Keybuk> Subject: 	bazaar_1.1.1-1_i386.changes ACCEPTED
[02:40] <Keybuk> awwh
[02:40] <Keybuk> bob2's first package
[02:40] <pitti> woot
[02:40] <pitti> bob2: congrats
[02:40] <daniels> keybuk-sponsoring-rweir@? :P
[02:41] <Kamion> Keybuk: yeeees, including the extra-special "let's use a version number already used in Ubuntu but for a non-identical package"
[02:41] <Keybuk> daniels: actually, in reality, bob2 had /nothing/ to do with it -- I just didn't want to maintain another Debian package so did it in his name :p
[02:41] <Keybuk> Kamion: it's an identical package :p  and you should've uploaded the ubuntu one as 0ubuntu1 /technically/
[02:41] <Kamion> Keybuk: dude, can you imagine the grief I'd've got if I uploaded Canonical software as 0ubuntu1?
[02:42] <daniels> Kamion: whoohoo!  (he says, having just uploaded xorg_6.8.2-1)
[02:42] <torkel> Keybuk: autocompletion in xchat? :-)
[02:42] <Keybuk> torkel: I guess
[02:42] <Keybuk> Kamion: yeah :)
[02:42] <Treenaks> daniels: to sid? :P
[02:42] <daniels> Kamion: oh and btw, it's Canonical Ltd, not Canonical Software ;)
[02:42] <Kamion> daniels: screw you hippy :)
[02:42] <Keybuk> bob2 got to be maintainer because he wasn't around to ask
[02:42] <Micksa> woo, hoary knows how to handle the grub config for a separate /boot
[02:42] <Keybuk> (and thus say no)
[02:42] <Micksa> awesome
[02:42] <bob2> haha
[02:42] <daniels> Treenaks: nope, I don't have a key in the keyring these days
[02:42] <Keybuk> daniels: That's Canonical, spelt F. I. E. L. D. W. A. V. E.
[02:42] <daniels> (need to find a friendly local DD to sponsor me)
[02:43] <daniels> Keybuk: no, I work for Canonical
[02:43] <bob2> Keybuk: only for your UK hacks
[02:43] <Micksa> Keybuk: 123NOTIT
[02:43] <bob2> the rest of us work for a real company
[02:43] <Keybuk> we work for the same company as Mark and Jane :p
[02:43] <bob2> hahaha
[02:44] <Kamion> woot, that's NFS support in kickseed, I think
[02:44] <Kamion> well, half of it. and missing the minor detail of kernel udeb support just yet, but ...
[02:45] <Keybuk> Kamion: details, details *mere* details
[02:48] <Micksa> *sigh* if only KVM switches weren't evil
[02:51] <zul> Kamion: ill bug t-bone about the nfs udeb wehn he is on
[02:54] <lamont> bob2: nroff formatting, I expect - they all have overstrikes in them
[02:54] <zul> hey lamont i didnt think you would be up
[02:54] <lamont> morning email strafing run
[02:54] <zul> ah
[02:55] <lamont> then I disappear for an hour
[02:55] <lamont> speaking of which...
[02:55] <lamont> anything before I run away?
[02:55] <zul> nah we just have to bug t-bone today
[02:56] <Kamion> lamont: nroff> GROFF_NO_SGR=1 and a pipe to col -b might be a plan, if you want just plain text
[02:57] <lamont> Kamion: I'm just delivering upstreams files.  He's the one formatting them... :-)
[02:57] <bob2> lamont: ah
[02:57] <lamont> been that way forever
[03:02] <lamont> speaking of disappearing... bbiab
[03:02] <zul> same here
[03:03] <tseng> woo i think my kernel package is finally building
[03:03] <tseng> fell asleep last night staring at it applying and reverting patches a few dozen times
[03:06] <tseng> zul: your enable-inotify will need updating. havent looked at it yet
[03:07] <zul> ok ill look at it this afternoon when i get back
[03:07] <tseng> fs/read_write.c: In function `vfs_read':
[03:07] <tseng> fs/read_write.c:234: error: `inode' undeclared (first use in this function)
[03:07] <tseng> huh wow
[03:07] <zul> tseng: yeah thats what i got
[03:07] <tseng> =/
[03:07] <Micksa> xorg can't seem to use my mouse through the KVM :(
[03:09] <zul> tseng: i have to go shovel :(
[03:09] <tseng> ok
[03:13] <trulux> my upgrade is broken (
[03:14] <tseng> inotify.c defines
[03:15] <tseng> +       struct inode            *inode; /* associated inode */
[03:15] <seb128> lamont: here ?
[03:16] <Mithrandir> seb128: 15:02 < lamont> speaking of disappearing... bbiab
[03:16] <trulux> tseng: that smells something from fs kernel code :)
[03:16] <seb128> arg
[03:16] <seb128> Mithrandir: thanks
[03:16] <tseng> trulux: its inotify. it wont build atm
[03:16] <trulux> umm
[03:16] <trulux> lemme check
[03:16] <tseng> 0.19-2
[03:17] <trulux> vfs_read... just an advice, since 7 weeks ago, many API has changed
[03:17] <trulux> among the networking structures
[03:17] <trulux> and such
[03:17] <trulux> contact upstream
[03:17] <Keybuk> tseng: that's got to be an entrant for the "most useless comment" award
[03:17] <Keybuk> YES, HE KNOWS IT'S A MULTIPASS^WINODE
[03:18] <tseng> heh yeah..
[03:18] <trulux> it seems to be that inode structure is not initialized (or might be used not initialized, passed as argument to function)
[03:18] <Keybuk> i++;  /* increment i *.
[03:18] <Keybuk> ...no, really?
[03:18] <tseng> what I dont see yet in the patch is read_write.c referencing inode
[03:18] <Kamion> er gcc is saying "undeclared", dude, not "uninitialized"
[03:18] <tseng> guess I need to dig up the full file
[03:18] <Keybuk> probably a , instead of a .
[03:19] <Keybuk> ptr,inode not ptr.inode
[03:19] <trulux> Kamion: yes, but some structures need to be used as simple argument-passed pointers &
[03:19] <tseng> oh, ill look for that
[03:19] <tseng> (my C isnt that amazing)
[03:19] <trulux> Keybuk: anyways, without having the thingy here I can't check further
[03:19] <trulux> and
[03:20] <trulux> Keybuk: undeclared is definitily that *node is missing either in args or initialized within the function
[03:20] <tseng> actually, read_write.c declares inode locally
[03:20] <trulux> *inode
[03:20] <trulux> tseng: what context?
[03:20] <tseng> hm but wrong function
[03:20] <Kamion> again, please don't say "initialized" when you mean "declared"
[03:21] <Kamion> they are DIFFERENT THINGS
[03:21] <trulux> sure, I think I have worked a bit with the fs api, among JFFS3 which I'm working for xattr support ;P
[03:22] <trulux> and noter the either, n
[03:22] <trulux> btw
[03:23] <tseng> vfs_{read,write} call fsnotify_modify(dentry, inode, dentry->d_name.name);
[03:23] <trulux> pitti: there?
[03:23] <tseng> which does look inotify-related
[03:24] <trulux> tseng: btw, this is the last error:
[03:24] <trulux> dpkg: error al procesar /var/cache/apt/archives/mozilla-firefox_1.0+dfsg.1-6ubuntu1_i386.deb (--unpack):
[03:24] <trulux>  intentando sobreescribir `/usr/lib/mozilla-firefox/defaults/profile', que est tambin en el paquete mozilla-firefox-locale-es
[03:24] <pitti> trulux: yes
[03:25] <trulux> pitti: we have worked on the gcc-3.4-ssp, but it won't compile (yet)  and we are lacking of testing machines again
[03:25] <smurfix> daniels: mail with the keymap translation table sent to you
[03:25] <daniels> smurfix: cool, thanks
[03:31] <tseng> hm this must already be fixed in our kernel package somewhere
[03:31] <tseng> a diff between .18-16 and .19-2 yields only
[03:31] <tseng> -+	spin_unlock(&dev->lock);
[03:31] <tseng> ++	//spin_unlock(&dev->lock);
[03:33] <trulux> fixed upgrade
[03:33] <trulux> this is going fast now :)
[03:38] <pitti> seb128: indeed I found the same patch as in upstream cvs for gnome-cups-manager
[03:38] <pitti> seb128: however, there is even another bug, it crashes with a SIGPIPE when I use cups browsing
[03:38] <seb128> pitti: ups, forgotten to try that yesterday
[03:38] <pitti> seb128: I'm debugging this ATM
[03:38] <pitti> seb128: I just did
[03:38] <seb128> k
[03:38] <seb128> thanks
[03:39] <pitti> seb128: this thing tries to use an existing http connection, but when you restart cups, you get a SIGPIPE
[03:40] <Kamion> lamont,elmo_: any idea why I haven't been getting daily d-i builds on powerpc for a while?
[03:40] <seb128> gcm uses an http connection ?
[03:40] <lu|away> seb128: yes
[03:40] <lu|away> IIRC
[03:40] <lu|away> you'd want to ask jody
[03:41] <pitti> seb128: do you know of any glib wrapper around signal(2)?
[03:41] <sivang> pitti: what does it use the http connection for?
[03:41] <pitti> seb128: currently I cheat this away with "signal (13, SIG_IGN)"
[03:41] <pitti> seb128: but this is not a portable solution for upstream
[03:41] <pitti> seb128: libgnomecups uses libcups, which provides a C API to cups
[03:42] <pitti> seb128: but all communication with cups always happens through http
[03:42] <pitti> seb128: it basically uses http://localhost:631
[03:42] <pitti> seb128: that's the very reason why we cannot disable the web interface :-)
[03:45] <seb128> but the interface doesn't work IIRC
[03:45] <pitti> seb128: we only disabled the administrative functions with http authentication
[03:45] <seb128> oh right
[03:45] <pitti> seb128: the unauthorized functions work well
[03:45] <pitti> and have to, because it is CUPS' only interface
[03:46] <seb128> pitti: for network stuff you can look on g_io_channel_*
[03:47] <seb128> oh, you are looking for signals handler, not network stuff
[03:48] <seb128> hum, dunno
[03:52] <Mithrandir> thom: is there some way to turn off "web pages can set hotkeys" in m-f?
[03:53] <thom> Mithrandir: no clue
[03:54] <Mithrandir> thom: it bites me each time I'm on the wiki and press alt-d to go to the address field.
[03:55] <Mithrandir> Keybuk: http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/libtool--multiarch--0--patch-1?cmd=cs_mod&file=libtool.m4
[03:59] <trulux> who maintains firefox packages?
[04:00] <Mithrandir> trulux: thom
[04:00] <thom> it's a lie!
[04:00] <trulux> Mithrandir: ok, danke sehn
[04:00] <trulux> thom: hah, I'm having trouble with them :)
[04:01] <thom> trulux: itanium?
[04:01] <trulux> thom: nop, just a simple x86
[04:01] <thom> ok, what's the problem?
[04:03] <trulux> thom: Updating mozilla-firefox chrome registry...E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
[04:03] <trulux> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
[04:03] <trulux> dpkg: error processing mozilla-firefox-locale-es (--remove):
[04:03] <trulux>  subprocess post-removal script returned error exit status 1
[04:03] <trulux> Removing mozilla-firefox-locale-es-es ...
[04:03] <trulux> Updating mozilla-firefox chrome registry...E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
[04:03] <trulux> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
[04:03] <trulux> dpkg: error processing mozilla-firefox-locale-es-es (--remove):
[04:03] <trulux>  subprocess post-removal script returned error exit status 1
[04:03] <trulux> Errors were encountered while processing:
[04:03] <thom> woah
[04:03] <trulux>  mozilla-firefox-locale-es
[04:03] <trulux>  mozilla-firefox-locale-es-es
[04:03] <thom> stop!
[04:03] <trulux> flood
[04:03] <trulux> sorry
[04:03] <trulux> rafvb
[04:03] <trulux> rafb
[04:03] <trulux> :)
[04:04] <thom> there's nothing higher up?
[04:07] <trulux> I think these packages are unofficial ones that I installed first boot after warty was installed
[04:08] <trulux> I don't think so
[04:08] <thom> trulux: um, you lose then; i've enough to do without supporting unofficial broken packages
[04:09] <trulux> thom: err, one moment
[04:09] <trulux> I'm not sure if these are unofficial
[04:09] <trulux> just lemme check
[04:10] <trulux> thom: Version: 0.9.3-1ubuntu1
[04:10] <trulux> official
[04:10] <trulux> AFAIK
[04:10] <trulux> :)
[04:12] <Kamion> mvo: #6865 seems to be fixed now; anything more before closing it?
[04:12] <thom> trulux: official, but not something that shipped with warty
[04:12] <mvo> Kamion: no, think it's fine. I'll close it now
[04:12] <Kamion> ok, cool
[04:12] <Kamion> it works for me anyhow
[04:13] <trulux> thom: err, fixed
[04:13] <trulux> thom: just that my teddy bear was not around :)
[04:15] <mvo> Kamion: the current apt contains a patch that scores pathes without symlinks on a cdrom high. that means that it will add "deb cdrom:[]  hoary main" to the sources.list. it will also do this with debian cds (deb cdrom:[]  sarge main). could this be a problem for debian (and it's d-i)?
[04:15] <pitti> seb128: I think I've found a workaround
[04:15] <pitti> seb128: gnome #168881
[04:18] <Kamion> mvo: you'd have to ask joeyh, I can never remember exactly what assumptions are made; it might be a problem
[04:21] <jdub> thom: you're using firefox now?
[04:21] <thom> jdub: yeah
[04:23] <HcE> when compiling a kernel with initrd, should I have cramfs as a module or built-in?
[04:23] <HcE> whops, wrong #
[04:36] <mvo> Kamion: I send a mail to joeyh describing the changes and asking for his opinion
[04:41] <doko> elmo: please could you import drdsl from unstable/non-free ?
[04:42] <jdub> thom: http://christopher.aillon.org/blog/dev/mozilla/20050228-pango.html
[04:43] <zul> jdub: tseng and i did a diff of inotify 0.18 and inotify 0.19 and we are going to see what it does
[04:44] <thom> jdub: ...
[04:44] <thom> we enabled it by default ages ago
[04:45] <tseng> jdub: if you want a full error message to pass to rml I can dig it out again
[04:46] <tseng> its starting to look quite odd considering the .19 patch is a one line change from ours
[04:47] <Keybuk> Mithrandir: *shrug*  you're the maintainer :p
[04:48] <Mithrandir> Keybuk: I'm not
[04:48] <Keybuk> are too, I just uploaded changing tha Maintainer field *cackle*
[04:48] <Mithrandir> Keybuk: I adopted pkg-config, that's a _nice_ thing in comparison
[04:48] <Keybuk> (* note: possible lie)
[04:48] <Mithrandir> *chuckle*
[04:49] <Mithrandir> you're too kind for that
[04:49] <Mithrandir> (and no, that was not a challenge)
[04:49] <Gagatan> hynfhynf
[04:49] <Keybuk> I'm _so_ not
[04:50] <Keybuk> I am seriously considering RFAing it though
[04:50] <Kamion> mvo: ok
[04:52] <jdub> thom: mmm, i thought you said you were going to disable it, as it was the source of our font rendering problems
[04:52] <jdub> zul, tseng: thanks
[04:52] <Mithrandir> Keybuk: releasing pkg-config is just make dist and put the tarball somewhere sensible?
[04:53] <Keybuk> Mithrandir: no idea, never did it :p
[04:53] <Keybuk> ask daniels
[04:53] <thom> jdub: no, i fixed the rendering problems
[04:53] <Mithrandir> daniels: ^^^
[04:53] <thom> or, caillon did and i stole it
[04:53] <jdub> thom: i still have bollocky font foo in textareas
[04:53] <thom> jdub: even seb is happy
[04:54] <Mithrandir> oh, multiarch will be soooo much fun.
[04:55] <torkel> daniels: re #4343, it finnaly works. Thanks!
[04:58] <ogra> pitti:
[04:58] <ogra> ping
[04:59] <pitti> ogra: Hey, how are you
[04:59] <ogra> nearly ready with the fixes ;)
[05:00] <ogra> pitti: do you think its ok to have hal-dmiwrapper in /usr/bin ? or should it be in /usr/sbin in any case, since its a suid executable....
[05:00] <pitti> ogra: I'd rather have it in /usr/lib/hal
[05:01] <Mithrandir> -e 's:^\(sys_lib_search_path_spec\)=.*:\1="/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib
[05:01] <Mithrandir> that's evil.
[05:01] <pitti> ogra: because normal users aren't supposed to execute it
[05:01] <pitti> ogra: remember, every program in /usr/bin or /usr/sbin/ requires a manpage
[05:01] <ogra> ah, ok.....
[05:01] <Keybuk> Mithrandir: there's more evil things in debian/rules than that
[05:02] <Mithrandir> Keybuk: dude, I've tried to work out why my change didn't propagate to the package. :P
[05:03] <Keybuk> Mithrandir: libtool uses gcc -print-search-dirs to seed that
[05:03] <Keybuk> and it means you get totally the wrong things in there
[05:03] <Keybuk> like no X11R6
[05:03] <Keybuk> and gcc-specific version information
[05:03] <Keybuk> so I just hard-code it on Debian, where the search path is known and well-documented :p
[05:03] <Mithrandir> Keybuk: I know, I know, but still.
[05:04] <Keybuk> it only affects /usr/bin/libtool
[05:04] <Keybuk> not source packages made on Debian
[05:05] <Mithrandir> it seems it creeps in; at least just changing the libtool.m4 wasn't enough.
[05:05] <Keybuk> how did you change libtool.m4?
[05:05] <Mithrandir> emacs
[05:05] <Mithrandir> :P
[05:05] <Keybuk> remembering that on Debian's libtool, sys_lib_dlsearch_path_spec is built by parsing ld.so.conf
[05:06] <Mithrandir> yes, and I append evilness to that
[05:06] <Mithrandir> http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/libtool--multiarch--0--patch-1?cmd=cs_mod&file=libtool.m4 is the patch
[05:07] <Keybuk> mmm, patchy
[05:07] <Mithrandir> (it's wrong, but it's not totally wrong :)
[05:08] <lamont> Kamion: ENOROSS
[05:09] <rburton> i'm a ross! use me!
[05:09] <Kamion> lamont: long-term?
[05:10] <lamont> gah.  ELAMONTBRAINDEAD
[05:12] <lamont> Kamion: ross is alive, but disabled.  I need to double check with elmo and make sure he's really done with it, then I can turn things back on (and do a d-i build for you)
[05:12] <sabdfl> :-)
[05:12] <sabdfl> you guys are nuts. fortunately our partners don't mind.
[05:14] <Kamion> lamont: ok, cool; of course new upload coming today anyway ...
[05:14] <lamont> of course
[05:14] <Kamion> lamont: but I'll need the daily d-i build tomorrow to pick up the new kernel upload, probably
[05:15] <lamont> right
[05:15] <Kamion> well, failing that I can always do an upload ...
[05:15] <lamont> given that ross has been up for 3 days, I think elmo might be done with it... :-)
[05:15] <lamont> nah - worst case I'll  move it to another machine
[05:15] <lamont> but I think we're golden
[05:16] <thom> dholbach: nice report!
[05:17] <lamont> ah, that's what happened
[05:19] <ogra> pitti: how do i convince automake that hal-dmiwrapper actually gets installed in /usr/lib/hal ? i cant manage it to go anywhere else then /usr/bin :(
[05:19] <lamont> elmo_: you around?
[05:19] <dholbach> thom: thanks!
[05:19] <dholbach> thom: felt it was time for it
[05:22] <pitti> ogra: dunno, sorry
[05:23] <ogra> hrm....
[05:23] <pitti> ogra: if anything helps, don't install it in the Makefile.am at all
[05:23] <pitti> ogra: and instead install it in debian/hal.install
[05:23] <ogra> i did
[05:24] <ogra> but it still must get build from the Makefile..... obvoiusly i use the wrong variables, since it gets installed with lshal and friends.... :(
[05:24] <mvo> ogra: you could use (in Makefile.am): helperdir=$(libdir)/hal \n helper_SCRIPTS=hal-dmiwrapper
[05:24] <lamont> Kamion: new daily running, just to grease the skids, so to speak
[05:25] <ogra> mvo: wow, thanks :)
[05:25] <mvo> ogra: see if it works first ;)
[05:25] <ogra> heh, trying....
[05:27] <lamont> ogra: you forgot to sacrifice the chicken
[05:27] <Keybuk> lamont: that's scsi
[05:27] <Keybuk> it's goats for autotools
[05:27] <ogra> ahh, thats the prob.....
[05:27] <Kamion> lamont: ta
[05:28] <Keybuk> the autotools book even clearly shows a goat about to be sacrificed on the cover
[05:28] <zul> what the plague?
[05:28] <lamont> bazaar finally made it out of NEW on debian
[05:29] <paul> hi, possibly a dumb question (i couldnt find anything on the website), but are there any plans for an AXP port?
[05:29] <Keybuk> lamont: it wasn't in NEW for long
[05:29] <Keybuk> I only uploaded it just over a week ago
[05:29] <lamont> ah, ok.
[05:30] <lamont> someone told me they'd uploaded it a while ago...  must be they were doing the upload by proxy or fantasy, eh?
[05:31] <Keybuk> they lied, I expect
[05:31] <Keybuk> bob2 was supposed to it eons ago
[05:31] <Keybuk> lifeless tempted me with gin, and I did it in London
[05:31] <Keybuk> (in bob2's name, of course; I don't want _bugs_)
[05:32] <eruin> anyone here tracking junkie ?
[05:33] <tseng> man is binding keys to commands in metacity ever a pain
[05:33] <paul> i guess not so.
[05:33] <dholbach> Kamion, lamont: you fixed all the  -lX -universe bugs? or shall i give them another try?
[05:34] <Kamion> dholbach: I'm certain that my qt-x11-free change didn't get them all, but I don't know if lamont has done the give-back yet
[05:34] <lamont> dholbach: I didn't fix any of them with my mail last night...  Just sent mail to let people know of the wonderful opportunity
[05:34] <Kamion> dholbach: imms at least needs -L/usr/X11R6/lib added to linker flags somewhere
[05:34] <Kamion> and there may be others
[05:35] <Keybuk> gconftool --set --type=string apps/metacity/keybinding_commands/command_N "commmand args..."
[05:35] <dholbach> Kamion, lamont: I'll put them on   wiki/MOTUTodo
[05:35] <Kamion> like I say, I only bothered looking 'cos I want libqt-perl in main at some point. :)
[05:35] <Keybuk> gconftool --set --type=string apps/metacity/global_keybindings/run_command_N "F99"
[05:35] <dholbach> Kamion, lamont: or   wiki/UniverseMissingXinerama   even
[05:36] <lamont> ever hear a cat walk down a piano keyboard?
[05:36] <Kamion> dholbach: make it more general: UniverseXorgBuildProblems or something
[05:36] <dredg> paul: nobody cares about your crazy notions :)
[05:36] <dholbach> Kamion: i like many small lists :-)
[05:36] <Kamion> mkay
[05:36] <dholbach> Kamion: but will do
[05:39] <paul> dredg: oh you get to annoy me on two channels now... dredg in stereo ;)
[05:40] <dredg> :)
[05:40] <paul> i'd donate cycles to a ubuntu alpha port, but i fear qemu/alpha on a modern machine would be faster than my 21164A/433MHz..
[05:40] <tseng> i dunno about that, qemu is pretty slow
[05:41] <paul> (if qemu had an alpha target)
[05:41] <paul> tseng: nah, it's pretty quick.
[05:41] <tseng> i tried running a livecd in it with gnome, it was dog slow
[05:41] <paul> least x86 target hosted on x86-64..
[05:41] <tseng> anyways..
[05:41] <HiddenWolf> tseng: livecd's are always slow, imho

[05:42] <luis_> unless you are on a fast drive,you aren't going to get decent performance on any liveCD
[05:42] <mdz> morning
[05:42] <thom> hey mdz
[05:42] <luis_> though clearly gnome could use help in the # of disc hits, etc.
[05:42] <HiddenWolf> My roommate has an old laptop. 133mhz, che thinks it's quite snappy. I just purchased a slab of ram that's worth more than that thing
[05:42] <dholbach> Kamion, lamont: done
[05:42] <paul> tseng: qemu is far far faster than, eg, bochs.
[05:43] <tseng> so rc5-mm1 has:
[05:43] <paul> its quite tolerable.
[05:43] <tseng> +inotify-locking-fix.patch
[05:43] <tseng> lets look at that.
[05:43] <paul> anyway.
[05:44] <HiddenWolf> luis_: Yeah. Gnome is slow where winxp was quite snappy, all due to and old hdd
[05:44] <tseng> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/inotify-locking-fix.patch
[05:44] <tseng> hm I believe that is the same or similar change in .19
[05:44] <HiddenWolf> tseng: tell me you didn't type out that url by hand..
[05:44] <lamont> bbiab
[05:44] <tseng> no, I know how to paste
[05:45] <tseng> go to his announce and then go up a dir, then back down into broken-out
[05:45] <tseng> not too hard :P
[05:45] <tseng> ill diff his inotify with ours as well
[05:45] <tseng> but I think its .18-X
[05:46] <tseng> hm hardly
[05:46] <tseng> but diffs possibly between -mm and vanilla patches
[05:46] <tseng> HiddenWolf: smartd or smartmon or so
[05:47] <HiddenWolf> tseng: will any of those tell me "your disc is going to fail soon" in time?
[05:47] <luis_> HiddenWolf: yeah, XP has done a lot of work to minimize disc hits
[05:47] <tseng> thats their aim, but its not a foolproof magic bullet
[05:50] <thom> huh. why does bugzilla change me about dependency changes for a closed bug?
[05:54] <thom> HiddenWolf: you're welcome to the other 90 i have assigned to me
[05:54] <trulux> language-pack-es seems broken :(
[05:54] <zul> HiddenWolf: your welcome to 145 to the kernel team
[06:02] <thom> HiddenWolf: please don't message me stuff; but "my" packages include firefox, the laptop support stuff; apache2/php/mod_python etc and whatever else i get assigned
[06:04] <HiddenWolf> thom: fix that silly missing icon in firefox. :)
[06:05] <thom> HiddenWolf: every time you mention it, i'm ignoring firefox for an extra day :P
[06:07] <zul> hey jbailey
[06:08] <jbailey> Heya Chuck.
[06:08] <zul> how is it going?
[06:08] <jbailey> zul: w00t the power outages.    That whole thing was the only thing I ever heard about him out west.
[06:10] <zul> or when he went to kenya and made some racist comment
[06:10] <jbailey> Yeah, that was afterI moved here.
[06:10] <jbailey> *sigh*
[06:10] <zul> anyways
[06:10] <HiddenWolf> dholbach: I'll behave myself
[06:11] <dholbach> HiddenWolf: you're lucky... didnt find the button :-)
[06:27] <sabdfl> doko: what's with the -dfsg in the python2.4 packages?
[06:29] <mirak> how does ubuntu update manager detects if there is new updates ?
[06:29] <mirak> is there a cron task or something ?
[06:29] <dholbach> mirak: yes
[06:30] <mirak> hum, I can't see it i the list
[06:30] <mirak> in
[06:30] <ogra> pitti: you got mail :)
[06:31] <doko> sabdfl: that's the upstream package with the python-profiler files removed. they have a non-free license.
[06:31] <sabdfl> non-free how?
[06:32] <sabdfl> dfsg is not a constraint on us
[06:32] <doko> you are not allowed to re-use the code in a non-python context.
[06:32] <ogra> doko: there is always multiverse....
[06:32] <sabdfl> erg
[06:33] <doko> see http://python.org/doc/2.4/lib/node829.html
[06:33] <Kamion> ogra: python2.4-profiler | 2.4-3ubuntu1 | hoary/multiverse | all
[06:33] <ogra> ah
[06:33] <doko> it's addressed upstream, but maybe gets difficult to have the license changed.
[06:34] <sabdfl> why on earth would guido want to retain that
[06:34] <sabdfl> do you know if anyone has contact infoseek to get them to release the code under a more generally free licence?
[06:36] <doko> yes, working on it, the answer from the author already is at http://mail.python.org/pipermail/python-dev/2005-February/051549.html
[06:38] <sabdfl> doko: thanks for the clarification
[06:39] <Kamion> mirak: /etc/cron.daily/apt
[06:41] <doko> mdz, jdub: need to get libcairo1-dev from universe to support to build gcc-4.0. ok to change the seed?
[06:43] <mirak> Kamion: thanks
[06:43] <JanC> the author has no problem with releasing the python profiler, it's just that nobody knows who owns the code now IIRC?
[06:43] <mdz> doko: you don't need to seed build-deps explicitly; germinate walks the tree
[06:44] <mdz> at this point, since the Java stuff has not materialized, I'm not sure that we should be shipping gcc-4.0 in main at all
[06:44] <mdz> that was its only purpose
[06:46] <doko> well, yes, still hoping that jbailey will get eclipse in, and then the python plugin.
[06:46] <wasabi> no chance
[06:47] <wasabi> wait whens the deadline?
[06:47] <Evaso> hi pitti
[06:47] <doko> hi wasabi!
[06:47] <wasabi> hi!
[06:47] <wasabi> when would eclipse have to be in by?
[06:48] <Evaso> pitti: i had send a mail to Devid Zeuthen the hal developer to find a common solution about pktcdvd
[06:48] <wasabi> http://www.ubuntulinux.org/wiki/JavaPackagingProgress
[06:49] <doko> wasabi: tonight, I'm unsure if it can/should go in after the preview release
[06:49] <wasabi> oh, no chance.
[06:49] <wasabi> java in ubuntu is so far from completion it's not funny. =)
[06:50] <JanC> what's the best way to get a new translation in ubuntu when it's available in CVS upstream (as a .po file)?
[06:50] <JanC> bugzilla, rosetta, ... ?
[06:50] <Evaso> guys what about encrypted home directory in ubuntu with libpam-mount, are officially supported?
[06:51] <ogra> doko, wasabi: its universe....if you take responsibility for the packages and think that four weeks are enough for bugfixing i think we still could get it in after preview.... (but only if you feel really safe with that)
[06:51] <wasabi> i don't.
[06:51] <ogra> ok
[06:51] <ogra> heh
[06:51] <T-Bone> Mithrandir: ping?
[06:52] <wasabi> I do think however having gcj in might be nice.
[06:52] <wasabi> Even without Eclipse, it is a useful development tool.
[06:52] <wasabi> It would be the only way to run java programs in main for free.
[06:52] <wasabi> right?
[06:52] <ogra> at least it will ease getting eclipse in....
[06:53] <wasabi> depends what drives inclusion: end user applications or development tools.
[06:53] <ogra> ...but as i said, someone has to take responsibility (there are no updates after release)
[06:53] <wasabi> gcj isn't my choice to make. =)
[06:54] <wasabi> i can only say that eclipse will not make it
[06:57] <mdz> doko: eclipse is not going to happen
[06:58] <HiddenWolf> mdz: you just broke someone's heart
[06:58] <wasabi> dude. if you don't like it, get working. ;)
[06:58] <wasabi> http://www.ubuntulinux.org/wiki/JavaPackagingProgress
[06:58] <mdz> (for Hoary)
[06:59] <wasabi> eclipse packages are done, and have been done for months. But they have a massive dependency tree which isn't.
[06:59] <mdz> right
[06:59] <mdz> I have followed the frenetic pace of your wiki updates :-)
[07:00] <wasabi> =)
[07:00] <T-Bone> Kamion: ping?
[07:00] <wasabi> i hacked that thing together last night because I kept forgetting what package i was working on . =(
[07:00] <Kamion> T-Bone: pong
[07:00] <T-Bone> Kamion: all bits needed for the kernel are in the baz archive i suppose? Anything I should be aware of before preparing the package?
[07:01] <Kamion> T-Bone: you mean just my kernel change?
[07:01] <Kamion> the nfs-modules thing?
[07:01] <T-Bone> Kamion: yeah, whatever should go in the linux-image package
[07:02] <T-Bone> for which you sent mail ;)
[07:02] <Kamion> T-Bone: 'baz merge<EMAIL_ADDRESS>should get you everything
[07:02] <Kamion> T-Bone: it increments the kernel-wedge dependency, but nothing else special; not a large change
[07:03] <T-Bone> Kamion: ok
[07:04] <trulux> who handles language-pack-es?
[07:05] <Kamion> trulux: pitti handles language-pack-*
[07:05] <trulux> Kaloz: ok
[07:05] <trulux> ERR
[07:06] <trulux> Kamion :)
[07:06] <seb128_> lamont: here ?
[07:07] <trulux> Kamion: mine is broken or seems to:
[07:07] <jani> I need advice on cross toolchain packaging,anybody?
[07:08] <trulux> E: Couldn't configure pre-depend language-pack-es for language-pack-es-update, probably a dependency cycle.
[07:09] <zul> seb128: he wondered out i think
[07:09] <seb128> k
[07:09] <seb128> elmo_: here ?
[07:12] <Mithrandir> T-Bone: pong
[07:12] <T-Bone> Mithrandir: still willing to have access to ia64? :)
[07:12] <Mithrandir> yes, please.
[07:13] <T-Bone> Mithrandir: mail me a login and a ssh v2 key at<EMAIL_ADDRESS>please (gpg-signed message)
[07:13] <Mithrandir> will do
[07:17] <jbailey> wasabi: Because of a power outage and stuff this morning, I'm not caught up, but I'm hoping to look more on why gij isn't building today.  I just have some other stuff to nail first.
[07:18] <Mithrandir> T-Bone: sent
[07:19] <elmo_> seb128: ?
[07:19] <seb128> elmo_: have you sync glib 2.6.3 yesterday ?
[07:20] <T-Bone> Mithrandir: got it. Give me five minutes
[07:21] <elmo_> seb128: no, sorry, I didn't see you ask for it
[07:21] <seb128> k, could you do it now ? :)
[07:22] <elmo_> [NOT Updating - Modified]  glib2.0_2.6.2-0ubuntu1 (vs 2.6.3-1)
[07:22] <seb128> and are you around for an hour or so ? I need to upgrade a new libwnck with a soname change and to get out of NEW quick to not break gnome-panel and a bunch of other desktop stuff
[07:22] <elmo_> ok to override?
[07:22] <seb128> yep
[07:22] <elmo_> seb128: yeah, I'll be around the rest of the evening
[07:22] <seb128> k, thanks
[07:23] <sivang> eh, a new gnome
[07:23] <Kamion> oh, hm, I should seed nfs-modules in advance
[07:25] <elmo_> I assume the "prompts me for a keyboard layout on upgrade" thing is fairly universal?
[07:25] <elmo_> s/"/"X /
[07:25] <mdz> doesn't sound familiar
[07:25] <seb128> elmo_: do you have the power to kick eel2's build or do we need lamont for that ?
[07:26] <elmo_> mdz: ah - well it prompted me on both i386 and ppc - to add insult to injury it prompted me twice on ppc
[07:26] <elmo_> I'll file a bug...
[07:26] <lamont> seb128: kicking
[07:26] <seb128> thanks lamont
[07:26] <seb128> please kick all the builds having issues with libhowl.la
[07:27] <seb128> I've kicked the depends out of libgnomevfs2
[07:27] <seb128> but a bunch of .la list it
[07:27] <Mithrandir> T-Bone: no hurry; I have plenty other stuff to fix before preview. :)
[07:27] <T-Bone> Mithrandir: heh ok...
[07:27] <elmo_> [oh twice too on i386; it was just slower to upgrade]
[07:28] <mako> Treenaks: that just put on boingboing.net.. it's doing TONS of traffic right now :)
[07:28] <Treenaks> mako: cool :)
[07:29] <sm-tests> nice site
[07:30] <doko> kamion: when adding the plone-site to the supported list, then running germinate, I don't see all dependencies from zope-cmfplone. I'm missing something ...
[07:30] <Kamion> doko: if they're not yet in main, you need to use -c main,restricted,universe,multiverse
[07:33] <doko> Kamion: ok, thanks
[07:37] <wasabi> jbailey, that's cool. Did you get my wiki page?
[07:38] <jbailey> wasabi: Which one?
[07:38] <wasabi> JavaPackagingProgress
[07:41] <jbailey> wasabi: Nope, this is a different one than you gave me yesterday.  Let me subscribe to it too.
[07:41] <wasabi> Yeah i whipped it up quickly
[07:42] <Nafallo> mako: is it time to register for hoarycds yet?
[07:43] <Kamion> what's with all the ia64 given-back build logs at the moment?
[07:50] <Kamion> pitti: it would be useful if your baz mirror on people.u.c/~pitti/arch/ had .listing files (i.e. baz make-archive -l)
[07:50] <Kamion> pitti: oh, sorry, forget it, I'm just wrong
[07:51] <jbailey> mdz: ping re: 5204
[07:51] <mako> Nafallo: not yet.. we're going to try to coordinate with the preview release
[07:52] <Nafallo> mako: oki :-)
[07:53] <elmo_> Kamion/smurfix: console-keymaps-tree wants to be demoted - ok?
[07:53] <Kamion> it does? looking
[07:55] <Kamion> elmo_: oh, NAK - it needs to be explicitly seeded because it's in debian-installer/build/pkg-lists/, doing now
[07:56] <Kamion> seeds fixed
[07:56] <elmo_> thanks
[07:58] <Kamion> pitti: strange that this pre-depends stuff in current langpacks isn't reflected in the langpack-o-matic archive
[08:04] <tseng> hey beagle works w/o inotify now
[08:05] <ogra> wow
[08:05] <tseng> think it still needs a newer dbus still
[08:05] <tseng> so we cant do it for hoary
[08:05] <tseng> dbus 0.23.2
[08:06] <trulux> language-pack-* broken
[08:06] <trulux> :(
[08:06] <crimsun> jdub mentioned that it might be worth looking into syncing/merging 0.23.2 from sid
[08:07] <tseng> it might be. or it might break all apps built against dbus
[08:07] <tseng> i might try it here, im a brave sort of guy
[08:07] <Kamion> trulux: we know, you've mentioned it a couple of times and filed a bug, which I've assigned to pitti
[08:08] <trulux> Kamion: heh, desperado!
[08:08] <trulux> :D
[08:09] <zul> tseng: still building
[08:10] <tseng> hm
[08:10] <tseng> good deal
[08:12] <elmo_> lamont: slower than your usual "GIVE BACK THE WORLD"? :p
[08:14] <thully> hi - is array 6 still on track?  I just installed an array 5 CD and I'm going to rsync and re-install (to test some things in the installer, as well as some other things) when array 6 comes
[08:14] <mdz> amu: ping
[08:14] <lamont> elmo_: actually, I was going to do it one package at a time, then said 'hell, life is short' and gave back all 13
[08:14] <mdz> thully: array 6 is scheduled for tomorrow
[08:14] <amu> mdz: pong
[08:14] <mdz> amu: when did kdelibs start using fam?
[08:14] <lamont> elmo_: the trick to mass-givebacks is to make sure that nothing is building or in transition
[08:14] <thully> oh - I thought it was today
[08:14] <mdz> amu: we don't want that in main, or in kubuntu-desktop
[08:15] <mdz> amu: can it be switched to gamin?
[08:15] <amu> mdz: ages .... i think ganim was the fam replacement
[08:15] <amu> mdz: sure, that no problem
[08:16] <Kamion> thully: releases are always scheduled for Wednesday at the moment (whether they happen then or not :-))
[08:17] <thully> OK - I thought I saw somewhere that array 6 was today
[08:18] <seb128> if you want a broken desktop on array 6 do that :p
[08:18] <seb128> wednesday is nice :)
[08:19] <thully> btw - does an ubuntu install done from an array 5 CD automatically use polypaudio?
[08:19] <jon1012> hi everybody
[08:20] <Kamion> thully: yes, polypaudio was in desktop in array 5, although pretty new then IIRC
[08:28] <mdz> polypaudio is about as broken today as it was on array 5, iirc
[08:29] <jon1012> yes, polypaudio have problems...
[08:29] <Kamion> mdz: I checked the l-p-en/l-p-en-update dependency loop out on archive.ubuntu.com, and it exists
[08:30] <Kamion> new in the 20050301 update, I think
[08:45] <Mithrandir> Kamion: any ideas how utf8migrationtool should handle the case where the current locale is C?
[08:48] <lunitik> Keybuk: says you uploaded choose-mirror, but I don't see it, any idea why?  (just update'd like 2 mins ago)
[08:49] <Keybuk> buildd
[08:50] <elmo> mjg59: btw -24 sleep works for me, thanks
[08:50] <zul> hey mjg59
[08:51] <mjg59> elmo: To disk, or to RAM?
[08:51] <mjg59> zul: Hi
[08:52] <elmo> mjg59: to RAM
[08:52] <elmo> I've never tried disk before, at all
[08:52] <mvo> Mithrandir: maybe just a little dialog with a message like: "get a serious locale dude"?
[08:53] <Mithrandir> heh :)
[08:53] <mjg59> elmo: Excellent
[08:53] <mdz> Mithrandir: cry();
[08:54] <Kamion> Mithrandir: C's compatible with UTF-8, so just ignore it IMHO?
[08:54] <Kamion> lunitik: /me != Keybuk.
[08:55] <Mithrandir> Kamion: so with C I can just close my eyes and don't care?
[08:55] <Kamion> lunitik: and choose-mirror is a udeb so it's not something you can install on your normal system anyway
[08:55] <Keybuk> Kamion: heh, I just assumed it was a merge-o-matic result :p
[08:55] <Kamion> Mithrandir: I think you have to :)
[08:55] <Mithrandir> Kamion: why does d-i have a C.UTF8 locale then?
[08:56] <Kamion> Mithrandir: I mean compatible in the "subset of" sense
[08:56] <Kamion> UTF-8 strings aren't valid in C, but anything that's valid in C is also valid in UTF-8
[08:57] <Mithrandir> true, but I want to migrate a person using C to a UTF8 locale
[08:57] <Mithrandir> what locale should they end up with?
[08:57] <Kamion> and if they've deliberately set LANG=C they probably don't want you to migrate them
[08:57] <Mithrandir> they're running the utf8migrationtool -- they want to be migrated. :)
[08:57] <Kamion> oh, god knows, you have to ask
[08:58] <Kamion> it could easily be en_<something>.UTF-8, but the currency and date handling are different in those
[08:59] <Keybuk> Kamion: you better not be trying to defend C.UTF-8 again you SICK MAN :p
[09:00] <Kamion> Keybuk: I'm not :)
[09:01] <mdz> amu: please don't remove kubuntu-desktop from the kubuntu desktop seed; that's how it gets into main
[09:01] <ogra> lamont: does "done" mean nothing is left ?
[09:01] <lamont> ogra: means I gave everything back
[09:01] <ogra> lamont: ah, ok
[09:01] <lamont> 75 packages spread across 4 architectures
[09:02] <amu> mdz: all right
[09:02] <mdz> I've added it back
[09:02] <amu> I didnt changed something?
[09:03] <Kamion> mdz: a while ago I suggested to amu that he take it out during the early heavy seed development so that he could see what was going on, since the presence of an old-and-busted kubuntu-desktop was confusing things
[09:03] <Kamion> but I didn't intend for it to be left out permanently
[09:03] <mdz> ah, ok
[09:04] <mdz> I fixed kubuntu-meta recently
[09:04] <T-Bone> mdz: you're expected on #u-meeting...
[09:05] <amu> mdz: it disappeared? as i remember you added it yesterday?
[09:05] <Mithrandir> lunitik: I would be interested; have you made it and have a screenshot?
[09:06] <Kamion> lunitik: it would appear to be under discussion for GNOME 2.12, so it would be a possibility for hoary+1
[09:06] <lunitik> Mithrandir: I've made it... but not during this install... I could real fast though if it would help convince?  :)
[09:06] <Mithrandir> lunitik: I guess not default, but universe at least?
[09:07] <lunitik> Kamion: yes... RH devels (namely Havoc) seem to be pushing for it... and pushing out Industrial apparently
[09:07] <lunitik> Mithrandir: would make life easier if it were packages, yes  :)
[09:08] <lunitik> packaged*
[09:08] <Kamion> lunitik: as I understand from Ross Burton's blog, it isn't final yet, though some news sites are reporting it as if it were
[09:08] <tseng> jdub made a package already
[09:08] <tseng> its in NEW
[09:08] <tseng> and ross's blog would be correct if it says so
[09:08] <lunitik> tseng: oh, cool... wasn't there when I decided to try it  :(
[09:09] <tseng> http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00011.html
[09:12] <lunitik> I think my
[09:12] <lunitik> message can be legitimately read as "we're doing Clearlooks as the
[09:12] <lunitik> default for 2.12 for sure"
[09:12] <lunitik> gah... Konversation pasting sucks... sorry
[09:12] <elmo> tseng: nothing's in NEW - what package do you think is?
[09:12] <tseng> you dont need to paste anything, people intersted in it can read the posting
[09:13] <tseng> elmo: jdub said he recently uploaded gtk2-engines-clearlooks or so
[09:13] <lunitik> tseng: how long you think it would take to actually show up?
[09:13] <lunitik> tseng: cuz I just apt-cache search'd 'clearlooks' and get nothing  :(
[09:14] <tseng> well if its not showing up in NEW, the its not going anywhere fast
[09:15] <elmo> it's not in NEW, can't even see it in REJECT
[09:23] <trulux> pitti: ping
[09:23] <pitti> trulux: I'm here, but in a meeting
[09:24] <amu> mako: any news cases mepis offer also source to their gpl programs?
[09:24] <trulux> pitti: oh, ok
[09:26] <trulux> pitti: language-pack-es still not working as the other ones :(
[09:27] <pitti> trulux: odd, it worked for me, and Keybuk suggested the Pre-dependency to work around a dpkg bug
[09:27] <pitti> trulux: I'll look into it ASAP
[09:28] <Keybuk> what's not working?
[09:28] <Kamion> Keybuk: l-p-en depends: l-p-en-update, l-p-en-update pre-depends: l-p-en
[09:28] <Kamion> Keybuk: BAD
[09:29] <Keybuk> meh; yeah, that won't work
[09:29] <Kamion> so l-p-en must be unpacked and configured (or previously configured) before l-p-en-update can be unpacked, but l-p-en-update must be configured before l-p-en can be configured
[09:30] <Keybuk> l-p-en shouldn't depend l-p-en-update
[09:30] <Kamion> if this is the dpkg Replaces bug, I think it should be ignored :P
[09:30] <Keybuk> at most, it's a recommends
[09:30] <trulux> pitti: ok, many thanks
[09:30] <Kamion> Keybuk: (a) that requires installer changes, (b) that makes it harder for users surely?
[09:31] <Keybuk> otherwise you have to ensure installer installs l-p-en first and l-p-en-update afterwards
[09:31] <pitti> Keybuk: before they just depended on each other, but that breaks due to the dpkg Replaces: bug
[09:31] <pitti> Keybuk: but normally folks should just install l-p-foo and be done with it
[09:31] <Kamion> what actually broke?
[09:31] <mako> amu: we had a conversation with mepis's publisher and author at linuxworld about this
[09:35] <pitti> Kamion: #184635
[09:36] <pitti> Kamion: this is exactly the use case for a base package and l-p-update packages which partially replace the base pkg
[09:36] <amu> mako: means finally we get the source? At least a easy thing, they distribute under GPL, and it says if someone request the source, you've to give it to him.
[09:36] <pitti> Kamion: you cannot install update first, then the base package
[09:36] <pitti> Kamion: that's why Keybuk suggested Pre-Depends: to force installation order
[09:36] <Kamion> I'm inclined to say "so?" :)
[09:37] <Kamion> but ok; I still think we should just fix dpkg rather than endlessly working around this bug
[09:37] <Keybuk> yes, we should
[09:37] <Mithrandir> Kamion: sorry, I was away for a long phone call -- you think just popping up a selection of en_* locales is sensible if the current locale is C?
[09:37] <pitti> Keybuk: I thouhgt you said that this won't happen for Hoary/Sarge?
[09:37] <Keybuk> pitti: it won't.
[09:37] <Kamion> Mithrandir: it seems sort of a reasonable approach, I think
[09:38] <Keybuk> I do not have the time to fix both #164595 and #170825 before then
[09:38] <pitti> Kamion: "so" -> it can break installations and upgrades if you don't manually force installation order
[09:38] <Mithrandir> Kamion: we could just do C.UTF8 and everybody should be happy though.. ;)
[09:38] <pitti> *cough*
[09:38] <Kamion> pitti: yeah, I know
[09:39] <pitti> "Hey elmo, I have to build all base packages again, kthxbye"
[09:39] <pitti> He will _love_ me for that...
[09:39] <pitti> any idea for a working solution?
[09:39] <Kamion> Keybuk: wow, #170825 is actually a really old bug isn't it? looks like it's related to the "dpkg doesn't check Depends: on downgrade" thing that's on iwj's ancient todo list for dpkg
[09:40] <Kamion> pitti: l-p-en-update depends l-p-en, l-p-en recommends l-p-en-update, and we make the installer install both?
[09:40] <Keybuk> Kamion: dpkg doesn't check Depends both on downgrade, and on installation of a different package
[09:40] <Keybuk> foo; Conflicts: bar
[09:40] <Keybuk> install foo
[09:40] <Keybuk> fine
[09:40] <Keybuk> now install bar
[09:40] <Keybuk> dpkg will let you, because you're not installing foo at the same time
[09:40] <Keybuk> etc.
[09:40] <Kamion> pitti: I realise it makes it less easy to install just one package and get both, but we were planning on having an application to install language packs eventually anyway, and it looks like this scheme is doomed
[09:40] <pitti> Kamion: I think we can work around this in the installer pretty easy, we can even force the order there
[09:41] <pitti> Kamion: I'm more concerned about user installation
[09:41] <pitti> Kamion: Hoary+1 will have a separate gui for this, though
[09:41] <Kamion> pitti: sure, I'm happy to make the installer install l-p-* and l-p-*-update in separate dpkg runs
[09:41] <pitti> hmm, a Recommends: then?
[09:41] <pitti> but will this really work with the pre-dependency if you install both packages?
[09:42] <pitti> hmm, it sould
[09:42] <pitti> should, even
[09:42] <Keybuk> recommends is a depends that doesn't affect order
[09:42] <Keybuk> (basically)
[09:42] <Kamion> does it have to be a pre-dep?
[09:43] <Kamion> oh, I suppose you need a pre-dep in order to work around broken replaces technically
[09:43] <pitti> Kamion: right, that was the reason
[09:43] <pitti> mvo: if l-p-foo recommends l-p-foo-update, will synaptic default to install it, too?
[09:46] <mvo> pitti: depends. it can do it if it is configured to do so (not by default right now, see #2171)
[09:46] <pitti> hmm, ok
[09:46] <pitti> I guess there is no perfect solution then
[09:46] <pitti> Keybuk, Kamion: okay, I go with the Recommends: approach if there is consensus about it
[09:47] <Kamion> I can't say I really like it, but I like all the other options less
[09:47] <Kamion> dunno about Keybuk
[09:48] <pitti> Kamion: same for me :-)
[09:48] <Keybuk> the other option would be to name the packages differently
[09:48] <Keybuk> so l-p-en-update becomes l-p-en
[09:48] <Keybuk> and l-p-en becomes l-p-en-base
[09:48] <Keybuk> or something, so users install the right one :p
[09:48] <pitti> how should that help?
[09:48] <pitti> ah
[09:48] <Keybuk> social rather than physical engineering
[09:48] <Kamion> that seems reasonable
[09:50] <Kamion> although getting rid of l-p-*-update that people have already installed would be interesting
[09:50] <Kamion> wonder what a dist-upgrade would pick out of A conflicts,provides,replaces B and B pre-depends,replaces A  :)
[09:50] <pitti> So l-p-en would Replace and Provide l-p-en-update
[09:51] <pitti> but what about the l-p-en-base?
[09:51] <Kamion> I think it would have to Conflict too
[09:51] <pitti> it can't provide and replace l-p-en
[09:51] <pitti> what a mess...
[09:51] <Kamion> doesn't need to
[09:51] <pitti> versioned conflicts, probably
[09:52] <Kamion> l-p-en C,R,P l-p-en-update, l-p-en Pre-Depends,Replaces l-p-en-base, l-p-en-base Recommends l-p-en and Replaces old versions of l-p-en
[09:52] <Kamion> ?
[09:58] <pitti> Kamion: I'm not _really_ fond of renaming all the packages, but if it is really required...
[09:59] <Kamion> needs a fair bit of testing with a private archive, I suspect, to make sure it actually does the right thing
[10:05] <Kamion> pitti: this sounds like it might take more than a day to get right. Could I have a temporary solution so that I can release Array 6 tomorrow, maybe just reverting the Depends->Pre-Depends change?
[10:05] <Kamion> unless you're confident it can happen by tomorrow
[10:06] <pitti> Kamion: just changing s/Depends/Recommends/ is relatively easy
[10:06] <pitti> Kamion: I just have to reupload all base packages
[10:06] <pitti> Kamion: doing the rename and dependency changes can be done tomorrow as well
[10:07] <pitti> Kamion: it's not much more work compared to just s/Depends/Recommends/
[10:07] <pitti> Kamion: when is array 6 due? I. e. what exactly would be my deadline?
[10:08] <Kamion> sometime tomorrow, no specific time
[10:08] <Kamion> ok, whatever you think's best
[10:08] <Kamion> if you could be contactable for a few hours after you make the change so that we can pick up on any problems, though, that would be good
[10:09] <pitti> sure
[10:10] <Kamion> thanks
[10:10] <pitti> Kamion: let's say I do this as very first thing tomorrow (too tired today)
[10:10] <Kamion> pitti: ok, sounds good
[10:10] <pitti> Kamion: then it can be ready, tested and uploaded by 1000 UTC
[10:10] <Kamion> pitti: where are the langpacks generated? I assume it's some machine in the DC
[10:11] <pitti> Kamion: I put some example packages onto p.u.c for testing before
[10:11] <pitti> Kamion: maybe you can test the packages as well
[10:11] <pitti> Kamion: yes, that is rookery:/srv/langpack...
[10:11] <Kamion> yep, can do
[10:11] <Kamion> ah, of course
[10:11] <pitti> Kamion: I think your dependency scheme looks right
[10:12] <Kamion> pitti: it was kind of off the top of my head, and I'm not sure I know all the constraints on language packs, so ...
[10:13] <pitti> Kamion: so far the only integration is with the installer
[10:13] <dredg> question: would it be worth having a page on the wiki with locations and names of people prepared to sign keys (on seeing valid ID of course)?
[10:14] <Kamion> pitti: well, I was thinking more of requirements; the various meetings mentioning it made my head spin
[10:14] <ogra> dredg: sure
[10:14] <dholbach> we should have jdub's world map for ubuntu as well
[10:14] <ogra> dredg: jdub madesomething and i think mako could have some data for it
[10:14] <pitti> Kamion: well, I won't change the structure and contents of the packaging, the mere name should just be obvious
[10:15] <Kamion> pitti: -update is just a bandwidth-saver, right?
[10:16] <pitti> Kamion: yes, this is the one we regenereate daily
[10:16] <Kamion> ok
[10:16] <pitti> Kamion: relative to the most recent base
[10:16] <Kamion> oh, I don't expect changes here for hoary, but any reason why -update doesn't just install files in a different location?
[10:17] <pitti> Kamion: because then we needed a third gettext path and a complicated three-way comparison in glibc
[10:17] <Kamion> fair enough
[10:17] <pitti> Kamion: and to save space
[10:17] <pitti> Kamion: otherwise you would have most of the files twice
[10:18] <dredg> ogra: ok, i might poke jdub with it next time he's about
[10:19] <ogra> dredg: yup, do that, and ask mako for keyholder data, he might have a list
[10:21] <mako> dredg: well.. we don't require signatures from people who are ubuntu developers (yet)
[10:21] <mako> ogra, dredg: we are mostly concerned with anybody in the strongly connected set
[10:21] <mako> the best site i know of for doing that sort of coordination is biglumber
[10:23] <dredg> mako: what i was getting at is hypothetically, i get my key into a strongly connected set associated with ubuntu by ubuntu people, and prospective members/maintainers could for example, contact me to have their key signed.
[10:23] <dredg> mako: this is ireland. not a big place :)
[10:24] <pitti> good night everybody
[10:24] <ogra> night pitti, and thanks forthe work
[10:24] <ogra> hrm
[10:25] <sivang> ogra: yep, he's quick :)
[10:25] <ogra> heh
[10:26] <Kamion> dredg: I'll probably be over there in August, but I think keysigning on one's honeymoon is deprecated ;)
[10:27] <dredg> Kamion: no, it's the new cool thing.. ors..
[10:27] <dredg> plus i'm more likely to be in the UK before then :)
[10:28] <mdz> lamont: ping?
[10:30] <lamont> ack
[10:30] <lamont> Kamion: deprecated, possibly.  But should still be doable, yes?
[10:31] <Kamion> lamont: hypothetically, but it ain't gonna happen :)
[10:31] <lamont> heh
[10:32] <lamont> hrm.. mdz ping and run?
[10:32] <Kamion> hm, is auckland not syncing at the moment?
[10:34] <lamont> Kamion: 1.06ubuntu5?
[10:34] <mdz> lamont: name of the powerpc porting box?
[10:34] <lamont> davis
[10:35] <Kamion> lamont: yes
[10:35] <lamont> it's installed according to my information
[10:36] <lamont> (although the file dumps are from 6 min ago)
[10:36] <lamont> haven't looked further back for when it really transitioned to installed
[10:37] <mjg59> Kamion: Someone's just posted hotplug patches for macio
[10:37] <Kamion> mjg59: mdz sent me some of those a while back, I never had time to review them :(
[10:37] <Kamion> having those would rock, though
[10:38] <Kamion> lamont: if I uploaded debian-installer now, would it be built against choose-mirror 1.06ubuntu5?
[10:38] <lamont> yes
[10:43] <mdz> mjg59: Jeff Mahoney?
[10:44] <seb128> lamont: can you kick bug-buddy build please ?
[10:45] <lamont> seb128: and it'll now magically find xmllint and xsltproc?
[10:45] <lamont> kicked
[10:45] <mdz> Kamion: do you have an array 6 todo list?
[10:46] <seb128> lamont: I've fixed gnome-doc-utils so it should
[10:46] <mdz> Kamion: I' m ready to do a full round of live+install testing
[10:46] <Amaranth> beagle doesn't need inotify anymore?
[10:47] <zul> Amaranth, apparently not
[10:49] <lamont> doko: aspell-sl is ftbfs, as reported in debian
[10:50] <mako> dredg: big enough
[10:52] <Kamion> mdz: I've been hoping to get a new kernel first, primarily, and there's these langpack changes
[10:53] <mdz> who are we waiting on for the kernel?
[10:53] <Kamion> lamont: do you know what's happening there?
[10:53] <mdz> if there isn't any particular reason to believe that we'll be able to use inotify for Hoary, there isn't any point in that bit
[10:54] <lamont> Kamion: t-bone is having screaming fits at baz, that much is known
[10:54] <Kamion> I'd like to have nfs-modules-*.udeb, it's fairly important for kickstart
[10:54] <mdz> is there any way that I can set up a powerpc system to boot from CD by default?
[10:54] <jon1012> good night all ^^
[10:54] <sivang> night jon1012
[10:55] <mdz> lamont: what do t-bone and baz have to do with the hoary kernel update?
[10:55] <Kamion> mdz: nvsetenv boot-device <something> ought to do it
[10:55] <T-Bone> mdz: maybe the fact that i'll be uploading next release
[10:55] <Kamion> mdz: possibly nvsetenv boot-device cd:
[10:56] <zul> mdz: about inotify tseng and i are testing something that we found
[11:03] <rubenv> mjg59: fabbione: what's the basic difference between booting in recovery and normal?
[11:04] <lamont> mdz: t-bone was doing the prepwork for this upload
[11:04] <rubenv> mjg59: fabbione: basically it boots with the recovery kernel and runs well, with the normal kernel, it just flunks out after a while
[11:04] <lamont> I have a diff of his tree, worst case I'll wind up reimporting it into baz here.
[11:04] <rubenv> for no specific reason
[11:05] <lunitik> rubenv: I think these are more topics for #ubuntu
[11:05] <Kamion> mdz: however the big change in the kernel is enabling ATAPI support in libata, which is a sabdfl item
[11:06] <Kamion> well I say "big", I think it's an #ifdef change :)
[11:06] <rubenv> lunitik: i know what's the difference, but this is a crashing kernel
[11:06] <rubenv> not a user issue
[11:06] <mdz> an #ifdef change which effects detecting the disks in all SATA systems, yes :-)
[11:06] <mdz> lamont: the kernel packages are in baz?
[11:07] <lunitik> rubenv: umm... its more a usage issue than a devel issue
[11:07] <Kamion> yeah ... I don't think I'm going to get away with not at least trying it, though
[11:07] <Kamion> rubenv: the "normal kernel" and the "recovery kernel" are the same kernel
[11:07] <rubenv> lunitik: a kernel that crashes after about 2 minutes for no specific reason is well, crap
[11:07] <rubenv> Kamion: yeah, i figured so too, reading from the grub conf
[11:07] <zul> Kamion: its been tested though
[11:07] <rubenv> hmmm
[11:08] <Kamion> recovery mode is just single-user, it's doing rather less work
[11:08] <Kamion> zul: *nod*
[11:08] <zul> and it was glemmed from mandrake
[11:08] <rubenv> yeah, but after booting on from single, it shouldn't start anything that can cause the kernel to hang?
[11:08] <Kamion> zul: don't get me wrong, I think it's a good idea, we'll just have to be quick about testing it and if necessary reverting
[11:09] <jbailey> rubenv: In general you can't promise that.  You need hotplug to get you usb keyboards and such.
[11:09] <rubenv> jbailey: it's a laptop :(
[11:09] <zul> Kamion:yep
[11:09] <rubenv> it's strange shit man
[11:09] <lamont> mdz: we imported the debian portion into baz
[11:09] <lamont> er, debian/ directory
[11:10] <lamont> seb128: same failure
[11:10] <seb128> graaa
[11:11] <lamont> seb128: which version of which package did you assert fixed it, and I'll verify that we actaully got that version
[11:11] <seb128> lamont: don't bother there is a build-depends issue too, I'll fix it right now :)
[11:11] <seb128> Uploading via ftp evolution_2.1.6.orig.tar.gz: Error '(32, 'Broken pipe')' during ftp transfer of evolution_2.1.6.orig.tar.gz
[11:11] <lamont> heh
[11:11] <seb128> GRRRRRRRAAAAA
[11:12] <seb128> hate this bug
[11:12] <lamont> seb128: you need smaller packages. :-)
[11:12] <seb128> that's an option
[11:13] <seb128> somebody willing to maintain gtk and evolution here ? :p
[11:13] <zul> uh....no..
[11:13] <ogra> seb128: what do you pay ?
[11:13] <seb128> that's for free
[11:13] <ogra> lol
[11:13] <seb128> you will have a lot of fun with them
[11:13] <seb128> that's better than money :)
[11:14] <ogra> yup, i already have....every day ;)
[11:14] <zul> T-Bone: you masochist you
[11:14] <T-Bone> zul: i must be. Baz's my bitch :P
[11:14] <zul> heh
[11:14] <ogra> T-Bone: you should talk to fabbione about that ;)
[11:15] <zul> when is he suppose to be back anyway?
[11:15] <ogra> zul: i thought you should know that
[11:16] <ogra> s/should/would
[11:19] <zul> yeah but i forget things easily :)
[11:21] <lamont> Kamion: you around?
[11:23] <jdub> elmo: ping
[11:24] <Kamion> mdz: re testing, I'm actually more or less in sync with live CDs now
[11:25] <seb128> jdub: new gamin :p
[11:27] <zul> Arrogance: are you in ontario?
[11:28] <Arrogance> zul, yes
[11:28] <Arrogance> Toronto
[11:28] <zul> i c
[11:29] <jdub> seb128: yeah, saw
[11:32] <zul> lamont: check out #ubuntu-kernel for a sec
[11:33] <Kamion> night all
[11:33] <dholbach> bye Kamion
[11:33] <dholbach> sleep tight :-)
[11:33] <ogra> Kamion: night
[11:34] <zul> night kamion
[11:37] <lunitik> modconf in warty, dropped in hoary?
[11:40] <sivang> lunitik: was dropped upstream IIRC
[11:40] <sivang> lunitik: ah oops,
[11:40] <sivang> lunitik: I thought you were talking about alsaconf
[11:41] <lunitik> sivang: heh... nah... someone is asking about it... its listed in the archive though, and I don't see it, so I'm guessing it was dropped for hoary
[11:41] <lunitik> sivang: personally, I don't see why someone would use it... but whatever
[11:42] <gma> I'm using glade on warty to create a UI with a GtkFileChooserDialog in it.
[11:42] <gma> but libglade doesn't know about the widget
[11:42] <sivang> lunitik: probably
[11:42] <gma> is there a known version number mismatch on warty?
[11:44] <sivang> lunitik: I wonder if you can install it from universe he he
[11:45] <lunitik> sivang: nope... I have that enabled
[11:46] <sivang> lunitik: I see, then probably not.
[11:46] <sivang> lunitik: I actually used it when I dind't know the exact name of the module i was requiring once
[11:49] <sivang> lunitik: right, google know
[11:49] <sivang> (s)
[11:51] <lunitik> Why oh why isn't Evince in main, and replacing GGV and XPDF yet?  *cries*
[11:51] <lunitik> Plus... why isn't eog going bye bye due to gthumb?
[11:52] <lunitik> Only complaints I have with Ubuntu right now  *still_crying*
[11:52] <jdub> they do different things
[11:52] <Mithrandir> gthumb also eats _loads_ of ram.
[11:52] <lunitik> jdub: what does eog do that gthumb can't?
[11:52] <jdub> lunitik: it's a simple, no-nonsense image viewer.
[11:53] <lunitik> jdub: gthumb is fast here... and is pretty basic while still doing what I need... I can't remember the last time I actually used eog on purpose
[11:53] <mxpxpod> also, what does eog do that nautilus can't do?
[11:54] <lunitik> I don't think I ever have actually
[11:54] <Mithrandir> gthumb uses 250MB of RAM for rotating a picture her.
[11:54] <lunitik> mxpxpod: actually... I think nautilus uses eog... should be using gthumb though  ^_^
[11:54] <jdub> mxpxpod: it's a simple no-nonsense image viewer.
[11:54] <lunitik> jdub: gdi... but it sucks  :(
[11:55] <lunitik> plus... thats trivial compared to other complaint
[11:55] <lunitik> So long as eog doesn't try to do anything, I'm happy... but XPDF is annoying, and ugly.
[11:56] <sivang> jdub: we should have a FAQ entry for the evince over xpdf issue :)
[11:56] <HrdwrBoB> if eog had a 'next' button'
[11:56] <HrdwrBoB> which progressed to the next picture in the directory
[11:57] <HrdwrBoB> .. it would be fine
[11:57] <lunitik> sivang: when evince is ready, I believe it will replace ggv and xpdf... but ever since wart preview, I have complained about xpdf being around, its even in kubuntu-base... I dislike it a great deal
[11:58] <lunitik> kubuntu-desktop
[11:58] <Mithrandir> HrdwrBoB: just click the first picture in the directory index and use the left and right buttons
[11:58] <sivang> lunitik: it does lack some nice gui frontending, but jdub noted to me sometime ago about some stuff evince is missing at the moment, the last time I asked him about it :)
[11:59] <lunitik> I even keep going over to Fedora simply because I don't want to ever see/use xpdf
[11:59] <jdub> ...
[11:59] <lunitik> The choice alone is just bad
[11:59] <HrdwrBoB> Mithrandir: I can see the preview in nautilus
[11:59] <jdub> it's difficult to take your input seriously with that kind of commentary
[12:00] <sivang> lunitik: that's hardly an applicable argument, I must admit.
[12:00] <Mithrandir> though, to be honest, eog uses loads of memory too.