[12:05] <Kamion> can people have a quick sanity-checking glance over http://people.ubuntulinux.org/~cjwatson/openssh.diff, for #1586?
[12:05] <Kamion> that diff is against the current version in sarge, but can be ported
[12:14] <minghua> hi, I am wondering how to get a package in universe updated
[12:14] <minghua> I am the Debian maintainer of scim package
[12:15] <minghua> and a user reported it does not work in ubuntu warty
[12:15] <minghua> he didn't reply my inquiry yet but I have an idea what can be wrong
[12:32] <Kamion> minghua: mail ubuntu-devel@lists.ubuntu.com and say what doesn't work, please; if it's just a matter of syncing a new source package from universe, then that should be possible
[12:32] <Kamion> er, s/from universe/from unstable/
[12:33] <Kamion> minghua: in general universe is frozen at the moment
[12:41] <yuval> Can I fix the Hebrew translation of ubuntu (debian) installer?
[12:44] <minghua> Kamion: thanks for the info.  is it possible to update universe even after warty is released?
[12:45] <minghua> since I am busy now, and not sure if I can sort things out before release
[12:45] <Kamion> minghua: not for warty. For hoary, we'll be syncing updates automatically from sid.
[12:45] <minghua> yuval:  I believe ubuntu uses d-i translation
[12:46] <doko> lamont: around?
[12:46] <minghua> yuval:  You may want to have a look at http://www.debian.org/devel/debian-installer/
[12:46] <Kamion> yuval: minghua is correct in general, although there are some branding changes (substituting "Ubuntu" for "Debian", mostly) where the Hebrew translation hasn't been updated. Please file a bug with your changes, and try to keep them confined to the Ubuntu-specific changes if you can so that we don't have to throw the changes away later when merging from Debian.
[12:47] <minghua> Kamion: thanks, I'll probably target this to hoary then
[12:51] <yuval> I'll ask the translator of debian installer. I think he fixed the d-i after ubuntu take the installer.
[12:52] <yuval> There is also a bug in the base-config after the installation. the base-confgi can't display Hebrew...
[12:52] <yuval> https://bugzilla.ubuntu.com/show_bug.cgi?id=1231
[12:54] <Kamion> yuval: I know about the bug (it's assigned to me); feel free to tell me how to fix it :-)
[12:55] <Kamion> ah, you've already updated the bug, hmm
[12:55] <Kamion> we're already using libfribidi is the thing
[12:55] <Kamion> I don't know what else it could be, unless it's something in the languagechooser/countrychooser/termwrap maze
[12:57] <yuval> I don't think libfribidi will help, because the hebrew is not displayed at all. And libfribidi is for reserved Hebrew.
[12:57] <Kamion> maybe lack of a UTF-8 console?
[12:58] <Kamion> termwrap has always been a nightmare, but I don't see anything relevant in the base-config changelog since we last synced
[12:58] <yuval> I think that it's font problam.
[12:58] <Kamion> yuval: your screenshot looks like garbled high ISO-8859-1 to me ...
[01:00] <Kamion> ... or maybe not
[01:02] <yuval> I think that for warty it's ok that this srtings will be in english, but it'll be grea if you can fix this bug.
[01:03] <Kamion> I have to admit that it's lowish on my priority list right now, but having a known fix would move it a long way up said list :-)
[01:04] <yuval> Where can I find the sources of the installer?
[01:05] <Kamion> the relevant source packages ...
[01:05] <Kamion> it may be easiest to find which source packages are involved by checking out debian-installer upstream (see http://www.debian.org/devel/debian-installer) and looking for the corresponding Ubuntu source packages
[01:06] <mdz> lamont: ping?
[01:11] <lamont> postfix fix tested, time to email kamion.  Or would someone else like to review the patch to base-config?
[01:13] <mdz> Kamion: I'm not convinced that #1586 is RC for Warty
[01:13] <mdz> lamont: just noticed that James filed a bug about an FTBFS; are there any other failures that may have happened while you were away which need bug reports?
[01:14] <lamont> will check
[01:14] <mdz> lamont: can you check for anything which is not built and file bugs as appropriate (is that quinn-diff?)
[01:14] <lamont> actually, I'll start with http://people.ubuntu.com/~lamont/buildLogs/Lists/warty.all.{i386,amd64,powerpc}, and see what's marked 'Building, out-of-date', or Building from !universe
[01:15] <lamont> but first I'm going to power down my computer long enough to replace the *(%^_^& powersupply fan.
[01:15] <lamont> after mailing off my diff.
[01:15] <lamont> mdz: you want to see the diff?
[01:15] <mdz> lamont: sure
[01:15] <lamont> verified to close 1711 and 1123
[01:16] <lamont> sent.
[01:16] <Kamion> mdz: I am, if we care about woody->warty upgrades at all
[01:16] <lamont> back in a few minutes
[01:16] <lamont> Kamion:  sent to you as well.
[01:16] <Kamion> mdz: it's a significant silent change to the meaning of your configuration on upgrade, which you may not notice and which affects your security policy
[01:18] <mdz> Kamion: ssh in woody didn't use PAM?
[01:18] <Kamion> mdz: it did
[01:18] <Kamion> mdz: the UsePAM directive did not exist until OpenSSH 3.7
[01:19] <Kamion> that's really a red herring though; the real problem is that ChallengeResponseAuthentication suddenly started working and people who thought they'd disabled all password authentication suddenly found that password-style auth was allowed again
[01:20] <Kamion> so the fix is to spot PasswordAuthentication being turned off, warn about the inconsistency, and offer to disable ChallengeResponseAuthentication too
[01:20] <Kamion> (basically, openssh upstream suck and everyone gets to work around them)
[01:20] <mdz> Kamion: so in woody, if I set PasswordAuthentication no, that implicitly disabled PAM as well?
[01:31] <yuval> Kamion, I talked with the Hebrew translator of d-i, and it may be also debian bug. I'll check it tomorrow. Good night all!
[01:31] <Kamion> mdz: no
[01:32] <Kamion> mdz: PAM keyboard-interactive was turned off in woody
[01:32] <Kamion> that option was removed in 3.7, and challengeresponseauthentication got applied to PAM
[01:33] <mdz> I see
[01:33] <mdz> so we can't solve it transparently due to the change in semantics
[01:33] <Kamion> right
[01:34] <Kamion> every so often I go out into a field and scream "I HATE OPENSSH"
[01:34] <Kamion> [not really, but maybe I should] 
[01:35] <mjg59> I wholeheartedly recommend abitrary rage
[01:36] <mdz> Kamion: lamont's base-config diff looks fine to me, but I'll be bouncing you a copy for a quick review
[01:36] <Kamion> he mailed it to me too
[01:36] <Kamion> it looks fine
[01:36] <mdz> ah, ok. he didn't send it at the same time
[01:37] <mdz> lamont's reboot is lasting awfully long :-)
[01:37] <Kamion> I've replied to him
[01:46] <|trey|> Hey... skvidel was in #ubuntu earlier asking about how we will go about "a kickstart alternative"... perhaps someone would like to talk to him about the plans atm?
[01:46] <lamont> who the hell still _SOLDERS_ powersupply fans into the thing???
[01:47] <daniels> lam	?!?
[01:55] <lamont> mdz/Kamion: thoughts on the base-config diff?
[01:56] <Kamion> lamont: you have mail
[01:56] <Kamion> |trey|: I was going to answer him, but he left
[01:57] <|trey|> Kamion: ahh, oh well, his loss  :)
[02:16] <lamont> Kamion: want to review a debootstrap patch for #1879?
[02:16] <lamont> (ia64 fix, trivial)
[02:17] <Kamion> lamont: sure
[02:17] <lamont> sent.  There was a little bit of cleanup in there too, to make the unsupported architectures more obvious.
[02:20] <lamont> fabbione: sounder 9 asked me for resolutions, etc.
[02:22] <lamont> ati mach64, ddcprobe ends a nice list of resolutions with 'edidfail', xresprobe gets nothing
[02:22] <lamont> daniels: thoughts?
[02:22] <daniels> lamont: edidfail -> your monitor is unprobeable
[02:22] <daniels> congratulations! :)
[02:22] <lamont> well, it's not exactly new...
[02:23] <daniels> the resolutions given before edidfail are the ones your card is capable of doing
[02:23] <daniels> yeah
[02:23] <lamont> ah, ok.
[02:23] <daniels> if you get edidfail, your monitor totally won't talk to us
[02:23] <lamont> so that's an expected condition, then...
[02:23] <daniels> yep
[02:23] <lamont> ok
[02:23] <daniels> thanks for the case-up
[02:23] <sabdfl> justdave: ping?
[02:23] <daniels> chase-up, too
[02:23] <justdave> sabdfl: pong
[02:24] <lamont> np
[02:33] <lamont> mdz: epiphany-extensions is the only ftbfs still outstanding from !universe
[02:37] <mdz> lamont: ok, thanks
[02:38] <lamont> mdz: universe trivial bugs still fair game?
[02:40] <lamont> hrm.. showimg is the only one that is currently d-w libtiff3g-dev, and ISTR there were other issues there..\
[02:42] <mdz> lamont: yes, but RC bugs have priority
[02:42] <lamont> certainly.
[02:43] <lamont> actually looks like showimg just needs the d-w cleared.  :(
[02:45] <lifeless> pmount is interesting...
[02:46] <lifeless> doesn't seem to add umask=077 to the mount, which makes it useless for ssh keys :[
[02:49] <mdz> lifeless: for ssh keys on vfat filesystems?
[02:49] <lamont> lifeless: why are they not correct on the fs?
[02:49] <lifeless> mdz: yes
[02:50] <lifeless> I've still not done a full install, so pmount doesn't actually run automatically for me, I was just reading the stated behaviour.
[02:50] <lifeless> any hints about upgrading a debian-stable system to ubuntu such that pmount does work would be great.
[02:52] <lifeless> lamont: vfat doesn't store modes.
[02:56] <lamont> mdz: 2083 is just a s/int/gsize/, it would appear.
[03:00] <mdz> lamont: I figured it was something like that
[03:00] <lamont> if/when the amd64 build succeeds, I'll upload
[03:02] <lamont> oops.  Fire training in -2 minutes.  bbl
[03:52] <Kamion> mdz: I only count 18 RC bugs now; what's the correct query to use?
[03:56] <mdz> Kamion: needs to include NEEDINFO
[03:56] <mdz> justdave: can we create a global, cooked query for RC bugs?
[03:56] <mdz> justdave: like the "My Bugs" one?
[03:57] <justdave> sure
[03:58] <justdave> make the query that returns what you want, then copy the URL for it and jabber it to me
[04:00] <Kamion> mdz: aha, thanks
[04:00] <Kamion> presumably on the Ubuntu product only
[04:10] <mdz> Kamion: I count 24
[04:10] <mdz> Kamion: https://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Ubuntu&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PENDINGUPLOAD&bug_severity=blocker&bug_severity=critical&bug_severity=major&emailassig
[04:10] <mdz> ned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&query_based_on=RC+Bugs&field0-0-0=noop&type0-0-0=noop&value0-0-0=
[04:10] <mdz> EEK
[04:10] <mdz> anyway, that's the query I'm using
[04:11] <justdave> mdz: stick this in your toolbar: javascript:void(location.href='http://tinyurl.com/create.php?url='+location.href)
[04:12] <mdz> justdave: it would be nice if it would omit the variables that are not being used in the search
[04:12] <mdz> the stuff which is left blank
[04:12] <Kamion> mdz: oh, you're using PENDINGUPLOAD too
[04:13] <justdave> yeah, it would.  needs some javascript hackery on the form in the submithandler to pull that off
[04:14] <Kamion> mdz: I think I'll downgrade the parted bug until/unless we get feedback that daily builds still break new machines
[04:14] <justdave> or maybe just have buglist.cgi redirect to itself with the empty fields removed if it gets any passed in that are empty
[04:19] <justdave> mdz: http://www.squarefree.com/bookmarklets/mozilla.html#shorten_bug_query
[04:21] <justdave> instead of searching for all of those specific statuses, you can clear the status box and search on resolution=---
[04:21] <justdave> that gets anything that's not resolved
[04:21] <mdz> justdave: ah, that's handy, if obscure :-)
[04:26] <justdave> ok, I just added the query you pasted in here (with it cleaned up a little) to the footer next to My Bugs
[04:27] <justdave> it's tied to My Bugs though, so if you turned off My Bugs, you'll lose that, too
[04:36] <justdave> mdz: should https://bugzilla.ubuntu.com/show_bug.cgi?id=1379 be a higher severity?
[04:39] <Kamion> #1379> if so, can it be reassigned to somebody else?
[04:40] <Kamion> or even possibly if not
[04:42] <justdave> I was thinking Herbert had it, but I see it's you...
[04:43] <justdave> is being able to install onto a firewire drive on PPC considered an RC issue?
[04:44] <justdave> I successfully installed there this time until it got to the point of installing yaboot and it errored out saying it couldn't determine the openfirmware path for the device
[04:52] <justdave> unfortunately that's my primary workstation, and testing that means rebooting :)
[04:55] <sabdfl> lifeless: erk, i think i've found the problem
[04:55] <lifeless> sabdfl: wrong channel ?
[04:55] <lifeless> :)
[04:55] <sabdfl> yup
[04:55] <sabdfl> wrong tz
[05:51] <fabbione> morning guys
[05:53] <lamont> epiphany-extensions is go on amd64.
[05:53] <lamont> mdz: OK to upload?
[05:58] <lamont> doko/mdz around?
[06:02] <fabbione> hey lamont 
[06:02] <fabbione> lamont: i can review the patch if you want
[06:03] <lamont> fabbione: ok
[06:03] <lamont> fabbione: sent.  The debian/control diff is an artifact of dpkg-buildpackage -S
[06:07] <fabbione> -int len;
[06:07] <fabbione> +gsize len;
[06:07] <fabbione> and that's it?
[06:07] <lamont> yep
[06:07] <fabbione> hmmm i need more investigation for that
[06:07] <fabbione> ahaha
[06:07] <fabbione> go ahead
[06:07] <lamont> heh
[06:15] <fabbione> calc: can you open a bug in bugzilla towards xserver-xfree86: module loader broken on amd64
[06:15] <fabbione> ops
[06:24] <doko> lamont: around!
[06:28] <mdz> lamont: yes
[06:29] <mdz> 22 bugs!
[06:29] <mdz> today was a good day
[06:29] <mdz> fabbione: early morning?
[06:29] <fabbione> mdz: as usual
[06:29] <fabbione> ;)
[06:31] <fabbione> lamont: there is one on chinstrap/~doko
[06:31] <fabbione> if that's the last one
[06:32] <doko> fabbione: it is
[06:32] <lamont> given how long it'll take, I'm tempted to wait until morning and sanity return
[06:33] <lamont> but I'll fetch that.
[06:33] <mdz> lamont: CCed you on the relevant bug
[06:33] <lamont> mdz: yeah, but I didn't see any relevant info in the bug...
[06:33] <doko> lamont: do you let a buildd rebuild the packages?
[06:34] <lamont> doko: scp ~doko/tetex,yes?
[06:34] <mdz> lamont: the title of the bug is "Non-free file license in tetex-base"
[06:34] <doko> lamont: correct
[06:34] <lamont> doko: I actually have another chroot on the buildd that I toss them at, so that they don't automatically upload
[06:35] <lamont> mdz: re-reading 2066 provides no usable information, other than the fact that I was cc'ed for regression testing....
[06:35] <doko> do you have a list of packages to rebuild?
[06:38] <lamont> whatever apt-cache showpkg tetex-base ... tells me...
[06:38] <mdz> mako: is "Spell Checkking" in traffic an error or tongue-in-cheek?
[06:41] <lamont> should be speel checkking if intentional, dammit. :-)
[06:45] <doko> lamont: not enough, IMO a test-rebuild of packages build depending on tetex-bin|tetex-extra|tetex-base is needed
[06:47] <fabbione> mako: there is a typo in traffic #06. http://.www.ubuntulinux.org/community/teams
[06:47] <fabbione> you added a "." too much in the url
[06:51] <mdz> justdave: is your Warty system in #1379 up-to-date?
[06:51] <lamont> dpkg: error processing tetex-bin (--configure):
[06:51] <lamont>  subprocess post-installation script returned error exit status 30
[06:51] <lamont> I thought that was fixed?
[06:51] <lamont> doko: yeah, that was the first ... in the list :-)
[06:52] <lamont> night all.
[06:52] <justdave> mdz: 2.6.8.1-3 kernel, newest one.
[06:52] <fabbione> night lamont 
[06:52] <justdave> I've got a 10/04 daily already burned sitting here, I'd be happy to wipe it and reinstall if you'd like
[06:53] <fabbione> mdz: we have some problems with X on amd64
[06:53] <fabbione> mdz: the solution is everything other than simple
[06:55] <justdave> I last updated it with synaptic about 2 days ago (when it picked up the new kernel)
[06:55] <fabbione> mdz: apparently the module loader is broken in some cases and the only solution seems to be to compile a server with modules compiled in, but than users won't be able to install the nvidia drivers for example
[06:55] <fabbione> mdz: otherwise they need to run the -dbg package
[06:55] <fabbione> mdz: i am really NOT sure what to do here
[06:56] <fabbione> and backporting the xorg server with possible fixes is not an option at 7 days from release
[06:56] <fabbione> mdz: an option could be to install both -dbg and the normal server on amd64 defaulting to the -dbg one
[06:58] <lamont> mdz: want I should build everything in universe that depends them too?
[06:58] <lamont> hrm.. build-depends, not depends...
[06:58] <lamont> more work.
[07:00] <mdz> justdave: can you try booting the non-smp kernel with only one parameter, root=/dev/hda11?
[07:00] <mdz> justdave: with no 'quiet' or 'splash'?
[07:00] <justdave> mdz: did that, it didn't help.
[07:00] <justdave> (tried that first before I added the devfs thing)
[07:01] <mdz> very weird
[07:01] <mdz> justdave: this is a default, non-expert install with an ext3 root filesystem?
[07:02] <mdz> fabbione: in which cases is the module loader broken?
[07:02] <justdave> mdz: that is correct
[07:02] <mdz> fabbione: I have not experienced any problems with the nv driver
[07:02] <mdz> justdave: could you try booting with rootfstype=ext3 ?
[07:02] <mdz> justdave: and if that doesn't work, rootfstype=ext2?
[07:04] <justdave> I asked earlier and no-one answered...  does it mean anything significant if the installer uses a red background?
[07:04] <lamont> mdz/doko: builds started.
[07:04] <lamont> 25 packages (not in universe) to build
[07:04] <lamont> s/not in universe/in main/
[07:05] <justdave> I remember always seeing it blue before, but I just realized when I boot the CD on the dual G4 it comes up red
[07:05] <fabbione> mdz: someone reported the problem with Nv, and calc yesterday with ATI
[07:05] <fabbione> mdz: the server gets a SIG11
[07:05] <mdz> lamont: don't worry about universe
[07:05] <fabbione> and dies
[07:05] <lamont> mdz: right.
[07:05] <mdz> fabbione: repeatable?
[07:05] <lamont> that also kinda ignores restricted... will check. :-)
[07:05] <fabbione> mdz: yes
[07:05] <fabbione> mdz: installing the -dbg works
[07:06] <mdz> fabbione: is there a bug filed?
[07:06] <fabbione> mdz: calc did a test for me creating a normal server but with modules compiled in and it worked
[07:06] <lamont> no build-deps from restricted
[07:06] <fabbione> mdz: calc was going to do so soon
[07:06] <mdz> if the module loader were broken on amd64, I would expect it to fail for me as well
[07:07] <justdave> ok, with rootfstype=ext3, it hangs.
[07:07] <justdave> rebooting now to try it with ext2
[07:08] <fabbione> mdz: i am not sure exactly in which conditions it breaks
[07:08] <lamont> hrmpf.  and then there were 23. :-(  WTH?
[07:09] <justdave> lamont: I bumped up 1379
[07:09] <lamont> ah, ok.
[07:09] <justdave> which may get bumped down again unless we find an easy way to fix it.  there's a lot of dual ppc's out there, but it's a pretty small chunk of our overall audience.
[07:10] <fabbione> mdz: 1999
[07:10] <fabbione> s/mdz/guys:
[07:10] <justdave> rootfstype=ext2 hangs also
[07:10] <fabbione> i really have no idea wtf is wrong on that system
[07:13] <lamont> doko/mdz: builds running on all 3 architectures.  since gcc-3.[34]  is involved, I'll check in the morning...
[07:13] <lamont> night for real, all.
[07:14] <lamont> fwiw, I had to dpkg --purge tetex-bin in my amd64 chroot (albeit old) before I could successfully install it...  30 == debconf return, of course.
[07:14] <lamont> must investigate that...
[07:16] <doko> lamont: you can drop gcc-3.[34] , it's not needed.
[07:19] <lamont> doko: yeah, but I'm going to bed anyway, and it should finish by morning either way.
[07:19] <lamont> anyway, to bed.
[07:25] <mdz> fabbione: re: 1999, maybe a debconf problem?
[07:28] <fabbione> mdz: if it was a debconf problem, both debian and us will be sharing approx 20000 bugs
[07:28] <mdz> fabbione: maybe try DEBCONF_DEBUG=.*
[07:28] <fabbione> that script didn't change for ages
[07:29] <fabbione> even Overfiend doesn't understand what the problem is
[07:29] <mdz> fabbione: perhaps something is messing with the debconf file descriptor?
[07:30] <fabbione> mdz: i really really doubt.. we are shipping that file since 4.3.0-1 was out
[07:33] <fabbione> joeyh told me that debconf dies automatically once the script exit 
[07:33] <fabbione> that is by design
[07:33] <fabbione> if it was a debconf leak, we would be able to see it everywhere
[07:34] <daniels> justdave: any chance there could be any way we could get slimmed-down bug pages?
[07:35] <fabbione> hey daniels 
[07:35] <fabbione> daniels: how is going the organization for the Xsprint meeting?
[07:35] <justdave> information overload?
[07:35] <fabbione> daniels: there are only 3 weeks left
[07:35] <fabbione> daniels: did you find a hotel room or something?
[07:37] <mdz> justdave: can you send dmesg output from the uniprocessor kernel booted with devfs=mount?
[07:40] <justdave> hmm, yaboot doesn't let you pass command line params like lilo does?
[07:40] <mdz> dunno
[07:40] <justdave> (I'd been editing yaboot.conf and running ybin before, but since I was in the process of rebooting as you said that anyway, figured I'd try it from the boot prompt - didn't work)
[07:40] <mdz> I've never tried
[07:43] <justdave> ok, with devfs=mount, it still hangs.
[07:43] <justdave> trying again with dall
[07:44] <fabbione> mdz: 2073.. i think that's the easiest solution in a short term.
[07:44] <fabbione> mdz: i don't believe they will ever manage to fix the licence in 7 days
[07:45] <mdz> fabbione: how did it get into main?
[07:45] <mdz> fabbione: does something build
[07:45] <mdz> -depend on it?
[07:45] <daniels> justdave: even if it's just back to the component text box with no selector
[07:45] <fabbione> apt-cache rdepends shows only the 3 packages i mentioned
[07:45] <daniels> fabbione: not too bad, I've been way too busy lately (moving back home today) and am organising stuff like that
[07:46] <fabbione> mdz: iirc we forced it into main
[07:46] <daniels> fabbione: is starting on the 1st or the 8th better for you?
[07:46] <fabbione> daniels: up to you.
[07:46] <mdz> fabbione: if it is not in one of the seeds, and it is not depended upon by another package, it should not be in main
[07:46] <fabbione> daniels: as i wrote you can come the 1st and stay until Dec Conf
[07:46] <justdave> daniels: oh, you mean the download size on the page because of the component list?
[07:46] <mdz> elmo has a tool which shows the differences between germinate and the archive, and it should have shown up there
[07:46] <fabbione> daniels: but you need a room somewhere
[07:47] <mdz> maybe elmo snuck it in because he needs it to implement the easter egg
[07:47] <fabbione> mdz: i didn't check the seeds yet...
[07:47] <fabbione> could be..
[07:47] <mdz> fabbione: it's not in supported or desktop
[07:47] <mdz> I don't have germinate stuff on my laptop
[07:47] <fabbione> neither do I here (in general)(
[07:47] <fabbione> web?
[07:47] <mdz> figlet                                | figlet                       | linda (Build-Depend)                     | Carlos Laviola <claviola@debian.org>                                      |          149092 |             832
[07:48] <mdz> fabbione: linda build-depends-indep
[07:48] <fabbione> WTF
[07:48] <fabbione> why the hell linda build-dep on figlet
[07:48] <fabbione> mdz: should we kick linda?
[07:49] <mdz> fabbione: no, but we could fix it
[07:49] <fabbione> so that figlet will be dropped to universe?
[07:49] <fabbione> mdz: kick = fix linda
[07:49] <mdz> yes
[07:49] <mdz> fabbione: I thought you meant kick = kick linda out
[07:49] <daniels> fabbione: ah, right
[07:49] <fabbione> well.. that too :-)))
[07:49] <daniels> justdave: yeah, it really hurts my modem
[07:50] <fabbione> linda (0.3.1) unstable; urgency=low
[07:50] <fabbione>   * Building:
[07:50] <fabbione>     - Put figlet, groff-base, file in the Build-Depends, since passing the
[07:50] <fabbione>       test suite is required for building. (Closes: #245407)
[07:51] <fabbione> mdz: i am taking the bug and see what we can do about it :-)
[07:51] <mdz> ok
[07:51] <fabbione> i don't think it is too dangerous to drop that specific test suite
[07:51] <fabbione> since it has been tested already several times
[07:55] <mako> mdz: that subject was a joke.. if people dont' get it i can change it :)
[07:55] <mako> fabbione: thanks, fixed in arch
[07:55] <fabbione> mdz: permission to upload linda :-))))
[07:56] <mdz> fabbione: sounds good
[07:57] <fabbione> mdz: change is trivial. 2 lines modified in the tests/run_tests.py
[07:57] <fabbione> mdz: nothing more than that
[07:57] <fabbione> package builds fine
[07:57] <mdz> fabbione: works for me
[07:58] <mdz> fabbione: check germinate rdepends to make sure nothing else uses it that I missed
[07:59] <justdave> mdz: now I can't make it boot with devfs=mount,dall either.  I think it was a fluke when it booted the first time.
[07:59] <daniels> Melbourne<->London $1845, Melbourne<->Copenhagen $9363.
[07:59] <fabbione> it seems to be only linda
[08:00] <fabbione> daniels: buy a Melbourne<->London with quantas and SAS from London to Copenhagen
[08:00] <fabbione> SAS or maerskair
[08:00] <daniels> fabbione: that's what I'm going to do
[08:01] <daniels> fabbione: given I'm Melbourne->London->Copenhagen->London->Spain->London->Melbourne (no direct flights from Spain)
[08:01] <fabbione> daniels: isn't easier: Melbourne->London->Copenhagen->Spain->London->Melbourne ?
[08:02] <fabbione> you can skip to fly to london again IF you want to stay around here
[08:02] <fabbione> it's up to you
[08:02] <fabbione> also.. we don't know if it is Spain yet
[08:31] <mdz> justdave: I see; please update the bug if you haven't already
[08:31] <mdz> justdave: how many times have you tried booting?  maybe it's a race condition and it works sometimes?
[08:37] <sladen> daniels: what type of dollahs are those?
[08:37] <daniels> sladen: $au
[09:24] <pitti> Hi guys!
[09:45] <fabbione> mdz: can i fix 2049?
[09:51] <fabbione> pitti: peer-review for 2049: one line change: s/cupsd/cupsys/ in the init script on a var used only to print the name of the script in case of "usage"
[09:52] <pitti> fabbione: #2049: it looks like you should rather s/reload/force-reload/?
[09:53] <pitti> fabbione: ah , soory
[09:53] <fabbione> pitti: no no.. the reload has been removed on purpose
[09:53] <pitti> fabbione: no, you are right
[09:53] <pitti> fabbione: yes, that was me :-)
[09:53] <fabbione> tsk :P
[09:53] <pitti> fabbione: I thought that was an error message by another program calling cupsys init script
[09:54] <pitti> fabbione: looks trivial
[09:54] <fabbione> pitti: wouldn't be better to leave the reload pointing to stop/start ?
[09:54] <fabbione> pitti: yes i am asking peer review before uploading :-)
[09:55] <pitti> fabbione: well, it does not really reload cupsys, but restart it
[09:55] <pitti> fabbione: reload is optional anyway, force-reload is the one which must exist
[09:55] <fabbione> right
[09:55] <fabbione> ok can i go for the s/ upload?
[09:55] <pitti> fabbione: before my changes, there really was a reload option in cups (which restarted 90% of the system anyway, but it was the same process)
[09:56] <pitti> fabbione: but that did not work as non-root, so I restarted cups completely
[09:56] <fabbione> yesi read the changelog
[09:56] <fabbione> pitti: you still didn't answer my question ;)
 ok can i go for the s/ upload?
