[12:02] <Surak> What's the way to enable dma in boot time or even modifying the breezy live iso? I would like to test with the hardware we sell.
[12:02] <netstar> Does anyone have a copy of /etc/mkinitramfs/initramfs.conf used to generate the initrd for the latest kernels?
[12:02] <netstar> and /etc/mkinitramfs/modules
[12:03] <netstar> I am losing this battle here
[12:06] <karlheg> jbailey, Have you looked at the patch I sent for initramfs-tools?  Will you apply it?  Will you push that to the bzr mirror?
[12:07] <karlheg> I have some changes in progress for the man page also.
[12:09] <Surak> Lathiat: I mean, with D-I commands, not changing /etc/hdparm.conf. Can this be done?
[12:11] <jbailey> karlheg: I have looked at them.  I'm uncomfortable with the directory move and the variable name change at this point, although I think both probably make sense after breezy releases.
[12:11] <jbailey> karlheg: I need to poke abentley for help getting bzr-push to work again.  I'll do that now.
[12:12] <Nafallo> jbailey: will you guys put bzr-tools in the archive at some point? ;-)
[12:12] <jbailey> Nafallo: Yes.  Although I'll put it up on my snapshot site first.
[12:13] <Nafallo> jbailey: oki, I'll probably build it locally till then ;-)
[12:14] <jbailey> Nafallo: Well, with any luck you'll have it in the snapshot section tonight. =)
[12:14] <jbailey> Nafallo: Failing that, you could build it and uploaded it and become a motu ;)
[12:15] <Nafallo> jbailey: I am a MOTU already ;-)
[12:15] <jbailey> Excellent!!!
[12:15] <jbailey> =)
[12:16] <Nafallo> that's why I will have to be carefull with dput if I build it ;-)
[12:16] <Nafallo> :-)
[12:22] <sabdfl> argh
[12:22] <sabdfl> Kamion: ping
[12:23] <karlheg> jbailey, Can you easily rework the patch, or do you need me to do that?
[12:23] <ajmitch> pitti: ping
[12:23] <Evaso> hi guys whois packaging prism54 driver for breezy?
[12:23] <jbailey> karlheg: I can no prob.
[12:23] <karlheg> For the variable name change, what about if, for now, both 'version' and 'VERSION' are defined, deprecating 'version'.
[12:23] <jbailey> karlheg: I was hacking on klibc to convince it to do jfs for a bunch of today.
[12:23] <jbailey> It's in prep for other initramfs pieces.
[12:24] <pitti> Hi ajmitch
[12:24] <ajmitch> pitti: n/m - build was still trying with older libgphoto2-2 :)
[12:24] <Evaso> there are some cards (for example netgear wg511v2) that are softmac cards
[12:24] <ajmitch> hi anyway :)
[12:24] <Evaso> drivers are here: http://jbnote.free.fr/prism54usb/
[12:24] <karlheg> For the directory move, what about if a postinst snippet can move the files to the new location?  It's much easier to copy the scripts to the initramfs image with them in their own subdirectory like that.  No package so far is shipping /etc/mkinitramfs/* conffiles, afaict.
[12:26] <karlheg> The thing is that if a local admin created an entirely new set of directories, by cloning 'nfs' or somesuch, they will automatically get copied if /etc/mkinitramfs/scripts/* are all copied to ${DESTDIR}/scripts.
[12:26] <karlheg> Before the patch, it does not copy anything at all from /etc/mkinitramfs/*.
[12:26] <karlheg> ... but should.
[12:26] <sabdfl> Evaso: could you ping BenC about that, please?
[12:26] <sabdfl> BenC: ping
[12:26] <sabdfl> ^^ re prism54 drivers
[12:26] <karlheg> Nobody noticed because no packages use those locations.  I use them for local hacks.
[12:27] <sabdfl> Evaso: perhaps mail him<EMAIL_ADDRESS>should work
[12:28] <karlheg> I think it would be useful to have sort of a reverse-depends feature, for this, and for a dependancy-based 'init' script setup.  A local script may need to run before a packaged one, but the packaged one cannot depend on a script it doesn't know about.
[12:29] <karlheg> Of course number prefixed file-names will probably suffice in most cases.
[12:31] <lamont> dpkg-gencontrol: error: package mac-fdisk-cross not in control info
[12:31] <lamont> dh_gencontrol: command returned error code 65280
[12:31] <lamont> mac-fdisk_0.1-12 suckage
[12:34] <thierry> could anyone check ubuntu bug 14744 to apply the patch?
[12:53] <jbailey> Nafallo: My bzr nightly snapshot archive now contains bzrtools
[12:53] <jbailey> Nafallo: A quick caveat is that the previous tools that were in my packages don't exist anymore, since they're now plugins to bzr.
[12:53] <jbailey> Nafallo: If you'd been following Aaron's code anyway, then it won't matter to you.
[12:54] <Nafallo> jbailey: where is that archive? :-)
[12:55] <jbailey> deb http://people.ubuntu.com/~jbailey/snapshot/bzr ./
[12:56] <jbailey> Updated nightly.
[12:57] <Nafallo> kewl :-)
[12:58] <\sh> wth is bzrtools? importing and exporting bzr archives from/to svn?
[12:58] <\sh> ,-)
[12:59] <ajmitch> \sh: oh far more than that
[12:59] <ajmitch> jbailey: so this means we can have bzr-buildpackage soon too? :)
[12:59] <ajmitch> \sh: tailor is what you want for importing svn
[12:59] <jbailey> ajmitch: Angie's away this weekend, perhaps I'll hack it then.
[12:59] <jbailey> ajmitch: Anything bzrish I do is only in my spare time, which is running in short supply atm.
[01:00] <Nafallo> \sh: http://bazaar.canonical.com/BzrTools
[01:00] <Nafallo> :-)
[01:00] <jbailey> \sh: Mostly I use bzr push to copy my archives up to people.ubuntu.com
[01:01] <\sh> jbailey: nice :) we just had a discussion about security things...ssh accounts/rsync or webdav ,-)
[01:01] <jbailey> \sh: context?
[01:01] <jbailey> (which 'we'?)
[01:02] <\sh> jbailey: having a bzr archive for some source...and to commit your local changes towards the public one (public means user auth secured)
[01:02] <\sh> jbailey: Nafallo, slomo and I
[01:02] <Nafallo> MOTUIM ;-)
[01:02] <\sh> the three from the garage ,-)
[01:02] <jbailey> \sh: Right, the problem is that there's isn't centralised commits yet, so you'll still need something like pqm to manage it for you.
[01:02] <thierry> could anyone check ubuntu bug 14744 to apply the patch?
[01:02] <\sh> well...actually u don't know this german movie with heinz ruehmann
[01:02] <jbailey> It's coming, but it's not here yet,AFAIK.
[01:03] <thierry> \sh : you asked to tell this here but nobody answered me yet
[01:03] <\sh> thierry: because it's already in bugzilla...and someone will have a look...u can't force anyone :) actually it's feature freeze
[01:03] <thierry> oh ok... thanks anyway
[01:04] <jbailey> It's a silly typo fix. =)
[01:04] <\sh> thierry: I just had a look...and will check it today
[01:04] <\sh> jbailey: it means it will break the pot file
[01:04] <thierry> yeah
[01:04] <\sh> jbailey: pqm?
[01:04] <jbailey> Fix it in the 'english' translation in rosetta maybe?
[01:05] <jbailey> \sh: You're thinking StringFreeze rather than FeatureFreeze, I think.
[01:06] <jbailey> And that was Sep 1, so this can't get applied.
[01:06] <\sh> jbailey: right...
[01:07] <bddebian> infinity or lamont: ping?
[01:07] <lamont> bddebian: ack
[01:07] <bddebian> lamont: Can you please clear the dep-wait for libffi2 on g-wrap?
[01:09] <lamont> dine
[01:09] <lamont> done, evn
[01:09] <bddebian> lamont: Thank you sir
[01:12] <pitti> jordi: cool, CAN arrived, and Steven even figured out my real email address :-)
[01:18] <\sh> lamont: when u wanted to start a universe test build run, or is it already running?
[01:29] <lamont> \sh: not sure - I know elmo dumped at least main back into a fresh breezy-autotest run...
[01:32] <\sh> lamont: ok...so we have some more time to polish ;)
[01:39] <mdz> doko: ping?
[02:37] <infinity> \sh : I only looked at one build log, so I may be wrong here, but you're note doing those phpapi changes by hand, are you?
[02:37] <infinity> \sh : ie: Hardcoding the number in debian/rules?
[02:38] <\sh> infinity: no...php-config --phpapi
[02:38] <infinity> \sh : Cause what you really want there is `php-config4 --phpapi`
[02:38] <infinity> \sh : Okay, good. :)
[02:38] <\sh> infinity: but phpize is b0rked
[02:38] <infinity> \sh : No, it's not.
[02:38] <\sh> infinity: phpize is giving the wrong phpapi ver..
[02:38] <\sh> infinity: or is it intentionally?
[02:39] <infinity> \sh : No, it's not.  the "phpapi-###" virtual package is the highest number from PHP API, Zend Module API and Zend Extension API.
[02:39] <infinity> I should probably have renamed the virtual package, but since it's invisible to most users, I really didn't care much.
[02:40] <infinity> Maybe I'll break the world and rename it after breezy ships, just to piss everyone off again.
[02:40] <bob2> man php makes me want to gouge my eyes out
[02:40] <bob2> even hearing about that sort of thing
[02:40] <infinity> bob2 : Me too.
[02:41] <\sh> well...
[02:41] <infinity> The problem is that the ABI can change (and has done so) when any of those APIs increments, so in the intrest of my own sanity (and since 'phpapi-###' is there for module<->ABI compatibility), I rev it on a bump of any of those.
[02:41] <\sh> last php package for today from the unmet deps
[02:42] <infinity> But yeah, I should rename it to phpabi, I suppose, to make that obvious.
[02:43] <infinity> \sh : Anyhow, thanks for that.  I was going to do it this weekend during my "clean up universe in my spare time" Saturday, but I guess I'll now find something else to attack.
[02:43] <\sh> infinity: hehe...well, just bored ;)
[02:43] <\sh> infinity: but you can fix gnome-launch-box instead to honour the new gnome-menus api ;)
[02:44] <\sh> infinity: so rewriting this piece of software ;)
[02:44] <\sh> infinity: bah checking for imlib_load_image in -lImlib2... no
[02:44] <\sh> configure: error: Imlib2 module requires CVS Imlib2
[02:44] <infinity> ...?
[02:45] <infinity> php-imlib?
[02:45] <\sh> yes
[02:45] <slomo> infinity: you can't remove packages from the archives?
[02:45] <infinity>  /msg vorlon and smack him around.
[02:45] <infinity> slomo : no.
[02:45] <slomo> infinity: hrm... ok, then i have to wait for elmo or just break that package again until he deletes it ;)
[02:45] <\sh> infinity: he is what for php-imlib?
[02:46] <infinity> \sh : Upstream author and Debian maintainer.
[02:46] <\sh> infinity: I see :)
[02:46] <infinity> Oh, wait.
[02:47] <infinity> You pulled a new version of it?
[02:47] <infinity> In that case, it's your fault. :)
[02:47] <infinity> 0.5-1 that was in the archive before should have built fine.
[02:47] <\sh> infinity: no
[02:47] <infinity> Oh, someone synced it.
[02:47] <infinity> At some point.
[02:47] <infinity> Feh.
[02:47] <\sh> 0.5-1
[02:48] <infinity> Oh, wait. I just can't read.
[02:48] <infinity> Christ.
[02:48] <\sh> who? I will give him a hiding ,-)
[02:48] <infinity> I'll go get something to wake me up, then come back and be coherent.
[02:48] <HrdwrBoB> is gnome-cups-manager supposed to be broken?
[02:48] <bob2> ETOOEARLY
[02:49] <infinity> 0.5-1 built fine previously.
[02:49] <jdub> NOOOOOOOoooooo......!
[02:49] <infinity> Probably a broken autoconf test of some sort.
[02:49] <\sh> or a new imlib2 version?
[02:49] <infinity> Yes, but newer shouldn't be an issue.
[02:50] <infinity> jdub : Which one?
[02:50] <jdub> ooh, maybe it's worse
[02:50] <jdub> i have a pdc40719 card
[02:51] <jdub> sata_promise
[02:51] <jdub> 2.6.13-git4 has an entry for the 40718
[02:51] <jdub> and an id patch for the 40519 (which i misread)
[02:53] <\sh> infinity: I'll check if there is a new upstream;)
[02:55] <infinity> \sh : Just the one with the added vi.po (ie: no code changes).
[02:55] <\sh> infinity: in debian there is 0.5-2
[02:56] <infinity> \sh : Yes, see above.
[02:56] <\sh> infinity: lemme try it...and eventually ask elmo for a sync
[02:56] <infinity> \sh : The only thing added in -2 is a vietnamese translation.
[02:56] <\sh> ok
[02:56] <infinity> \sh : On the other hand, our libimlib hasn't changed either, so I still assert that this is just a goofy/broken autoconf check.
[02:57] <infinity> \sh : And if you can't figure it out, leave it to me and I'll fix it later.
[02:57] <infinity> \sh : I can either fix it, or smack vorlon around, since we have years of violent history. :)
[02:57] <\sh> infinity: I just queried him
[02:57] <\sh> infinity: he doesn't know me ;)
[02:59] <\sh> grmpf..i have to clean the hallway today
[02:59] <infinity> slomo : What did you want removed?... haskell-cabal?
[02:59] <slomo> infinity: yes
[02:59] <infinity> slomo : Yeah, okay, me too. :)
[03:00] <ogra> \sh, you still didnt do it ... ?
[03:00] <\sh> ogra: no :(
[03:00] <slomo> infinity: i have all the haskell stuff lying on my hdd... is just can't upload because of this crappy package ;)
[03:00] <\sh> ogra: I'm a lazy bastard
[03:00] <ogra> \sh, nah
[03:00] <\sh> ogra: but today after I'm leaving bed ,-)
[03:00] <infinity> elmo : Can we get haskell-cabal dropped from the archive and blacklisted from syncs?  It breaks the world, and ghc6 >= 6.4 no longer needs/wants it anyway.
[03:00] <slomo> infinity: but i removed the depend in haskell-devscripts on cabal... so most stuff should be fine for most stuff
[03:01] <slomo> infinity: (correct grammar ;) )
[03:01] <infinity> slomo : Kay, cool.  Thanks.  I'll have to run through all the buildds in a few minutes and see if any of the chroots are still broken from libghc6-cabal-dev sucking.
[03:01] <infinity> slomo : Did you unbreak libghc6-hsql-dev while you were at it?  (It's uninstallable too, but not for the same reason)
[03:01] <\sh> infinity: same issue with 0.5-2 so I think I will deal with config.m4 to get it straight
[03:01] <slomo> infinity: it broke the chroots? wonderful ;)
[03:02] <slomo> infinity: i have it on my hdd... need to try it again after cabal is gone
[03:02] <slomo> infinity: does libghc6-hsql-dev also have a broken postinst?
[03:02] <infinity> slomo : Does ghc6 6.4 completely replace the need for cabal-dev?
[03:03] <slomo> infinity: yes
[03:03] <\sh> ogra: and u r not sleeping ,-)
[03:03] <bddebian> Hey, don't we need a cabal to be like Debian?? ;-PO
[03:03] <bddebian> -0
[03:03] <ogra> \sh, on my way to bed :)
[03:04] <infinity> slomo : Cause, if so, you could do something icky like conflict against it to make sure it never gets pulled into a build using ghc 6.4
[03:04] <infinity> slomo : yes, hsql-dev's postinst is broken too, but it looks like it's due to the pgsql migration/shuffle at first glance.  Didn't look into it.
[03:04] <slomo_> infinity: haskell-devscripts had a depend on "libghc6-cabal-dev | ghc6"
[03:04] <slomo_> infinity: and my cabal upload a few seconds ago was braindead... well, it will fail anyway...
[03:05] <slomo_> infinity: ok, i'll try to fix it
[03:05] <BenC> what's the correct option to disable framebuffer in the installer: debian-installer/framebuffer=false ?
[03:05] <\sh> infinity: the function for checking imlib2 is broken somehow
[03:05] <bddebian> slomo_: You ROCK as always too :-)
[03:05] <infinity> \sh : No surprise there.
[03:05] <\sh> ogra: good night :) when I fixed this imlib crappy thingy here I'll go to bed as well
[03:05] <infinity> \sh : Just leave it to me.  I'll attack it today.
[03:06] <infinity> BenC : Yes.
[03:06] <BenC> infinity: thanks
[03:06] <infinity> BenC : Also, given your rich debian/sparc heritage, you should know that by heart, given how many sparc machines blow up if the FB is on in the installer. :)
[03:07] <\sh> infinity: ok...your choice :)
[03:07] <\sh> but actually the rest built fine
[03:07] <infinity> \sh : Cool.
[03:07] <BenC> infinity: given that sparc requires framebuffer for any sort of video (outside of prom console), and that I always do my sparc installs the hardway (serial console), I've never used it before :)
[03:08] <bddebian> heh
[03:08] <infinity> Benc : Some of the sparcs I've installed on just do very, very weird things unlkess I disable d-i/fb... But yes, most I've done via serial, which completely eliminates the problem. :)
[03:08] <\sh> infinity: use 0.5-2 then ...
[03:09] <infinity> \sh : Yeah, if I'm going to be mucking with it anyway, I'll upgrade to -2 first to get that extra translation.
[03:09] <slomo_> infinity: did you also want to fix the haskell stuff? or just hsql?
[03:10] <infinity> slomo_ : No, I want YOU to fix hsql.. I can't be bothered. :)  But I can revisit your cabal/ghc/devscripts changes and make sure it all looks sane to me.
[03:11] <slomo_> infinity: ignore my cabal changes... just pretend this package is already deleted ;)
[03:11] <slomo_> infinity: i just asked because you wanted cabal deleted too
[03:11] <infinity> slomo_ : You know, the problem would probably easily be masked by changing the order of that dependency from "cabal-dev | ghc6 (>> 6.4)" to "ghc (>> 6.4) | cabal-dev", so brain-dead parsers will be satisfied with the first, first.
[03:12] <slomo_> infinity: i know... but it doesn't matter for us anyway... we don't have a ghc << 6.4 ;)
[03:12] <infinity> Yes, true.
[03:12] <\sh> infinity: I'm speaking to vorlon right now ;)
[03:12] <slomo_> infinity: is it defined, that the first conditional dependency is tried first?
[03:13] <infinity> slomo_ : Anyhow, anything you can do to make sure all the libghc* stuff is actually installable, buildable, and working would be great.  Because we waited so long to bootstrap ghc6, I suspect a lot of haskell stuff is a bit goofy.
[03:13] <infinity> slomo_ : And I have a lot of main bug reports to work on right now.
[03:14] <slomo_> infinity: ghc6 isn't bootstrapable currently? how did we get the working package? :)
[03:14] <infinity> slomo_ : Well, not exactly, but if you have "foo | bar (>> 2), bar" (which is what we have in that package), bar is already pulled in by the "and" dependency, so we're free to pull in foo for the "or", (and probably will, because it's first in the list)
[03:15] <infinity> slomo_ : It is bootstrappable NOW.
[03:23] <\sh> infinity: I'd send vorlon a config.log...it's a mess
[03:26] <Lathiat> fabbione: kernel good so far
[03:28] <slomo_> are the ppc buildds dead?
[03:30] <slomo_> infinity: how can i remove a broken hsql package after partially installing it? ;) dpkg --remove fails because of broken prerm
[03:31] <infinity> The prerm isn't broken, but it fails because the postinst never finished.
[03:32] <infinity> Just comment out the call to unresgister it in the prerm.
[03:32] <infinity> (/var/lib/dpkg/info/libghc6-hsql-dev.prerm)
[03:32] <\sh> ok..another dosis of iron maiden for today
[03:32] <slomo_> \sh: good choice :)
[03:33] <bddebian> pfft Metallica baby ;-)
[03:33] <\sh> bddebian: baby music ;)
[03:34] <\sh> but I could watch metallica - whisky in the jar video ,) with all those drunken b*tch*s
[03:38] <bddebian> Heh
[03:50] <mjg59> Is there any easy way to get stats out of bugzilla?
[03:50] <mjg59> I'd be interested in knowing how many people have more assigned bugs than me...
[03:51] <infinity> Haha. :)
[03:51] <jdub> mjg59: luis is a good person to ask :)
[03:51] <elmo> bugzilla _better_ have good stats since luis was pimping them to hard as bugzilla's winning feature
[03:51] <infinity> elmo : Can I get php-imap synced?
[03:52] <bddebian> Hey, stand in line ;-P
[03:52] <mjg59> Nnngh.
[03:53] <mjg59> I have 120 open bugs for which I'm owner
[03:53] <bddebian> Nice
[03:53] <mjg59> Plus some more where I'm on the Cc list and effectively dealing with it
[03:53] <bddebian> Want some Malone bugs too? ;-)
[03:53] <mjg59> Ah, yes, 200 in total.
[03:53] <mjg59> Hurrah!
[03:54] <mjg59> Sorry, only 156 open
[03:54] <mjg59> Out of 3280 open bugs
[03:54] <mjg59> I own 5% of open bugs? Seriously?
[03:55] <bddebian> Feels good to be wanted doesn't it?
[03:55] <mjg59> Nngh. Ang 728 of those are debzilla, which takes me to 156 out of 2500
[03:55] <\sh> infinity: it can't find X libs stuff...
[03:55] <bddebian> \sh: Which one?
[03:56] <\sh> bddebian: php-imlib
[03:56] <bddebian> I meant which X lib stuff :-)
[03:57] <\sh> bddebian: yes..php-imlib needs some X libs ,-)
[03:57] <bddebian> Grr
[03:57] <mjg59> Daniel has 173, Colin has 312, Ben has 362 (but inherited all of the kernel bugs), mdz only has 73!
[03:57] <\sh> actually imlib2 needs it and php-imlibs tries to link against imlib2 + -lX11
[03:58] <bddebian> I guessed, that, what's it failing on? Ohh
[03:58] <infinity> \sh : Ahh, easy enough to fix, then.
[03:58] <\sh> infinity: but normally imlib2 should pull them in
[03:59] <\sh> infinity: anyways trying to fix it
[03:59] <infinity> \sh : Uhm, libimlib2-dev DOES pull in libx11-dev, so something else in that test is failing.
[04:00] <slomo_> infinity: working hsql uploaded :)
[04:00] <\sh> infinity: I'll see it right now...the configure test is not linking towards -lX11
[04:01] <infinity> slomo_ : Cheers.
[04:01] <jbailey> mjg59: What %age of RC bugs do you have? =)
[04:01] <\sh> infinity: no wonder checking for X... libraries /usr/X11R6/lib, headers in standard search path
[04:01] <mjg59> jbailey: Good question. No idea...
[04:01] <jbailey> I have 30/251 =(
[04:01] <mjg59> Maybe I should ask for a big pile of money :)
[04:01] <jbailey> Mostl either evolution-exchange or initramfs-tools, though.
[04:02] <jbailey> The first is annoying, but the second I can actually do something about.
[04:02] <mjg59> What does RC count as?
[04:02] <jbailey> Maj and above.
[04:02] <jbailey> Thinking of which, can you comment on 7463 so hat I can deal with it?
[04:02] <jbailey> It's the recover-the-swap link that you sent to me.
[04:02] <mjg59> I've got 14 of them
[04:03] <jbailey> mdz said basically that it sounds reasonable and asks for your feedback.
[04:03] <jbailey> I might not actually have 30.  My query also includes RC bugs that I'm cc:'d on.
[04:03] <mjg59> Yeah, me too
[04:03] <mjg59> I generally assume that if I'm on the cc, either someone wants it to be my fault or I'm taking the blame anyway...
[04:03] <bddebian> heh
[04:04] <mjg59> Nnngh.
[04:04] <mjg59> jbailey: Done
[04:04] <infinity> Deleting bugzilla mails is one of my favourite passtimes.
[04:05] <jbailey> mjg59: You could do my solution and just tell bugzilla not to send them.
[04:07] <jbailey> infinity: Hey, ppc hasn't done klibc yet.  Is the buildd having issues?
[04:08] <infinity> jbailey : One buildd is offline, cause it's acting up, the others are probably stuck building Big Things, but I'll check.
[04:09] <jbailey> I'm not too fussed, it's just unusual that a small package wouldn't have showed up by now on only one arch.
[04:09] <infinity> Yup, Openoffice on adare and gcc-4.0 on ross.
[04:10] <jbailey> Cool, I'll check it again in the morning.
[04:10] <jbailey> I wrote it on a ppc box, though, so there's no risk.
[04:10] <infinity> It'll all clear itself up and be happy again soon enough.  There's only 20 package sin needs-build for powerpc, so it's not exactly "behind".
[04:10] <mdz> mjg59: you're CCed on bugs because you don't answer on IRC ;-)
[04:10] <elmo> infinity: err, acting up?
[04:10] <infinity> elmo : Yes, I need to dig around the chroot and make sure it's not my fault, then bug you if it looks like hardware.
[04:10] <mjg59> mdz: Dude, I'm too busy having a life
[04:10] <mdz> mjg59: regarding #6108, any reason not to go ahead with the workaround of avoiding hdparm -B?
[04:11] <mjg59> mdz: No, assuming it works
[04:11] <infinity> elmo : royal's had an incredible number of segfaults that the other two haven't been seeing.
[04:11] <infinity> elmo : Like, just about every libtool invocation on royal segvs.
[04:11] <mjg59> The power saving probably isn't that great, but some time we should figure out what's actually going wrong
[04:11] <elmo> infinity: royal's also the one with the ghc fux0red chroot?
[04:11] <mjg59> Someone needs to bitch about it on LKML
[04:11] <infinity> elmo : No, that's cleaned.
[04:11] <mdz> mjg59: I was able to reproduce the bug on AC power in single-user mode with only hdparm -B
[04:11] <mdz> mjg59: so I'm pretty confident that'd work around the issue
[04:12] <mjg59> Ok
[04:12] <infinity> elmo : But the segv issue stands.  Unless it fixed itself overnight.  I need to test some stuff later, then email you if it's out of my domain.
[04:17] <Nafallo> elmo: could you sync sbackup from unstable and NEW it, please?
[04:19] <bddebian> Nafallo: No, you have to wait in line too! :-)
[04:19] <Nafallo> bddebian: :-P
[04:20] <bddebian> Although elmo could probably spend days with all the crap I keep sending the poor guy
[04:21] <\sh> infinity: fixed...now I make a patch
[04:22] <bddebian> \sh: rockin'
[04:27] <\sh> infinity: oh sh*t 2:27utc
[04:27] <infinity> ?
[04:27] <\sh> infinity: I should be in bed
[04:28] <infinity> Yes, you should be. :)
[04:28] <Nafallo> infinity: that means 4:27 local time ;-)
[04:28] <infinity> php-imlib isn't more important than sleep.
[04:28] <\sh> infinity: php-imlib works now .. after patching config.m4
[04:28] <Nafallo> for both me and \sh :-P
[04:32] <\sh> infinity: na..I don't like packages laying around unfixed ;)
[04:38] <\sh> infinity: 0.5-2ubuntu1 is hitting the archives...;)
[04:39] <bddebian> heh
[04:40] <\sh> bddebian: if u see elmo...gtk-gnutella from debian unstable can be synced..it fixes all ftbfs issues with gcc4 ....thx :)
[04:41] <bddebian> \sh: Sheesh do you guys WANT elmo to hate me? ;-)
[04:42] <\sh> bddebian: haha ;)
[04:42] <\sh> bddebian: do not worry...I tested it on amd64...so it's ok :)
[04:43] <bddebian> \sh: I'm not worried about your request, I have just been flooding the poor guy with sync requests :-)
[04:43] <\sh> bddebian: prepare some 6packs of your best local beer and send it via UPS
[04:44] <\sh> anyways I'm ready to go to bed...anything else?
[04:45] <bddebian> \sh: If Imake it to UBZ I'll have to buy himsome.. ;-)  Gnight man, good work as always! :-)
[04:46] <\sh> g'night gentlemen
[05:08] <khermans> I think I found a security vulnerability in mozilla-thunderbird on AMD64
[05:09] <khermans> if anyone can verify, msg me
[05:11] <wasabi> irc:// is never a registered protocol.
[05:11] <wasabi> I wonder if we should add that.
[05:14] <infinity> khermans : Only on amd64?
[05:14] <khermans> infinity, seems so
[05:15] <khermans> if someone can verify, let me know
[05:15] <infinity> Feh.  Kay, can't readily test right now, then.  Only my i386 machine is up.
[05:16] <khermans> it has to do with running the Import function
[05:16] <khermans> if you open the import tool, and it doesnt crash immediatly, you are not vulnerable
[05:16] <infinity> khermans : If you could mail<EMAIL_ADDRESS>and CC<EMAIL_ADDRESS>with details, that might be helpful.
[05:17] <khermans> ehh...im busy right now -- ill do it if someone else verifies it first, otherwise it could be one of my libs
[05:17] <khermans> gotta finish this scheme homework
[05:17] <infinity> Although, aI'm not sure how "the import tool crashes" is necessarily a security bug..
[05:19] <khermans> infinity, the data that the import tools read on startup may be causing it to crash -- i some weird things in the stack that should not be there
[05:19] <khermans> it is only a local vuln
[05:19] <infinity> Not even that.
[05:20] <infinity> The import tool could be reading everything from your home dir (and may well do so), but if it can only do so on your command, that's not a security hole, just something you odn't like.
[05:21] <khermans> it seems that another user on the system may be able to manipulate some things it does read on bootup, so if that is true, and they control them, and they are in the stack....
[05:21] <khermans> it doesnt really matter, i just came to see if anyone else had the same setup
[05:21] <infinity> Still a non-issue.  If the user can access those things with thunderbird, that means they can access them with, oh, say, 'cat'.
[05:21] <khermans> this is not anything like the firefox HOST vuln
[05:21] <infinity> khermans : I'd just file a bug about the crash, with a backtrace.
[05:22] <infinity> khermans : Being able to read files you have access to isn't a security issue. ;)
[05:22] <khermans> infinity, , did you know evolution mail client stores passwords very insecurely?
[05:23] <infinity> Surely it stores them in files with mode 700
[05:23] <khermans> haha
[05:23] <khermans> nope
[05:23] <Lathiat> where does it store them?
[05:24] <khermans> .gnome2_private, which is 700, but the file with the passwords is 744
[05:24] <khermans> and they are only base64
[05:24] <infinity> Oh, same thing.
[05:24] <Lathiat> ffs
[05:24] <Lathiat> you know
[05:24] <infinity> If the directory is 700, there's no problem.
[05:24] <Lathiat> your right
[05:25] <Lathiat> infinity: oh?
[05:25] <Lathiat> i thought you could still get at files just not readlist them
[05:25] <infinity> Yeah, directories have permissions for a readson, you know.
[05:25] <infinity> No.
[05:25] <Lathiat> ah
[05:25] <Lathiat> is ee
[05:25] <infinity> If you have read on a directory, you can list files, if you have execute, you can traverse, if you have neither, you can't go near it.
[05:26] <infinity> But don't take my word for it, you have a shell, you have the power to create test users, give it a try. :)
[05:26] <khermans> i know this is true, but still dumb to store passwords in base64
[05:27] <Lathiat> it ried it :)
[05:27] <Lathiat> khermans: what else are you going to store them in
[05:27] <Lathiat> khermans: its not going to be any more or less secure
[05:27] <khermans> do a hash, jeesh
[05:27] <Lathiat> err
[05:27] <Lathiat> khermans: and how do you propse to unhash the password to send to the server
[05:27] <infinity> It has to be a 2-way hash, or you can't GET IT BACK.
[05:27] <infinity> Storing it in base64 is snakeoil, though, it should probably just be sotred plaintext.
[05:28] <khermans> lol
[05:28] <infinity> But, whatever.  People base64 the thing to give a false sense of security, I'm sure.
[05:28] <infinity> (Or to allows for easier import/export of weird characters)
[05:28] <infinity> Either way, it's not a problem, cause only you can read the file.
[05:28] <Lathiat> well
[05:28] <Lathiat> if someone jumped  on my machine
[05:28] <Lathiat> at least they couldnt remember my password
[05:28] <infinity> Don't let them do that.
[05:28] <Lathiat> if they only had 2 seconds
[05:28] <Lathiat> :)
[05:29] <infinity> If they jump on your machine, they can just run your mail client.
[05:29] <Lathiat> sure but they cant do that later
[05:29] <Lathiat> :)
[05:30] <khermans> i hate computers, everything is insecure, code is horrible, always will be
[05:30] <infinity> But in this case, nothing is actually insecure.
[05:30] <infinity> Except if you let people shoulder-surf, or steal your hard drive.
[05:31] <khermans> infinity, but what about client side exploits?  your are totally vulnerable
[05:32] <daniels> khermans: so you propose that your client ... never knows your password?
[05:32] <infinity> If you tell the client to "save your password", it'll probably have it in memeory all the time anyway.
[05:32] <khermans> if i found a remote bug in thunderbird, knew you used it to acess your corporate mail, and your user/pass are stored in that evolution file in plain text, and i make it read and then send it back to me, well now you have a problem
[05:32] <khermans> sorry evo
[05:33] <infinity> Uhm, I can ull your mail password from tbird, too, not just evo.
[05:33] <bob2> daniels: encrypt it on the client, duh
[05:33] <infinity> And this has nothing to do with either.
[05:33] <bob2> then no one can steal it
[05:33] <infinity> If you don't want the client to know your password, don't click the box.
[05:33] <infinity> If a completely DIFFERENT bug allows you to read the stack of any application that knows one of your passwords, you are vulnerable, yes.  So, don't let them know your passowrds, or watch out for other exploits.
[05:34] <infinity> But having them know your passowrd isn't an exploit in and of itself.
[05:34] <daniels> khermans: er, I could use a client-side exploit in Firefox to steal your password, provided I can read files on the disk.
[05:34] <khermans> and thats the thing, encryption is never 100% either -- so there is always a vuln somewhere
[05:34] <daniels> i think what you're trying to say is that if someone has access to your user account, you're stuffed.
[05:34] <khermans> daniels, yea
[05:34] <fabbione> morning guys
[05:34] <daniels> and yeah, that's pretty true.  try not to let that happen.
[05:34] <khermans> lol, you go on the net, anyone has access to your machine
[05:35] <bddebian> Heya fabbione
[05:35] <fabbione> khermans: i remember i solved a problem like that with a user when i was working as sysadm
[05:35] <fabbione> it was very simple.. i just unplugged his power cord and left the room :)
[05:36] <khermans> hehe, 100% remote security
[05:36] <bob2> if your account is compromised, you lose
[05:36] <bob2> film at a11
[05:36] <wasabi> This argument sucks.
[05:36] <wasabi> Can we move onto discussing the best beer?
[05:36] <khermans> guiness
[05:36] <bob2> cooper's heritage
[05:36] <wasabi> Guiness is like drinking pudding.
[05:36] <bddebian> *lol*
[05:37] <bddebian> Newcaslte
[05:37] <infinity> wasabi : I propose we discuss why ant just failed to build in an autotest run.
[05:37] <bddebian> Err Newcastle even
[05:37] <wasabi> Awww. Do we have to?
[05:37] <bob2> I'd like to meet the persion who looked at make syntax and thought "...you know what this needs? some more xml."
[05:38] <wasabi> It's not that it needed XML.
[05:38] <wasabi> It was that reusing a XML parser was easier than writing a Makefile parser in Java.
[05:38] <bob2> if only someone had already written a make parser
[05:38] <bob2> they could call it "make"
[05:38] <daniels> wasabi: buckley's dark bock, bellevue kriek
[05:38] <bob2> and use it to build all sorts of things
[05:38] <wasabi> And Make doesn't very well handle compiling multiple files with one command
[05:38] <wasabi> Pssh.
[05:38] <wasabi> Java devs use java.
[05:38] <infinity> wasabi : http://people.ubuntu.com/~lamont/buildLogs/Test/a/ant/1.6.5-0ubuntu3/ant_1.6.5-0ubuntu3_20050914-0311-i386-failed.gz
[05:39] <wasabi> Or they'd be using python instead or something.
[05:39] <bob2> java devs only know java
[05:39] <bob2> which is a problem in itself
[05:39] <wasabi> Perhaps.
[05:39] <infinity> wasabi : Mithrandir has been changing a bunch of other java packages that were FTBFS, I assume this needs something similar.
[05:39] <wasabi> Cooper's heritage you say? Where can I find that?
[05:39] <bob2> wasabi: probably not outside .au
[05:40] <bob2> get daniels to bring some
[05:40] <wasabi> Oh.
[05:40] <wasabi> Looks like somebody changed the command line options on ecj.
[05:40] <wasabi> Oh.
[05:40] <wasabi> I bet it's because somebody upgraded ecj.
[05:47] <whiprush> howdy bob2
[05:48] <bob2> aloha
[05:48] <bob2> fridge?
[05:49] <whiprush> bob2: although, I've been slammed at work for 2 weeks, so yeah, I suck also.
[05:57] <daniels> cooper's heritage is indeed great stuff.  and I'm not flying through the US, so I might chuck a few in my bag.
[05:59] <jammcq> whiprush: HEY
[05:59] <whiprush> hi jam.
[05:59] <whiprush> see /msg
[06:00] <jammcq> hmm, nothing there
[06:00] <jammcq> are you registered?
[06:00] <jammcq> am I?, hmmmm
[06:01] <whiprush> thought I was. freenode seems content in making things difficult.
[06:01] <jammcq> yeah
[06:01] <jammcq> and everytime theres a netsplit, it seems I have to re-identify myself
[06:01] <whiprush> yeah, that's what happened to me.
[06:09] <fabbione> hey jamesh
[06:09] <fabbione> ops
[06:09] <fabbione> jammcq: hey
[06:11] <jammcq> hey fabbione, how's it going?
[06:11] <fabbione> jammcq: not extremely well... my ws is driving me nuts and i don't understand why
[06:11] <fabbione> it keeps turning off by itself
[06:11] <fabbione> (hw problem)
[06:11] <jammcq> hmm
[06:11] <jammcq> no fun
[06:11] <fabbione> no
[06:11] <jammcq> thermal issue?
[06:12] <fabbione> at least i managed to get it to stay up for a while
[06:12] <fabbione> i don't think so.. CPU is at 47C
[06:12] <fabbione> i did remove each single gram of dusts from it to be sure all the fans are working properly
[06:12] <fabbione> changed one of the power supply and so on...
[06:12] <jammcq> hmm, my workstation doesn't have a fan :)
[06:13] <fabbione> but it didn't help mych
[06:13] <fabbione> much
[06:13] <jammcq> in fact, my workstation doesn't have any moving parts at all :)
[06:13] <fabbione> jammcq: ehhe
[06:13] <fabbione> jammcq: well.. we still need to talk about that :)
[06:13] <jammcq> yep
[06:13] <fabbione> but i think we will take 2 of the one you suggested..
[06:14] <jammcq> we'll figure out some special pricing, to make the ubuntu guys happy
[06:14] <fabbione> jammcq: price isn't an issue.. really
[06:14] <jammcq> oh, in that case.... :)
[06:14] <fabbione> it's more important how we the deliver
[06:14] <fabbione> jammcq: well at least it is not for me...
[06:14] <fabbione> but i would love to be able to save in delivery and custom (if possible ;))
[06:15] <fabbione> that would make me happy enough
[06:15] <jammcq> yeah, that shouldn't e any problem
[06:15] <fabbione> specially because i will take them to dk
[06:15] <fabbione> and one them will travel to italy
[06:16] <fabbione> jammcq: otherwise, if you make a special price, we will use the difference for beer ;)
[06:16] <fabbione> and have extra fun at UBZ :P
[06:16] <jammcq> the beer margin :)
[06:16] <fabbione> eheh
[06:16] <jammcq> and Canada is the place to get some damn fine beer
[06:17] <fabbione> i tend to prefer belgium beer, but i guess whatever it's there will do
[06:21] <fabbione> elmo: ping?
[06:23] <fabbione> mdz: ?
[06:27] <jdub> daniels: is there a good proggy to use for lcd display autoconfiguration? nvidia has a nice one for windows
[06:27] <Lathiat> jdub: to configure what exactly?
[06:27] <Lathiat> jdub: nvidia-settings lets you fiddle a few values
[06:28] <jdub> not configuration
[06:28] <jdub> displaying a test screen
[06:28] <Lathiat> oh
[06:28] <jdub> for display-side autoconfiguration
[06:28] <Lathiat> to calibrate with
[06:28] <Lathiat> yeh
[06:28] <Lathiat> open X
[06:28] <Lathiat> with that backgroudn it defaults to
[06:28] <jdub> bong
[06:28] <jdub> ok
[06:28] <Lathiat> you know the checkered one
[06:28] <Lathiat> :)
[06:29] <jdub> better, but still has pretty bad shadowing
[06:31] <jdub> unfortunately the screen autoconfigures during the nvidia logo bit
[06:31] <Lathiat> ah
[06:31] <Lathiat> cant you ask it to tho
[06:31] <Lathiat> most things have an auto-adjust button
[06:32] <fabbione> Lathiat: how is it going with the test kernel?
[06:32] <jdub> yes, but it's autoadjusting against an inconsistent image
[06:32] <Lathiat> fabbione: good so far
[06:32] <fabbione> great
[06:32] <Lathiat> still need longer to see tho
[06:42] <fabbione_> grrrr
[06:42] <fabbione_> it
[06:42] <fabbione_> it's not a temperature problem...
[06:42] <fabbione_> it is more like the video card freezes
[06:46] <daniels> jdub: the X grey/black moire is the best for that
[06:47] <daniels> jdub: but it also shows up the slightest flaw in your display; it makes my 21" Trinitron weep
[06:48] <Lathiat> yeh its horrid on alot of crts
[06:48] <fabbione> daniels: are you aware of any way to monitor an nvidia temperature?
[06:48] <fabbione> (gfx.. not the chipset itself)
[06:48] <Lathiat> fabbione: if you are using the binary driver
[06:48] <fabbione> Lathiat: i do...
[06:48] <Lathiat> fabbione: nvidia-settings has it, and i hacke dup a program to dump it to stdout
[06:49] <Lathiat> i was graphing mine
[06:49] <fabbione> s/do/must do/
[06:49] <Lathiat> under 'thermal monitor' in nvidia-settings just to look at it
[06:50] <fabbione> i have no such thing like "thermal monitor"
[06:51] <Lathiat> kmm
[06:51] <Lathiat> perhaps your card doesnt support it?
[06:51] <Lathiat> its in the list between 'antialiasing settings' and 'display device' for me
[06:51] <fabbione> probably it doesn't
[06:51] <fabbione> there is no such thing
[06:51] <Lathiat> oh well
[06:52] <Lathiat> interestingly, i cant get that information from the nvidia stuff in windows
[06:52] <Lathiat> at least i couldnt find it
[06:52] <fabbione> hmmm
[06:55] <fabbione> i don't trust nvidia-settings anyway.. it finds only one of the 2 cards and one of the 3 monitors
[06:56] <Lathiat> heh
[06:57] <fabbione> i guess i will need to fiddle with the BIOS a bit more.. i start to believe it's not hw the problem
[06:57] <Lathiat> what happens?
[06:58] <fabbione> well the machine freezes hard (both windows and linux)
[06:58] <Lathiat> ah
[06:58] <Lathiat> memtest?
[06:58] <fabbione> in linux i can see that only the monitors connected to a specific card blank
[06:58] <fabbione> i did run memtest. memory is fine
[06:58] <fabbione> i suspect more an irq problem at this point in time
[06:58] <Lathiat> interesting
[06:58] <fabbione> at BIOS level
[06:59] <fabbione> because i noticed yesterday a lot of ERR in /proc/interrupts
[06:59] <fabbione> now i just enabled IO-APIC
[06:59] <fabbione> and the cards got different IRQ
[06:59] <fabbione> and no ERR
[07:25] <jdub> daniels: so with the nvidia test image in windows, which includes blocks of colour, it calibrates really nicely. with the X 'checkers', it still isn't quite right.
[07:25] <daniels> jdub: interesting
[07:26] <daniels> jdub: i guess the nvidia test image looks not unlike the sbs test image?
[07:28] <jdub> daniels: hrm, bit different
[07:28] <jdub> wonder if i can sshot it
[07:31] <jdub> haha, rad
[07:38] <jdub> daniels: http://people.ubuntu.com/~jdub/2005/nvidia-display-test.png
[07:38] <jdub> it's only 20K, but it's 1920x1200
[07:38] <Lathiat> jdub: interesting
[07:38] <ajmitch> shows how screwy my monitor is :)
[07:39] <Lathiat> heh
[07:39] <Lathiat> looks perfect here ;)
[07:40] <Lathiat> not so great when scaled down
[07:43] <jdub> yeah, when this thing isn't calibrated, that image is... ah... moving. :-)
[07:43] <Lathiat> i hear 10% brightness level is good ;)
[07:47] <daniels> jdub: oh, wow.  yeah, that's a really good image.
[07:47] <jdub> pretty thorough
[07:50] <jdub> oh man
[07:50] <jdub> usb-storage sucks so hard on windows
[07:50] <jdub> like, we are *way* ahead
[07:59] <[Chameleon] > jdub: pretty much everything sucks so hard on windows.
[07:59] <[Chameleon] > except for availability of games... but, actually, that fact sucks, too.
[08:15] <jdub> fabbione: still here
[08:15] <jdub> ?
[08:23] <jdub> heh
[08:23] <jdub> gar
[08:28] <pitti> Good moooorning!
[08:48] <torkel> pitti: thanks for taking care of heimdal, and I'm sorry for taking so long to do the debdiff
[08:48] <pitti> torkel: no worries, thanks for doing it
[08:50] <doko> good morning
[08:55] <jdub> http://www.brendoman.com/dbc/2005/09/13/my_techtv_appearance
[08:55] <jdub> ha ha ha ha
[08:56] <Treenaks> "I haven't even bothered trying to compile a program since I switched to Ubuntu."
[08:57] <pitti> Hi doko
[08:57] <jdub> check the comment ;)
[08:57] <pitti> daniels: to make the nvidia driver work, I had to add a symlink from the new into the old driver directory; known issue?
[09:03] <pef> hello
[09:12] <pitti> Mithrandir: do you care for ia32-libs?
[09:22] <Kamion> sabdfl: pong, re your ping last night
[09:25] <Mithrandir> pitti: yes
[09:26] <dholbach> good morning
[09:26] <mvo> hey dholbach
[09:26] <dholbach> hey mvo
[09:27] <pitti> Mithrandir: could you please upgrade the contained zlib to the latest version to fix CAN-2005-1849 and CAN-2005-2096?
[09:27] <pitti> Hi dholbach
[09:27] <Burgundavia> Kamion, how does one test the oem installer?
[09:27] <dholbach> hey pitti :-)
[09:29] <Mithrandir> pitti: in all dists or just breezy?
[09:39] <Mithrandir> mvo: didn't you do an upload to fix 8265 yesterday?
[09:41] <mvo> Mithrandir: not yesterday, but it should timeout in at most ~120sec
[09:42] <Mithrandir> mvo: per request or in total?
[09:42] <Kamion> Burgundavia: install oem-config
[09:42] <mvo> Mithrandir: how long does it take for you to timeout?
[09:43] <Kamion> Burgundavia: to test it properly, it's best to install oem-config along with the desktop system (by preseeding)
[09:44] <Burgundavia> Kamion, ok
[09:44] <Mithrandir> mvo: I haven't tested it, since I don't have such a setup here; I was just asking what the code is supposed to do?
[09:44] <Burgundavia> Kamion, is there docs for that somewhere? If not, lets talk at UBZ about building an OEM doc pack and what it needs
[09:46] <mvo> Mithrandir: the default timeout for http is 120sec, apt will have to timeout once for each active sources.list entry. so it's 240s. I think the installer could probably use a slightly lesser timeout
[09:46] <mvo> Mithrandir: this only applies for setups that have working dns but non-working direct access to the archive
[09:49] <Mithrandir> mvo: ok, is it tunable with a command line parameter or something?
[09:50] <mvo> Mithrandir: yes, "-o Acquire::http::Timeout"
[09:50] <Kamion> Burgundavia: not at the moment, no, it's too new
[09:51] <Kamion> I suppose I could add an (undocumented) 'oem' boot option to the CDs, so that people can test this more easily
[09:51] <Burgundavia> that would be nice
[09:53] <pitti> Mithrandir: just breezy; stables were fixed a while ago
[09:54] <pitti> Mithrandir: please also mention these two CAN numbers in the changelog
[09:54] <Mithrandir> pitti: ok, will do once my apt-get upgrade finishes so I have > 0 free space
[09:54] <pitti> thanks
[09:57] <dholbach> good morning seb128! :)
[09:57] <seb128> hey dholbach
[09:58] <Kamion> Burgundavia: ok, as of next CD images it should be possible to boot with preseed/file=/cdrom/preseed/oem.seed to test oem-config
[09:58] <Treenaks> Kamion: cool!
[09:59] <Burgundavia> Kamion, thanks
[10:11] <parshimers> is there anything buggy about sudo in breezy?
[10:12] <robitaille> parshimers,  not that I know
[10:12] <Burgundavia> parshimers, it is a little bit slower than in hoary
[10:12] <[Chameleon] > parshimers is having problems with it
[10:12] <[Chameleon] > on a clean install
[10:13] <[Chameleon] > we've tried to figure it out in #ubuntu, but aren't getting far
[10:13] <[Chameleon] > it's basically not doing anything for him. most of the time it seems to just exit.
[10:14] <[Chameleon] > parshimers: I was going to ask you to type this:
[10:14] <[Chameleon] > dmesg | tail
[10:14] <[Chameleon] > and look for anything related to sudo
[10:14] <[Chameleon] > you could actually do this:
[10:14] <[Chameleon] > dmesg | grep -i sudo
[10:14] <[Chameleon] > that'll be better
[10:14] <pitti> ogra: will you upload a new moodle anytime soon?
[10:14] <parshimers> parshimers@Parshimers:~$ dmesg | grep sudo
[10:14] <parshimers> parshimers@Parshimers:~$
[10:14] <parshimers> :\
[10:15] <pitti> parshimers: what do you expect?
[10:15] <pitti> parshimers: kernel messages don't have anything to do with sudo
[10:15] <parshimers> i figured
[10:15] <mdz> fabbione: ?
[10:16] <fabbione> mdz: ?
[10:16] <[Chameleon] > pitti: sorry, I figured it was worth checking on
[10:16] <fabbione> mdz: it was about the tetex-* stuff..
[10:16] <fabbione> mdz: i did add comments based on the stuff that's happening in Debian, but i would like a double review
[10:17] <mdz> fabbione: saw your comment via mail
[10:17] <mdz> fabbione: probably elmo would be the right person to review
[10:17] <fabbione> mdz:  ok
[10:20] <torkel> [Chameleon] /parshimers: check /var/log/auth.log
[10:21] <parshimers> lol thats great
[10:21] <parshimers> i need to be root to read the file
[10:21] <parshimers> :(
[10:21] <Mithrandir> elmo: can you please sync sgml2x and blender?  Ok to override and the blender sync has been approved by Kamion.  (The sgml2x doesn't need approval)
[10:26] <[Chameleon] > parshimers: bummer
[10:27] <[Chameleon] > parshimers: you might try single-user mode. That should give you root access.
[10:28] <[Chameleon] > parshimers: at the grub boot screen, type the letter 'a' and then add an 'S' to the end of the boot string, separated by a space.
[10:28] <[Chameleon] > parshimers: disclaimer: I think that's right, that's how it worked on FC3's grub boot, should be the same here.
[10:29] <parshimers> the problem was it didnt add my 2nd user to the sudoers list :P
[10:29] <torkel> [Chameleon] : can we please move it back to #u?
[10:30] <[Chameleon] > torkel: sure, but it seems he has found the problem.
[10:30] <[Chameleon] > parshimers: back to #ubuntu we go.
[10:30] <torkel> [Chameleon] : I know :-)
[10:30] <[Chameleon] > :)
[10:30] <[Chameleon] > torkel: thx for your help
[10:30] <[Chameleon] > pitti: you too
[10:31] <torkel> [Chameleon] : np
[10:34] <seb128> mvo: around?
[10:42] <mvo> seb128: yes
[10:42] <mvo> seb128: 'sup?
[10:43] <seb128> mvo: hi :)
[10:43] <seb128> Trying patch debian/patches/05_use_C_locale.patch at level 0...1...success.
[10:43] <seb128> Trying patch debian/patches/09_desktop.patch at level 0...1...2...failure.
[10:43] <seb128> make: *** [debian/stamp-patched]  Error 1
[10:43] <seb128>
[10:44] <seb128> mvo: build log for current gdm
[10:44] <mvo> seb128: uh, bad
[10:44] <mvo> seb128: thanks. I didn't touched 05_use_C_locale but had to adjust 09_desktop. but it applied for me. oh well
[10:45] <seb128> np
[10:48] <jkrogh> Hi.. the latest breezy kernel gives me a "busybox" after bootup..
[10:48] <jkrogh> 2.6.12-8-amd64-smp
[10:48] <jkrogh>  169.472773]  audit(1126687587.704:0): initialized
[10:48] <jkrogh> [  170.303754]  scsi_proc_hostdir_add: proc_mkdir failed for <NULL>
[10:48] <jkrogh> mount: Mounting /root/dev on /dev/.static/dev failed: No such file or directory
[10:48] <chmj> anyone know if the archive is broken or something ?
[10:49] <jkrogh> mount: Mounting /dev on /root/dev failed: No such file or directory
[10:49] <jkrogh> Target filesystem doesn't have /sbin/init
[10:49] <sivang> Morning all!
[10:49] <jkrogh> Anyone you knows what to do to submit a proper bugreport?
[10:49] <chmj> I keep getting MD5Sum missmatches and I'm not behind a proxy
[10:49] <chmj> elmo: ping
[10:49] <doko> chmj: too early :)
[10:49] <jkrogh> 2.6.12-3-amd64-k8-smp works fine..
[10:50] <mvo> chmj: maybe a transparent proxy? breezy seems to be fine here
[10:50] <sivang> morning mvo , seb128 , pitti
[10:50] <chmj> mvo: nope
[10:50] <jkrogh> The archive works fine from here..
[10:50] <jkrogh> dk.archive.ubuntu.com
[10:50] <chmj> mvo: no proxy
[10:51] <pitti> Hi sivang
[10:51] <seb128> hi sivang
[10:51] <seb128> hi pitti
[10:51] <pitti> Moin seb
[10:52] <chmj> hmmm, it means something wrong by my side then
[10:52] <mvo> chmj: you may try "apt-get update -o Debug::Acquire::http=true" and look at the http headers
[10:55] <chmj> mvo: thanks
[10:55] <jkrogh> Should i ask on the ubuntu-devel list instead?
[11:00] <mvo> chmj: if you want, paste the debug output somewhere and I'll have a look
[11:01] <chmj> mvo: I think the local telco is caching us or something
[11:01] <chmj> mvo: we've been having problems with adsl
[11:05] <seb128> does somebody have a ldap setup here?
[11:07] <\sh> dholbach / seb128: can u have a look on libgda2...binary package gda2-freetds has unmet dep on libct1 (which should be libct3) but all versions of libgda2 (up to 1.3.91) are ftbfsing because of using the wrong interfaces of freedts lib
[11:08] <Mithrandir> \sh: it's infty's bug, he asked other to let him handle it
[11:08] <\sh> Mithrandir: ok then..
[11:09] <seb128> Mithrandir: do you want amd64 bug? http://bugzilla.ubuntu.com/show_bug.cgi?id=14903
[11:09] <Mithrandir> yay bugs! /me munches
[11:09] <sivang> seb128: I  have some kind of ldap server on one of the machines, what do you need?
[11:09] <seb128> Mithrandir: that's browsers crashing with totem video player, seems to be reproducible if you use "previous page" from a video
[11:09] <Mithrandir> seb128: I'll take a look
[11:09] <seb128> sivang: https://bugzilla.ubuntu.com/show_bug.cgi?id=14763
[11:09] <seb128> Mithrandir: thanks
[11:11] <Kamion> chmj: transparent proxy == local telco caching you
[11:11] <Kamion> due to the "transparent", you often won't know about it
[11:12] <Kamion> well yes
[11:12] <chmj> they should not be doing that anyway
[11:14] <\sh> chmj: normal behaviour of ISPs in modern times
[11:15] <HrdwrBoB> my ISP doesn't transparent proxy me
[11:15] <\sh> Mithrandir: btw...is {gcc,g++}-3.4 installable on amd64 again, since dokos upload yesterday? :)
[11:15] <\sh> HrdwrBoB: not all..but many
[11:16] <HrdwrBoB> \sh: I cheat though.. I route traffic through work
[11:16] <Mithrandir> \sh: yes, done.
[11:17] <\sh> Mithrandir: u rock :) thx :)
[11:17] <jdub> seb128: that totem plugin bug appears on !amd64 too
[11:18] <seb128> jdub: ppc?
[11:18] <jdub> x86
[11:18] <jdub> at least last time i tried
[11:18] <jdub> currently stuck in console tho
[11:18] <jdub> will try again later
[11:19] <seb128> jdub: I don't have it on my box, but on the same box with the amd64 liveCD it crashes the browser everytime I do "previous page" from a video page
[11:19] <seb128> with the same versions
[11:19] <seb128> jdub: get me a backtrace on x86 please, amd64 are screwed
[11:19] <jdub> ok
[11:20] <seb128> thanks
[11:20] <dholbach> Kamion: do i get approval  to sync workrave from debian? (new upstream, builds nicely, fixes #10667)
[11:20] <jdub> hrm
[11:20] <jdub> how do i get a backtrace? run firefox in gdb?
[11:21] <Mithrandir> firefox -g, iirc
[11:22] <jdub> ahr
[11:26] <seb128> jdub: or gdb -p `pidof firefox-bin`
[11:26] <seb128> when it's running
[11:26] <jdub> yeah
[11:26] <jdub> seb128: did you see alexl's blog?
[11:28] <seb128> jdub: nop, /me opens planet
[11:29] <seb128> jdub: waouh, that's cool
[11:30] <jdub> yummy :-)
[11:32] <\sh> hmmm.
[11:33] <\sh> this is much more valuable: http://www.gizmoproject.com./
[11:33] <\sh> this is much more valuable: http://www.gizmoproject.com/
[11:34] <dholbach> elmo: could you pretty please sync tdiary (security issues)
[11:35] <pitti> dholbach: I just write an email to elmo with a whole bunch of sync requests
[11:35] <pitti> dholbach: I just do a major security review, also of universe
[11:35] <\sh> pitti: put gtk-gnutella as well on it, thx :)
[11:35] <pitti> dholbach: email requests generally work better anyway
[11:35] <dholbach> pitti: cool, will you add tdiary please then?
[11:35] <pitti> dholbach: it's already there :-)
[11:35] <dholbach> pitti: super, thanks
[11:35] <pitti> dholbach: I included all recent DSAs and CANs
[11:36] <dholbach> ROCK :)
[11:36] <pitti> \sh: changelog doesn't mention a security issue
[11:37] <\sh> pitti: ok...then I write the email by myself...it's gcc4 issues...need to collect anyways for universe
[11:38] <Kamion> dholbach: that's a fairly substantial upgrade; have you tested it?
[11:38] <pitti> \sh: yes, thanks
[11:39] <Kamion> dholbach: please check with the doc team to find out whether they've got workrave in screenshots or other documentation; if so, I'd rather stick with what we've got, since it's after UI freeze
[11:39] <\sh> pitti: btw..when u do a security review also of universe...can u put somewhere the list of source packages which a vulnerable somewhere on the wiki?
[11:40] <pitti> \sh: putting that on a wiki would be error prone and redundant
[11:40] <pitti> \sh: I just invent a mechanism in ubuntu-cve for that
[11:40] <pitti> \sh: I added some vulnerable packages, if anybody spots something, I can easily add it
[11:40] <dholbach> Kamion: ok... will talk to them - the release contains mostly bug fixes and translation updates - will give it some more testing, before i will request the sync
[11:41] <mdke> i don't think we have such a package in our documentation
[11:41] <\sh> pitti: can u give me a link to this list for ubuntu-cve?
[11:41] <mdke> dholbach, ^
[11:41] <dholbach> mdke: merci beaucoup :)
[11:42] <pitti> \sh: http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html
[11:42] <pitti> \sh: look at the very end, there is breezy universe
[11:42] <pitti> \sh: shortly the list will get bigger when I add the new stuff
[11:42] <pitti> I'm still in the review process
[11:43] <pitti> \sh: if something on that list is fixed, please tell me
[11:44] <pitti> CAN-1005-1759
[11:44] <pitti> php4 [Ubuntu: 4.4.0-2]  [Debian: 4:4.4.0-2, vulnerable]
[11:44] <Kamion> dholbach: merge rather than sync, I'd expect
[11:44] <pitti> ouch - that is a *VERY* old one :-/
[11:45] <dholbach> Kamion: are you still talking about  workrave ? we don't need to merge, it builts nicely as it is
[11:45] <pitti> dholbach: about which package are you talking?
[11:45] <pitti> ah, ok
[11:45] <dholbach> :)
[11:45] <mvo> seb128: do you have a idea for #15361?
[11:49] <\sh> pitti: is the wine stuff fixed in 20050725?
[11:50] <Kamion> dholbach: er, ok, I just assumed that since one of the Ubuntu changes was a modular X.org build fix ...
[11:50] <Kamion> :qa
[11:50] <Kamion> (d'oh)
[11:51] <pitti> \sh: http://bugs.winehq.org/show_bug.cgi?id=2715, please check
[11:51] <Kamion> elmo: please sync man-db and groff
[11:52] <pitti> \sh: should indeed be fixed in the existing version already
[11:52] <\sh> pitti: should be...regarding your link ------ Additional Comment #4 From Marcus Meissner  2005-03-17 11:29 -------
[11:53] <\sh> The misc/registry.c code is gone in CVS right after 20050310 release.
[11:53] <\sh> pitti: but I could do a new upstream version to 20050725 as well ;)
[11:53] <pitti> \sh: ok, marked as fixed in Breezy; hoary could still be vulnerable
[11:53] <\sh> pitti: hoary had the old wine packages..we're using now scotts
[11:54] <\sh> pitti: we could ask backport team to use breezy ones...
[12:18] <Mithrandir> doko: mind if I steal 14938 from you?
[12:19] <doko> if you have a solution, currently investigating ...
[12:20] <Mithrandir> it's the same as 14609
[12:20] <Mithrandir> and it appears to be that gcj doesn't handle many input files.
[12:21] <Mithrandir> or doesn't reorder input files or something like that.
[12:22] <doko> the file definitely is in the ecj.jar
[12:23] <Mithrandir> if you try to compile a bit fewer files, it works.
[12:25] <doko> ok, that looks like a good workaround
[12:26] <Mithrandir> gcj should really be fixed
[12:31] <Mithrandir> doko: it's a bloody ugly workaround, though.  I'm considering just closing infinity's bug as duplicate of yours and leaving it to you.
[12:31] <Mithrandir> doko: as I said, I think it's a gcj bug, but I'd like not to go completely insane, so I'm not going there. :-)
[12:31] <doko> yes, it looks better in 4.1
[12:31] <Mithrandir> can you add the workaround and we'll just leave it as that for now?
[12:33] <doko> yes
[12:34] <Mithrandir> cheers
[12:40] <ogra> pitti, yes, i'm on it, could you review the remaining dependency (mimetex) ?
[12:41] <pitti> ogra: can you please upgrade to 1.5.1 or port the security fix, and mention CAN-2005-2247 in the changelog?
[12:41] <pitti> ogra: I'm doing the review ASAP
[12:41] <ogra> pitti, will do
[12:45] <sivang> elmo: ping, got my email?
[12:59] <seb128> Mithrandir: Debian has new pwlib/gnomemeeting packages, you use it right? Do you want to try if they work and do the update/ask for the sync?
[01:00] <Mithrandir> seb128: I could do that, sure.
[01:00] <seb128> thanks
[01:01] <jdub> elmo, seb128: did ross ping either of you about python-cairo?
[01:02] <seb128> jdub: no, he should? The new version PENDINGUPLOAD on my list, what's the issue with it?
[01:02] <jdub> ah, ok
[01:02] <seb128> jdub: blocked by freeze some days ago ... should I not upload for a reason?
[01:02] <jdub> he wanted the new version :)
[01:02] <seb128> ah
[01:03] <seb128> new version junky :)
[01:03] <jdub> no, please go ahead
[01:03] <seb128> sync don't work for python stuff BTW
[01:03] <jdub> he said he'd let 90% of my blood if it didn't go in
[01:03] <seb128> since Debian still has 2.3 by default
[01:03] <seb128> ah ah
[01:03] <jdub> and he's a bit of a closet blade fanatic
[01:03] <jdub> yeah
[01:04] <jdub> heh
[01:04] <Robot101> the 2.3/2.4 thing makes my sid/breezy hybrid box cry :)
[01:04] <jdub> pipka will be after you for the cleaning bill ;-)
[01:04] <pitti> seb128: asa long as the package is sane and uses the python metapackage, syncs should be fine
[01:04] <seb128> pitti: the non versionned package points on 2.3 usually
[01:05] <pitti> seb128: but the package is rebuilt for Ubuntu, and then it should become 2.4 as default
[01:05] <seb128> pitti: how so? The Debian has a "Depends: python2.3-cairo (= ${Source-Version})"
[01:06] <pitti> ouch
[01:06] <seb128> pitti: we sed the control to change 2.3 to 2.4? :)
[01:06] <pitti> seb128: that explicit version is evil, right
[01:06] <pitti> seb128: nevermind then
[01:06] <seb128> pitti: lot of package do that ... python-cairo Depends on python2.N-cairo
[01:07] <seb128> pitti: what Depends should be used?
[01:08] <pitti> seb128: dunno, I just remember many packages that use ${python:Depends} and work fine
[01:08] <Kamion> python:Depends only handles python itself, not modules.
[01:09] <Kamion> there is no shlibdeps-like mechanism for python
[01:09] <Kamion> same goes for perl modules
[01:11] <mjg59> "Dapper drake"? Oh my.
[01:12] <doko> Mithrandir: which files did you translate in a separate compiler run? compiling each file for itself doesn't work neither
[01:12] <jdub> shoulda been dingo ;-)

[01:12] <ogra> jdub+++
[01:13] <Mithrandir> doko: you need to compile each file once, then retry them all, iirc.
[01:13] <Mithrandir> doko: ignore failures on the first run
[01:15] <sivang> mjg59: that's the code name for breezy+1 ?
[01:15] <mjg59> sivang: Yes
[01:15] <Robot101> ha
[01:15] <ogra> sivang, read te mailing list :)
[01:16] <sivang> ogra: I will I will, on weekend =) hard to managet to catch on all the mails while at work..
[01:17] <sivang> ogra: u-d ml ?
[01:18] <ogra> u.u
[01:19] <sivang> ogra: at work I'm only trying to keep with u.d ;-)
[01:27] <WaterSevenUb> in which package is the "disks-admin" tool?
[01:28] <ogra> WaterSevenUb, gnome-system-tools
[01:28] <WaterSevenUb> ogra, thx.
[01:43] <daniels> pitti: hmm?
[01:47] <mvo> elmo: can you please nuke "babytrans" from the archive? it's useless without babytrans-common (dictionary files) and that seems to have no license (both are from marillat)
[01:48] <dholbach> can somebody tell me if  http://bugzilla.ubuntu.com/show_bug.cgi?id=12076  really is all about metacity?
[01:55] <Evaso> Benc: ping
[02:01] <sivang> hey mpt
[02:01] <Evaso> who is maintaining synaptic?
[02:01] <pitti> Evaso: mvo
[02:02] <Evaso> mvo: ping
[02:02] <mvo> Evaso: pong
[02:02] <mpt> hi sivang
[02:02] <Evaso> hi mvo
[02:02] <Evaso> what do u think about to propose removing packages installed by dependencies on package remove?
[02:03] <Evaso> if this dependencies are not needed from others installed packages
[02:03] <mvo> Evaso: I like the idea a lot, there is already a experimental apt branch that supports this feature called apt--auto-mark--0
[02:04] <Evaso> mvo: this also works for suggested and reccomended packages?
[02:04] <mvo> Evaso: hm, I don't think so. right now only for "real" depends. are you interessted in working on such a project?
[02:05] <Evaso> mvo: i doesn't know apt internals, but i would to integrate upstream version in synpatc with Dehs
[02:07] <mvo> Evaso: let's move to #synaptic and talk about details, ok?
[02:07] <Evaso> ok
[02:08] <infinity> pitti : <poke>
[02:09] <pitti> infinity: eek
[02:09] <infinity> pitti : Want me to go through this universe CVE list and tell you which ones are wrong? :)
[02:09] <pitti> infinity: you mean on ubuntu-cve/unfixed.html? sure, that would be nice
[02:10] <pitti> infinity: I did not add them manually, it's just the fallout of automatic changelog computation
[02:10] <infinity> pitti : Well, I see a lot.  Ahh.
[02:10] <pitti> daniels: I had to create a symlink /usr/lib/xorg/modules/drivers/nvidia_drv.o => /usr/X11R6/lib/modules/drivers/nvidia_drv.o
[02:11] <infinity> piti : 1005-1759 is a CAN we accidentaly invented due to a typo in a changelog, BTW. :)
[02:11] <pitti> infinity: just saw that, a thousand year old CAN is something rare :-)
[02:11] <daniels> pitti: errr ... what?
[02:12] <pitti> daniels: well, yesterday I installed the nvidia-glx driver again, which drops the driver into /usr/X11R6
[02:13] <pitti> daniels: but xorg does not find the driver there, all others are in /usr/lib/xorg
[02:13] <Mithrandir> 7win 26
[02:13] <Mithrandir> bah
[02:14] <pitti> infinity: I propose to leave the CAN there as a reminder to fix it at the next php update
[02:14] <infinity> pitti : Anyhow, it looks like everything against php4/php4-universe is a false positive, and the apache vulns are also false (because apache in hoary and breezy uses apache2-utils, not apache-utils)
[02:15] <daniels> pitti: oh, right
[02:15] <pitti> infinity: they are solved upstream in 4.4, I suppose?
[02:15] <daniels> pitti: modular server
[02:15] <pitti> daniels: oh, right, it should still be installed
[02:16] <sivang> \sh: added a comment for you on your blog :)
[02:16] <hunger> fabbione: I sometimes get the /dev/input/mouse missing after bootup problem with your kernel. Never noticed that with my 2.6.13 kernel.
[02:16] <pitti> infinity: ok, I mark them as fixed; can you also add the CANs to the changelog in your package RCS?
[02:16] <infinity> pitti : Yeah, the php ones are all solved in 4.4.0 (except for the XML_RPC vulns, but php4-pear no longer contains files, it just depends on php-pear from php5, which is all fixed up)
[02:17] <\sh> sivang: thx :) and yes...this is what I want ;)
[02:17] <fabbione> hunger: it's a udev issue. not a kernel issue
[02:17] <hunger> fabbione: Your/BenC's kernel did work fine so far (after the occasional udevstart).
[02:17] <fabbione> hunger: there is a bug open already
[02:17] <pitti> infinity: btw, AFAICS we should remove php4-universe from the archive, right?
[02:17] <hunger> fabbione: That is what I was told. I just never noticed it with a 2.6.13 kernel.
[02:18] <hunger> fabbione: Maybe I am just lucky;-)
[02:18] <infinity> pitti : Same story for mod_ssl.. The vuln there was fixed in .18 or .19 or something (I backported it to warty, but hoary and breezy already had the fix)
[02:18] <sivang> \sh: sounds very interesting, I'll look forward to UBZ to maybe discuss thiat
[02:19] <\sh> sivang: me too :)
[02:19] <pitti> infinity: and you are sure that php4-universe 4.3.10-15ubuntu2 fixes e. g. CAN-2005-1921?
[02:19] <infinity> pitti : Yes, php4-universe and php4-imap should go, elmo was meant to do that. :)
[02:19] <pitti> infinity: ok, then I don't mark these packages manually, just php4
[02:19] <sivang> \sh: but still, I think there are more things to come before, like automatic mounting of existing file systems, unversal hardware support, but this can probably grow together
[02:21] <infinity> elmo : We still need php4-unive and php4-imap (source) tossed from breezy.
[02:21] <\sh> sivang: well...one side is distro..the other is community..and this idea is community environment :)
[02:21] <infinity> pitti : Yeah, php4-universe no longer produces any binaries in breezy (except for php4-universe-common), so I intentionally ignored it.
[02:22] <pitti> infinity: ok, marked php4 and apache; thanks for the review
[02:23] <infinity> On a different note, some MOTU should bribe me to fix php3 in the older releases.  I completely forgot it was there.
[02:23] <infinity> pitti : libapache-mod-ssl, too.
[02:24] <pitti> infinity: shall I send you a list of all apache and php related CANs I manually marked in my db, so that you can add them to the changelogs? that would rock
[02:25] <infinity> pitti : If you'd like to, sure.
[02:26] <infinity> pitti : When you're scanning, keep in mind to check source<->binary mappings, I think a few of those got confused.  And stuff like "apache-utils doesn't actually ship anything, so it can't possibly be vulnerable to anything)
[02:40] <seb128> \sh: do you have a slow or loaded box?
 seb128: i just got another weird deleted/created: /usr/share/control-center-2.0/capplets
 i didn't touch it, honest ;)
 inotify has load issues
 the moment i start a pdebuild a load of files "disappear" and "reappear"
[02:41] <\sh> seb128: when I start pbuilding then i goes up to 1 or 2 sometimes (depends)
[02:41] <seb128> does the menu breakage happen then?
[02:41] <\sh> seb128: but it happens also when nothing runs
[02:41] <seb128> k, so that's not it
[02:41] <\sh> seb128: the log files I'd attach were when I did nothing at all
 not sure if that's gamin or inotify
 seb128: i bet it's inotify
[02:43] <seb128> bah
[02:43] <seb128> this bug suck
[02:44] <\sh> yes it sucks
[02:45] <\sh> seb128: and after all, the menus were not coming back this time :(
[02:46] <pitti> doko: poppler-utils is still in NEW, btw
[02:46] <\sh> seb128: and if it's really inotify we only have time until the 29th ;)
[02:49] <doko> pitti: -> elmo
[02:49] <seb128> what is "knotify"?
[02:49] <pitti> doko: I know, I just thought you were unsure about the status
[02:52] <\sh> seb128: where is it?
[02:55] <seb128> \sh: I installed amarok and when starting it I had a "starting knotify" windows list entry for like 15s
[02:55] <seb128> seconds
[02:56] <\sh> seb128: oh...i think it's one of the magical communiction utilities of kde ;)
[02:56] <seb128> maybe the breakage is due to it
[02:56] <seb128> I didn't get any issue before using it
[02:56] <seb128> let's note if that change something now
[02:56] <\sh> I didn't use amarok or any kde stuff
[02:57] <seb128> k, so it just don't happen on my box
[02:57] <seb128> s/don/doesn/
[02:57] <\sh> I'm just using the ubuntu-desktop aka gnome
[02:57] <pitti> sivang: I'm just fixing the cups bug, FYI
[02:59] <Mithrandir> seb128: 14903 works for me; no crash.
[03:00] <Mithrandir> seb128: I see the gstreamer bug, but that's just gstreamer not having an appropriate plugin?
[03:02] <jdub> ogra: http://www.gnome-look.org/content/pre3/29050-3.png
[03:02] <seb128> Mithrandir: start firefox, go to http://www.apple.com/trailers/, start a trailer, press the toolbar back button ... does i crash?
[03:03] <seb128> s/i/it/
[03:05] <ogra> jdub, see #ubuntu-meeting ;) thanks :)
[03:05] <jdub> for...?
[03:06] <ogra> jdub, we just have our weekly edubuntu meeting :)
[03:06] <Mithrandir> seb128: hmm, now I got it crashing, yes.
[03:06] <sivang> pitti: k, cool
[03:10] <seb128> Mithrandir: cool
[03:10] <mxpxpod> jdub: you have a ppc machine, right?
[03:10] <pitti> jordi: did you already upload mailutils to Debian without the CAN? Or did you read yesterday's mail in time?
[03:10] <pitti> jordi: also, do you want to fix this in Ubuntu?
[03:11] <jdub> mxpxpod: i have what we may refer to as "an excuse" for a ppc machine
[03:11] <mxpxpod> jdub: heh, could you check something for me?
[03:11] <mxpxpod> jdub: I'm trying to figure out if this problem is ppc only or not
[03:11] <mxpxpod> jdub: first, do you have a pretty recent breezy on your ppc machine?
[03:12] <Mithrandir> seb128: now I made it just hang. :-/
[03:13] <jdub> mxpxpod: not atm
[03:13] <mxpxpod> jdub: ok, don't worry about it
[03:13] <mxpxpod> jdub: I'm trying to figure out why beagle is crashing on me
[03:17] <mvo> ping jamesh
[03:21] <slomo> hi... is some kind of dpkg guru here? while creating the diff.gz i get the following error http://paste.ubuntulinux.nl/2182
[03:27] <bddebian> Morning
[03:28] <Diziet> Blimey.  This Firefox privacy situation is much worse than I thought.
[03:28] <Diziet> There a variety of different kinds of stuff it remembers about what you've been doing, any one of which could get you nailed if that's what you're worried about.
[03:29] <Diziet> These all have different UI controls for clearing them.
[03:29] <Diziet> Some of those controls don't clear and flush the profile to disk, so a subsequent crash undoes the clear.
[03:29] <Diziet> Some of them don't have a way to clear them at all (depending on version and configuration).
[03:29] <Lathiat> firefox has a big fat screen of various informations tored and a clear all button?
[03:30] <Lathiat> what other stuff does it store?
[03:30] <Diziet> I'm reading the bugzilla.
[03:30] <Diziet> Apparently in some versions `clear all' doesn't clear all.
[03:31] <sivang> hey bde
[03:31] <sivang> err, bddebian even :)
[03:31] <bddebian> Morning sivang
[03:35] <Diziet> Luckily few of those bugs are in our version.
[03:35] <Diziet> Ours just has the bug that the clear search history option on the search box context menu doesn't clear the browser history (so your searches are still recorded) and doesn't flush the profile.
[03:36] <Mithrandir> Diziet: any thoughts on http://bugzilla.ubuntu.com/show_bug.cgi?id=14903 ?
[03:36] <Diziet> I think I'll delete the option.  It's either that or invent a new popup saying `you mean to clear your whole history then?'
[03:38] <Diziet> mith: I don't have any thoughts off the top of my head, no.  I'm not sure it's worth spending an afternoon chasing it down at this stage ?
[03:38] <Diziet> Our mozilla package has been unmaintained for too long.
[03:38] <Diziet> firefox, I mean.
[03:41] <sivang> does anybody know if elmo is up already?
[03:44] <bddebian> sivang: I think I killed him with requests ;-)
[03:50] <ogra> fabbione, ping
[03:51] <sivang> bddebian: I hope not ;-)
[03:53] <fabbione> ogra: fast pong.. i am on the way off
[03:53] <ogra> fabbione, who in the kernel team is our inotify specialist ?
[03:54] <ogra> fabbione, i'll need help with 14967
[03:54] <JaneW> never miss (or step out of) a meeting...  http://www.comics.com/comics/dilbert/archive/images/dilbert2002713250914.gif
[03:56] <seb128> \sh: I get the bug now
[03:56] <seb128> \sh: it's load dependend here
[03:56] <ogra> Riddell, any thought about 14967 ? it affects all KDE apps in the GNOME menu
[03:56] <fabbione> ogra: that's not a kernel bug. it's a gamin bug
[03:56] <fabbione> ogra: probably related to the same memory leak
[03:56] <fabbione> or stuff like that
[03:56] <ogra> fabbione, hmm
[03:56] <fabbione> the inotify in the kernel works fine
[03:57] <\sh> seb128: hmmm
[03:57] <ogra> fabbione, but its not gamin claiming that the dirs disappear afaik...
[03:57] <\sh> seb128: this bug sucks really
[03:57] <ogra> fabbione, it just recieves the event fom inotify
[03:57] <fabbione> ogra: gamin had the exact same issue when we were using dnotify+polling
[03:57] <fabbione> gamin is crap
[03:58] <fabbione> we did workaround it
[03:58] <fabbione> but not for inotify
[03:58] <ogra> fabbione, do you remember how ?
[03:58] <fabbione> seb128, pitti and jdub will remember
[03:58] <ogra> oki
[03:58] <seb128> fabbione: no
[03:58] <ogra> fabbione, thanks for now :)
[03:58] <seb128> fabbione: it was dropping events
[03:58] <fabbione> ogra: basically gamin sucks at keeping track of what's under checking adn what's not
[03:58] <fabbione> seb128: that was a consequence
[03:59] <fabbione> hmm no
[03:59] <seb128> fabbione: now we get "inotify: resource /....folder/ went away" messages
[03:59] <fabbione> seb128: right..
[03:59] <seb128> fabbione: no reason to create events
[03:59] <fabbione> seb128: check the code.. i am sure it's a gamin problem
[03:59] <fabbione> see where that message comes from
[03:59] <seb128> server/gam_inotify.c for gamin
[03:59] <fabbione> because the code and the messages are misleading
[04:00] <seb128>         if (event->mask & IN_DELETE_SELF)
[04:00] <seb128>         {
[04:00] <seb128>                 GAM_DEBUG (DEBUG_INFO, "inotify: resource %s went away. Adding it to missing list\n", data->path);
[04:00] <fabbione> seb128: when i did the debug last time, i had to re-read the entire code and add my debug statement
[04:00] <seb128> fabbione: most of the code has been rewritten and not by DV this time :)
[04:00] <seb128> maybe it's better now
[04:00] <fabbione> seb128: well than i dunno.. but i am not going to pick up another talk with DV.. that's for sure
[04:01] <seb128> fabbione: it's probably easy to monitor a folder with inotify to make a testcase
[04:01] <fabbione> and i am 99.99% sure inotify is fine
[04:01] <fabbione> seb128: sure.. reduce the test case to the minum that can be reproducible
[04:02] <fabbione> seb128: adding debug statement to kernel inotify is very very easy
[04:02] <fabbione> it's made of only 3 functions :)
[04:02] <seb128> fabbione: is there any example of inotify code somewhere?
[04:02] <fabbione> not that i am aware of.. probably there are some references in the kernel code itself
[04:02] <fabbione> fs/inotify.c
[04:02] <seb128> k
[04:04] <seb128> mvo: you have not played with inotify by any luck?
[04:05] <mvo> seb128: no, only fam/gamin
[04:05] <seb128> k, thanks anyway
[04:05] <\sh> seb128: http://www.developertutorials.com/tutorials/linux/monitor-linux-inotify-050531/page4.html if it helps
[04:06] <seb128> \sh: thanks
[04:06] <\sh> seb128: i think u can use the example as a test case with little modifications
[04:06] <Lathiat> seb128, \sh: its changed since then tho
[04:06] <Lathiat> its no longer a /dev device
[04:06] <\sh> argl
[04:07] <Lathiat> its a ioctl or whatever
[04:07] <Mithrandir> I thought there was a libinotify or something, with glib bindings and all
[04:08] <seb128> no, that's libnotify
[04:08] <\sh> Mithrandir: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ ?
[04:08] <seb128> which makes the bubble you get for updates by example
[04:08] <seb128> no?
[04:09] <Mithrandir> seb128: no, libinotify; what sh posted looks approximately right.
[04:09] <seb128> oh, k
[04:09] <ogra> hmm, we dont ahve/use it apparently
[04:09] <seb128> I don't want an another layer
[04:09] <seb128> the goal is to know if inotify is to blame
[04:09] <Mithrandir> well, it has code you can look at. :-)
[04:09] <seb128> so better to use it directly
[04:09] <seb128> ah, right
[04:09] <Mithrandir> pitti: ia32-libs uploaded.
[04:10] <Mithrandir> and it's trivial enough that it's meaningful to look at too
[04:12] <pitti> Mithrandir: merci
[04:14] <\sh> seb128: /usr/src/linux-source-`uname -r`/Documentation/filesystems/inotify.txt
[04:28] <netstar> what's ubuntu's equivalent to /etc/rc.d/rc.local?
[04:32] <Kamion> netstar: write a new init script
[04:32] <Kamion> (in /etc/init.d/) and use update-rc.d to link it into the /etc/rc?.d/ directories
[04:33] <netstar> ok
[04:33] <netstar> thanks
[04:33] <ogra> Diziet, after you took care of firefox now, would it be possible to add native forms support to it ? http://www.gnome-look.org/content/show.php?content=28984&vote=good&tan=33542613
[04:34] <ogra> (i'm requesting that since warty btW)
[04:35] <Kamion> didn't thom explicitly say no to that?
[04:35] <Kamion> I'm sure I remember there being some problem with them
[04:35] <seb128> \sh, ogra: thanks to mvo who pointed http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/inotify-utils-0.25.tar.gz we figured your issue is an inotify bug
[04:36] <\sh> seb128: u rock :)
[04:36] <ogra> Kamion, for warty, because it wasntmature enough back then
[04:36] <seb128> \sh, ogra: can you try with it if you get a DELETE events when that happens?
[04:36] <ogra> seb128, YAY !!
[04:36] <seb128> just untar, run ./inotify_test /usr/share/applications/kde
[04:36] <Kamion> ogra: I was *sure* it was later than warty.
[04:36] <daniels> /w/win 31
[04:36] <seb128> and not any event
[04:37] <ogra> Kamion, then it was beginning of hoary.... i gave up on it later... its a simple css extension, nothing intrusive
[04:37] <Kamion> ogra: you asked near the end of the hoary cycle
[04:38] <\sh> seb128: running
[04:38] <ogra> i'm pretty sure a asked at least 5 times... one might have been at the end of hoary...
[04:38] <Kamion> http://people.ubuntu.com/~fabbione/irclogs/archived/2005-03/ubuntu-devel-2005-03-04.html, about two-thirds of the way down
[04:38] <Kamion> there was a theming problem
[04:39] <Kamion> and some display problem reported by tseng - should check if that's still a problem
[04:40] <Kamion> although the one you just pointed to is clearlooks rather than industrial, so I guess it won't share the theming problem
[04:40] <ogra> Kamion, 02:11	<thom>	i'll try and get it in for 1.0.1 if i can
[04:40] <\sh> seb128: how long did u wait? or did u make some load on your machine?
[04:40] <Kamion> ogra: with comments after that
[04:40] <Kamion> context is everything ...
[04:41] <seb128> \sh: I started a pbuilder
[04:41] <seb128> \sh: it should get the signal when your menu are hidden ... you better know how long you wait usually
[04:41] <\sh> hmm..pbuilder is running working on psi
[04:41] <ogra> Kamion, even with themeing probs, its still more beauty to have clearlooks forms than crappy gtk default ones :)
[04:41] <seb128> but you said is not load depened for you
[04:41] <\sh> seb128: so u had the menus before...because right now, I don't have them ;)
[04:41] <Kamion> ogra: ok, well it's not my call
[04:42] <ogra> Kamion, i just wanted to repeat the quetion for breezy since it seems we have a ff maintainer again :)
[04:42] <ogra> and the theming has oimproved it seems
[04:42] <seb128> \sh: doesn't matter, mv a /usr/share/applications/.desktop to force a refresh
[04:43] <seb128> \sh: but the issue is not the panel, it's inotify sending the "resource folder went away" and that happens running the panel or not ...
[04:44] <\sh> seb128: ok...I just copied a .desktop to kde/
[04:45] <seb128> if panel has stopped to monitor kde/ changes, that's not going to work :p
[04:45] <seb128> that's why I said /usr/share/applications/
[04:46] <\sh> seb128: ah...ok...so I have to restart my session
[04:46] <seb128> no
[04:46] <seb128> gnome-session-remove gnome-panel && gnome-panel &
[04:46] <seb128> by example
[04:46] <ogra> \sh, jut touch a .desktop file in applications/
[04:46] <ogra> just even
[04:46] <seb128> or change a file to a monitored folder
[04:46] <seb128> ie: /usr/share/applications/.desktop
[04:47] <seb128> panel will get this notification
[04:47] <seb128> and should redraw the menus
[04:47] <\sh> ok..now ;) i have my kde stuff again
[04:47] <ogra> yay
[04:49] <\sh> got it
[04:49] <doko> Kamion: please could you process poppler-utils from new?
[04:49] <\sh> EVENT ON WD=1
[04:49] <\sh> DELETE_SELF (file) 0x00000400
[04:49] <\sh> EVENT ON WD=1
[04:49] <\sh> IGNORED (file) 0x00008000
[04:49] <mvo> seb128: it's interessting that it gets a IN_DELETE_SELF and not a IN_DELETE. do you have a idea?
[04:50] <\sh> seb128: and now with load on my laptop
[04:50] <Kamion> doko: is elmo not around?
[04:50] <doko> Kamion: no, net yet
[04:51] <Kamion> meh, ok
[04:51] <Kamion> doko: is it targeted at main?
[04:51] <doko> yes, but it is code, which was already in main (xpdf-utils)
[04:52] <Kamion> I just want to know whether I need to do the straight-to-universe dance
[04:52] <doko> pitti: did you already review poppler?
[04:53] <doko> oops, no, I didn't write the report ...
[04:53] <Kamion> doko: I'll process this for now, but you're missing a Replaces: xpdf-utils; please add that
[04:53] <pitti> doko: it's not yet in the archive, or is it?
[04:53] <seb128> \sh: and you menu broken when you got it?
[04:53] <Kamion> (so that the packaging system knows that poppler-utils is a complete replacement for xpdf-utils)
[04:54] <seb128> mvo: not really, I don't know how inotify events work
[04:54] <Kamion>  Description: PDF utilitites (based on libpoppler)
[04:54] <Kamion> also typo in the control file; that should be "utilities"
[04:54] <\sh> seb128: yes
[04:54] <Evaso> BenC: ping
[04:55] <mvo> seb128: I figured the difference between IN_DELETE and IN_DELETE_SELF is that the former is emited when a file is removed from a directory and the later if the inode goes away. but I don't see the big picture yet
[04:55] <doko> pitti: the source _is_ in the archive
[04:55] <pitti> doko: oh, fine
[04:55] <doko> Kamion: will do
[04:56] <seb128> mvo: k, so we get an event saying the folder itself got away
[04:56] <doko> seb128: any word on pdftohtml?
[04:56] <Kamion> doko: thanks
[04:57] <jdub> mdz: around?
[04:57] <jdub> hmm, not quite yet
[04:57] <\sh> seb128 / mvo: what fs are u using?
[04:58] <seb128> doko: it's fine with me
[04:58] <seb128> \sh: ext3
[04:58] <\sh> xfs here
[04:58] <\sh> so there is no string in between
[04:59] <mvo> \sh: AFAICS (and I'm really no expert in no way) the event is emited from the dcache, so it may not be file system specific
[05:00] <doko> seb128: ok, will upload the update
[05:01] <\sh> mvo: ok for now, we know now it's a kernel bug...
[05:01] <seb128> doko: thanks
[05:01] <jdub> dides
[05:01] <jdub> dudes rather
[05:01] <jdub> http://people.ubuntu.com/~jdub/2005/mdz.png (and mdz-big.png)
[05:02] <mvo> jdub: ROTFL
[05:02] <jdub> that is mdz's "DON'T FUCK WITH THE FREEZE" face :-)
[05:02] <pitti> jdub: yay, his new hackergotchi?
[05:02] <jdub> pitti: for when he gets himself a blog ;)
[05:02] <\sh> jdub: lol
[05:03] <sivang> lool: omg, he looks rather intimedating :)
[05:04] <ogra> jdub, wasnt that look caused by Burgundavia ? iirc
[05:04] <ogra> (i think he took the pic :) )
[05:04] <jdub> jonmasters
[05:05] <ogra> ah
[05:05] <fabbione> Dapper! Dapper!   Yes, it's full of bugs and probably always will be.
[05:07] <ogra> Diziet, your last mail looked encouraging that its much better now :)
[05:08] <Diziet> You mean my activity report ?  I'm barely scratching the surface here.
[05:08] <fabbione> http://www.bearcreekgifts.com/other-collectables.htm <- pic of Dapper Drake
[05:08] <Diziet> And all of the really hard stuff that's not totally essential I'm not even bothering with - just hoping upstream fix it one day.
[05:08] <ogra> Diziet, i mean Firefox and Mozilla Update from -devel
[05:09] <dholbach> Diziet: you think we should all sign a petition to split up the source code into modules and libraries   R S N  ?
[05:09] <ogra> Diziet, waiting for upstrem can last forever...
[05:09] <seb128> fabbione: turned that the bog is inotify bog
[05:09] <Diziet> ogra: Um, that mail of mine is just me throwing out one of the trickier problems that upstream definitely aren't going to solve.
[05:10] <ogra> Diziet, thunderbird has no rply to list until today and its at version 1.0.6 :)
[05:10] <Diziet> And, for the rest, if you don't like waiting for upstream I encourage you to go fix it there.  Fixing stuff downstream here is probably a poor use of effort unless it's a really painful bug.
[05:10] <fabbione> seb128: i didn't read the scrollback..
[05:10] <fabbione> seb128: how so?
[05:10] <seb128> fabbione: read current comment on http://bugzilla.ubuntu.com/show_bug.cgi?id=14967
[05:11] <Diziet> split up the source code> You must be joking.  It already is split up internally; you'd just be asking for a versionitis nightmare.
[05:12] <daniels> not if you did it properly
[05:12] <dholbach> daniels HAD to answer on that one :)
[05:12] <Diziet> upstream vs here> The transaction costs of dealing with _two_ bugzillas are even worse than twice the (astonishing) costs of dealing with one.  And of course we're always lagging upstream's version so there's version skew in everything we do.
[05:12] <daniels> got to defend my honour
[05:15] <jordi> pitti: yes, and yes.
[05:15] <jordi> pitti: merge from incoming
[05:15] <pitti> jordi: do you want to fix stables?
[05:16] <jordi> pitti: joey has a build going now
[05:16] <pitti> jordi: I mean warty and hoary
[05:17] <jordi> oh. it's universe, isn't it?
[05:17] <pitti> jordi: yes, that's why I ask
[05:17] <jordi> pitti: I don't know what your policy is wrt that. If it can be fixed, I don't see why not.
[05:17] <jordi> the patches are pretty straight forward.
[05:17] <pitti> jordi: it's generally a community-based thing; as long as there is somebody who prepares the upload, I happily process it
[05:18] <jordi> pitti: great. If it can be done, that would be great.
[05:19] <jordi> right now mailutils is problaby not used by many, because mailx gets installed by default
[05:19] <jordi> but obviously some people do, as I get bug reports for Debian
[05:20] <pitti> jordi: https://wiki.ubuntu.com/SecurityUpdateProcedures
[05:20] <pitti> jordi: just send me a debdiff, I take a look at it, and happy upload :-)
[05:22] <jordi> what does ubuntu have now?
[05:22] <jordi> or do you want a debdiff of just this (I think ubuntu had -1, current is -3)
[05:25] <pitti>  mailutils | 1:0.4+20040601-2 | http://archive.ubuntu.com warty/universe Sources
[05:25] <pitti>  mailutils |    1:0.6-2 | http://archive.ubuntu.com hoary/universe Sources
[05:40] <slomo> can someone kick xmule to build? seems to be on dep-wait
[05:46] <Evaso> hi guys: what is this
[05:47] <Evaso> on boot pnp: Evaluate _CRS failed
[05:47] <Evaso>  pnp: Failed to activate device 00:0
[05:48] <infinity> slomo : Neither me nor lamont nick hilight on "someone".
[05:49] <slomo> infinity: sorry :/ and xmule is not on dep-wait but "Not-For-Us"... what does this mean? distribution is breezy
[05:50] <infinity> slomo : It means I had it frozen for the C++ transition.  Does thta mean libcrypto++ is transitioned oand built on all arches?
[05:50] <\sh> seb128: u changed #14967 to unconfirmed?
[05:51] <infinity> slomo : Ahh, looks like.  Freeing it up to build, then.
[05:51] <slomo> infinity: at least on x86... libcrypto++5.2c2 depends on the gcc4 stuff
[05:51] <slomo> infinity: ok, thanks :)
[05:51] <infinity> slomo : Yeah, "at least on i386" isn't good enough, but I just checked the others.
[05:51] <\sh> slomo: did it build on all arch?
[05:52] <slomo> \sh: yes
[05:53] <\sh> grmpf...and where is the bug entry?
[05:54] <\sh> ajmitch: *barkbark*
[05:56] <\sh> infinity: btw...yehia will be morgued
[05:56] <infinity> \sh : What's the status on libyehia0.5, libxdb1, and libace?
[05:56] <infinity> Oh. :)
[05:57] <\sh> infinity: ace has some really nasty -fPIC recompile stuff...I tried, and bmonty...but I think it's more upstream crap
[05:59] <bddebian> I thought yehia was to be morgued?
[05:59] <HiddenWolf> \sh infinity: btw...yehia will be morgued
[06:00] <\sh> lol
[06:00] <ogra> \sh, infinity, bddebian, HiddenWolf, yehia will be morgued
[06:00] <ogra> if you didnt know yet
[06:00] <\sh> uhm...yehia will be morgued? ,-)
[06:00] <Evaso> i had goot with breezy preview: prism54: Your card/socket may be faulty, or IRQ line too busy
[06:00] <HiddenWolf> ogra, now thats saying it 3 times in 10 minutes. :P
[06:01] <infinity> \sh, ogra : And what happens to gql?... Will it be taught to not need/want yehia, or will it also go away>
[06:01] <ogra> HiddenWolf, that will certainly make it disappear finally ;)
[06:01] <HiddenWolf> Evaso, please file a detailed bug. :)
[06:01] <seb128> \sh: I reassigned, it does that
[06:01] <\sh> seb128: ok...
[06:01] <Evaso> HiddenWolf: i had filed also this bug with Hoary with the hardware tools
[06:02] <seb128> mvo: still waiting for mclasen ...
[06:02] <HiddenWolf> Evaso, comment that it is still in breezy, and ask on the bug what info they need of you.
[06:02] <mvo> seb128: that's ok
[06:02] <\sh> infinity: it will...yehia has no upstream work since a couple of years
[06:02] <Evaso> HiddenWolf: at prism54 chanell doesn't know what is the problem but with ndiswrapper this card works fine.
[06:02] <mvo> seb128: I'll be away for ~1h, if you hear anything I would appreciate if you could /msg it to me
[06:02] <Evaso> HiddenWolf: where i can find bugs reported with the hardware gtk gui?
[06:03] <dholbach> mvo: bye michael
[06:03] <\sh> infinity: and if xdb builds nicely I'll upload it in a few
[06:03] <HiddenWolf> Evaso, bugzilla.ubuntu.org
[06:03] <\sh> actually it was mvos work ;-)
[06:03] <infinity> \sh : Cool.  Want me to poke at ace on the weekend?... If so, remind me.
[06:04] <\sh> infinity: u can if you want
[06:04] <infinity> \sh : Down to only one lib left to transition kinda excites me. :)
[06:04] <sivang> yay IPP printer detection is working again
[06:04] <\sh> infinity: libhid needs some love as well...
[06:04] <ogra> infinity, MOTU will give you a medal if you take ace :)
[06:04] <dholbach> just morgue ace too, it's too complicated to use anyway ;)
[06:04] <infinity> \sh : ...  My frozenapps is down to 3 apps waiting on 3 libs.
[06:05] <infinity> dbbalancer dep-wait libace5.4c2
[06:05] <infinity> gql dep-wait libyehia0.5-0c2
[06:05] <infinity> oleo dep-wait libxdb1
[06:06] <\sh> infinity: libxdb1 u will get in 3 2 1 now ,)
[06:06] <infinity> So, if I can fix the first, and the second goes away, and you're doing the third right now..
[06:06] <\sh> infinity: xdb uploaded -> creating bug entry
[06:09] <sivang> yay almost time to go home and then much some bugs ....
[06:09] <jbailey> infinity: oleo?
[06:10] <jbailey> Like the spreadsheet?
[06:11] <\sh> jbailey: there is more software in the archive, which shouldn't be there anymore ,-)
[06:11] <bddebian> Heh, no kidding :-)
[06:12] <Diziet> pool/main/o/openoffice.org-amd64/openoffice.org-amd64_1.1.2-2ubuntu6.1.orig.tar.gz WTF?!
[06:13] <sivang> lol
[06:13] <ogra> wow, thatsancient
[06:13] <dholbach> ogra: oh no... the dog has it... he's carrying it outside ;)
[06:13] <mdz> it's in warty-security and is current
[06:14] <ogra> lol
[06:14] <Kamion> openoffice.org is horribly un-64-bit-clean, and at the time we didn't have sufficient biarch compiler support to build an amd64 .deb with 32-bit binaries
[06:14] <Kamion> we might do now; not sure
[06:14] <Diziet> And it needs a different .orig.tar.gz with the ubuntu revision in the version ?  Someone's got too much upload bandwidth to spare.
[06:14] <\sh> ogra: leave the dog alone ;)
[06:14] <mdz> Kamion: it's not so much the compiler support as having to mess with all of the libraries
[06:15] <Kamion> oh, yeah, that too
[06:16] <mdz> Diziet: it needs to be updated each time openoffice.org is updated
[06:16] <Diziet> I mean, what would be wrong with  cp openoffice.org_1.1.2.orig.tar.gz openoffice.org-amd64_1.1.2.orig.tar.gz ?
[06:16] <mdz> that's the point
[06:16] <mdz> Diziet: the fact that it has entirely different contents
[06:17] <Diziet> The _.orig_ has entirely different contents ?
[06:17] <mdz> Diziet: do you suggest we put the i386 binaries in the .diff.gz?
[06:17] <Kamion> the .orig contains the i386 binaries ...
[06:17] <infinity> The orig has the i386 binaries in it.
[06:17] <Diziet> Obviously I'm foolishly imagining that it's the upstream source tarball.
[06:17] <Kamion> (as .debs, no less)
[06:17] <Diziet> Cripes.
[06:17] <infinity> Similar to the evil that is ia32-libs.
[06:17] <Kamion> I tend to run away from it in case I get infected
[06:18] <Diziet> Very wise.
[06:18] <infinity> Kamion : A fine plan.
[06:19] <bddebian> heh
[06:20] <mdz> Diziet: this turned out to be significantly more practical than chasing 64-bin cleanliness bugs through a few hundred megs of source code
[06:25] <Diziet> mdz: Um, yers.
[06:31] <sivang> anyone seen elmo ?
[06:32] <bddebian> sivang: I told you man, I buried him in e-mail. ;-)
[06:36] <sivang> bddebian: hehe, anyway see you 1.5 hours later
[06:36] <bddebian> Later sivang
[06:37] <mdz> doko: ping?
[06:46] <doko> mdz: pong
[06:47] <mdz> doko: sent mail
[06:48] <doko> ok, looking at the mime-types
[06:56] <mdz> doko: also, germinate still seems confused about xpdf
[06:58] <doko> mdz: no, it shouldn't once poppler-utils is available
[06:58] <mdz> doko: it is available and has been for some time
[07:01] <tiefox> what is the best way to install the java firefox plugin in breezy?
[07:01] <doko> Source: zope2.7-archetypes
[07:01] <doko> Version: <IP_ADDRESS>-2ubuntu1
[07:01] <doko> Replaces: zope2.7-cmftransforms
[07:01] <doko> Depends: lynx, pdftohtml, python2.3-docutils (>= 0.3.3), poppler-utils | xpdf-utils, zope-common (>= 0.5.7), zope2.8 | zope2.7
[07:01] <Lathiat> tiefox: blackdown is in multiverse i think that includes a plugin no?
[07:01] <ogra> tiefox, enable multiverse, install j2se
[07:02] <doko> mdz: that should work. note that the binary did enter breezy only two hours ago
[07:02] <tiefox> thx ogra and Lathiat
[07:02] <mdz> doko: I ran germinate 10 minutes ago
[07:03] <doko> so why does it prefer xpdf-utils?
[07:03] <mdz> doko: that is the question
[07:05] <Kamion> cjwatson@jackass:/srv/ftp.no-name-yet.com/sync/germinate/output$ grep -c '^xpdf-utils ' ALL
[07:05] <Kamion> 2
[07:05] <Kamion> it's just hppa and sparc
[07:06] <Kamion> (at a guess, anyway)
[07:07] <elmo> it's arch: all
[07:07] <elmo> I was wondering if it's because they're all currently in universe
[07:07] <Kamion> poppler-utils isn't
[07:07] <Kamion> poppler-utils | 0.4.2-0ubuntu2 |        breezy | hppa
[07:07] <Kamion> poppler-utils | 0.4.2-0ubuntu3 |        breezy | amd64, i386, ia64, powerpc
[07:07] <elmo> right, but everything else is
[07:07] <elmo> I dunno if that affects germinate's DTRT algorithm for or'ed deps
[07:07] <Kamion> so certainly sparc will still pull in xpdf-utils, not sure about hppa
[07:07] <elmo> or if it even has one
[07:08] <elmo> we don't look at germinate for hppa
[07:08] <elmo> but sparc would do it.  meh
[07:08] <elmo> maybe I should just drop all the non-release arches from germinate and whitelist their needed packages for main
[07:08] <Kamion> DTRT> not really, although ordering within the Packages file it's given can sort of affect things
[07:09] <Kamion> but only if the situation is unstable anyway
[07:09] <tiefox> opra: cant find packet j2se
[07:10] <elmo> yeah, excluding sparc fixes it
[07:10] <doko> or fabbione should build poppler-utils with a higher priority
[07:10] <elmo> of course now it wants to drop efi, elilo, silo etc.
[07:10] <Kamion> the way germinate deals with ORed deps is to check whether the whole thing is satisfied by something it has in the relevant seed; if not it tries to pull in something from a further-out seed; if not it tries to add the first of the ORed deps that's possible
[07:11] <ogra> tiefox, rather j2sdk, sorry i muddled re and sdk to be se
[07:11] <Kamion> but you're not looking at just one package here, so if multiple packages have some set of ORed deps in a different order, then which one ends up in main depends on which of those packages gets encountered first
[07:11] <Kamion> elmo: ah, the two entries were probably Ubuntu and Kubuntu then, or something
[07:12] <elmo> mdz/kamion: any objections to me dropping the arch list anastacia considers to release arches and using a hardcoded whitelist of stuff to keep in main to deal with the non-release-arch-specific packages like silo etc.?
[07:12] <Kamion> it would be handy if you'd run germinate in a different subdirectory for each distro/arch combination to make this kind of thing easier to debug
[07:12] <elmo> as a short term hack
[07:12] <elmo> kamion: I already do, mostly
[07:12] <tiefox> ogra: i cant find j2sdk either...and i have multiverse enable
[07:13] <elmo> kamion: anastacia can choose at run time which arches to pay attention to
[07:13] <Kamion> you do? where?
[07:13] <doko> tiefox: j2sdk1.4
[07:13] <ogra> tiefox, what gives a search for java ?
[07:13] <Kamion> cron.sync doesn't cd
[07:13] <doko> tiefox: or j2re1.4
[07:13] <ogra> (and this belongs to #ubuntu btw)
[07:13] <Kamion> elmo: I mean when you're building the ALL etc. files
[07:14] <elmo> kamion: it redirects the output to different arch named files
[07:14] <tiefox> ogra: breezy questions too /
[07:14] <tiefox> ?
[07:14] <elmo> Kamion: and anastacia uses them rather than ALL
[07:14] <Kamion> oh, right, I see
[07:14] <Kamion> $ grep '^xpdf-utils ' all_*
[07:14] <Kamion> all_edubuntu_breezy_sparc:xpdf-utils                             | xpdf                            | zope2.7-portaltransforms                 | Hamish Moffatt<EMAIL_ADDRESS>                                                  |         1187368 |            3148
[07:14] <Kamion> all_ubuntu_breezy_sparc:xpdf-utils                             | xpdf                            | zope2.7-portaltransforms                 | Hamish Moffatt<EMAIL_ADDRESS>                                                  |         1187368 |            3148
[07:14] <Kamion> that makes much more sense
[07:15] <elmo> sivang: around?
[07:15] <mdz> doko: why is it using zope2.7-portaltransforms  anyway; shouldn't we use zope2.8?
[07:15] <ogra> tiefox, support questions dont belong here, this channel is for development, all support suld be done in #ubuntu, also breezy support
[07:16] <Diziet> What should I do if I discover what looks like a problem clause in a licence in non-free ?
[07:16] <Diziet> Um, universe, I mean.
[07:16] <tiefox> ok..sorry
[07:16] <\sh> Diziet: which package?
[07:16] <mdz> 2 zopes seems like enough for main
[07:16] <bddebian> elmo: I think sivang said he'd be gone for 1.5 hours or so.  Should be back in about 1 hr
[07:16] <Diziet> acroread.
[07:16] <\sh> isn't it in multiverse?
[07:16] <Diziet> multiverse I mean of course.  Excuse my wittering.
[07:17] <Diziet> But still, the licence is not one that we ought to accept, I think.
[07:17] <ogra> Diziet, acroread is fine in universe... its for the nonfree stuff
[07:17] <ogra> Diziet, as long as it allow distribution its fine
[07:17] <ogra> allows even
[07:17] <mdz> Diziet: if it allows us to redistribute it, it's OK for multiverse
[07:17] <mdz> _not_ universe
[07:17] <Diziet> 12. Compliance with Licenses. If you are a business or organization, you agree that upon request from Adobe or Adobe's authorized representative, you will within thirty (30) days fully document and certify that use of any and all Software at the time of the request is in conformity with your valid licenses from Adobe.
[07:17] <ogra> err s/uni/multi inseed
[07:17] <doko> mdz: no, the package name was choosen, because the versions for 2.6 and >2.6 were needed together in the archive. zope2.7-portaltransforms does work with 2.8 as well.
[07:17] <ogra> damned, cant type today
[07:18] <Diziet> AFAIAA we (Canonical) have no mechanism for responding to such a request.
[07:18] <\sh> Diziet: Ubuntu != canonical, or?
[07:18] <Diziet> The file is on Canonical's servers.
[07:18] <Diziet> But if that doesn't count (it's not clear whether Canonical had to agree to the licence for that) then fine.
[07:18] <\sh> Diziet: then it's forbidden for all mirrors to distribute this file
[07:19] <Diziet> Clearly, however, I can't agree to the licence when I'm doing paid work for Canonical.  So I ought to close the bug with `can't investigate' ?
[07:19] <ogra> not only ubuntu...
[07:19] <Diziet> ogra: Quite so.  But one thing at a time ...
[07:20] <Diziet> \sh: Well, perhaps the mirrors have some other licence (an implied one perhaps).  The bit I'm quoting is in the clickwrap that turns up when you try to use the mozilla plugin.
[07:20] <\sh> Diziet: no what I mean, is distributing...
[07:21] <Diziet> Yes, I know what you mean.  We seem to be talking at cross purposes.
[07:22] <ogra> anyway, i doubt adobe ever asked someone for the stuff above... as long as you dont try to make money with it
[07:22] <Diziet> ogra: I'm not in the habit of agreeing to bad small print just because `it probably won't be enforced'.
[07:22] <Diziet> And in any case, it's not my decision to make.
[07:23] <ogra> nope, mine neither
[07:23] <Diziet> My question is really, what's the correct forum for this discussion ?
[07:23] <ogra> and i thin it already happened when it entered multiverse... i know how hard it is to get nonfree stuff past elmo :) he has eagle eyes
[07:27] <Diziet> At this rate I'll end up crossposting to ubuntu-devel and debian-legal.
[07:27] <elmo> what's it got to do with debian?
[07:27] <Diziet> I don't know yet; I'm checking.
[07:28] <Diziet> Looks like acroread isn't in Debian.  So it's just an Ubuntu problem.
[07:28] <elmo> the package in multiverse was imported from Marillat
[07:28] <elmo> Debian doesn't have it
[07:28] <Diziet> Marillat is full of semidodgy stuff, isn't it ?
[07:28] <HiddenWolf> it is
[07:29] <elmo> Diziet: yes
[07:29] <bddebian> Moreso than aptget.org? ;-)
[07:29] <Diziet> So should I post to ubuntu-devel, do you want to talk about it here, or what ?
[07:29] <Kamion> bddebian: yes
[07:29] <Kamion> (generally)
[07:29] <bddebian> elmo: Hey, what's the deal?  All those syncs I send you and you just to pkerns? :-)
[07:29] <elmo> Diziet: is this from the acroread package itself?
[07:30] <elmo> Diziet: because the copyright file in the package doesn't have that kind of onerous clause
[07:30] <Diziet> It's either from acroread or mozilla-acroread.
[07:30] <elmo> of course the copyright file bears no relation to reality
[07:30] <elmo> "#!$%
[07:31] <Diziet> There's a file in mozilla-acroread that contains the text it's displaying to me.
[07:31] <Diziet> And another in acroread.
[07:31] <Diziet> /usr/share/doc/acroread/LICREAD.TXT.gz
[07:32] <elmo> yeah, I think I only checked debian/copyright in the source, which was clearly a mistake
[07:32] <Diziet> It's clause 12 (see my quote above) that I think is the problem.  (I stopped there and haven't read the rest.)
[07:33] <Diziet> Hrm.  It looks like Adobe changed the licence and the packager didn't update .../copyright
[08:03] <neiras> Hello, I am experiencing the "no default font 'fixed'" X issue that a number of other Breezy testers are having. Can anyone here tell me how to get my X fonts working again?
[08:05] <bddebian> Chirst, wtf is up with libextractor...
[08:05] <Lathiat> what about it?
[08:05] <Lathiat> i thought i fixed that
[08:05] <ogra> neiras, thats an #ubuntu question, but i'd generate a clean xorg.conf if i were you
[08:06] <bddebian> Lathiat: Fixed what?  I am trying to build 0.5.4 from Debian unstable and it's taking FOREVER
[08:06] <Lathiat> bddebian: heh
[08:06] <dholbach> have a nice evening everybody, see you tomorrow
[08:07] <neiras> ogra, asking in #ubuntu. I've had several clean xorg.confs and stripped my system down to ubuntu-minimal, then reinstalled everything with no dice
[08:09] <neiras> all I did was dist-upgrade! *sob*
[08:10] <jdub> jbailey: did you see the thread on u-d about the dude with the fusion mpt card having initramfs probs?
[08:11] <jbailey> jdub: I did, I'm going to reply in a few moments with a test initramfs-tools for him to try.
[08:11] <jdub> rad!
[08:13] <jbailey> mpt: Careful, one of us will lay you on our bench and...
[08:13] <ogra> mpt, eat more vitamins ;)
[08:13] <jbailey> Wait, what were we talking about?
[08:13] <jdub> mr fusion
[08:13] <mpt> Mr Fusion? That's from Back to the Future, right?
[08:14] <jdub> aye
[08:17] <mirak> jbailey: hi
[08:17] <mirak> jbailey: can I take a bit of your time ?
[08:17] <jbailey> mirak: Sure.
[08:17] <mirak> jbailey: I have you are in charge of ubuntu ppc
[08:17] <mirak> heard
[08:17] <jbailey> Eh?
[08:17] <jbailey> Don't pin that on me. =)
[08:18] <mirak> what ? :)
[08:18] <jbailey> Ne me donne pas a. =)
[08:18] <mirak> lol
[08:18] <mirak> it means nothing
[08:18] <mirak> :)
[08:18] <mirak> hard communication
[08:18] <mirak> jbailey: I have a problem with the kernel
[08:18] <jbailey> I have two ppc boxes, so I tend to care about it more than some other do, but it's a supported arch for us.
[08:19] <mirak> do you havge knowledge avout that ?
[08:19] <mirak> what are you box ?
[08:19] <jbailey> I am unlikely to be able to help you much with the kernel.  I can help with bootup/hotplug and such.
[08:19] <mirak> bootup ?
[08:19] <mirak> the problem I have is at boot time
[08:19] <jbailey> mirak: I try to avoid giving lists of my equipment to help random googlers decide what to steal from me.
[08:19] <jdub> that's jbailey's speciality :-)
[08:20] <mirak> I own a G3 and a G4
[08:20] <mirak> a G3 b&w
[08:20] <mirak> the G3 b&w have a problem with breezy
[08:20] <jbailey> What sort of problem?
[08:20] <mirak> you there is two ide controlers on this box
[08:20] <jbailey> Hmm.  Are all G3's oldworld?
[08:20] <mirak> the cmd646 and something else
[08:20] <mirak> no it's a newworld
[08:20] <jbailey> 'k
[08:21] <mirak> well, seems the module doesn't load
[08:21] <mirak> in the kernel it's built as a module, so it should be in the intird
[08:21] <jbailey> 'kay.  Reboot and add the word 'break' to the kernel command line.
[08:21] <jbailey> We need to check to see if it's loading at all.
[08:21] <mirak> I can't do that right now
[08:21] <jbailey> We can tell by doign an 'lsmod'
[08:21] <mirak> I can control the computer remotely
[08:21] <jbailey> "I can't do that right now, Dave"
[08:22] <mirak> but it's 300km away from me
[08:22] <mirak> at my mums place :)
[08:22] <jbailey> Ah.
[08:22] <jbailey> Will you be near it sometime soonish?  It's quite difficult to test boottime stuff remotely unless you have remote power and serial console setup.
[08:23] <mirak> I don't have that
[08:23] <mirak> what kind of box do you have ?
[08:23] <mirak> jbailey: you know on the G3 b&w there is some troubles with the two ide controlers.
[08:24] <mirak> it can happen that they switch letters
[08:24] <mirak> depending of wich ide module is loaded first
[08:24] <jbailey> letters?
[08:24] <jbailey> Right.
[08:24] <mirak> /dev/hda
[08:24] <jbailey> We load them in pci bus order as shown in /sys
[08:24] <mirak> so my system is always on /dev/hdc
[08:24] <jbailey> mirak: If they initialise in different order randomly, I suggest you use LVM for your root volume and swap.
[08:25] <mirak> well that's not random
[08:25] <jbailey> Dapper will support volume names for plain volumes, but udev grew that feature after UVF
[08:25] <mirak> ah
[08:26] <mirak> what I can do is build a kernel with the module included in it
[08:26] <mirak> built in
[08:26] <mirak> but I exept it will switch drives
[08:27] <mirak> i might try another binary, maybe it's fixed
[08:27] <mirak> my mom can reboot the computer ^^
[08:27] <jbailey> Well, if you'll be near the box soonish, it would be nice to know why the ide module isn't detected right.
[08:30] <bddebian> jbailey: Maybe because it's SCSI? ;-)
[08:30] <jbailey> bddebian: On a cmd646 chip?
[08:30] <bddebian> Oh, hehe, missed that part :-)
[09:09] <bddebian> elmo: Thanks for those.  Did you get my responses about vipec and oregano?  I'm wondering if my mail client at work is getting through?
[09:14] <bddebian> We don't have guile-1.6??
[09:17] <bddebian> Anyone, anyone, Beuhler?
[09:20] <bddebian> Never mind
[09:40] <ploum> Hello
[09:40] <ploum> I've seen that OOo 1.1.5 is released. Will it makes to Breezy ?
[09:41] <ogra> ploum, breezy uses ooo2
[09:41] <ploum> ogra, yes, but I'm talking about universe
[09:42] <ploum> For example, I've an old laptop here where there's no room left to install OOo2 ! (and I'm not sure it will even start, it's so heavy)
[09:42] <ploum> But I think that I must be able to read odt file...
[09:43] <ploum> So I'm asking if this will be a "freeze exception" or not
[09:44] <tseng> oo2 replaces oo1 on a clean breezy install
[09:44] <ploum> this is not the question..
[09:44] <ploum> my hardware cannot run OO2
[09:44] <mdz> mvo: ping
[09:45] <tseng> i seem to read that you didnt even try to start it
[09:45] <tseng> but you have your answer.
[09:45] <mvo> mdz: pong
[09:45] <mdz> mvo: never mind, assumed you were gone and sent mail
[09:45] <ploum> tseng, I've only 2Go on this computer..
[09:46] <mvo> mdz: about #15361? sorry, my comment was badly worded
[09:46] <mvo> mdz: oh, usplash, just got the mail, reading now
[09:47] <ploum> and it takes 2 minutes to start OOo1.  I know it's not very mathematic, but OO2 si 1.5x slower on my main computer..
[09:47] <ploum> so I guess it would be 3 minutes ;-)
[09:48] <ploum> anyway : usplash is not working on this computer. It's a very old config. Must I file a bug about this or not ?
[09:48] <mdz> mvo: also, your changes to console-screen.sh seem to kill usplash
[09:50] <mvo> mdz: how so?
[09:50] <mvo> mdz: I tested it here localy
[09:51] <mdz> mvo: 15344
[09:51] <mvo> mdz: thanks, I'll have a look now
[09:53] <mdz> ploum: depends on whether you enabled it, and what the failure mode is
[09:55] <mdke> what is up with this: http://davyd.ucc.asn.au/images/af/af-shot2.png Is that for real?
[09:55] <mdz> seb128: the gdm slowness issue is something to do with how the background is drawn; I see it here too
[09:55] <Burgundavia> mdke, that looks like a great prank
[09:56] <Burgundavia> mdke, here is another one http://jrb.webwynk.net/files/evince-sponsor.png
[09:56] <mdz> seb128: did something change from bitmap to svg or something like that?
[09:56] <mdke> Burgundavia, ok just a prank then
[09:57] <ogra> mdz, nothing changed in the artwork
[09:57] <seb128> mdz: not that I known of
[09:57] <Burgundavia> mdke, notice the doc creation date (april 1st)
[09:58] <mdke> Burgundavia, ah, now I see what af means
[09:58] <seb128> s/known/know/
[09:58] <seb128> mdz: maybe gtk/cairo ...
[09:59] <ogra> seb128, what does gdm use to draw the fullscreen background ? cairo, canvas ?
[09:59] <seb128> mdz: cairo has created slowdown for some stuff
[09:59] <mdke> by the way I installed poedit on Breezy today, and I noticed that it is not using gtk2, but gtk1, is that intentional? it's real ugly
[09:59] <mdz> isn't cairo a vector graphics package?
[09:59] <seb128> right
[10:03] <mdz> seb128: I see this everywhere, on completely different hardware,  so I don't think it's X related
[10:03] <mdz> it's completely cosmetic of course, but it gives the impression of slowness :-/
[10:03] <ogra> its very likely that its cairo...
[10:03] <mdz> people will say that the entire system is slower because it makes them feel this way
[10:04] <seb128> it's the kind of issue not easy to track since it's subjective
[10:04] <ogra> probably svg artwork would help
[10:04] <mdz> it's  basically scaling a bitmap and drawing it on the screen
[10:04] <mdz> should
[10:04] <mdz> be very quick
[10:05] <mdz> seb128: are there any simpler programs which use cairo to do this, so that we can more easily compare and profile them?
[10:05] <seb128> one stuff to try for somebody noticing the difference with hoary would be to run gdm with GTK 2.6 and 2.8
[10:05] <mdz> seb128: do you have the bug# for this?
[10:06] <seb128> #
[10:06] <seb128> Ubuntu | gdm
[10:06] <seb128> ------- Additional Comments From<EMAIL_ADDRESS>2005-09-14 09:25 UTC -------
[10:06] <seb128> The thing is, I have a very fast system and gdm loaded as such in Hoary. I would
[10:06] <seb128> have thought this problem would be worse for slower machines. Not sure however.
[10:06] <seb128> IMHO, it's not so much the time, it's the uglyness :).
[10:06] <seb128> But yes, definitely not a high priority problem.
[10:06] <seb128> --
[10:06] <seb128> Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
[10:06] <seb128> ------- You are receiving this mail because: -------
[10:06] <seb128> You are the assignee for the bug, or are watching the assignee.
[10:06] <seb128> grrraaa
[10:06] <seb128> ups
[10:06] <mdz> hehe
[10:06] <seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=15373
[10:06] <mdz> thanks
[10:06] <seb128> np
[10:07] <bddebian> Any of you main folks have a problem syncing libdv 0.104 from Debian?  It closes a Malone bug but it would be a UVF exception I think
[10:07] <seb128> gdm doesn't use cairo directly, it uses GTK which uses cairo
[10:09] <bddebian> elmo: ping?
[10:09] <mvo> seb128: speaking of gtk+, did you had any luck pinging mclasen?
[10:09] <mdz> seb128: so someone could install hoary, change sources.list to breezy, update, install gdm
[10:09] <seb128> mvo: not yet, I'll let you know
[10:09] <ogra> bddebian, "mdz ping" would be the right term rather if you want to request a UVF breakage ;)
[10:10] <seb128> mdz: it will take gtk with it since the shlibs has been updated
[10:10] <bddebian> ogra: No, this is different.  But I guess I should be used to being ignored ;-P
[10:10] <bddebian> lirc isn't a main package is it?
[10:10] <seb128> mdz: somebody could build GTK 2.6 and try with it or somebody could install an hoary and build the current gdm on it, it doesn't require any new GNOMish stuff
[10:10] <mdz> bddebian: apt-cache madison
[10:10] <ogra> bddebian, you talked about libdv (libdv4 i guess)
[10:10] <Kamion>       lirc | <IP_ADDRESS>-1ubuntu2 |        breezy | source
[10:10] <Kamion> yes, it is in main
[10:11] <bddebian> Oh, it's in both
[10:11] <Kamion> (due to liblircclient0 and liblircclient-dev)
[10:11] <bddebian> Fuxxor
[10:11] <mdz> the lirc binary package is in universe, the source and libs are in main
[10:11] <mdz> no, that's quite intentional
[10:11] <bddebian> Well both lirc and libdv have bugs on Malone asking for newer versions.
[10:11] <mdz> bddebian: which packages could potentially be affected by changing libdv?
[10:12] <ogra> kino
[10:12] <mdz> bddebian: is there any rationale besides "it's newer"?
[10:12] <mdz> ogra: nothing else?
[10:12] <ogra> kino from the top of my head
[10:12] <ogra> hmm, maplayer and friends it seems in the rdepends
[10:12] <ogra> mplayer even
[10:13] <ogra> gstreamer0.8-dv
[10:13] <ogra> thats a lot
[10:13] <seb128> mdz: first thing to try would be to build current gdm on hoary, it's fast and easy
[10:14] <bddebian> mdz: "libdv 0.103 is not optimized for x86-64, and so is dog slow (i.e. cannot decode in real-time). libdv 0.104 has been out for many moons now, and there is a package in debian unstable. If it is at all possible, having libdv 0.104 in breezy would be great."
[10:14] <mdz> seb128: ok, please add simple instructions to the bug if you could
[10:14] <ogra> looks like that pulls a small multimedia apps transition on its tail bddebian
[10:14] <seb128> mdz: k, doing this
[10:14] <bddebian> ogra: OK, NP.
[10:15] <ogra> bddebian, apt-cache rdepends libdv4
[10:15] <bddebian> Here is lirc "I would like to see lirc upgraded to the latest version. This adds support for the Hauppage PVR-250 and PVR-350 infrared capabilities, which are very popular among MythTV users."
[10:17] <phlaegel> that new lirc version would be very useful to me as well, if another vote makes a difference :-)
[10:17] <seb128> mdz: what setting would you use for #14763? 3 people have reported the issue, seems that GDM simply doesn't work with ldap atm which is annoying
[10:18] <bddebian> rdepends for lirc:   vdr
[10:18] <bddebian> , lirc-x, lirc-x, lirc-modules-source, irmp3, liblircclient0
[10:18] <ogra> YAY
[10:18] <ogra> Some good news with Edubuntu 'Preview' release: installation now works
[10:18] <ogra> with my Serial-ATA disk on the AMD64 machine. :-)
[10:18] <ogra> :-D
[10:18] <bddebian> ogra: Nice
[10:18] <ogra> from a mail i just got :)
[10:18] <mdz> bddebian: it has new features, and it doesn't seem to contain any bugfixes.  it's hard to think of a clearer example of a new version that we don't want ;-)
[10:19] <bddebian> mdz: OK, fine with me, just saw those when digging through Malone bugs.  Thx.
[10:19] <mdz> bddebian: (referring to libdv)
[10:19] <mdz> I haven't looked at licr
[10:19] <bddebian> Ohh
[10:19] <mdz> bddebian: take a look at the changelog and see what's there
[10:19] <bddebian> mdz: For lirc?
[10:20] <torkel> bddebian: what? I'm pretty sure the version in breezy already supports -250 and -350
[10:20] <bddebian> torkel: Possible
[10:22] <mdz> bddebian: yes
[10:25] <bddebian> mdz: Here are the two Ubuntu changelog entries: lirc (<IP_ADDRESS>-1ubuntu2) breezy; urgency=low
[10:25] <bddebian>   * md5sum from coreutils doesn't have -v, so drop that for now.
[10:25] <bddebian>  -- LaMont Jones<EMAIL_ADDRESS>Sat, 23 Jul 2005 13:33:16 -0600
[10:25] <bddebian> lirc (<IP_ADDRESS>-1ubuntu1) hoary; urgency=low
[10:25] <bddebian>   * remove svgalib1 Dependency completely.
[10:26] <bddebian> Has there been anymore discussion/decision about dropping yehia?
[10:26] <ogra> bddebian, look if oyu find something about -{2,3}50
[10:26] <bddebian> Ohh
[10:26] <mdz> bddebian: what I meant was that you should read the upstream changelog and debian changelog
[10:27] <mdz> bddebian: the purpose is to learn which changes you are proposing that we include in breezy
[10:27] <bddebian> mdz: Honestly I'm not proposing anything.  I was just trying to close some bugs and initially hadn't realized this was a main package.
[10:27] <ogra> bddebian, re yehia, yes... we'd like to morguify it
[10:28] <ogra> upstream is dead since years
[10:28] <bddebian> ogra: elmo was questioning it because of several rdepends.  Of course man of them are gql which also sucks. ;-)
[10:30] <ogra> bddebian, did anyone try to build it with gcc3.4 as last resort ?
[10:30] <bddebian> ogra: You mean yehia/etc?
[10:30] <ogra> yup
[10:31] <bddebian> I haven't no but if they are dead, why keep them?
[10:31] <ogra> because someone might want them ?
[10:32] <bddebian> Fair enough
[10:32] <ogra> if its only a compiler issue, we could still keep it for breezy
[10:32] <ogra> s/for breezy/as long as we have a gcc3.4
[10:42] <bddebian> Well someone just let me know if I should do something/anything about any of this.
[10:50] <Surak> Hello, could someone help me on problems with latest totem in today's breezy?
[10:50] <Surak> It outputs this when I run it under gdb and I try to open a dvd:
[10:50] <Surak> Program received signal SIGFPE, Arithmetic exception.
[10:50] <Surak> [Switching to Thread -1231230032 (LWP 20650)]
[10:50] <Surak> 0xb665cd07 in gst_ffmpegdeinterlace_register () from /usr/lib/gstreamer-0.8/libgstffmpeg.so
[10:51] <Surak> This is happening with the only two DVDs I have here...
[10:52] <seb128> Surak: gstreamer0.8-ffmpeg bug
[10:52] <Surak> is this known? should I open it?
[10:52] <seb128> it's not known, no
[10:52] <seb128> you can open a bug with the backtrace
[10:52] <seb128> debug backtrace is better
[10:53] <Surak> ok
[10:53] <seb128> bugzilla.gnome.org is better too :)
[10:53] <seb128> that's an upstream issue probably
[10:53] <seb128> if you open a bug on ubuntu use malone, gst-ffmpeg is an universe package
[10:54] <Surak> allright. The strange thing is, it is happening with some recent daily builds, after the freeze. That's why I'm asking here before posting right into gnome.org
[10:54] <seb128> is that new?
[10:54] <Surak> yes.
[10:54] <seb128> gst-ffmpeg has been update from 0.8.4 to 0.8.6 a few days ago
[10:54] <seb128> you can try downgrading the gsreamer0.8-ffmpeg package
[10:54] <seb128> and note on the bug if that fixes the issue
[10:55] <Surak> ok
[10:58] <Surak> seb128: the downgrade made it work
[11:02] <Surak> will it worth something to add it into ubuntu's malone also?
[11:11] <Surak> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=316341
[11:17] <seb128> Surak: thanks
[11:18] <HiddenWolf> seb128, is there an option to unmount volumes from within nautilus?
[11:18] <seb128> Surak: could you just put a comment saying it doesn't happen with 0.8.4 ?
[11:18] <Surak> sure
[11:18] <seb128> HiddenWolf: computer:///, right click, umount
[11:19] <HiddenWolf> seb128, ah, thanks. ( I was expecting an unmount button/rightclick action on the places sidebar, or a menu option)
[11:22] <Surak> talking on unmount, the places menu should have the right-button ability for mounted units . You can only eject a mounted cd with its desktop icon or by opening the "computer" window.
[11:25] <shawarma> I have a patch for the gstreamer packages that enables the mms plugin. It requires libmms, which I've also packaged (and uploaded to REVU (the MOTU review site))... But since gstreamer is in main, libmms also has to be in main if gstreamer depends on it... How should I handle this?
[11:25] <shawarma> Should I just start out by wating ~1 month?
[11:26] <seb128> there is a wiki procedure for that
[11:27] <seb128> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[11:28] <seb128> do what is written here
[11:28] <shawarma> Right. So get libmms into main first, submit my patch for gstreamer afterwards. right?
[11:30] <seb128> no need of the patch, it's quite trivial and there is a bug open about it
[11:30] <seb128> just package the lib and get it moved
[11:30] <seb128> then I'll upload a package using it
[11:30] <seb128> thanks :)
[11:31] <shawarma> Ok.. But not until after the Breezy release, I suppose?
[11:31] <shawarma> And yes, the gstreamer patch was definitely the easiest part. :-)
[11:35] <shawarma> seb128: Thanks for your help! Gotta go!
[11:57] <Evaso> BenC: ping
[12:00] <ctw> Hi! I installed the Breezy preview on a HP Pavilion dv1000 notebook and have some issues with suspend to ram/disk (apprently both worked fine in Hoary). Would anybody here be interested in more details or be willing & able to help out?