[09:57] <pitti> fabbione: yes, I thought I said so
[09:57] <fabbione> oky
[09:59] <fabbione> done
[09:59] <fabbione> one orphaned bug less
[10:06] <plovs_work> where is the transcript of yesterdays technical board meeting?
[10:15] <pitti> mdz: shall I care for DSA 558-1? (security bug in apache)
[10:17] <fabbione> pitti: ?
[10:17] <fabbione> for which version of apache?
[10:17] <pitti> fabbione: this DSA talks about a fixed problem in 2.0.51-1
[10:18] <pitti> fabbione: but we still have 2.0.50-something
[10:18] <pitti> fabbione: or did you already fix it in ubuntu3?
[10:18] <fabbione> pitti: i think thom did backport the fixes already
[10:18] <fabbione> and please.. call it apache2 :-)
[10:18] <fabbione> apache = apache1.3 ;)
[10:18] <pitti> fabbione: okay, next time :-)
[10:20] <pitti> fabbione, mdz: forget about this, it's already fixed. Sorry
[10:21] <fabbione> plovs_work: there was no meeting as far as i can tell
[10:26] <Mithrandir> doko_: is the fritz driver in the restricted modules package now? (on i386)?
[10:27] <plovs_work> fabbione, ok, misread wiki then, sorry 
[10:28] <doko_> Mithrandir: no, the person at AVM was in vacation the last two weeks. He emailed we yesterday that he will respond soon.
[10:29] <doko_> what kind of agreement (email/fax) do we need to redistribute the drivers?
[10:29] <Mithrandir> doko_: ok; if you could prod me once we have them, I'll be happy to test on my gateway.
[11:08] <pitti> Can anybody please peer-review the patch in #2069? It's a bit ugly, but minimal and unintrusive
[11:12] <elmo_> pitti: looks okay to me
[11:15] <elmo_> (I assume the configuration is dealt with by pppconfig or something similar?)
[11:15] <fabbione> pitti: what about dpkg-reconfigure?
[11:15] <fabbione> wouldn't the exit 0 kill it completely?
[11:16] <pitti> fabbione: yes
[11:16] <pitti> fabbione: there's wvdialconf 
[11:16] <elmo_> so would the exit 0 that's already there? :)
[11:16] <pitti> fabbione: and there are the gnome-system-tools
[11:16] <fabbione> pitti: ok
[11:16] <pitti> elmo_, fabbione: right, if /etc/wvdial.conf exists, the old code did nothing anyway
[11:17] <elmo_> SKIP (too new)
[11:17] <elmo_> Rejected: Unknown distribution `unstable'.
[11:17] <elmo_> pitti: ----^
[11:17] <pitti> elmo_: gar, sorry. I'll upload again.
[11:17] <elmo_> *blush* that's in the interdiff, I suck too
[11:23] <tof--> hi all
[11:38] <fabbione> Mithrandir: 1854
[11:39] <fabbione> Mithrandir: does it happen if you run only apt-extracttemplates on a large amount of debs?
[11:39] <Mithrandir> fabbione: haven't tried yet.
[11:39] <fabbione> Mithrandir: that can be a test case...
[11:40] <fabbione> Mithrandir: in order to get the % counter i modified slightly the perl script that calls apt-extracttemplates
[11:40] <fabbione> i doubt the bug is in the modifications but it can be related to perl?
[11:41] <Mithrandir> I wonder if it has to do with threading, somehow.
[11:41] <Mithrandir> or c++
[11:41] <Mithrandir> but it's weird that gzip is the one hanging
[12:00] <fabbione> time to prepare some food
[12:03] <amu> fabbione: is your GF in vacation ;)
[12:04] <Mithrandir> seb128: 2097, worksforme, ok with you?
[12:04] <Mithrandir> seb128: as in, the patch fixes it for me.
[12:05] <seb128> ok, I'll upload the fix
[12:05] <Mithrandir> thanks
[12:06] <Mithrandir> it also does a ton of translation, config.{guess,sub}, some XML files updates here.
[12:06] <seb128> np
[12:09] <thom> pitti: the bug in 2.0.51 only affects 2.0.51
[12:09] <thom> so, you won't see anything in the changelog
[12:09] <pitti> thom: nevermind, I already saw that the security fix from 2.0.51 was already backported. Thanks anyway
[12:12] <fabbione> amu: eheheh no.. she is at work :-))
[12:19] <sivang> anybody messed with dpkg / apt / aptitude recently? aptitude upgrade last night, now my warty is dead...
[12:20] <sivang> kernel boots (i think) however , "cannot execute /sbin/mgetty"
[12:20] <sivang> "ld has spawned too fast"
[12:20] <sivang> ??
[12:24] <pitti> Hi sivang!
[12:29] <rburton> hm, no "ant" package in universe. i presume contrib isn't being autobuilt into universe
[12:33] <thom> rburton: nyet
[12:34] <rburton> darn
[12:35] <elmo_> not yet,
[12:36] <rburton> it seems that shutdown with nfs homes hangs
[12:36] <rburton> would this be a known bug?
[12:36] <rburton> it appears that something is trying to access portmap, but that has already been shutdown
[12:37] <pitti> rburton: I can't find it in bugzilla
[12:38] <rburton> k
[12:40] <elmo_> amen
[12:49] <hazmat> hi folks, i have a long install report i wrote up with some suggestions and issues, i'm wondering which list to send it to.. any suggestions?
[12:51] <fabbione> hazmat: ubuntu-users
[12:52] <hazmat> is sounder dead then?
[12:54] <fabbione> hazmat: it was changed to chitchat something, but basically yes
[12:56] <hazmat> fabbione: ok, thanks.
[12:58] <fabbione> np
[01:06] <sivang> hey pitti, whassup?
[01:07] <pitti> sivang: the usual stuff, bug fixing :-)
[01:07] <sivang> pitti : ofcourse. I see 19 only now. good work:-)
[01:08] <sivang> for everybody ofcourse ;-)
[01:15] <fabbione> i think i am into BDSM
[01:15] <fabbione> i hate X, i love X
[01:15] <fabbione> i can't sleep at night thinking how to switch to X.org
[01:16] <fabbione> but i don't feel happy if i don't fix it
[01:25] <thom> addict :-)
[01:27] <fabbione> thom: really.. it's becoming a drug
[01:27] <fabbione> someone needs to take X away from me
[01:30] <sivang> fabbione : X-Men?? ;)
[01:30] <fabbione> people that maintains X ;)
[01:30] <fabbione> basically me and daniels 
[01:30] <fabbione> we all have some kind of unnatural power
[01:31] <DrXavier> see
[01:31] <DrXavier> i can read and control people mind
[01:49] <sivang> fabbione : then I'll be Wolverine ;-)
[01:49] <elmo_> fabbione with mind control - women of the world RUN AWAY..
[01:49] <elmo_>  :P
[01:50] <fabbione> elmo_: ahha
[01:50] <fabbione> too bad Xavier is on a wheel chair ;)
[01:50] <azeem> it's always the X maintainers who strive for that super power
[01:50] <fabbione> azeem: WE HAVE SUPER POWERS
[01:50] <fabbione> :P
[01:53] <fabbione> ok.. time to stop for today
[01:53] <fabbione> my brain is melting down
[01:54] <thom> -rw-r--r--    1 thom     98693974 2004-10-06 12:52 ../mozilla-firefox_0.99+1.0PR.1-0ubuntu1_i386.deb
[01:54] <thom> *ahem*
[01:54] <pitti> fabbione: don't let that happen
[01:54] <fabbione> thom: HOLY S**T!
[01:55] <fabbione> what did you break this time?
[01:55] <pitti> thom: what's with this version? I already have it installed...
[01:55] <pitti> thom: ugh, it's a bit biiiiiig
[01:55] <pitti> thom: is this the debugging version?
[01:55] <fabbione> slightly :-)
[01:55] <azeem> it has the WWW pre-cached
[01:56] <pitti> ALL the www?
[01:56] <fabbione> PR0N!!!
[01:56] <thom> yes, this is the magical no-internet-required version
[01:56] <pitti> http://unluckystar.net/media/downloadwww.gif
[01:56] <thom> totally unstripped, -O0
[01:57] <pitti> thom: unstripped? so it *is* kind of p0rn :-)
[01:57] <rburton> poor poor thom
[01:58] <pitti> thom: are you able to get a nice backtrace for the crashing sites?
[01:58] <fabbione> at least it is VERY sexy!
[01:58] <pitti> thom: a guy on the mailing list enumerated a few other sites that crash for him
[01:58] <thom> pitti: yeah
[01:58] <thom> it crashes reproducibly in gmail
[02:01] <thom> seb128: dpkg -L libatk1.0-dbg|grep atk-1
[02:01] <thom> /usr/lib/debug/usr/lib/libatk-1.0.so.0.800.0
[02:01] <thom> um, me thinks that ain't quite right
[02:02] <seb128> thom: should be directly in /usr/lib/debug ?
[02:02] <thom> that's what libgtk2.0-dbg and libpango1.0-dbg have, yeah
[02:03] <seb128> $ ls /usr/lib/debug/usr/lib/
[02:03] <seb128> gtk-2.0                libcspi.so.0.10.4  libgnomeui-0             libloginhelper.so.0.0.0
[02:03] <seb128> libatk-1.0.so.0.800.0  libglade           libgnomeui-2.so.0.800.0  libspi.so.0.10.4
[02:03] <seb128> grumpf
[02:10] <thom> pitti: i should've let you take this on, i can't work it out at all
[02:10] <pitti> thom: I can debug the crash if you want
[02:10] <pitti> thom: Can I download the deb somewhere?
[02:11] <Kamion> pitti: surely unstripped is precisely the opposite of pr0n ...
[02:11] <pitti> Kamion: ugh, right. 
[02:11] <thom> pitti: it's a 90 meg deb, it'll take longer than a couple of hours to upload it :/
[02:12] <pitti> thom: okay, then I will build it on my own
[02:12] <thom> pitti: i'll send you my debian/
[02:12] <pitti> thom: did you do any changes in it?
[02:12] <pitti> thom: did you adopt the DEB_BUILD_OPTIONS thingy?
[02:12] <thom> yeah, adopted those, and added some more to get the libraries stripped
[02:13] <pitti> thom: doesn't take dh_strip care of it?
[02:13] <elmo_> thom: tube it to the DC ;-)
[02:13] <thom> pitti: you need to pass --disable-strip --disable-strip-libs to configure
[02:13] <pitti> thom: ah, nice
[02:14] <pitti> thom: of course I already deleted the stuff yesterday, apt-get source'ing again :-)
[02:15] <thom> d'oh :/
[02:18] <thom> pitti: my BT is at http://www.planetarytramp.net/firefox-bt
[02:20] <pitti> thom: nice. #95, var_args looks scary, but maybe that's normal
[02:21] <thom> yeah, that one concerned me a little
[02:23] <pitti> thom: did you already send me your debian/? SO far I've got no mail
[02:23] <pitti> thom: source download is complete, I can start to build it
[02:23] <thom> it's cleaning, currently
[02:23] <thom> wait one
[02:27] <pitti> thom: got it, thanks
[02:28] <pitti> thom: is it normal that most of the dpatches aren't included in 00list?
[02:29] <thom> pitti: yeah, i turned them off
[02:29] <thom> to try and work out if it was a problem with one of the patches
[02:29] <pitti> thom: ah; should they be normally turned on?
[02:29] <thom> normally they'd be turned on
[02:30] <elmo_> is it linking anything statically?
[02:30] <elmo_> if not, just blame doko and be done with it ;-)
[02:30] <thom> heh
[02:30] <pitti> thom: 06_fix_freetype_compile was added by you, but it's not in the changelog nor in 00list; shall I enable it?
[02:31] <thom> no, leave that turned off
[02:31] <thom> sorry, that's stolen from redhat and looked initially like they added it in response to similar problems
[02:35] <daniels> Kamion: comments on #1683, #1301?
[02:35] <Kamion> since new installs of openssh since 1:3.8p1-2 have set PasswordAuthentication no
[02:36] <Kamion> daniels: fixing #1683 properly involves going through languagechooser, countrychooser, base-config termwrap, and possibly console-data, and making sure they all have the right answers for that locale.
[02:37] <Kamion> I don't think automatic unicode_start is the right answer
[02:37] <Kamion> if you want to take care of that bug you're welcome ...
[02:37] <daniels> Kamion: ahr.  I might levae it to someone who has a slightly better idea of what they're doing, in that case ;)
[02:38] <Kamion> daniels: for #1301, xfs_freeze is not anywhere near sufficient, I'm afraid; Daniel Silverstone and I spent most of last Friday trying all the possibilities we could think of and failed
[02:38] <daniels> Kamion: er? I was always able to hack around it with xfs_freeze followed by xfs_unfreeze
[02:38] <Kamion> daniels: if you want to learn about localization in the installer, #1683 is a good place to start :) you'll probably know more about it than me by the time you're finished ...
[02:38] <Kamion> daniels: it's a race condition - you were lucky
[02:38] <daniels> Kamion: heh
[02:38] <daniels> Kamion: oh, hooray.  whacky.
[02:39] <Kamion> you don't need xfs_freeze in a udeb anyway, because the obvious place to put it is in grub-install and that gets run inside a chroot
[02:39] <Kamion> but we did try xfs_freeze -f /boot/grub followed by xfs_freeze -u /boot/grub, and grub still hung
[02:39] <Kamion> (in grub-install)
[02:40] <daniels> Kamion: ah, in the chroot, that's OK
[02:40] <Kamion> daniels: I'm almost tempted to say that the right answer for warty is to make the install fail hard at partitioning if you try to put /boot on XFS
[02:40] <Kamion> there's already a warning I think, but people ignore it
[02:41] <daniels> Kamion: yeah, fair enough
[02:41] <daniels> Kamion: or grub-install; sleep 10; killall -9 grub-install; xfs_freeze; xfs_unfreeze; grub-install :P
[02:41] <Kamion> possibly :)
[02:42] <Kamion> or unmount /target, which we think is the only reliable way, but is *very* hairy to do at that point ...
[02:42] <daniels> um, btw, if that gets implemented, I didn't suggest it
[02:43] <daniels> Kamion: does xfs_freeze; sync; xfs_unfreeze help?
[02:44] <Kamion> not as far as I recall
[02:45] <Kamion> we also tried sync; xfs_freeze -f; xfs_freeze -u; sync
[02:45] <daniels> argh!
[02:46] <daniels> freeze->sync->unfreeze would make the most sense to my mind, since freeze just blocks/queues all IO, and unfreeze reallows it
[02:46] <daniels> maybe you want sync->freeze->sync->unfreeze(->sync?)
[02:46] <Kamion> possibly, but apparently sync only guarantees that the data has been written to the journal, not to the disk
[02:46] <Kamion> s/disk/actual filesystem/
[02:47] <Kamion> there was a thread about it from March on the xfs-devel list; Google finds it fairly easily
[02:47] <daniels> iirc _freeze flushes the journal, though
[02:47] <Kamion> freeze; unfreeze worked for the Fedora guy apparently, but we duplicated what he did as closely as possible and it didn't work for us
[02:47] <daniels>        The  -f  flag  requests  the  specified  XFS  filesystem  to  be frozen from new modifications.  When this is
[02:47] <daniels>        selected, all ongoing transactions in the filesystem are allowed to complete, [...] 
[02:48] <Kamion> the whole thing scares me too much at this stage, I'd rather forbid it and revisit it for Hoary
[02:49] <daniels> yeah, if it's looking so shakily non-trivial
[02:49] <Kamion> we're going to get very little testing of installer changes from now on, so they do need to be safe
[02:49] <daniels> yeah
[02:49] <Kamion> it's basically only the sort of people who grab daily builds
[02:49] <daniels> hence why you can have 1683
[02:49] <Kamion> damn, I wanted to give that to you. :)
[02:50] <daniels> dude, I'm not going to break the installer a fortnight before Warty :P
[02:50] <daniels> i mean, learning about stuff is fun and cool, but, er
[02:50] <Kamion> I'm happy to review your changes, I'm confident I can tell the difference between something that will break things and something that won't
[02:50] <daniels> hm, OK
[02:50] <daniels> i might snarf it, then
[02:51] <daniels> feel free to reassign; you'll probably get to the bug in the next half an hour, before the page loads here :P
[02:51] <Kamion> daniels: also I think there's a similar bug in Debian that's been discussed recently
[02:51] <Kamion> look in the changelogs of the packages I mentioned
[02:51] <Kamion> possibly solved, even
[02:51] <daniels> Kamion: sure, I'll check it out when I get back from the supermarket
[02:51] <Kamion> thanks, will reassign
[02:51] <daniels> cleaning products and energy drinks: two great tastes that taste great together
[03:07] <lamont> doko/mdz: i386/amd64 built everything they tried (all build-dep-ing), ppc is still chunking away...
[03:10] <thom> anyone care to review https://bugzilla.ubuntu.com/attachment.cgi?id=356 ?
[03:12] <daniels> thom: would suggest using modprobe -q instead of redirection, but it fits in nicely with the style, so meh; that aside, the only comment I have is `` -> $()
[03:12] <daniels> thom: looks otherwise correct
[03:13] <thom> daniels: 14:13 < tbm> StevenK: hey, do you know how to contact daniels?  apparently his email's not working or something
[03:18] <daniels> gah. thanks for the heads-up.
[03:20] <sivang> has both lp and gnome-daemon-settings bug been fixed?
[03:20] <thom> daniels: on OFTC #d-d
[03:20] <sivang> where have all critical bugs went? ;-))
[03:21] <Mithrandir> sivang: crushed. :)
[03:22] <sivang> Mithrandir : wowo :-)) can I find them (see what's been done to fix) on the "closed" bugs?
[03:22] <Kamion> they're all in bugzilla ...
[03:23] <thom> ok, and https://bugzilla.ubuntu.com/attachment.cgi?id=357 (it's unbelievably trivial)
[03:24] <rburton> and i assumed you were loading toshiba_acpi on purpose
[03:25] <thom> heh.
[03:25] <thom> i assume the eventual intent is to handle this crap with hotplug
[03:26] <Kinnison> thom: have you uploaded the nice new acpi-support yet?
[03:26] <thom> no, i should get that reviewed too
[03:26] <Kinnison> thom: It's getting *really* tired having to plug my laptop in to shut it down
[03:30] <thom> Kinnison: i forgot, matt already said i could upload. done
[03:31] <Kinnison> thom: rock on
[03:31] <Kinnison> thom: I'll let you know how I get on later
[03:34] <thom> coolies
[04:01] <pitti> thom: mine is bigger than yours :-)
[04:01] <pitti> thom: -rw-r--r--    1 martin   martin   10645500 2004-10-06 15:59 mozilla-firefox_0.99+1.0PR.1-0ubuntu1.1_i386.deb
[04:01] <pitti> thom: no, it isn't. A digit it missing...
[04:03] <thom> heh
[04:03] <pitti> thom: DAMN! After two hours of compiling this thing is still stripped
[04:03] <pitti> thom: What did I do wrong? I built with DEB_BUILD_OPTIONS=nostrip,noopt debuild -us -uc -b
[04:04] <pitti> thom: and indeed the files were compiled with -g -O0
[04:04] <thom> that's exactly what i did
[04:04] <pitti> thom: $ file browser/app/firefox-bin
[04:04] <pitti> browser/app/firefox-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
[04:05] <Mithrandir> pitti:  rm browser/app/firefox-bin ; make ?
[04:05] <pitti> Mithrandir: and all the libraries?
[04:06] <pitti> thom: your --disable-strip logic is wrong, AFAICS
[04:06] <thom> huh
[04:06] <thom> file ~/tmp/x86-home/usr/lib/mozilla-firefox/firefox-bin
[04:06] <thom> /home/thom/tmp/x86-home/usr/lib/mozilla-firefox/firefox-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
[04:06] <pitti> thom: ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) will be false if you give nostrip
[04:06] <Mithrandir> pitti: find -name \*.so | xargs rm as well, then?
[04:07] <thom> i'm sure i gave you the version i was using
[04:07] <pitti> Mithrandir: yes, something along that line. Thanks, will try
[04:07] <pitti> thom: I think ifeq needs to be changed to ifneq
[04:07] <pitti> thom: or --disable-strip and --enable-strip swapped
[04:07] <thom> ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
[04:07] <thom> STRIP=--enable-strip --enable-strip-libs
[04:07] <thom> else
[04:07] <thom> STRIP=--disable-strip --disable-strip-libs
[04:07] <thom> endif
[04:08] <pitti> thom: right, that's how it should be
[04:08] <thom> is what my debian/rules has
[04:08] <pitti> thom: my debian/rules has it exactly the other way round
[04:08] <thom> hrm. must have found an old one
[04:08] <thom> very, very sorry about that
[04:08] <pitti> thom: well, it does not matter that much, I'm busy with aptitude anyway
[04:09] <pitti> thom: did you change anything else?
[04:09] <thom> nope
[04:10] <pitti> thom: okay, then I will just make the swap myself. Thanks.
[04:10] <thom> it'll take about 40m for my .deb to upload
[04:10] <thom> if you want to just download that
[04:10] <pitti> thom: can I download it right from your machine?
[04:10] <pitti> thom: my connection is not faster (about 50 kB)
[04:11] <thom> no, i'm behind nat :/
[04:11] <pitti> thom: me too :-)
[04:11] <pitti> thom: nevermind, I just rebuild it
[04:11] <pitti> thom: I will fix aptitude and maybe #1552 in the meantime
[04:11] <pitti> thom: or have dinner :-)
[04:12] <thom> pitti: heh :-) it'll be at www.planetarytramp.net/mozilla-firefox_0.99+1.0PR.1-0ubuntu1_i386.deb in about 40m, so if that's fasdter it's there
[04:12] <pitti> thom: thanks
[04:18] <daniels> pitti: only 10MB? that's tiny
[04:18] <pitti> daniels: see above, due to a slight error in debian/rules it got stripped
[04:18] <daniels> pitti: even so :)
[04:18] <daniels> if your source tarball is less than 50MB when .bz2'd, I have no sympathy :P
[04:18] <pitti> daniels: well, 10 MB for a browser should be more than enough :-)
[04:19] <daniels> pitti: you'd think that ...
[04:19] <pitti> daniels: hey, in C64 times software needed to fit into 64 KBytes! :-)
[04:20] <daniels> do you really want to be running Moz on C64?
[04:20] <pitti> daniels: _even_ the graphical environment (GEOS), to be precise :-) (SCNR)
[04:20] <daniels> hm, that reminds me, I still need to get around to seeing how long KDE takes to load on an m68k
[04:21] <daniels> pitti: X is a hulking PoS, news at 11 :P
[04:21] <pitti> daniels: poor m68k
[04:21] <pitti> daniels: it already takes ages at my Duron 1.3
[04:22] <azeem> it was interesting to read keithp blog about twin
[04:22] <pitti> daniels: I already heard of several alternatives, one was called 'Y' and was really tiny
[04:22] <elmo_> azeem: keithp blogged about ben a. ?
[04:24] <azeem> pitti: twin is supposed to be less than 50KB, from what I read
[04:24] <pitti> azeem: well, if an X replacement relies on the kernel framebuffer (or something like that), it shouldn't be that big
[04:25] <daniels> pitti: y is good for a laugh
[04:25] <pitti> azeem: but something has to provide all this 3D and network stuff, so 50 KB are certainly not enough for a Desktop
[04:25] <daniels> pitti: and relying on the kernel framebuffer really sucks
[04:25] <pitti> daniels: I know, I tested it and was pretty amused
[04:25] <daniels> twin is good for putting on a computer watch or something equally hypothetical
[04:25] <pitti> daniels: but what makes X actually so big? Only device drivers?
[04:25] <pitti> daniels: or layers over layers of abstraction layers which abstract other layers?
[04:25] <daniels> pitti: if you know anyone who wants to fund me, keithp, jaymz, anholt, ajax, and possibly andersca full-time for a year, let me know ;)
[04:25] <Mithrandir> does the kernel framebuffer support any kind of 3d?
[04:26] <daniels> pitti: drivers, support for everything under the sun, a whole crapload of useless libraries/fonts/docs (in FrameMaker format, no less), and some useless abstraction layers
[04:26] <daniels> drivers are also pretty big, I suppose
[04:26] <pitti> Mithrandir: none that I know of
[04:26] <daniels> Mithrandir: last I looked, there wasn't any real good 2D acceleration in any of them
[04:27] <pitti> Mithrandir: however, 2D support is quite good in the specialized drivers (riva, radeonfb etc.)
[04:27] <pitti> daniels: not?
[04:27] <pitti> daniels: the radeonfb driver is pretty cool
[04:27] <daniels> pitti: is it still as buggy?
[04:27] <Mithrandir> yeah, it's buggy.
[04:27] <daniels> pitti: last time I tried, when I got it to work, it left droppings all over my screen
[04:27] <pitti> daniels: on a 9200 it works like charm
[04:28] <pitti> daniels: no, I never encountered that
[04:28] <pitti> daniels: but maybe it blurbs on better radeons
[04:28] <daniels> pitti: i saw it on a 9000 and an 8500
[04:29] <daniels> anyway, I'm killing my bandwidth by rsyncing all the fd.o CVS repos back here right now so I can do some hacking
[04:29] <daniels> so, I'll talk to you later :)
[04:29] <pitti> daniels: odd. Well, if it works on one system and crashes at another, it still counts as buggy, I suppose
[04:34] <lamont> well, once X and the other 100 packages install... :-(
[04:43] <sivang> fabbione : integerating X.org is going to be a pain in the arse? ;-)
[04:44] <sivang> (seen your comments about it increasing your insomnia sympthoms ;-)
[04:55] <thom> pitti: 8 minutes
[04:56] <daniels> sivang: it's a massive amount of work
[05:03] <thom> pitti: done
[05:04] <pitti> thom: thanks!
[05:04] <thom> 94MB  29.8KB/s   54:00
[05:08] <lamont> yea! new metacity actually remembers what workspace a window is in!
[05:20] <Kamion> please review https://bugzilla.ubuntu.com/attachment.cgi?id=361
[05:28] <lamont> Kamion: nothing leaps out at me in 60 seconds or less.
[05:28] <daniels> Kamion: looks OK to my tired eyes
[05:31] <lamont> Kamion: would it be simpler to just sync the debian package?
[05:31] <Kamion> lamont: we've already forked it
[05:31] <Kamion> otherwise I would :)
[05:32] <lamont> right
[05:37] <Kamion> set_config_option is hairy but I think it's right
[05:40] <Kamion> uploaded
[05:44] <Kinnison> w00p
[05:45] <Kamion> ooh, I don't have the highest number of RC bugs any more
[05:45] <rburton> i should find the time to put ubuntu onto my laptop
[05:45] <rburton> then i can get thom to fix acpi for me
[05:50] <lamont> Kamion: yeah, but herbert's are all in _one_ package... :-)
[05:51] <thom> 14 of the 20 bugs assigned to me are about firefox
[05:51] <thom> *sigh*
[05:51] <elmo_> dude, I told you were the Mozilla czar
[06:22] <Mithrandir> does anybody care about ibcs?
[06:22] <lamont> Mithrandir: was that a vote for Conflicts?
[06:22] <Mithrandir> yeah
[06:22] <lamont> sold
[06:22] <Mithrandir> or talk to the ibcs maintainer
[06:23] <Mithrandir> what does trace(8) do?
[06:23] <lamont> or both. :-)
[06:23] <lamont> I believe that's sendmail -bt support
[06:23] <lamont> nope
[06:23] <Mithrandir> NAME
[06:23] <Mithrandir>        bounce - Postfix message bounce or defer daemon
[06:23] <Mithrandir> is what I get from man 8 trace
[06:24] <lamont> yeah - it's the same man page for all 3
[06:24] <lamont> bounce defer trace
[06:24] <Mithrandir> lamont: well, dpkg -S trace | grep post only returns the man page here..
[06:26] <lamont> looks to be DSN stuff
[06:26] <lamont> ibcs is universe
[06:27] <lamont> mdz: thoughts?
[06:27] <lamont> bidwatcher should be main, dammit.
[06:28] <mdz> morning
[06:28] <lamont> mdz: and a fine thought that is, too. :-)
[06:30] <mdz> lamont: both packages should be shot for naming a binary 'trace'
[06:31] <Mithrandir> mdz: postfix doesn't have any binaries named trace, it seems.
[06:31] <lamont> mdz: well, yes... I suppose I could rename it to postfix-trace
[06:31] <Mithrandir> mdz: it's just a service in master.cf
[06:31] <mdz> ah, so it's a manpage conflict?
[06:31] <Mithrandir> looks like it.
[06:32] <Mithrandir> : tfheen@yiwaz ~ > dpkg -S trace |  grep /trace$
[06:32] <Mithrandir> oftc-hybrid: /usr/share/oftc-hybrid/help/opers/trace
[06:32] <Mithrandir> irssi-text: /usr/share/irssi/help/trace
[06:32] <Kamion> trace.8postfix.gz?
[06:32] <lamont> man8/trace.8:
[06:32] <lamont>         echo .so man8/bounce.8 >$@
[06:32] <Mithrandir> (this box has postfix installed)
[06:32] <mdz> is ibcs even actively maintained?
[06:32] <Kamion> man section extensions are the standard way to solve conflicts
[06:33] <mdz> that sounds reasonable
[06:33] <lamont> Kamion: I like that - is it just a matter of delivering it as trace.8postfix?
[06:33] <Kamion> lamont: yes
[06:33] <lamont> and should I deliver all of them in that section, or just the conflicts?
[06:33] <Mithrandir> mdz: seen my latest comment on 1854? :/
[06:33] <pitti> mdz: morning
[06:35] <mdz> Mithrandir: fortunately, that bug only happens to you :-P 
[06:35] <Kamion> mdz: what do you think about this wget "security" bug? #261755
[06:35] <Mithrandir> mdz: has anybody actually tried to reproduce it using the instructions I gave?
[06:36] <mdz> Mithrandir: yes
[06:36] <mdz> Mithrandir: except for the bit about "buy a P4 HT and use an SMP kernel"
[06:36] <mdz> Kamion: I think it's silly
[06:36] <Mithrandir> mdz: well, given that you need a P4 HT.. :)
[06:37] <Kamion> that was my initial reaction
[06:37] <mdz> Jan Minar has filed a bunch of similar bugs
[06:37] <Kamion> mdz: I'm being asked to review it for pushing into sarge
[06:37] <mdz> I'm waiting for the one against cat(1)
[06:37] <mdz> where it will allow arbitrary characters to be displayed on the terminal
[06:37] <Kamion> can I quote you there, to the wget maintainer?
[06:37] <mdz> "I think it's silly" -mdz
[06:37] <mdz> like that? :-)
[06:37] <Kamion> approximately :)
[06:37] <mdz> it's especially discouraging that the proposed patch has bugs
[06:38] <mdz> sure, quote me if you think it'd help
[06:38] <lamont> Kamion: should I deliver all of the section 8 manpages in 8postfix, or just trace?
[06:40] <Kamion> probably best to be consistent; perhaps deliver all the ones that are just master.cf services in 8postfix
[06:47] <mdz> Kamion: did you determine that unfuzzying translations with s/Debian/Ubuntu/ was relatively non-evil?
[06:47] <mdz> Kamion: (#2085)
[06:50] <mdz> justdave: please attach a dmesg from a successful boot to #1379
[06:53] <thom> so my dad was installing ubuntu on a vaio with a usb cdrom drive last night
[06:53] <thom> he was going to call if he had any problems
[06:53] <thom> no phone call :-)
[06:53] <thom> uh, s/usb/pcmcia
[06:53] <pitti> thom: nice idea from you to disable your phone :-)
[06:54] <thom> heh
[06:55] <thom> pitti: having fun with firefox?
[06:55] <pitti> thom: I just tried to debug it
[06:55] <pitti> thom: it's a mess
[06:56] <thom> yes
[06:56] <thom> :(
[06:56] <pitti> my current quick "fix" is to use Mozilla.
[06:56] <pitti> I will return to that tomorrow, I'm too tired today to deal with such a monster
[06:57] <thom> eeexcellent
[06:58] <mdz> pitti: regarding #2085, I noticed the description for 'base' and it should be changed semantically
[06:58] <mdz> pitti: section 'base' does not at really correspond to the base system at all
[06:58] <pitti> mdz: okay, I can change that, too
[06:59] <pitti> mdz: what would you propose?
[07:00] <pitti> mdz: BTW, I hope that it was okay for me to prepare patches, although the bug was assigned to you
[07:01] <Kinnison> daniels: Erm; gnome-volume-manager isn't responding to plugin events again :-(
[07:01] <pitti> mdz: my own list got major-free this morning :-)
[07:01] <mdz> pitti: I don't know what the text should be; section 'base' is not very meaningful
[07:01] <mdz> it's not very meaningful in Debian, either, but even less so in Ubuntu :-)
[07:01] <pitti> mdz: I also stumbled about this in my NM processes
[07:02] <pitti> mdz: its ,well, just "base packages" - packages which we do not have a special name for...
[07:02] <sivang> aren't they providing "basic system capabilities" ?
[07:02] <sivang> the essentials
[07:03] <pitti> all these are just synonyms
[07:03] <mdz> the essentials are Essential: yes packages
[07:03] <pitti> mdz: I know, but an user will not care for the difference
[07:06] <pitti> mdz: What about "Ubuntu system packages - Packages in the "base" section provide the basic functionality of an Ubuntu installation (hardware support, package management, etc.)"
[07:06] <fabbione> daniels: 1117, can you give the driver to Herbert please?
[07:06] <fabbione> mdz: i solved the problems with the ADSL line transfer. In the worst case I will have 2 to 5 hours of downtime
[07:07] <fabbione> mdz: 2 if the adsl line is ok, 5 if it is not (and my previous employer will host me in his offices)
[07:08] <mdz> fabbione: nice
[07:09] <mdz> pitti: the thing is, there are many packages in that category which are not in section 'base'
[07:09] <mdz> and things in section 'base' which do not fit that description
[07:09] <pitti> mdz: well, the whole categoryseems to be more or less arbitrary
[07:09] <mdz> pitti: correct, which is why it is hard to describe :-)
[07:09] <pitti> mdz: "Packages which we did not find a better section for "
[07:11] <elmo_> base should be what debootstrap installs or it shouldn't exist
[07:11] <pitti> elmo_: certainly a nice explanation for a new user :-)
[07:13] <Kinnison> thom: want an amusing mozilla-firefox bug? </sarky>
[07:13] <thom> oh, i'm sure amusing is just the word *sigh*
[07:14] <pitti> mdz: what do you think about the patches in general? Shall we aim for new translations? Any thing I forgot about?
[07:14] <Kinnison> thom: I can reproducably stop firefox scrolling with the scrollwheel by viewing long bugs on bugzilla.ubuntu.com
[07:14] <thom> Kinnison: already filed
[07:14] <Kinnison> thom: Boo hiss; I thought I'd found a new one
[07:14] <Kinnison> thom: fix it
 areas and <code> areas seem to do it
[07:15] <Kamion> mdz: yes
[07:15] <Kamion> mdz: where it's obviously possible; sometimes it's hard
[07:16] <thom> Kinnison: #1962
[07:16] <Kamion> ohbugger; archive-copier needs to copy mdetect, xresprobe, and laptop-detect
[07:16] <Kamion> forgot about those when I turned off copying of Ship
[07:16] <mdz> pitti: the patches look fine
[07:17] <pitti> mdz: so we need a "base section description contest" now? :-)
[07:18] <mdz> pitti: "miscellaneous packages which provide basic functionality"
[07:18] <Kamion> miscellaneous sounds wrong to me there
[07:18] <mdz> Kamion: any idea about that kbd-chooser hang on -users?
[07:18] <mdz> Subject: Re: Install choking after country selection
[07:18] <Kamion> it has connotations of "extra"
[07:18] <Kamion> mdz: haven't had time to look at it yet, will do
[07:18] <Kamion> it's probably hardware-specific to some extent which makes it annoying
[07:19] <Kamion> and damnit, I forgot to do anything about Nathaniel's openssh init script patch
[07:19] <fabbione> mdz: i will have to upload X again. daniels wacom backport is botched
[07:20] <mdz> fabbione: is that related to the wacom driver update enhancement bug?
[07:20] <fabbione> mdz: yes
[07:20] <fabbione> mdz: the driver that is inside X now is not meat or fish
[07:21] <thom> fabbione: "fish or fowl"
[07:22] <fabbione> thom: shuuus ;)=
[07:22] <pitti> Kamion: seems that all in all the Debian description is not the worst one :-)
[07:24] <mdz> pitti: let's leave it as-is for the sake of getting the other work done
[07:25] <pitti> mdz: okay, I agree. We can still upload another version with more translations and some tweaks
[07:25] <pitti> mdz: so any other things before approval?
[07:26] <mdz> pitti: no, looks good
[07:26] <pitti> mdz: okay, then away with it
[07:32] <elmo_> python-gtk2-doc_2.4.10-2ubuntu1_source.changes 
[07:32] <elmo_> who uploaded that/
[07:32] <elmo_> s#/#?#
[07:34] <fabbione> probably seb?
[07:35] <thom> Kinnison: https://bugzilla.mozilla.org/show_bug.cgi?id=263198
[07:35] <fabbione> he was the one asking for it in the first place
[07:35] <mdz> elmo_: yes
[07:35] <Kinnison> thom: cool
[07:36] <thom> add additional urls if you have 'em :-)
[07:36] <elmo_> seb128: sorry, due to an obscure technical problem which I won't bore you with the details of, that file was removed - could you reupload just the .changes, please?
[07:36] <seb128> elmo_: ok, no problem
[07:36] <seb128> just the .changes ?
[07:36] <Kinnison> elmo_: saved.
[07:37] <elmo_> seb128: yeah
[07:40] <seb128> elmo_: done (I've also uploaded a libgnomeprint changes by mistake, just ignore it)
[07:41] <thom> an obscure 'rm -f' by "ftpmaster" problem? :p
[07:41] <seb128> time to dinner, later
[07:42] <Kinnison> thom: ssssh. you'll give his s3kr1t away
[07:53] <sivang> lamont : I would, as soon as my warty's XFS is fixed..;-)
[07:53] <Kinnison> sivang: what's up now?
[07:53] <Kinnison> sivang: or is it in general?
[07:54] <thom> pitti: https://bugzilla.mozilla.org/show_bug.cgi?id=255372 is the upstream for the firefox bug
[07:54] <sivang> Kinnison : ah, some funky output from xfs_check, and xfs_repair
[07:54] <lamont> sivang: most of the change is adding README.Debian files..
[07:54] <Kinnison> sivang: aah yes; I had that on Friday
[07:54] <Kinnison> sivang: been running Debian's 2.6.7 kernel since then with no problem
[07:54] <lamont> patch is at people.ubuntu.com/~lamont/postfix.diff
[07:54] <sivang> Kinnison : this on the bugzilla I hope?
[07:55] <Kinnison> sivang: Not sure
[07:55] <thom> we really need an UPSTREAM status badly
[07:55] <sivang> lamont : this a debdiff?
[07:55] <lamont> it's a diff -ur between the old tree and new one.
[07:55] <lamont> what's a debdiff? :-)
[07:55] <pitti> thom: okay, thanks. Let's just pass the buck to upstream, then :-)
[07:56] <lamont> er, -urN actually
[07:56] <pitti> thom: however, if it crashes on all pages with javascript popups, this can even be regarded as RC then...
[07:57] <sivang> lamont : sorry, misunderstanding. I think it
[07:57] <thom> pitti: agreed
[07:57] <sivang> lamont : is something comparing too pkgs if I am not mistaken
[07:57] <thom> mdz: 1676 as major?
[07:59] <lamont> sivang: yeah, I read the manpage.. 
[07:59] <sivang> lamont : do you happen to know it's package name on debian sid?
[08:00] <lamont> it's in devscripts
[08:10] <lamont>  /etc/init.d/xfree86-common: line 11: /lib/lsb/init-functions: No such file or directory
[08:11] <lamont> fabbione: daniels: what's up with that???
[08:12] <pitti> thom: what makes the warty firefox different from upstream's, if it works with upstream?
[08:12] <pitti> thom: does upstream already have a newer build?
[08:12] <lamont> pitti: besides build-depends?
[08:12] <pitti> lamont: you mean the firefox crash is actually a problem in a library?
[08:12] <lamont> pitti: nfc
[08:13] <pitti> lamont.explain( "nfc" )
[08:13] <lamont> "No F***ing Clue"
[08:13] <pitti> lamont: ah, thanks :-)
[08:13] <lamont> but build-deps is certainly a difference between the two, I expect.
[08:13] <thom> pitti: don't know, i don't understand why upstreams works
[08:13] <thom> pitti: same build
[08:14] <pitti> lamont: the stack trace does not suggest that it is in an external lib
[08:14] <lamont> which architecture?
[08:14] <pitti> thom: different compilers?
[08:14] <pitti> thom: maybe the bug is triggered only on a particular way of compilation
[08:14] <pitti> lamont: ppc and i386
[08:15] <pitti> lamont: the 32 bit ones, amd64 works well
[08:15] <lamont> pitti: that's just sick and wrong.
[08:15] <pitti> usually segfaults potentially occur on all architectures, but sometimes the compiler may hide it
[08:15] <pitti> the bug in gstreamer I tackled with recently was such a case
[08:16] <pitti> so I don't really believe that the bug is fixed upstream
[08:16] <thom> pitti: they compile with gcc-3.2, amd64 is on 3.4 and doesn't have the bug (but x86 with 3.4 still does)
[08:17] <pitti> well, we could try compiling with 3.2 and see if it works :-)
[08:17] <thom> we could, indeed
[08:17] <pitti> 7 days before the RC release we have to find faster methods of bug fixing
[08:18] <thom> ... go back to using epiphany by default? :-)
[08:18] <pitti> thom: mozilla plain works greeeeeat!
[08:18] <pitti> epiphany is just mozilla with another UI, isn't it?
[08:18] <thom> a gnome ui, yeah
[08:18] <pitti> at least epiphany draws in all the mozilla stuff in the dependencies
[08:19] <pitti> thom: would it help to revert to an earlier build?
[08:19] <pitti> thom: the upstream bug said something about reintroducing it in version whatever
[08:19] <thom> pitti: you'd be looking at backporting a stack of security fixes if we go back to 0.9.3 (which was the last version that didn't suck)
[08:20] <pitti> hmm, as long as they are properly documented and the CVS is available...
[08:21] <thom> (but firefox 1.0 is a feature goal AIUI)
[08:21] <thom> *shrug*, i think we need to speak to mdz and jdub and find out what the goals are here, and what we can do
[08:23] <pitti> thom: well, as long as the boys fix 1.0, then I'm all for it :-)
[08:23] <pitti> thom: or maybe we can convince lamont to have firefox built with gcc 3.2 :-)
[08:25] <lamont> gcc-3.2 is ftbfs on ppc
[08:25] <lamont> and amd64.
[08:26] <thom> weee
[08:26] <mdz> thom: hmm?
[08:26] <mdz> thom: re: 1676, I've never seen it
[08:27] <pitti> mdz: aren't you on amd64 as well?
[08:28] <mdz> pitti: not primarily, but sometimes
[08:28] <mdz> right now I'm laptop-only
[08:29] <pitti> mdz: I asked because the firefox crash does not appear on amd64
[08:29] <pitti> mdz: it is pretty annoying
[08:29] <pitti> mdz: I cannot do online banking and some webmail stuff with firefox, have to take mozilla proper for that
[08:30] <mdz> my online banking stuff works with firefox in ubuntu
[08:30] <pitti> mdz: and according to the mailing list, many other people suffer from this as well
[08:30] <mdz> what's the story upstream?
[08:30] <pitti> mdz: same thing. Firefox crashes on every page that opens a window with javascript
[08:31] <thom> mdz: basically, anything that does window.Open() in javascript crashes firefox
[08:32] <mdz> anyway I can test it without killing my existing firefox and all its tabs?
[08:32] <thom> mdz: create a test user, go to Applications/System Tools/New Login, log in as that user...
[08:33] <mdz> aha, -P
[08:34] <mdz> thom: just tried it in the javascript console, and it works perfectly, doesn't crash
[08:34] <mdz> is there any website I can test with that doesn't require a login?
[08:34] <pitti> mdz: https://financepilot-banking.mlp.de/ works nice for me
[08:34] <pitti> mdz: or, rather, crashes
[08:35] <pitti> mdz: this is my web banking, BTW
[08:35] <thom> mdz: www.cpsact.com.au and click on CPS Web-Link
[08:35] <mdz> pitti: when I load that page, it gives me an error in German and firefox tells me that it blocked a popup
[08:35] <pitti> mdz: you have to accept the popup
[08:36] <mdz> thom: no crash
[08:36] <thom> mdz: did you get a popup window?
[08:36] <mdz> it does open the popup, but it works fine
[08:36] <lamont> ditto
[08:36] <mdz> thom: yes
[08:36] <thom> huh.
[08:36] <mdz> this is with a fresh default profile, too
[08:36] <thom> it crashes 100% with current firefox for me
[08:36] <pitti> mdz: I also tried with a fresh profile
[08:36] <thom> fresh, stale, or downright smelly profiles
[08:37] <pitti> mdz: well, the fact that it works on amd64 and fails on i386 shows that it is a somewhat tricky one...
[08:37] <lamont> about: says firefox 0.10.1
[08:37] <pitti> mdz: sometimes it even worked for me the very first time, but it crashes the second time
[08:38] <pitti> mdz: but now I cannot get it to load a single time any more
[08:38] <lamont> still works here
[08:40] <pitti> damn, why demos always tend to fail?
[08:40] <pitti> thom, this _is_ an ugly bug. It hides itself
[08:41] <thom> interestingly, i can't get cpsact to crash on my laptop, but gmail kills it every time
[08:41] <lamont> pitti: just lucky, I guess
[08:41] <thom> mdz: i can send you a gmail invite :-)
[08:41] <lamont> thom: if you sent me one, could I give it to someone else?
[08:41] <thom> pitti: and yes, it is a nasty one for sure
[08:41] <thom> lamont: yeah, absolutely
[08:42] <lamont> (it'll let me boot my fire chief off the itanic in the other room..)
[08:42] <pitti> thom: Will you beat me up if I tell you that the CPS thingy works for me?
[08:42] <pitti> thom: can we please swap our online banks?
[08:43] <thom> lamont: just sent you two invites
[08:43] <pitti> nice, now my online bank works as well
[08:43] <pitti> I KNOW: it depends on the current time, obviously
[08:44] <lamont> pitti: glad that mdz and I could help. :-(
[08:44] <thom> pitti: you're cursed with heisenbugs recently :-)
[08:44] <pitti> lamont: it was the aura of the people who would decide to hurt this bug
[08:44] <lamont> "there are very few things about computers that cannot be explained if you are willing to grant them fear and malice."
[08:45] <pitti> thom: can we quickly rewrite firefox in python?
[08:46] <lamont> doesn't have to be quick.. Take until Fridy
[08:47] <pitti> lamont: with this timeframe we can even add a doom and a tetris plugin :-)
[08:48] <lamont> there's a tetris plugin for firefox??
[08:49] <thom> pitti: as long as we can call it pyrefox
[08:49] <pitti> lamont: not yet :-)
[08:49] <pitti> Hi T-Bone
[08:50] <lamont> hi T-Bone
[08:50] <T-Bone> hey dudes :)
[08:51] <lamont> T-Bone: where was your gcc-3.4 source again?
[08:51] <mdz> thom: regarding the powernowd module loading stuff, can we do anything smart about i386 systems which require a speedstep-* module?
[08:51] <T-Bone> lamont: envy.esiee.fr/~varenet/newgcc iirc
[08:51] <lamont> ok
[08:52] <thom> mdz: sladen, mjg59 and i were playing with a script to guess, but it's pretty fragile
[08:52] <thom> probably hoary material
[08:53] <T-Bone> lamont: mind that it built fine on ia64
[08:54] <mdz> Kamion: which kernel made it onto the 1006 daily CD?
[08:54] <mdz> thom: agreed
[08:54] <seb128> jdub: ping ?
[08:55] <mdz> Kamion: never mind, .list tells me
[08:55] <seb128> mdz: gstreamer/totem release today which improve totem-gstreamer a lot ... FC3 is going to include (they are in hard freeze too). Perhaps we want to do so ?
[08:56] <seb128> since totem-gstreamer is the default player and works pretty bad, I think we should consider the update
[08:58] <mdz> seb128: yes, I think so, but let's test it a bit before uploading
[08:58] <mdz> a few different people
[08:59] <seb128> ok, I'll prepare the packages and put them somewhere
[09:01] <mdz> anyone have a printer to test #2114?
[09:01] <mdz> it stinks of NOTWARTY, but I have no printer at the moment
[09:11] <lamont> mdz: been printing things for a while, not sure where gs-esp fits into the sequence, though...
[09:11] <lamont> mdz: btw, when you get bored, 2022 has an attached patch now.
[09:11] <mdz> lamont: print a postscript file (e.g., from mozilla)
[09:12] <mdz> lamont: don't you need to clean up that diversion it used to create?
[09:13] <mdz> (ewww on that, by the way)
[09:13] <lamont> mdz: well, um, probably.
[09:13] <lamont> I could just unconditionally remove it in postinst, with errors redirected... or is that uglier?
[09:16] <lamont> mdz: wrt those ppds...  which package are you thinking should change? gimp-print? or cupsys?
[09:30] <mdz> lamont: foomatic-filters-ppds
[09:30] <mdz> the one with all the ppd files in it
[09:30] <carlos> seb128: seems like latest gstreamer release improves video playback, will it enter into warty?
[09:31] <mdz> carlos: scroll up a bit; we already discussed it :-)
[09:31] <seb128> carlos: read what I said 20 lines up
[09:31] <carlos> :-P
[09:31] <carlos> sorry
[09:31] <seb128> np :)
[09:32] <seb128> one more voluntary to test the new packages I guess ? :)
[09:32] <carlos> seb128: send me the URL of the packages and I will test them
[09:32] <carlos> yes
[09:32] <lamont> mdz: updated the bug
[09:32] <pitti> mdz: I will try it; i already produced some postscript printouts which look good
[09:32] <carlos> mdz, jdub: I forgot to ask about gstreamer-ffmpeg plugin inclusion into universe, is that possible?, I suppose that it cannot be in main because patent problems, right?
[09:33] <seb128> carlos: ok, they are not ready yet but I'll
[09:33] <pitti> seb128: if I ever find a video which totem-gstreamer is actually able to play, I would test this as well
[09:33] <seb128> pitti: ok :)
[09:33] <seb128> -ffmpeg would help a lot ..
[09:33] <pitti> seb128: oh, ffmpeg plugin sounds like MPEG4 and stuff?
[09:33] <seb128> yes
[09:33] <pitti> seb128: so xvid, divx? 
[09:33] <pitti> great
[09:33] <seb128> yes
[09:35] <carlos> pitti: but it's not in warty or Debian
[09:35] <mdz> pitti: thanks, please NOTWARTY it if appropriate
[09:35] <carlos> only external sources
[09:35] <pitti> mdz: I can only try some BTS pages, the bug does not give other examples
[09:36] <mdz> pitti, thom: a friend of mine just pointed out that the firefox crash only seems to happen with multiple tabs open
[09:37] <mdz> pitti, thom: I had been testing with a single tab, but when I opened more than one, I got it to crash on the first try
[09:37] <pitti> mdz: that could be it, I will try
[09:37] <pitti> mdz: that would be a more sane explanation than the square root of daytime etc.
[09:37] <thom> i can get it with a single tab, tho
[09:40] <pitti> thom, mdz: single tab crashes for me, too
[09:40] <pitti> thom, mdz: maybe "if you ever had a second tab.." and so on?
[09:41] <pitti> mdz: printing BTS pages works perfectly on my Samsung ML-1410 laser
[09:41] <pitti> mdz: but before closing the bug, maybe some more people should test?
[09:42] <mdz> pitti: if gs-esp works with the default setup, fonts, etc. it is at least not RC
[09:42] <pitti> mdz: could be a specific driver problem then
[09:43] <pitti> mdz: I downgrade, comment and leave it open for now, then (plus NEEDINFO or so)
[09:43] <mdz> pitti: I suppose it's possible
[09:43] <lamont> mdz: fwiw, gimp-print Suggests: cupsys-driver-gimpprint, which Depends: cupsys-driver-gimpprint-data, which appears to provide the driver for the S200.
[09:44] <lamont> OTOH, those last two binaries are in universe.
[09:44] <mdz> I don't know much about gimpprint
[09:44] <mdz> but cupsys uses the ppds in foomatic-filters-ppd directly
[09:45] <mdz> if it can use the gimpprint ones, too (and they don't conflict), we could look at that
[09:45] <lamont> or rather, foomatic-filters-ppd (and cupsys, and cupsys-driver-gimpprint-data, and ...) all deliver files into /usr/share/cups/model, where cups can find them...
[09:45] <mdz> but I think it's best to have all of the ppds in one place
[09:46] <lamont> cupsys, hp-ppd, foomatic-filters-ppds, gs-esp, cups-pdf, cupsys-driver-gimpprint-data all deliver there.
[09:46] <lamont> (== too late for that.)
[09:47] <mdz> hmm, I can't get firefox to crash again
[09:47] <mdz> even with multiple tabs
[09:47] <pitti> mdz: as we guessed: a heisenbug
[09:49] <mdz> pitti: the procedure my friend just posted to the bug works for me
[09:49] <pitti> mdz: luckily it still crashes in a debugging version (which is a 100 MB deb :-) )
[09:49] <pitti> mdz: it's annoying, but I'm not sure whether to raise it to RC
[09:50] <mdz> pitti: try the procedure in the most recent comment
[09:51] <pitti> mdz: phone, will try later
[09:52] <lamont> mdz: cupsys-driver-gimpprint comes from gimp-print source, which makes me believe that they added all of the support when they added the part that the submitter says is there...
[09:54] <lamont> mdz: and reading the internal documentation in gimp-print makes me believe that even more.
[09:54] <mdz> lamont: so you're saying that we need gimp-print in the default install just to have a complete set of drivers?
[09:55] <lamont> well, I think we need to move cupsys-driver-gimpprint to at least supported.seed
[09:56] <lamont> and if we're installing cupsys and gimp-print in desktop, then we should also install that suggested package...
[09:56] <lamont> s/suggested/(suggested)
[09:57] <lamont> moving it would just leave escputil in universe (epson stylus printer clean/alignment util)
[09:58] <lamont> 2.7MB of .debs
[10:05] <mdz> we're installing cupsys
[10:05] <seb128_> mdz: ok to sync gdk-pixbuf from debian ?
[10:05] <mdz> I don't think we're installing gimp-print
[10:06] <mdz> seb128_: I think so; double-check the changelog
[10:06] <seb128_> mdz: I've double checked, the only change between warty and debian (out of the security patch which is different) is "Link gnomecanvaspixbuf.so.1.0.0 against gdk_pixbuf.la"
[10:07] <seb128_> ok, I'm fixing gdk-pixbuf now :)
[10:52] <npmccallum> mdz: what was the result of your testing madwifi?
[10:53] <npmccallum> mdz: its still not working at all with the latest kernels for me
[10:56] <npmccallum> pitti: ping
[10:56] <pitti> npmccallum: pong
[10:57] <npmccallum> pitti: did you get my email?
[10:58] <pitti> npmccallum: no personal one
[10:58] <pitti> npmccallum: somewhere on the list?
[11:05] <pitti> npmccallum: anyway, I'm going to sleep now. If you sent a mail to @debian.org, please use the direct way with martin@piware.de. @debian.org email sometimes lags for as much as 4 weeks (see lengthy thread on d-devel)
[11:06] <pitti> good night everybody!
[11:11] <nasdaq4088> bye pitti
[11:26] <mdz> npmccallum: it works fine for me
[11:26] <mdz> npmccallum: WEP and all
[11:36] <thom> mdz: so what do you think about sudo's prompts. leave till hoary?
[11:36] <npmccallum> mdz: It was working perfect for me as well, however, since a recent kernel upgrade I can't get dhcp at all
[11:37] <mdz> npmccallum: works for me with what I believe is 2.6.8.1-11
[11:37] <mdz> I've upgraded since the last time I rebooted, so it's using the new module at least
[11:47] <Kamion> fabbione: fontconfig's dependencies look a bit barmy
[11:47] <Kamion> Package: fontconfig
[11:47] <Kamion> Depends: libc6 (>= 2.3.2.ds1-4), libfontconfig1 (>= 2.2.1), debconf (>= 0.5) | debconf-2.0, defoma (>= 0.7.0), ucf (>= 0.29), ttf-bitstream-vera | ttf-freefont | gsfonts-x11 | msttcorefonts | laptop-detect
[11:47] <Kamion> what's that | doing before laptop-detect?
[11:56] <sivang> ah! at last I fixed that dpkg problems.
[11:56] <sivang> hope my system doesn't break again..