[12:08] <tseng> jeez
[12:08] <ogra> lol
[12:09] <lifeless> erm, whos ops here that can HURT 
[12:09] <lifeless> SOMEONE
[12:09] <lifeless> BADLY
[12:09] <tseng> i asked lilo
[12:09] <tseng> dunno if he is awake
[12:11] <T-Bone> wouldn't it be just fine to ban *!*@pound.ifndef.com ?
[12:11] <T-Bone> (locally ban, here on #ubuntu-devel, for a starter)
[12:12] <tseng> yes, but no one is seeming to jump on that
[12:12] <tseng> i guess he slowed down
[12:12] <ogra> i think the guy is known here, i've seen it happen before
[12:13] <tseng> hooray
[12:13] <Geert> :)
[12:16] <Kamion> I've never seen KeyserSoze actually talking here
[12:16] <ogra> me neither, but he is always here....(probably a logbot...)
[12:17] <srbaker> so upgrading to hoary from warty is as simple as s/warty/hoary/ in sources.list and doing dist-upgrade, right?
[12:18] <srbaker> anything i should know besides that?
[12:18] <srbaker> oh well.  what the hell
[12:18] <thom> ber, too slow
[12:20] <ogra> mdz ?
[12:20] <seb128> elmo: around ?
[12:20] <elmo> seb128: unfortunately
[12:20] <seb128> elmo: what's broken with openh323 exactly ?
[12:21] <mdz> ogra: ?
[12:22] <mdz> Kamion: do you have some time to go over some casper stuff?
[12:22] <elmo> seb128: the soname (and thus pkgname) of pwlib changed?
[12:23] <wasabi_> jbailey: had any time to check out the eclipse packages yet?
[12:23] <wasabi_> oops
[12:23] <elmo> The following packages have unmet dependencies:
[12:23] <elmo>   libopenh323-1.13.2: Depends: libpt-1.6.3 but it is not installable
[12:24] <elmo> the two libs are quite tightly synced; I dunno if it requires a newer version or just a rebuild
[12:24] <seb128> elmo: correct, please sync openh323 it's also needed for gnomemeeting
[12:24] <seb128> from experimental
[12:24] <seb128> and nothing out of gnomemeeting uses it in main
[12:25] <Kamion> mdz: I have maybe fifteen minutes now
[12:26] <mdz> Kamion: ok, first thing is making netcfg more suitable for the live CD environment
[12:26] <mdz> Kamion: i.e., being entirely non-interactive
[12:26] <elmo> seb128: ok, done
[12:26] <seb128> thanks
[12:26] <mdz> Kamion: I'm happy for it to try to bring up an interface automagically if it can, but if not, it should just fall back to doing nothing
[12:28] <Kamion> mdz: if DHCP sends back a hostname, do you want to use it?
[12:28] <Kamion> if so, that will probably require a minor netcfg change to make that preseedable
[12:29] <sivang> mdz: Do we want to change the entry over there to bendy? ==> http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule , notice the 26th March.
[12:30] <ogra> sivang
[12:30] <Kamion> let's not set "bendy" in too much stone :P
[12:31] <mdz> Kamion: yes
[12:32] <mdz> Kamion: but if that's not easy, I'm fine with using a static hostname instead
[12:32] <mdz> Kamion: the important thing is to suppress the interactivity
[12:33] <Kamion> ok, do you have the logs from when I gave you questions to preseed to achieve that?
[12:33] <sivang> Kamion: woops, noted.
[12:33] <mdz> Kamion: you gave me preseed magic to suppress the hostname prompt
[12:33] <mdz> but that's not the bit I'm worried about
[12:33] <mdz> mostly the actual interface config
[12:34] <mdz> the hostname prompt is actually very convenient, because it pauses the process at just the right time for me to netcat over a new casper and test it out :-)
[12:34] <Kamion> oh, you mean the "pick an interface" bit? ok
[12:34] <mdz> yeah
[12:34] <mdz> ideal would be to try each interface in turn to see if one can be configured automatically
[12:34] <mdz> but I guess I'd be happy with tryng the first one and giving up, if that's significantly easier
[12:35] <Kamion> netcfg selects the first one that has a link beat as the default
[12:35] <Kamion> the trick will be to get it to just pick the default, without asking the question
[12:35] <lamont> daniels: you around?
[12:35] <Kamion> mdz: try 'db_fset netcfg/choose_interface seen true'
[12:36] <mdz> ok
[12:36] <sladen> mjg59: I'm in Cambridge tomorrow.  You around?
[12:36] <mdz> Kamion: then there's the isolinux text, which should either be made generic, or different text used for the live CD
[12:37] <Kamion> mdz: I think that will die if a default doesn't get set for whatever reason, though
[12:37] <Kamion> mdz: I thought I'd already done that
[12:37] <mdz> The default installation is suitable for most desktop or laptop systems.
[12:37] <mdz> To install only the base system, type 'server'.
[12:37] <Kamion>   * Add syslinux.txt.live with slightly different text for the live CD.
[12:37] <mdz> that's what it currently says
[12:37] <Kamion> (debian-installer_20041227ubuntu5 changelog)
[12:37] <mdz> hm, didn't see that change go in
[12:37] <mdz> was that after the most recent live CD build?
[12:37] <Kamion> maybe I forgot to make the corresponding debian-cd change
[12:37] <Kamion> no, well before
[12:37] <mdz> I just pasted that from hoary-live-i386.iso
[12:38] <mjg59> sladen: Leaving at about 9AM
[12:38] <mdz> Kamion: and the final thing is the templates which say "installer"
[12:38] <mdz> (language used "for the installation process", etc.)
[12:39] <Kamion> those will have to be made generic, I think
[12:39] <Kamion> it's likely to be too much work to allow them to be variable
[12:39] <mdz> once those three things are taken care of, I think we'd be ready to do a wider live CD milestone release
[12:39] <mdz> I agree
[12:41] <Kamion> sigh, syslinux.txt.live didn't make it into debian-cd_info.tar.gz; fixing
[12:42] <mdz> Kamion: if dhcp fails on an interface with linkbeat, doesn't netcfg fall back to static configuration prompts?
[12:42] <mdz> if so, the live CD wants to suppress that as well
[12:43] <Kamion> I'm sure I gave you directions for that
[12:43] <Kamion> as well as the hostname thing
[12:43] <mdz> Jan 06 09:40:12 <Kamion>        perhaps: db_fset netcfg/dhcp_options seen true;
[12:43] <mdz> db_set netcfg/get_hostname some-default-hostname; db_fset netcfg/get_hostname seen true
[12:43] <mdz> that's what you gave me before
[12:44] <Kamion> there was another occasion
[12:44] <mdz> and then we decided that get_hostname wasn't necessary
[12:44] <mdz> oh?
[12:44] <Kamion> let me try to figure it out from scratch again
[12:45] <mdz> that's the only other db_fset I found in my log from you
[12:45] <Kamion> hm, yes in fact the above should be it
[12:45] <Kamion> db_fset netcfg/dhcp_options seen true
[12:45] <Kamion> oh, no
[12:46] <Kamion> you will also need db_set netcfg/dhcp_options 'Do not configure the network at this time'
[12:46] <sladen> mjg59: gah, damnit
[12:46] <Kamion> (and hope that that works in non-English locales ... not sure about that)
[12:46] <mdz> ah, I didn't realize that template was dhcp_options
[12:46] <Kamion> dhcp_options only gets asked if DHCP fails
[12:46] <mdz> my understanding is that choices aren't translated in the db
[12:46] <Kamion> they are
[12:46] <mdz> so I assume that works
[12:46] <Kamion> sometimes
[12:46] <mdz> oh
[12:47] <Kamion> in particular that one is
[12:47] <mdz> the Value: is translated? how weird
[12:47] <Kamion> oh, well it is in the templates db anyway; whether it is in the questions db I'm not entirely sure, but there's code in other parts of d-i to cope with that
[12:47] <Kamion> it's all very dodgy
[12:47] <mdz> I mean, the choices are translated for display, but I thought the english version was actually stored as the value
[12:47] <Kamion> this is one of the bits of debconf I don't fully understand
[12:47] <mdz> so I'll take a stab at the netcfg stuff tonight
[12:48] <mdz> regarding the d-i templates, are you OK with me going through and mangling them?
[12:48] <Kamion> yeah, that's fine, make sure to run debconf-updatepo after doing so
[12:49] <mdz> ok, I'll try to do that tonight too, if I get around to it
[12:49] <gt500> hey peepz , is there a gui for the ati fglrx-control , or do i have to type fglrxconfig ?
[12:49] <gt500> woopz
[12:49] <mdz> and the syslinux thing should happen with the  next live CD build?
[12:49] <gt500> wrong channel
[12:49] <gt500> :p
[12:51] <Kamion> mdz: I'm just this moment uploading debian-installer to fix that, so whenever elmo does the byhand + next live CD build
[12:51] <mdz> ok, great, thanks
[12:51] <Kamion> with regard to the hostname prompt, have you considered just using expert mode?
[12:52] <mdz> yeah, I suppose I should do that instead
[12:52] <mdz> it's just terribly convenient as-is :-)
[12:52] <Kamion> while I appreciate the value of having pauses at convenient times and all :)
[12:52] <mdz> expert mode involves lots of keypresses, right?
[12:52] <mdz> I thought about adding a casper/debug template which it would check, and pause if it were set
[12:53] <Kamion> expert mode isn't all that bad
[12:53] <mdz> though typing in casper/debug=true is lots of keypresses too
[12:53] <mdz> and qwerty ones
[12:53] <Kamion> it's maybe half a dozen more presses of Enter
[12:53] <elmo> christ, the upload server gets warez tested _every_ day
[12:53] <Kamion> warez tested?
[12:54] <Kamion> mdz: you could also go back to the main menu and change debconf priority
[12:54] <mdz> Kamion: should I preseed in casper-check, then?
[12:54] <Kamion> mdz: yeah, I think that's easiest
[12:54] <mdz> MKDIR .dpwh
[12:54] <Kamion> the alternative's for casper-check to ship an actual preseed file
[12:54] <elmo> Kamion: a file from an automated scanner thing uploads this same (empty) 1mb test file
[12:54] <Kamion> I'm not sure there's a big win either way
[12:54] <mdz> which would be a problem for casper/enable=false, I assume
[12:55] <Kamion> mdz: no, it would be set by the same bootloader options that set casper/enable=true
[12:55] <mdz> hm
[12:55] <Kamion> if you have lots of things to set then a preseed file might be a bit more convenient, but until then I wouldn't worry about it
[12:56] <mdz> I suppose I need to do the db_register trick in order to get the values into the db?
[12:56] <Kamion> and you have slightly more flexibility outside preseed; for example you can mark a template seen without having to set a default value, if you know that the code in question tolerates that
[12:56] <Kamion> mdz: yeah
[12:57] <mdz> ok, I think that should give me enough to go on for the next day or so
[12:57] <mdz> thanks
[12:58] <Kamion> mdz: anything still pending from the stuff in scrollback over the weekend? I basically had to discard a lot of that, there was too much
[01:10] <Kamion> night all
[01:10] <ogra> night Kamion
[01:10] <sivang> night Kamion 
[01:30] <jdub> GOOD MORNING FREEDOM LOVERS!
[01:31] <ajmitch> hello jdub 
[01:32] <tseng> hey jdub, see my message?
[01:33] <mjg59> GOOD MORNING MR JDUB
[01:33] <jdub> tseng: tomboy/blam/libgecko-cil
[01:33] <tseng> jdub: yessir :)
[01:34] <jdub> tseng: send source packages this way when you're happy with them
[01:34] <sivang> jdub: waiting for your pantelonas greeting :)
[01:34] <tseng> jdub: email or what
[01:35] <jdub> tseng: somewhere i can snarf them via http would be easiest
[01:35] <tseng> sure thing
[01:35] <tseng> i can do blam right quick
[01:43] <pitti> night everybody!
[01:43] <tseng> jdub: hows http://getsweaaa.com/~tseng/blam/
[01:44] <elmo> mdz: d-i daily build is in the archive
[01:44] <mdz> thanks
[01:44] <elmo> [actually it was there, like 20 mins ago, but auckland took a while to catch up :/] 
[01:58] <daniels> lamont: sup
[01:58] <jdub> tseng: /blam/blam.exe
[01:58] <jdub> tseng: wtf? ;)
[01:59] <tseng> grr how do i keep doing that?
[02:00] <jdub> tseng: should build depend on intltool without libxml-parser-perl
[02:02] <tseng> -libxml-parser-perl, +intltool
[02:02] <jdub> yeah
[02:03] <tseng> there a min version for that?
[02:04] <jdub> hmm, shouldn't matter
[02:08] <tseng> the MonoConventions page is broken on alioth atm
[02:08] <tseng> there is a bit on locations for foo.exe
[02:09] <tseng> jdub: refresh the dir for build-dep update
[02:14] <jdub> tseng: add planet ubuntu, too :)
[02:16] <tseng> heh
[02:17] <tseng> ah easy++
[02:22] <tseng> testing that patch quick.
[02:22] <robertj> have any decisions been made about Mono for Grumpy?
[02:23] <jdub> $ sudo -i
[02:23] <jdub> sudo: cannot get working directory
[02:23] <jdub> ^ uh oh
[02:24] <jdub> robertj: fairly likely we
[02:24] <jdub> robertj: fairly likely we'll include it if beagle is ready
[02:24] <tseng> jdub: -4 uploaded, same bat channel
[02:24] <tseng> with sweet Planet Ubuntu love
[02:24] <ajmitch> jdub: included in main?
[02:25] <jdub> ajmitch: fairly likely, yes
[02:25] <ajmitch> aha
[02:26] <robertj> those beagle flash videos were impressive
[02:26] <robertj> did you see em?
[02:26] <ajmitch> they looked rather neat
[02:26] <jdub> yeah
[02:27] <tseng> yeah, Nat is a fun character
[02:27] <tseng> they should make him in plush
[02:27] <jdub> tseng: so this is based on another package elsewhere?
[02:27] <robertj> are the req'd kernel extensions aok'd by upstream?
[02:27] <tseng> jdub: 1.6.0 source in hoary
[02:27] <tseng> jdub: it never built it seems
[02:27] <jdub> tseng: ah, ok
[02:28] <jdub> tseng: so you need to change the version to "1.6.0-1ubuntu1"
[02:28] <jdub> tseng: that'd be your first modified revision
[02:28] <tseng> ah right
[02:28] <jdub> then you'd ++ to 1.6.0-1ubuntu2
[02:28] <tseng> how can i specify the suffix?
[02:29] <tseng> or prefix as it were
[02:29] <jdub> same way, in debian/changelog
[02:29] <jdub> because your packages haven't been uploaded, you can coalesce your changes into a 1ubuntu1 releaser
[02:29] <tseng> yep
[02:29] <sivang> jdub: dch does that usually fine most of the time..
[02:29] <sivang> jdub: (from my few experiments)
[02:29] <jdub> yes, it does
[02:31] <elmo> uh, anyone got a default warty install handy?  or at least, an unmodified sources.list?
[02:31] <elmo> if so, what hostname does it point at?
[02:31] <daniels> elmo: hold on a sec
[02:31] <jdub> archive.ubuntu.com
[02:32] <elmo> boggle
[02:32] <elmo> does anyone here not see archive.ubuntu.com resolve to a round-robin?
[02:33] <daniels> yeah, a.u.c/s.u.c
[02:33] <jdub> jdub@lazarus:~$ host archive.ubuntu.com | wc -l
[02:33] <jdub> 2
[02:33] <tseng> jdub: refresh if you would please
[02:33] <daniels> elmo: resolves to auckland+mirnyy here
[02:33] <elmo> so why has auckland done like 8x the traffic of mirnyy in the last couple of hours
[02:33] <bob2> same here
[02:35] <jdub> tseng: it is golden.
[02:35] <tseng> great
[02:35] <tseng> glad I could help.
[02:37] <jdub> tseng: if you pitch for MOTU, i will second you :)
[02:37] <tseng> hmm alright ill reread that page
[02:39] <mdz> elmo: is 90% of it from one host or something?
[02:39] <ajmitch> am I only allowed to complain to the MOTU's about universe bugs (providing fixes, of course)? :)
[02:40] <elmo> mdz: I'm talking, 90 GB, vs. about 10Gb
[02:40] <mdz> ajmitch: if you provide fixes, you can complain to anyone you like ;-)
[02:41] <mdz> elmo: shrug, it's round-robin everywhere I look
[02:42] <elmo> and it's http too
[02:42] <robertj> is there a troubleshooting guide for hibernation and the like?
[02:42] <elmo> I might just disable the auckland.warthogs.hbd.com name in case everyone in the world is using it or something
[02:42] <ajmitch> mdz: great, there's still 155 packages in universe that won't install with python 2.4 :)
[02:43] <ajmitch> elmo: who chose auckland, it makes me think it's a local (nz) mirror :)
[02:44] <mdz> elmo: speaking of warthogs.hbd.com, is there a non-warthogs equivalent for admins?
[02:44] <jdub> yikes, rsync is working nicely for the livecd
[02:44] <elmo> ajmitch: sabdfl
[02:44] <elmo> mdz: er, kind of, it's not fully functional yet - why?
[02:44] <elmo> hmm, ftp.*.$TLD weren't RR.. done them too
[02:45] <elmo> btw, hoary/main/i386(+all) is 2 and a bit Gb

[02:46] <mdz> elmo: phasing w.h.c out of my mutt config
[02:47] <jdub> mdz:    550086656 100%    1.87MB/s    0:04:40  (1, 100.0% of 1)
[02:47] <mdz> yep
[02:47] <jdub> tasty ;)
[02:51] <mdz> jdub: I wonder if better rsync efficiency translates to more or less I/O thrashing on the server side
[02:52] <jdub> tseng: and, um, distro name is hoary not unstable (sorry, should've noticed that)
[02:52] <tseng> gr
[02:52] <jdub> just respinning now
[02:52] <tseng> ah ok, i was going to fix
[02:52] <tseng> nps then.
[02:56] <jdub> tseng: upload accepted ;)
[02:57] <tseng> jdub: good show, i need to hit all the docs again before applying
[02:57] <tseng> i still dont feel like im up to snuff
[02:57] <sladen> robertj: it's called ''/query mjg59''
[02:58] <bob2> robertj: or wiki.ubuntu.com/PMTesting
[02:58] <ajmitch> hm, there doesn't seem to be anything on the wiki about the need to rebuild packages for python2.4
[02:59] <elmo> does anyone know how to do wildcard domains in postfix's config file?
[02:59] <jdub> tseng: always happy to answer questions, etc.
[03:00] <jdub> elmo: as in, accept mail for wildcard domains?
[03:00] <tseng> jdub: appreciate it
[03:00] <elmo> jdub: I want to relay for *.$tld (sic)
[03:00] <jdub> should just be .$tld
[03:00] <elmo> yeah, doesn't work
[03:01] <jdub> serious hooray for sftp://
[03:02] <jdub> elmo: erm, been a while since i've been knee deep; perhaps a regexp hash or something? (should be simpler than that)
[03:03] <elmo> jdub: I'll have  a look at that.. but this is for lamont anyway, I guess it can wait till he comes back
[03:03] <jdub> ok
[03:04] <jdub> hrm, skills atrophy :|
[03:05] <sladen> elmo: have you tried something along the lines of  virtual_maps = regexp:file  
[03:06] <elmo> sladen: unfortunately this is the relay host for ubuntu.com, canonical.com etc. so I don't want to mess around, and I'm too tired/lazy to setup the same thing on another box
[03:06] <ajmitch> ah, this python rebuild is going to take a long time
[03:07] <elmo> apache's server status page is like a lava lamp... would make a cool xscreensaver hack
[03:08] <sladen> elmo: this is for  xyz@foo.ub.com,  xyz@bar.ub.com  all going -> xyz@canonical_domain.com  (pardon the pun)
[03:10] <elmo> sladen: no, I want to relay *@*.sometld to another host
[03:10] <elmo> if I use foo.sometld in relay_domains, it works
[03:10] <elmo> if I use .sometld, and try to mail bar@foo.sometld, it doesn't
[03:15] <mdz> W: GPG error: http://archive.ubuntu.com hoary Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[03:16] <mdz> elmo: ^^ ?
[03:16] <ajmitch> crap, pdebuild doesn't want to work, it won't auth packages
[03:20] <wasabi> There a pbuilder-xen yet?
[03:20] <wasabi> =)
[03:20] <mdz> elmo: hmm, a second update just now got a valid one. did you do anything?
[03:21] <mdz> elmo: or is there a temporary desynchronization when it mirrors?
[03:21] <elmo> no
[03:21] <elmo> no there isn't.. until we start RR-ing with one crap server and one good one
[03:21] <sladen> elmo: I've not used it with relay_domains;  Touching-Wood, I'd guess just   /^(.+)@\([^.] +)\.example.com/ foobar    and a regexp: path to that file But break/test it on another machine first
[03:21] <mdz> elmo: I mean desynchronization between Release and Release.gpg
[03:21] <elmo> I guess there's no guarantee apt will get the Packages, Releases and Releases.gpg from same IP, is there?
[03:21] <mdz> no, there isn't
[03:22] <elmo> mdz: there's a _very_ small race there, but I doubt it's an issue .. I suspect it's more the RR
[03:22] <elmo> well bugger
[03:22] <elmo> sladen: yeah, thanks
[03:23] <elmo> mdz: could we not fix apt?  this is going to completely kill Debian
[03:24] <elmo> it's halfway solvable for us, on our LAN, but it'll kill us too if we ever want to RR a non-local mirror (e.g. archive.us.ubuntu.com)
[03:24] <mdz> I don't think we can, if you consider proxies and stuff
[03:25] <elmo> gag
[03:25] <mdz> unless we do something crazy like keep old Packages, Release and Release.gpg around under different names
[03:25] <mdz> I guess we could have it retry if the sig check fails
[03:26] <mdz> treat it like a transient failure
[03:26] <mdz> but that sucks when you get down to Packages files
[03:26] <elmo> yeah, but that's still a random chance whether or not you get a good IP
[03:26] <sladen> do something like --clearsign in as a comment/line: so that it's backward compatible?
[03:26] <elmo> this totally hoses round-robins; the only way I can see to do them is to have them signal back when they're ready or something insane like that
[03:26] <mdz> hey, I know, we could just sign packages!
[03:27] <elmo> tho, we could sign _Packages_
[03:27] <mdz> yeah, you'd have to sync over all the index stuff separately, and rename it all at once, or something
[03:27] <elmo> but, err, no that still has the same problem, meh
[03:28] <mdz> signing Packages would work if we signed it inline, rather than detached
[03:28] <elmo> mdz: all sane Debian mirrors sync the indices seperately anyway
[03:28] <elmo> yeah, that's true
[03:28] <sladen> instead of .gpg being a detached sig;  you could have .gpg just have an inline signature
[03:28] <mdz> elmo: all at once across all mirrors ;-)
[03:28] <elmo> mdz: not all mirrors, just all mirrors in the RR
[03:28] <elmo> no one sane has more than 6 or so in a RR at once anyway
[03:29] <mdz> sladen: there would still be multiple files that need to be in sync
[03:29] <mdz> sladen: Release is signed, contains md5sums for Packages.gz, etc.
[03:29] <mdz> elmo: if all of them in the RR sync the indexes in a second run, that should make the race pretty small
[03:30] <elmo> actually, even with the "signal, and then move" thing, you'd get screwed by write-starved machines like auckland, but I suppose you just lose if you hae auckland
[03:30] <elmo> mdz: dude, there's like a 10 min gap between mirnyy finishing and auckland finishing
[03:30] <elmo> or, between newsamosa (Gb LAN) and saens (half way across the US)
[03:30] <elmo> it's much more than 10 min
[03:30] <mdz> i guess 10 min/day for Debian is not so bad, but 10 min per 30-minute day or whatever we have is pretty crap
[03:31] <elmo> argh, this is so bad
[03:32] <mdz> it really shouldn't happen all that often, considering that apt uses http keepalives
[03:32] <mdz> I don't even know how it happened this time
[03:32] <elmo> mdz: does anything ignore keepalive requests?
[03:32] <mdz> stuff that doesn't speak HTTP/1.1
[03:32] <sladen> if they constantly keep a connection open to rsynd, the updates should get pushed in the order they are performed.  Packages/etc files are then just a checkpoint
[03:33] <mdz> I've got it going through squid here
[03:33] <mdz> which I'm fairly certain does keepalives
[03:34] <elmo> well, let's leave ours in a RR for a day or two and see how many complaints we get
[03:34] <bob2> lifeless: ^^
[03:35] <mdz> I remember this came up in debian before
[03:37] <aj> dadadadum
[03:37] <elmo> aj has a cunning plan
[03:38] <jdub> aj: congrats :-)
[03:39] <aj> the idea is make cron.daily to   jenna; rsync; apt-ftparchive   and expect it to run 2-4 times per day
[03:39] <elmo> that's mostly on a Debian timescale, but the 30 mins cron.daily thing isn't sustainable with triggered mirrors anyways
[03:39] <elmo> so it could scale to Ubuntu timescales too
[03:40] <mdz> what does jenna do?
[03:40] <elmo> mdz: updates suites, so that 1.10-2 replaces 1.10-1
[03:40] <aj> err, >=2-4 times per day, whatever
[03:40] <elmo> basically, you'd sync the files in pool first, and then later (like an hour or so or whatever) actually change the Packages files
[03:40] <mdz> so 1) move debs around in the archive, 2) push debs out, 3) update the indexes, 4) push the indexes
[03:40] <aj> jenna's standing in for "install debs into the pool, etcetc"
[03:41] <aj> no
[03:41] <mdz> no?
[03:42] <aj> move debs in the archive; push debs packages out (referring to old debs); push pool out (doesn't matter how long this takes, since no one will reference any of the changes anyway yet); when that's done, run apt-ftparchive to update indexes for next run later
[03:42] <elmo> it's kind of like taking the "rsync everything except indices, then rsync indices" on the client and turning it into "install stuff into the pool, rsync, wait.. generate indices files... repeat cycle" on master
[03:42] <mdz> ok, so that's what I said, only omitting 4)
[03:42] <mdz> and leaving it for the next rsync instead
[03:42] <aj> it's like what you said, but it goes (1) (4) (2) (3)
[03:42] <mdz> how does that address the indexes being out of sync with each other?
[03:43] <aj> we currently do (1) (3) (2) (4)
[03:43] <elmo> mdz: if they only have to sync the indices, the mirror is hugely shorter
[03:43] <mdz> but they already sync the indexes separately
[03:43] <elmo> err, window for the race, I mean
[03:43] <aj> step (4) is very quick, so there's no time to get out of sync on the indices
[03:44] <mdz> I'm not clear on how changing the order helps with this particular problem
[03:45] <mdz> it helps with master<->mirror syncage, but not mirror<->mirror
[03:45] <elmo> mirror <-> mirror gets out of sync because the time-to-mirror is variable
[03:45] <mdz> or have I misunderstood?
[03:45] <elmo> if you're only mirroring changed Packages files, the time-to-mirror is much smaller, and -> the variation is much smaller
[03:45] <mdz> right, but as you said earlier, sane mirrors already do the indexes in a separate pass, no?
[03:46] <elmo> mdz: directly _after_ they just did the big pool/ update
[03:46] <elmo> so the variation is still there
[03:46] <elmo> mirnyy does it's seperate indices pass 10 mins before auckland even starts his
[03:46] <aj> and they have to do it after the pool/ update, coz unstable Packages will refer to packages that weren't in the pool last time they synced
[03:47] <mdz> ohh, I see
[03:47] <mdz> you're turning it around client/server wise
[03:47] <aj> the bit after "coz" in the above changes if apt-ftparchive is only run after rsync
[03:47] <infinity> daniels : Stop that.
[03:47] <mdz> I didn't realize it worked that way
[03:47] <usual> how new is the ubuntu update manager?
[03:47] <mdz> so currently, the individual mirrors do 1) pool, 2) indexes, but they do it according to their own schedule
[03:47] <usual> never noticed it before
[03:47] <elmo> mdz: no, they do it when we trigger them
[03:48] <aj> well, they do it when we tell them to
[03:48] <elmo> mdz: if they're triggers, otherwise yes
[03:48] <mdz> ...
[03:48] <mdz> I must be thick
[03:48] <aj> but it could be anytime they like
[03:48] <elmo> mdz: ?
[03:48] <mdz> I think I'm lacking context about how this stuff actually works currently
[03:49] <mdz> I thought that the pushes went out in two passes, 1) pool to all mirrors, 2) indexes to all mirrors
[03:49] <mdz> but what I think you're saying is that it's currently pool-to-mirror-1, indexes-to-mirror-1, pool-to-mirror-2, indexes-to-mirror-2
[03:49] <elmo> no, what happens atm is:
[03:49] <aj> no, it's {pool, then index} to all mirrors simultaneously
[03:49] <elmo> right ^- that
[03:49] <mdz> ok, gotcha
[03:50] <elmo> we just "signal" them
[03:50] <mdz> and we give only one signal which lets them do both passes at their own pace
[03:50] <mdz> can we not signal them separately for pool and indexes?
[03:51] <mdz> or do we not have a way to tell when they're finished?
[03:51] <elmo> we don't have a way to tell when they're finished
[03:51] <aj> right, whoops
[03:51] <elmo> we could get one..
[03:51] <aj> it has to be "apt-ftparchive; install into archive; push {dists/, pool/}" not what i said
[03:51] <aj> my bad
[03:51] <elmo> we'll have to get one for either scheme
[03:52] <mdz> yeah
[03:52] <aj> we will?
[03:52] <aj> the above should work without that
[03:52] <mdz> only if you can safely assume that they're done by the time the next cycle rolls around
[03:52] <mdz> which works for long cycles, but not short
[03:52] <aj> err
[03:52] <elmo> well, as I said, I don't think many mirrors will be happy to be triggered every 30 mins
[03:53] <aj> well, if you have mirrors that don't finish in between cycles you're screwed
[03:53] <aj> i guess delaying the cycle would be okay
[03:53] <aj> you could do a snapshot.ubuntu so you create a new dists/ every 10 minutes, so places can keep downloading the old dists for 20 minutes i guess
[03:54] <mdz> elmo: as long as all of the mirrors in a particularl RR are on the same cycle
[03:54] <elmo> mdz: yeah
[03:54] <mdz> archive.u.c and archive-less-up-to-date-but-faster.u.c
[03:55] <elmo> I'm not sure what to do about the 30mins thing - if we keep it for archive.u.c, but not for mirrors, the hoary/crack-of-they-day folks aren't going to use mirrors
[03:55] <aj> (bittorrent!)
[03:56] <mdz> people won't use mirrors anyway until they get shitty throughput
[03:57] <mdz> I would like to do the bittorrent experiment someday
[03:57] <elmo> uh.
[03:57] <elmo> are you guys  serious?
[03:57] <mdz> not bittorrent, but the model
[03:57] <elmo> ok
[03:57] <mdz> at the file level, rather than the block level, really
[03:58] <jdub> i would run a torrenty mirror here if we had that feature
[03:58] <mdz> no point in getting pieces of a .deb from a bunch of random places, but there would be value in letting peers exchange debs
[03:58] <mdz> make everyone's apt cache a mini-mirror
[03:58] <jdub> if mirrors and downloaders could share packages similarly, that'd be rad
[03:58] <mdz> the authentication stuff was a prerequisite for anything like that, which is one reason I haven't bothered with it yet
[03:59] <mdz> I guess you could end up in a shitty situation where you were downloading a huge .deb from a slow peer
[04:00] <mdz> but generating .torrents for everything is insane I think
[04:00] <elmo> totally
[04:00] <elmo> it's beating-worthy to even suggest it
[04:00] <srbaker> hehe
[04:03] <jdub> and who better to administer the beating than the sysadmin team (shit-your-self administration)
[04:04] <daniels> 'employee agrees to be fired out of a cannon'
[04:04] <aj> yeah, bittorrent itself is unusable for debian; i tried
[04:04] <stub> Torrents can contain multiple files, and clients may choose to download only some files. Would one torrent, or perhaps a handful, work?
[04:04] <mdz> it would be nice to be able to download 10 or so smaller debs from 10 peers in parallel, though
[04:04] <aj> but apt-cache/proxy + bittorrent's logic for finding peers should be doable
[04:05] <mdz> stub: I think a .torrent for the entire archive would be huge anyway
[04:05] <aj> stub: no, coz every time the archive gets updated, all the old torrent info becomes useless
[04:05] <elmo> you'd definitely need to update the algroithm somehow to take into account peer's speeds
[04:05] <aj> also Packages contain most of the information a torrent needs, so it's half redundant
[04:07] <mdz> has anyone experimented with sorting the entire Packages file in such a way as to try to maximize compression?
[04:07] <stub> If Packages was extended to contain *all* of the information a torrent needs, it could be generated on the client
[04:08] <elmo> it'd be fun actually you could build a figleted "WHATEVER" into the protocol as a message to the peer that you'd didn't want no more of his slow-as-molasses download
[04:08] <daniels> haha
[04:08] <mdz> stub: it would be gigantrous
[04:08] <daniels> i fear the protocol that you build, elmo.
[04:09] <daniels> it would include 'kthxbye', figlet, and deep personal abuse
[04:09] <elmo> are you still better about being called a GTK bug? :)
[04:09] <elmo> bitter too
[04:09] <mdz> I guess the current sort-by-binary-name probably gets 90% of any benefit that could be had by sorting
[04:09] <daniels> elmo: no, I'm happy, because verbal abuse means you're not beating me
[04:09] <mdz> that's only because you're out of reach
[04:09] <elmo> the last protocol I did was bloody awful.  in a moment of deep insanity, I chose CVS as an inspiration.  unfortunately, I am not joking
[04:10] <daniels> elmo: and you have root on all our machines, yes?
[04:11] <elmo> if I don't, we're in trouble
[04:11] <daniels> well, apparently, if you do, we're in trouble also :P
[04:11] <aj> mdz: huh? how's sorting going to improve Packages.gz's compression?
[04:11] <aj> mdz: (and you've seen tiffani right?)
[04:11] <mdz> aj: by grouping related items together
[04:11] <mdz> and no
[04:11] <aj> mdz: why would gzip care about related items being together?
[04:11] <elmo> god damn it I HATE AUCKLAND
[04:12] <mdz> aj: bz2 does
[04:12] <aj> mdz: okay, i'll blog about it tonight sometime
[04:12] <aj> mdz: ??
[04:12] <mdz> aj: getting related items into the same block should give you smaller blocks overall
[04:12] <aj> mdz: bz2's just byte&block based like gzip...
[04:13] <elmo> anyway, past 3am.. night all
[04:13] <mdz> night
[04:13] <aj> night elmo
[04:13] <daniels> elmo: night
[04:13] <mdz> now that elmo's gone, I can reveal that I think that moving descriptions out of Packages might not be completely insane
[04:13] <jdub> aj: mdz has been involved in some fairly sick rsync optimisations recently, so... forgive him for thinking too hard on this one.
[04:13] <aj> mdz: tiffani's the "apt-get update pulss diffs" thing, it's running on merkel atm and is in theory usable, but i need to check
[04:14] <daniels> mdz: i think we should have one deb per language per package, for language packs
[04:14] <mdz> daniels: troll
[04:14] <mdz> aj: oh, the thing that you and mvo and I were talking about
[04:14] <mdz> ?
[04:15] <aj> was mvo the one who posted the patch to apt? if so, yeah
[04:15] <mdz> #128818
[04:15] <aj> yeah, looks like the right number of digits :)
[04:18] <mdz> aj: what's the problem with diff -e?
[04:18] <mdz> florian weimer mentions something about it not being suitable for 'one-pass processing'
[04:18] <aj> mdz: it puts the changes in reverse order
[04:19] <aj> mdz: diff -f puts them in order, so you can read from the diff and the original file, and just use pipes to generate the output
[04:19] <mdz> aj: does your implementation use the one-patch-to-current approach, or a sequence of patches?
[04:19] <aj> sequence of patches
[04:19] <mdz> oh
[04:19] <mdz> that problem doesn't exist if you do each patch relative to current
[04:20] <aj> trivial to change if needed (the hacked up client wouldn't even need to change), but i couldn't see the point
[04:20] <mdz> and it should be smaller, too
[04:20] <mdz> and faster
[04:20] <mdz> (one HTTP request instead of N)
[04:22] <aj> yeah, but more complicated on the server, so that can be v2 afaic
[04:23] <lifeless> bob2: ?
[04:24] <aj> (it's also harder on mirrors; which might impact how far back diffs can go, though probably not; it's also harder on ftp-master.d.o)
[04:24] <aj> (doing it as day 14-8 -> day 7; day 7-1 -> today would probably work though)
[04:25] <aj> (err, 21-15 -> 14 too)
[04:45] <mako> is there a recommended usb wireless stick for folks stuck on ibooks?
[05:02] <aj> heh
[05:03] <aj> i've heard you can plug the old airport cards in instead of the new airport extr3m3, and have it work. no idea if it fries your computer or not though :)
[05:07] <sivang> anybody knows if dh_make is deprecated or something? it's not recognizable on my dev set up hoary...
[05:07] <jdub> jdub@lazarus:~$ apt-cache search openoffice.org2 | wc -l
[05:07] <jdub> 13
[05:07] <jdub> BLING!
[05:08] <aj> "openoffice.org2" ? those package names just get worse and worse
[05:08] <jdub> haha, ooo2-core is 45MB
[05:08] <jdub> aj: parallel-installable
[05:09] <sivang> nm, missed one dependency
[05:11] <mdz> jdub: do you have an opinion on whether we should put it in main now (and possibly remove it later), or wait?
[05:12] <jdub> mdz: if we're serious about shipping it, we should get it in for testing
[05:13] <srbaker> i just upgraded to hoary.
[05:13] <jdub> mdz: oh, i can't make seed changes atm - unrecognised signature
[05:13] <jdub> i pulled the keyrings
[05:13] <srbaker> it seems to be OSS only.  i want alsa.
[05:13] <mdz> haha
[05:13] <mdz> jdub: have you seen the oo.o2 splash?
[05:13] <jdub> srbaker: we use alsa by default, via the oss-emu modules.
[05:13] <jdub> mdz: not yet, downloading
[05:13] <srbaker> jdub, uh.
[05:13] <srbaker> ahh
[05:14] <jdub> lifeless: ping
[05:14] <srbaker> when i open the volume control, it says it's oss
[05:14] <mdz> the UI is very different
[05:14] <mdz> too many gradients
[05:14] <jdub> srbaker: you'll have volume controls for alsa and oss for each device
[05:14] <jdub> mdz: got the -gnome package?
[05:14] <sivang> srbaker: try to select asla from "select multimedia system" 
[05:14] <srbaker> jdub, no, i only have for OSS
[05:14] <jdub> haha:
[05:14] <sivang> srbaker: that's waht I usually do
[05:14] <jdub> Get:3 http://archive.ubuntu.com hoary/universe openoffice.org2-core 1.9.66-0ubuntu8 [45.1MB] 
[05:15] <srbaker> gah
[05:15] <srbaker> it's crackly
[05:15] <jdub> Get:7 http://archive.ubuntu.com hoary/universe openoffice.org2-impress 1.9.66-0ubuntu8 [153kB] 
[05:15] <sivang> srbaker: after a couple of crashes for gnome, it works
[05:15] <jdub> Get:8 http://archive.ubuntu.com hoary/universe openoffice.org2-writer 1.9.66-0ubuntu8 [929kB] 
[05:15] <jdub> 
[05:15] <jdub> modular a-go-go!
[05:15] <whiprush> it's pretty crashy over here.
[05:15] <jdub> hahaha
[05:15] <sivang> whee whaa, modulerzied OOo ???
[05:15] <jdub> mdz: nice!
[05:15] <jdub> sivang: look at the packages sizes
[05:15] <sivang> jdub: RAWKING
[05:16] <jdub> er, no
[05:16] <jdub> very silly
[05:16] <sivang> ;-)
[05:16] <srbaker> url for textmate?
[05:17] <srbaker> ahh
[05:17] <srbaker> tgot it
[05:17] <jdub> mdz: i only see the gradients on the toolbar-too-long menus
[05:17] <jdub> hrrrm, the menu padding is all out
[05:18] <mdz> jdub: my menu bar has one gradient, then the toolbar has a different gradient in a different direction
[05:18] <mdz> then the second toolbar has the same gradient as the first toolbal
[05:18] <mdz> s/bal$/bar/
[05:18] <jdub> mdz: got the -gnome package?
[05:18] <mdz> jdub: not yet
[05:18] <jdub> that fixes it
[05:18] <jdub> mostly
[05:18] <mdz> ah, that's better
[05:19] <mdz> gah
[05:19] <mdz> the file open dialog still crashes
[05:19] <jdub> yeah, just finding that myself :|
[05:19] <jdub> oh
[05:19] <jdub> worked that time
[05:19] <mdz> and the crash dialog is broken
[05:19] <jdub> yay gnome file dialogue
[05:20] <jdub> mdz: click the toolbar open button?
[05:20] <jdub> hrm, no, mine both work now
[05:20] <mdz> I used the drop-down menu
[05:21] <lexhider> daniels: I just had a weird thing happen. On boot-up gdm came up in a really low resolution [probably 800x600 or 640x480]  and everything was HUGE. Without changing anythinga 'sudo /etc/init.d/gdm restart' fixed everything. I just want to make sure there isn't already an existing bug before I open one.
[05:21] <mdz> lexhider: can you reproduce the bug by rebooting again?
[05:22] <jdub> mdz: what's the patch summary for ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-109 ?
[05:22] <jdub> mdz: and who committed it?
[05:22] <mdz> patch-109
[05:22] <mdz>     Add culmus to supported
[05:22] <mdz> I did
[05:23] <jdub> i just get invalid signature
[05:23] <jdub> key id?
[05:23] <lexhider> mdz: I'm on dialup so I'll have to try that later. It's not the 1st time, but it doesn't appear to happen everytime.
[05:23] <mdz> mdz@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-109 $ gpg --verify !$
[05:23] <mdz> gpg --verify checksum
[05:23] <mdz> gpg: Signature made Fri Jan 21 01:19:22 2005 GMT using DSA key ID 43E25D1E
[05:23] <mdz> gpg: Good signature from "Matt Zimmerman <mdz@alcor.net>"
[05:24] <daniels> lexhider: er, weird.  if you open a bug, remember /var/log/Xorg.0.log and /etc/X11/xorg.conf.
[05:24] <mdz> jdub: why don't I have a signature from you on my key?
[05:24] <mdz> daniels: maybe a start-gdm-earlier thing?
[05:24] <jdub> mdz: because i can't believe you're not butter.
[05:25] <zenrox> lol
[05:25] <jdub> updated, still have invalid signature
[05:25] <mdz> you're buggy
[05:25] <daniels> mdz: do we do anything after S12 that could influence this?
[05:25] <mdz> daniels: dunno, just a guess
[05:26] <daniels> i'll check it out when I get back from the supermarket
[05:26] <mdz> daniels: maybe a udev race, too
[05:26] <jdub> oh man
[05:26] <jdub> now i get it on 110!
[05:26] <daniels> all I've had today so far is an up 'n go
[05:26] <daniels> and the only things left are red eye and vodka
[05:26] <jdub> mdz: who's 110?
[05:26] <mdz> jdub: that's me as well
[05:26] <mdz> hmm
[05:26] <mdz> well
[05:26] <jdub> a fresh get choked on 110, not 109
[05:26] <mdz> the dir is owned by me
[05:26] <mdz> but it's Colin's commit
[05:27] <jdub> 10FA4CD1?
[05:27] <mdz> gpg: Signature made Fri Jan 21 17:01:37 2005 GMT using DSA key ID 10FA4CD1
[05:27] <mdz> which is Colin's key
[05:27] <lexhider> I'll see if I can reproduce with a few reboots, bye.
[05:27] <jdub> yeah
[05:28] <jdub> nup
[05:28] <jdub> hits the wall at 110 again
[05:28] <jdub> lifeless: ping
[05:28] <daniels> mdz: i can buy udev being racy
[05:29] <mdz> daniels: /dev/fb0?  /dev/agpgart?
[05:29] <aj> does warty/hoary support the 915g chipset?
[05:29] <daniels> mdz: i was thinking more /dev/nvidiactl
[05:30] <mdz> I don't use that noise
[05:30] <daniels> aj: warty should have basic support for 915g, hoary has full 3d for 915g and 915gm
[05:30] <daniels> mdz: neither do I, but it's plausible
[05:30] <aj> l33t
[05:30] <daniels> aj: (ironically, it's the most advanced open driver in existence.  even that doesn't save it from the crushing weight of shit hardware, though.)
[05:37] <jdub> can binary packages have different versions to source packages?
[05:38] <jdub> "... have a different version to the source package that produced them ..."
[05:39] <lamont> jdub: see glibc
[05:39] <mdz> jdub: absolutely
[05:42] <jdub> lamont: hrm, not seeing different versions
[05:42] <jdub> $ apt-cache show $(apt-cache showsrc glibc | grep ^Binary | sed 's#^Binary: ##;s#, # #g') 2> /dev/null | grep ^Version | uniq | wc -l
[05:42] <jdub> 1
[05:42] <jdub> 8)
[05:43] <lamont> hrm..
[05:43] <mdz> oh man, oo.o2 has problems
[05:43] <jdub> well, regardless of the example, do you just put a Version: in the binary section?
[05:44] <lamont> Source: util-linux (2.12p-2ubuntu1)
[05:44] <lamont> Version: 1:2.12p-2ubuntu1
[05:44] <lamont> Package: comerr-dev
[05:44] <lamont> Source: e2fsprogs (1.35-8ubuntu1)
[05:44] <lamont> Version: 2.1-1.35-8ubuntu1
[05:44] <jdub> $ apt-cache show $(apt-cache showsrc util-linux | grep ^Binary | sed 's#^Binary: ##;s#, # #g') 2> /dev/null | grep ^Version | uniq | wc -l
[05:44] <jdub> 2
[05:44] <jdub> :_)
[05:45] <lamont> I'd say look at e2fsprogs source.. :-)
[05:45] <jdub> lamont: thanks :)
[05:45] <jdub> this might assist with the gtk-engines/gnome-themes fuckage
[05:49] <lamont> sorry for being so, um, helpful. :-)
[05:49] <jdub> heh
[05:50] <jdub> nah, don't like having all the answer straight up :)
[05:51] <lamont> jdub: but partial answers jepordize my reputation as a know-it-all. :-0)
[05:51] <jdub> hahaha
[05:51] <lamont> s/know-it-all/all-knowing-wizard/ :-
[05:51] <lamont> _
[05:54] <jdub> is there some clever lore behind choosing epoch numbers, or is starting with 1: reasonable?
[05:54] <lamont> 1 is reasonable
[05:55] <lamont> and has the added avantage of making it look like you only screwed up your version numbers once... :0)
[05:56] <jdub> ;)
[06:35] <bob2> what severity a bug is "faaaaaaaaaaaaaaaaaaaaaaaaaaaaabbionne, your 2.6.10 kernels hardlock my machine when I unplug my camera"?
[06:35] <mdz> it's "leave the severity to fabbione" severity
[06:36] <mdz> letting bug submitters choose severity is broken anyway
[06:39] <bradb> Any plans for ndiswrapper to be built for ppc?
[06:40] <bob2> it only works on i386
[06:40] <bob2> unless you want a cpu emulator in your kernel ;)
[06:40] <mdz> whether it works on ppc or not, there aren't any ppc NDIS drivers that I know of :-)
[06:41] <bradb> bradb@oxygen:~/ndiswrapper-1.0rc4 $ grep -rin powerpc * | wc -l
[06:41] <bradb> 9
[06:41] <bradb> bradb@oxygen:~/ndiswrapper-1.0rc4 $
[06:41] <bradb> all of those matches are in c header files
[06:41] <bradb> but yeah, i had a feeling it might be a lost cause
[06:42] <bradb> mandrake distributes it on ppc though. *shrug*
[06:42] <mdz> it didn't build on powerpc when we (accidentally) tried
[06:42] <mdz> http://people.ubuntulinux.org/~lamont/buildLogs/l/linux-source-2.6.8.1/2.6.8.1-7/
[06:43] <bradb> it certainly failed here too
[06:43] <mdz> but seriously, I don't think there are any ppc Windows drivers out there
[06:44] <mdz> bradb: I was talking with haggai about the possibility of using Malone to track bugs in universe
[06:44] <mdz> bradb: what do you think about it?
[06:45] <bradb> it's a bit early for distro using malone, unforunately, other than on a case-by-case basis (which, iiuc, isn't a possibility even with universe...unless it is.)
[06:47] <bradb> RSN now though. I'm almost finished support for private bugs. (maybe another full day of work on it will finish it.) Then kiko and mpt will be in Montreal over the next week to really go nuts on the UI, and, who knows, perhaps that might bring us to a really usable point for distro. The main thing we lack right at this moment is a sane way to specify distro and/or sourcepackage and/or binarypackage (as specific as the user can 
[06:47] <bradb> get.) The UI isn't there yet.
[06:47] <bradb> s/RSN now/RSN/
[06:51] <mdz> bradb: there are only a small number of bugs reported about universe packages, but we need someplace to put them
[06:51] <mdz> if malone isn't ready for it, then we'll need to set up yet another ad hoc bugzilla :-/
[06:51] <mdz> and then import it later
[06:51] <mdz> you don't think it's workable even with a light load?
[06:51] <bradb> mdz: when do you need to do it by?
[06:52] <mdz> bradb: they currently have no bug tracking facility at all
[06:52] <mdz> bradb: so the sooner, the better
[06:53] <bradb> kiko, mpt and I should be able to take some big steps in Montreal towards bringing that part of it to a usable state. I don't have a clear idea from kiko about exactly what we're focussing on, but I'll mention it to him tomorrow and maybe we can focus what we'd need to do to Take on the Universe next week (they're here Jan 26 - Feb 1.)
[06:54] <bradb> I'll write him the email right now and Cc, just to be sure this isn't lost. :)
[06:54] <bradb> s/Cc/Cc you/
[07:03] <bradb> sent
[07:08] <mdz> bradb: ok, thanks
[07:10] <fabbione> morning guys
[07:14] <mdz> morning
[07:15] <fabbione> hey bdz
[07:15] <fabbione> bah
[07:15] <fabbione> mdz
[07:15] <fabbione> :-)
[07:28] <lamont>   ubuntu-desktop: Depends: gnomemeeting but it is not going to be installed
[07:28] <lamont> bummer
[07:28] <fabbione> hey lamon
[07:28] <fabbione> t
[07:29] <lamont> same old livecd images on all 4 architectures. :(
[07:29] <lamont> hey fabbione 
[07:30] <fabbione> good night :-)
[07:32] <lamont> night. back in about 6 hours or so.
[07:34] <lifeless> jdub: phew
[08:22] <jdub> lifeless: dude, have issues for you
[09:09] <jdub> mdz: what do you do for mass bogofilter spam/ham classifications?
[09:09] <mdz> jdub: I have a huge corpus
[09:09] <mdz> I used to dump it into bogofilter -M, but at some point it grew too large for bogofilter to handle in one go
[09:10] <jdub> do you use maildir or mbox?
[09:10] <mdz> so the last time I had to break it up with formail, which was much slower
[09:10] <mdz> mbox
[09:10] <jdub> mmm
[09:11] <jdub> have to do big maildir classifications
[09:11] <jdub> very slow
[09:12] <opi> two more minutes and I'll have a Horay box :-)
[09:12] <fabbione> jdub: did you have any time to check the installer on sparc again?
[09:13] <jdub> not today ;)
[09:16] <opi> nooo
[09:16] <opi> [Invalid UTF-8]  Could not parse file '/usr/share/applications/ooo645calc.desktop': desktop entry contain line 'Comment[ca] =Fulla de c\xc3| lcul d'OpenOffice.org' which is not UTF-8
[09:18] <Treenaks> [ca] ? /me blames Canada
[09:18] <opi> dist-upgrade failed at Mozilla-Firefox
[09:18] <opi> Treenaks, it's not a real country anyway ;-)
[09:19] <opi> so much for a Horay
[09:21] <mvo_> blame jordi ... ca == catalan
[09:22] <opi> should I file a bugzilla raport or e-mail/IRC him?
[09:22] <opi> it should be a quick fix
[09:22] <mvo_> opi: before you file, please have a look if it is not already reported (IIRC it is)
[09:22] <opi> ok then
[09:23] <opi> I'll put Firefox on hold and see if rest will go up to Horay
[09:23] <jdub> mdz: https://bugzilla.samba.org/show_bug.cgi?id=2092
[09:23] <jdub> mdz: approve?
[09:23] <jdub> mdz: at least in theory? :)
[09:25] <mdz> jdub: seb128 already rolled that in, dude
[09:26] <mdz> jdub: /usr/share/doc/samba-common/changelog.Debian.gz
[09:27] <jdub> hah!
[09:34] <fabbione> Kamion: ping?
[09:35] <opi> 16:00 UTC is 17:00 CET?
[09:35] <Treenaks> yes
[09:35] <opi> okidok ;)
[09:35] <Treenaks> opi: TZ=UTC date ;)
[09:41] <opi> smurfix, that was fast :->
[09:41] <opi> smurfix, I'll ask at our mailing list
[09:42] <smurfix> opi: we have these domains for a few days now, I'm waiting for mako to think about my announcement text ;-)
[09:42] <opi> smurfix, hehe :-)
[09:43] <opi> smurfix, how about ,,we rules. now pay us.''
[09:43] <pitti> Morning!
[09:43] <opi> morning pitti
[09:43] <fabbione> hey pitti
[09:43] <fabbione> hi guys
[09:43] <opi> (I think I'm tabcomp. addicted, I just typed morn<tab> to get morning)
[09:49] <lifeless> jdub: what are your issues?
[09:49] <fabbione> SteveA: ping
[09:51] <opi> uhm..
[09:51] <opi> why x-window-system-core's on hold..
[09:51] <opi> ok, fixed
[09:53] <haggai> what's the canonical way (not Canonical :) to close bugs?  I see closes: Ubuntu#nnn and Hoary #nnn
[09:54] <haggai> (and nothing in the wiki)
[09:54] <pitti> haggai: there is no official Standard
[09:54] <fabbione> haggai: i use the same way as Debian does
[09:54] <pitti> haggai: some use (Ubuntu: #nnnn), some just #nnnn
[09:54] <haggai> pitti: do you close them in bugzilla manually?
[09:54] <pitti> haggai: yes
[09:54] <pitti> haggai: uploads don't close them
[09:54] <mdz> haggai: none of those actually do anything
[09:55] <haggai> pitti: aha, that's what was confusing me
[09:55] <mdz> they're purely informational at this point
[09:55] <pitti> Hi mdz
[09:55] <SteveA> hi fabbione 
[09:55] <mdz> good morning
[09:55] <mdz> I'm headed for bed shortly
[09:55] <pitti> mdz: I want to make a new upstream microrelease of pmount soon to fix some bugs
[09:55] <pitti> mdz: can I upload this?
[09:55] <mdz> certainly
[09:55] <pitti> okay
[09:56] <pitti> mdz: same for hal, there are new upstream microreleases available
[09:56] <mdz> the UVF doesn't really apply to packages where one of us is upstream, so long as we follow the release guidelines for the changes we make
[09:56] <pitti> mdz: however, they also contain some small new features
[09:56] <SteveA> fabbione: i'm still running the kernel you made
[09:56] <pitti> mdz: own upstream> makes sense :-)
[09:56] <mdz> pitti: well, we're not in feature freeze quite yet
[09:57] <mdz> pitti: and ogra says that he needs some of those new features for the hardware database (/proc support, apparently)
[09:57] <pitti> mdz: right
[09:57] <mdz> I told him to talk to you about whether we should bring in a new hal
[09:57] <pitti> mdz: okay, then I coordinate this with him
[09:57] <fabbione> SteveA: i read what you wrote.. i am hounestly not sure what to do more than that. I backported the entire new bluez stack. Perhaps you need the firmware installed?
[09:57] <mdz> but...CC meeting in 7 hours, so I'm off
[09:57] <pitti> mdz: he already told me about his plans
[09:57] <mdz> ok, good
[09:57] <pitti> mdz: good night!
[09:59] <fabbione> night mdz
[09:59] <SteveA> fabbione: maybe.  is there something in /sys/ or /proc/ that i can look at to see if the kernel even knows about the CF card?
[10:00] <fabbione> SteveA: probably.. i don't know which entries the bluez stack creates around. you will need to poke around yourself.. lacking that hardware here, doesn't make it simpler for me
[10:00] <SteveA> I'll mail you the card if you want.  Just scrap metal and plastic here.
[10:00] <opi> damn, damn
[10:01] <opi> after update to x.org prop. NVidia driver gone mad
[10:01] <fabbione> SteveA: can you try using the firmware?
[10:01] <pitti> ogra: ping
[10:01] <fabbione> SteveA: or give me a way to check /proc
[10:01] <pitti> sjoerd: ping
[10:02] <opi> splash screen covers everything, so even after loggin all I see is NVidia logo
[10:02] <opi> with Option "NoLogo" there's a blank screen
[10:03] <opi> it worked with nv driver
[10:05] <opi> anyone saw something similar?
[10:06] <sjoerd> pitti: pong
[10:06] <pitti> sjoerd: Morning!
[10:06] <sjoerd> morning :)
[10:06] <pitti> sjoerd: any plans to package hal 0.4.7?
[10:06] <sjoerd> ofcourse
[10:07] <ogra> pitti: pog....hal meeting ? :)
[10:07] <ogra> pong even
[10:07] <pitti> sjoerd: cool! it seems that it (once again) includes all patches, right? :-)
[10:07] <pitti> ogra: there recently was a thread about /proc/ support on the hal list
[10:07] <ogra> yup
[10:07] <sjoerd> ogra: you have about 10 minutes to ask questions :)
[10:08] <ogra> thanks for pointing me there, i owe you a beer or something :)
[10:08] <pitti> ogra: do you know whether you need the new 0.4.7 for your project? or would 0.4.4 be sufficient in principle?
[10:08] <sjoerd> pitti: well, i've not added patched to the debian for some time now so :)
[10:08] <ogra> i'm not sure which one is the first to have proc support, but this one i will need
[10:08] <pitti> I would like to package 0.4.7 anyway, but I don't want to interfere with your work
[10:09] <pitti> sjoerd: right, this stable branch was really a good idea
[10:09] <sjoerd> ogra: what proc support are we talking about ?
[10:09] <sjoerd> pitti: yeah, HEAD code is basically a complete rewrite
[10:09] <ogra> sjoerd: i want /proc/cpuinfo in hal....
[10:09] <sjoerd> ogra: 0.6.x :)
[10:09] <ogra> sjoerd: argh
[10:10] <ogra> sjoerd: any chance to backport something of that ?
[10:10] <sjoerd> or if you have some simple patches, maybe david will accept them
[10:10] <ogra> ok
[10:10] <sjoerd> ogra: it's not even in yet.. for now it's mostly acpi and pmu stuff
[10:10] <Treenaks> sjoerd: HEAD doesn't compile on my Suse box 8)
[10:10] <sjoerd> Treenaks: you don't want had right now
[10:10] <sjoerd> s/had/head/
[10:11] <sjoerd> (the procfs code is mostly acpi and pmu stuff)
[10:11] <sjoerd> ogra: do you want the complete /proc/cpuinfo in hal or just some pars ?
[10:11] <Treenaks> sjoerd: dbus doesn't work anyway.. so hal won't do a thing either ;)
[10:11] <ogra> sjoerd : heh, im fine with everything i can get :)
[10:12] <sjoerd> well you must have some reason to want the properties right :)
[10:12] <sjoerd> Treenaks: you also don't want dbus cvs currently :)
[10:12] <pitti> ogra: you have to create the patches against 0.4.x for Ubuntu anyway
[10:12] <pitti> ogra: we will not have 0.6 in Hoary
[10:12] <Treenaks> sjoerd: tell jhbuild ;)
[10:12] <ogra> pitti: yeah, looks like...
[10:13] <sjoerd> ogra: probably nice if you could discuss the properties you want on the hal list.. So they will be the same in 0.6
[10:13] <pitti> ogra: but keep it as simple as possible and leave the "real" and generic solution for hal upstream
[10:14] <ogra> pitti: if there is already something in HEAD i can dervie from, i will take that
[10:14] <sjoerd> ogra: it's not yet in, just discussion, spec and some playing code from some guy..
[10:15] <ogra> sjoerd: but at least there is a skeleton.....(spec)
[10:15] <sjoerd> yeah, but you might need to add stuff to the spec
[10:15] <ogra> thats no prob....
[10:16] <ogra> you know the problems with the writer and the empty sheet of paper ;)
[10:16] <sjoerd> heh
[10:23] <Kamion> fabbione: yo
[10:23] <fabbione> hey Kamion 
[10:23] <fabbione> SteveA: re
[10:24] <fabbione> Kamion: for that kernel problem.. i have half of an idea.. can you try to just rebuild the kernel locally?
[10:24] <fabbione> i am kinda suspicious about compilation options that are applied on the buildd
[10:24] <fabbione> and if you can spot if it was introduce in a specific version would also be great
[10:24] <Kamion> ok, sure
[10:25] <Kamion> fabbione: definitely 2.6.10-10
[10:25] <Kamion> fabbione: 2.6.10-9 works great
[10:25] <fabbione> because it's a little while that i don't update x86_64 specific bits
[10:26] <Kamion> fabbione: hm, should I try with 2.6.10-11 first?
[10:26] <Kamion> since that hit my mirror last night
[10:27] <fabbione> Kamion: if you can that would be nice
[10:28] <jordi> mvo_: ping
[10:28] <mvo_> jordi: pong
[10:29] <jordi> mvo_: when synaptic broken due to the libglade2 bug, did you change anything in the code, or just rebuilt? Do you have any reasoning for why the toolbars were fucked?
[10:30] <mvo_> jordi: I saved and loaded the glade file with a new glade. the old glade file was incompatible with the new libglade
[10:31] <mvo_> the toolbar is fucked because libglade2 changed 
[10:31] <jordi> so might it be a glade-2 bug, not a libglade2 one?
[10:32] <Kamion> fabbione: 'k, on way
[10:32] <fabbione> Kamion: no rush :-)
[10:32] <mvo_> it's a libglade2 bug. the new glade generates GtkToolbarButtons in the glade file, the old one just generates GtkButtons
[10:32] <smurfix> How can I run an installer-level program (like, for instance, kbd-chooser ;-) without actually booting into the installer?
[10:32] <Kamion> may as well do it now while I'm thinking about it
[10:33] <Kamion> smurfix: there are various 'make demo' targets in debian-installer
[10:33] <Kamion> but in general it's hard, particularly for stuff like kbd-chooser that really cares about the hardware
[10:33] <mvo_> the "fix" was to regenerate the toolbar with gtktoolbuttons from glade, but libglade should handle a toolbar with GtkButtons equally well 
[10:33] <fabbione> Kamion: also... when you have time.. we finally have a strace for sparc, so if you can kindly queue up in your debootstrap TODO list to revert that change, it would be just great
[10:33] <mvo_> the real "problem" is that the GtkToolbar code in gtk changed 
[10:34] <Kamion> smurfix: most d-i developers create cheap images like netboot for that kind of testing
[10:34] <mvo_> melt is bitten by this problem too BTW
[10:34] <fabbione> Kamion: (we did an exception since strace was FTBFS)
[10:34] <fabbione> Kamion: but i didn
[10:34] <Kamion> fabbione: righto
[10:34] <fabbione> Kamion: but i didn't want to upload straigh ahead because i remember you talking about generating the lists from seeds or something
[10:34] <jordi> mvo_: yes, that's the bug we're trying to chase.
[10:34] <jordi> mvo_: we fear there might be other apps affected.
[10:34] <Kamion> fabbione: yes, it's automatic, will rerun
[10:34] <jordi> but no other have been identified
[10:35] <fabbione> thanks!
[10:35] <Kamion> well, semi-automatic
[10:35] <fabbione> :-)
[10:35] <mvo_> jordi: there is a patch floating around for libglade that may fix it
[10:35] <mvo_> jordi: each app that don't use a recent glade and uses glade to build it's toolbar is affected
[10:35] <mvo_> s/uses glade/uses libglade/
[10:35] <jordi> mvo_: where is that patch?
[10:35] <Kamion> smurfix: BTW if you're on powerpc you can boot a netboot image straight off a filesystem without actually having to do a real netboot ...
[10:36] <elbi> a question, why don't you have a php imap package in warty? (neither multi- or universe)
[10:36] <Kamion> image=/home/cjwatson/src/debian/debian-installer/trunk/debian-installer/installer/build/dest/powerpc/netboot/vmlinux
[10:36] <Kamion>         label=random26
[10:36] <Kamion>         read-only
[10:36] <Kamion>         initrd=/home/cjwatson/src/debian/debian-installer/trunk/debian-installer/installer/build/dest/powerpc/netboot/initrd.gz
[10:36] <mvo_> attached to #290811, 288445
[10:36] <Kamion>         root=/dev/ram
[10:36] <Kamion> stuff like that
[10:36] <mvo_> jordi: I can also forward it to you by mail
[10:36] <smurfix> Kamion: Thanks. For now. ;-)
[10:37] <mvo_> jordi: (gnome BTS number is #163322 btw)
[10:37] <Kamion> pitti: has anyone told you that all the language packs are uninstallable on ia64?
[10:37] <Kamion> pitti: they all have a versioned dep on libc6 ... ia64 has libc6.1
[10:37] <jordi> oh
[10:37] <jordi> there is recent activity in this bug
[10:38] <jordi> ah, no, I had read this already.
[10:38] <Kamion> fabbione: doesn't seem to be on sparc.ubuntu.com yet?
[10:38] <thom> sladen: have you read #5361? is the reporter on crack?
[10:38] <thom> morning, y'all
[10:38] <pitti> Kamion: urgh, no
[10:39] <pitti> Kamion: the versioned depends was just to ensure that you use it with a libc6 with /usr/share/locale-langpack support
[10:39] <jordi> mvo_: if you could mail it I would build a fixed package right now
[10:39] <fabbione> Kamion: not yet.. do you want me to push it? it's in the buildd queue
[10:39] <pitti> Kamion: would "libc6 (>= foo) | libc6.1 (>= bar)" do the job?
[10:40] <fabbione> Kamion: behind the kernel and libc6 :(
[10:40] <Kamion> pitti: best answer's probably to use ${libc-depends} or whatever and substitute in libc6 (>= 2.3.2.ds1-19ubuntu2) using substvars
[10:40] <Kamion> pitti: libc6 | libc6.1 works technically but is ugly - substvars are much nicer
[10:40] <mvo_> jordi: send
[10:40] <pitti> Kamion: and determine the platform in debian/rules. Okay
[10:40] <mvo_> jordi: as I wrote, not tested, not reviewed
[10:40] <jordi> mvo_: you don't mean marga's patch that reverts some of the changes, right?
[10:41] <jordi> mvo_: ok
[10:41] <Kamion> pitti: do something like dh_gencontrol -- -V'libc-depends=$(LIBC) (>= 2.3.2.ds1-19ubuntu2)' maybe?
[10:41] <mvo_> jordi: I'm afraid that's what I send you :(
[10:41] <Kamion> fabbione: no hurry
[10:41] <jordi> mvo_: oh dear.
[10:41] <fabbione> Kamion: ok thanks :-)
[10:42] <Kamion> pitti: if you're maintaining a list ... alpha/ia64 have libc6.1, hurd-i386 has libc0.3
[10:43] <mvo_> jordi: so this is not the right fix? bad :/
[10:44] <pitti> Kamion: hmm, but I guess that nobody modified libc6.1 / libc0.3 to support the alternate gettext tree?
[10:44] <jordi> mvo_: what happens with the pakcages now using the new api?
[10:44] <Kamion> pitti: they're all from the same source package
[10:44] <pitti> Kamion: oh, nice
[10:44] <Kamion> pitti: glibc just generates different names depending on the architecture
[10:44] <Kamion> for historical reasons
[10:44] <pitti> Kamion: then the versions should indeed be the same
[10:44] <Kamion> e.g. alpha/ia64's soname changed when some different 64-bit syscalls got introduced, I think
[10:45] <Kamion> yes, definitely
[10:45] <mvo_> jordi: it just reverts everything? that's clearly wrong.
[10:46] <elbi> a question, why don't you have a php imap package in warty? (neither multi- or universe)
[10:46] <fabbione> elbi: becasue it is too buggy to be maintained properly
[10:46] <fabbione> and it is cause of several headackes
[10:47] <jordi> mvo_: yeah
[10:48] <SteveA> fabbione: well... i was trying out the hcitool and rfcomm commands to see what worked, and the whole machine locked up
[10:48] <SteveA> fabbione: so, i guess it isn't ready for prime time
[10:48] <fabbione> that's not nice
[10:48] <fabbione> ok
[10:48] <SteveA> the card is certainly detected
[10:48] <SteveA> and it is presenting itself in the right way to the tools
[10:48] <fabbione> but it wasn't before.. right?
[10:48] <SteveA> but it didn't actually *work*
[10:49] <SteveA> yes, I'm in the usual hoary kernel now
[10:49] <SteveA> and the card isn't detected at all
[10:49] <fabbione> not even with cardinfo status?
[10:49] <SteveA> oh wait
[10:49] <SteveA> that's odd
[10:50] <SteveA> it appears in hcitool on the second insertion
[10:50] <fabbione> SteveA: HMMMMM do you actually hear a bip or two bips when you insert the card the first time?
[10:51] <fabbione> because there is a code behind the beeps to decode the pcmcia status
[10:51] <jordi> hi SteveA 
[10:51] <fabbione> first beep(high tone): pcmcia got the card
[10:51] <fabbione> second beep(high tone): driver is loaded correctly
[10:52] <elbi> fabbione, several php mail clients depend on that module, so ubuntu shouldn't be used on apache/php deployments?
[10:52] <fabbione> second beep(high tone): no driver available
[10:52] <Kamion> fabbione: FWIW 2.6.10-11 still dies
[10:52] <Treenaks> fabbione: that's second beep(low tone)
[10:52] <fabbione> Kamion: ok.. :(
[10:52] <trukulo> hi
[10:52] <fabbione> Treenaks: right
[10:52] <elbi> any way to compile the module manually? fabbione 
[10:52] <Kamion> trying a rebuild now
[10:53] <fabbione> elbi: yes but this is offtopic here, ask in #ubuntu
[10:53] <fabbione> Kamion: i doubt it will solve...
[10:53] <fabbione> Kamion: the only major change is the inotify patch
[10:53] <SteveA> fabbione: hmm -- same on usual hoary kernel
[10:53] <Kamion> fabbione: I might try backing out individual changes from 2.6.10-10
[10:53] <fabbione> SteveA: ok. the driver is way buggy
[10:53] <SteveA> fabbione: crashed when i reinserted the card a few times and ran rfcomm
[10:54] <fabbione> Kamion: if you want i can build kernels for you on concordia. I have everything ccached
[10:54] <fabbione> SteveA: can you add all these info to the bud i mentioned yesterday
[10:54] <fabbione> ?
[10:54] <SteveA> fabbione: okay.  i'll keep an eye on the bluez development list to see if support for the card improves
[10:54] <Kamion> fabbione: mm, that'd certainly be faster if you don't mind and you know what the best candidates to back out are ...
[10:54] <SteveA> fabbione: okay
[10:54] <fabbione> Kamion: i don't mind at all....
[10:54] <fabbione> SteveA: thanks
[10:54] <fabbione> Kamion: what flavour do you need?
[10:55] <Kamion> fabbione: generic's fine
[10:55] <fabbione> Kamion: ok thanks
[10:56] <Kamion> it's a K8 but I've been doing the testing with generic since that's what's on d-i CDs
[10:56] <fabbione> ok
[10:58] <fabbione> Kamion: also because i love to push concordia up to Load: 430 :-)
[10:58] <fabbione> make -j 400 is teh r0ck
[11:00] <SteveA> fabbione: comment feels a bit random.  hope it helps.
[11:00] <SteveA> thanks for looking into this/
[11:00] <fabbione> SteveA: welcome dude
[11:01] <fabbione> Kamion: building now
[11:03] <fabbione> haggai: did you ever get around to check ooo1?
[11:06] <haggai> fabbione: yes I did, I'm looking at it
[11:06] <fabbione> ok
[11:06] <fabbione> great
[11:06] <fabbione> hey rburton !
[11:10] <fabbione> jdub: any news about 5431?
[11:10] <rburton> hi fabbione 
[11:10] <jdub> fabbione: not yet
[11:10] <fabbione> ok
[11:11] <fabbione> my god.. concordia is so slow....
[11:13] <fabbione> Kamion: people.u.c/~fabbione/
[11:13] <fabbione> there is a kernel image for you to test there
[11:15] <Kamion> fabbione: downloading; what's changed?
[11:15] <fabbione> reverted inotify patch
[11:15] <fabbione> from new to old one
[11:15] <fabbione> but still there
[11:27] <jdub> lifeless: so
[11:27] <opi> uff. Done. http://opi.pegasos.pl/?siurp=single&id=220 :P
[11:27] <lifeless> jdub: ah,finally, we pong together
[11:28] <jdub> lifeless: i'm having problems doing fresh checkouts of the seeds archive
[11:28] <jdub> lifeless: because there's an invalid signature on patch 110
[11:28] <jdub> lifeless: however, it works fine for mdz
[11:28] <lifeless> can you cat the checksum file for me ?
[11:36] <lifeless> 21:34 <lifeless> ok, that looks fine to me, I'll be its gpg.
[11:36] <lifeless> 21:34 <lifeless> save that file on your dist, then run sh ~/.arch-params/signing/<relevant .check rule> < path-to-that-file
[11:36] <lifeless> 21:34 <lifeless> *disc*
[11:36] <lifeless> 21:35 <lifeless> the relevant check rule is archive-name.check, or, =default.check, searched for in that order.
[11:36] <lifeless> that should be 'I'll bet its gpg'
[11:38] <thom> lifeless: your typing seems somewhat off beam today
[11:39] <lifeless> thom: its on plastic chair is why.
[11:39] <lifeless> no beam at all.
[11:40] <fabbione> was it -ctime or -mtime to identify file created more than N days ago?
[11:40] <Kamion> grr, people who think forums are the ideal place for bug reporting
[11:40] <fabbione> (using find)
[11:40] <lifeless> ctime
[11:40] <lifeless> created ;)
[11:40] <fabbione>               File's status was last changed n*24 hours ago.
[11:40] <Kamion> ctime is not created timestamp, it's status last changed timestamp
[11:40] <Kamion> there is no created timestamp
[11:40] <fabbione> that's why the manpage says changed?
[11:40] <fabbione> ;)
[11:40] <lifeless> oh, crapola.
[11:41] <jdub> $ sh /home/jdub/.arch-params/signing/\=default.check < checksum; echo $?
[11:41] <jdub> 1
[11:41] <jdub> 
[11:41] <jdub> ok
[11:41] <jdub> farout
[11:41] <jdub> my fault
[11:41] <lifeless> man, thats crack, what is the different from 'mod' and 'change' to a file ?
[11:41] <fabbione> Kamion: what would you suggest? i simply need to create some kind of morgue script to remove old files from a dir
[11:41] <Kamion> fabbione: that kernel still segfaults
[11:41] <jdub> bazaar-gpg-check > baz-gpg-check
[11:41] <lifeless> jdub: ;)
[11:41] <Kamion> lifeless: modification => contents changed, change => inode changed
[11:41] <Kamion> AIUI
[11:41] <fabbione> Kamion: ok... let's try something else...
[11:42] <jdub> lifeless: are the gpg-related improvements slated for 1.2?
[11:42] <lifeless> jdub: not at the moment, we're looking at 'log', 'import', 'export', and 'resolved'.
[11:42] <jdub> ok
[11:42] <pitti> seb128: is there any chance that we could get gnome-vim integration into Evolution for Ubuntu?
[11:42] <lifeless> and if you are a good boy, we might even give you some annotate.
[11:44] <seb128> pitti: is that an existant stuff ? or should we code it ? :p
[11:44] <jdub> no, it's total crack
[11:44] <jdub> it replaces the editor component
[11:45] <jdub> but you have to modify the evo source or binary to do so
[11:45] <seb128> urg
[11:45] <pitti> seb128: existing
[11:45] <pitti> seb128: http://www.opensky.ca/~jdhildeb/software/gnome-vim/
[11:45] <pitti> seb128: look at http://www.opensky.ca/~jdhildeb/software/gnome-vim/evolution.png
[11:46] <pitti> seb128: we already have a vim-gnome package in main, not sure whether this is already the one part
[11:46] <pitti> seb128: however, it seems that our Evolution does not support changing the editor
[11:46] <pitti> seb128: or does it?
[11:46] <pitti> seb128: I could not find the option
[11:46] <jdub> it doesn't
[11:46] <seb128> it doesn't
[11:46] <jdub> you ahve to mod the source or binary
[11:46] <jdub> this is serious crack, dude :)
[11:46] <seb128> but what's wrong with the textview ?
[11:48] <pitti> jdub: it _is_ crack, but it is good one
[11:48] <jdub> looks like he's got patches for very old evo
[11:48] <jdub> to do editor switching
[11:48] <pitti> I just cannot get used to using another editor than vim any more...
[11:48] <jdub> which is at least an improvement to the old patches
[11:48] <pitti> jdub: yeah, that's the problem
[11:48] <pitti> jdub: however, why is such a thing not adopted upstream?
[11:48] <jdub> because this is hideously old and hacky
[11:49] <pitti> jdub: changing the editor should be reasonably generic 
[11:49] <fabbione> Kamion: building another kernel now
[11:49] <jdub> if you want to update his patches and submit them upstrea, that'd be great
[11:49] <jdub>  iw oudl use it too :)
[11:49] <pitti> whenever I find myself in a non-vim editor, I use to destroy the file by putting "ifoo:w" or "jjjjjkkdw" all over the place...
[11:50] <stub> I reported a bug in the Roundup package upstream since the Ubuntu Bugzilla didn't want it, but the package maintainer says it is installable for him. Can someone quickly try to install Roundup and let me know if it is an Ubuntu problem (victimized by Python2.4 likely) or upstream ? 
[11:50] <jdub> haha, same 8)
[11:50] <pitti> jdub: well, for now I'm a hard core mutt user
[11:50] <pitti> jdub: but I wanted to at least take a look at the software we are shipping :-)
[11:51] <lifeless> I have a couple of hardware bugs right now ...
[11:52] <Kamion>  Package: roundup
[11:52] <Kamion>  Depends: python (>= 2.3), python (<< 2.4)
[11:52] <Kamion> just needs trivial fixes for python 2.4 I think
[11:52] <lifeless> started happening with the 10-2 kernel (&acpi support at the same time). They are 1) fn-F4 (sleep now please) doesn't have any affect, and 2) many times, usb key plugni events don't result in the kernel seeing the usb storage device.
[11:54] <Kamion> stub: ping one of the masters of the universe and get them to fix it
[11:55] <stub> Kamion: Who plays He-Man? (I play dumb-user myself)
[11:56] <Kamion> stub: http://www.ubuntulinux.org/wiki/MOTU
[12:00] <fabbione> Kamion: new kernel up: removed the 2 patch stolen from upstream and old inotify patch
[12:00] <stub> Kamion: Ta. Bounced to ogra.
[12:01] <fabbione> Kamion: i am slowly going back to -9 basically...
[12:01] <fabbione> there is only one or two changes left that might affect the thingy
[12:01] <fabbione> after that is -9
[12:09] <jdub> fabbione: you reverted inotify?
[12:17] <lifeless> fabbione: any thoughts on my question about usb & fn-sleep ?
[12:18] <Kamion> jdub: for testing purposes, trying to nail down my amd64/grub problem
[12:18] <thom> lifeless: check /etc/defaults/acpi-support for the latter
[12:18] <jdub> Kamion: ahr
[12:18] <lifeless> thom the new acpi-support package replaced it
[12:19] <lifeless> thom: what should I look for .. ACPI_SLEEP=true ?
[12:19] <thom> yeah
[12:19] <thom> make sure that's uncommented ;-)
[12:19] <lifeless> ok, thats one.
[12:19] <lifeless> oh yeah, ipw2200 doesn't come back from sleep
[12:20] <lifeless> I have to remove and add it, was mjg's magic to do that reverted ?
[12:20] <thom> add it to the list of modules lower in that file
[12:20] <lifeless> done
[12:20] <lifeless> thanks.
[12:20] <lifeless> now for the usb thing ...
[12:21] <lifeless> usb 4-1: new full speed USB device using uhci_hcd and address 2
[12:21] <lifeless> usb 4-1: device descriptor read/64, error -71
[12:21] <lifeless> usb 4-1: device descriptor read/64, error -71
[12:21] <lifeless> u
[12:21] <lifeless> is what I see when it fails..
[12:27] <fabbione> lifeless: what kernel version are you running?
[12:28] <lifeless> Linux lifelesslap.robertcollins.net 2.6.10-2-686 #1 Wed Jan 19 18:58:12 UTC 2005 i686 GNU/Linux
[12:29] <fabbione> i mean the debian version... 2.6.10-???
[12:30] <nakee_> what's the url to see what package a langauge pack has?
[12:30] <lifeless> fabbione: -10
[12:30] <pitti> nakee_: apt-cache search language pack <yourlanguage>
[12:31] <pitti> nakee_: if you know your language code (de, en, he, etc.), it's language-pack-<langcode>
[12:32] <pitti> nakee_: for Israel it should be -he
[12:32] <nakee_> pitti thanks, but is there a way to see it from the web?
[12:32] <fabbione> lifeless: do you get these messages after a resume?
[12:32] <nakee_> I want to show it to people who doesn'thave ubuntu yet
[12:32] <pitti> nakee_: not yet
[12:32] <fabbione> lifeless: or after a reboot?
[12:32] <lifeless> fabbione: after a clean boot
[12:32] <lifeless> fabbione: modprobing usb-storage seems to help
[12:32] <pitti> nakee_: there will be a web platform which can do this in the near future, but not right now :-(
[12:33] <nakee_> pitti not even like debian package search?
[12:33] <fabbione> lifeless: how does it help? is that happening with a usb storage of any kind?
[12:33] <pitti> nakee_: no
[12:33] <nakee_> oh.. too bad
[12:33] <lifeless> fabbione: its my usb flash key.
[12:33] <pitti> nakee_: at most http://archive.ubuntu.com/ubuntu/pool/main/l/
[12:34] <fabbione> lifeless: well usb-storage should be loaded automaticcally... 
[12:34] <lifeless> fabbione: yah, all I know is this never happened before the latest round of updated
[12:34] <lifeless> *s*
[12:34] <fabbione> HMMMMM GRRRRR
[12:35] <nakee_> pitti that has only the po files, I thought it also have other programs?
[12:36] <nakee_> or is it added as dependencies?
[12:38] <pitti> nakee_: the dependencies come with language-support-he
[12:38] <pitti> nakee_: the packs only have translations (mo files)
[12:39] <nakee_> ok that's what Iwas looking for (the meta package)
[12:40] <nakee_> if I want to add request packages to be added I need to submit a bug report right?
[12:40] <pitti> nakee_: you can also ask me straight away
[12:40] <pitti> nakee_: the next version will depend on the culmus package
[12:41] <fabbione> lifeless: the only usb change between -9 and -10 is to fix an irq issue on a few ehci driven controllers...
[12:41] <fabbione> lifeless: are you using ehci?
[12:42] <lifeless> ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
[12:42] <lifeless> PCI: Setting latency timer of device 0000:00:1d.7 to 64
[12:42] <lifeless> ehci_hcd 0000:00:1d.7: irq 5, pci mem 0xe8000000
[12:42] <lifeless> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
[12:42] <lifeless> PCI: cache line size of 128 is not supported by device 0000:00:1d.7
[12:42] <lifeless> ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
[12:42] <Kinnison> jdub: how about base-files, apt-utils or dpkg to house that script?
[12:42] <lifeless> hub 5-0:1.0: USB hub found
[12:42] <lifeless> hub 5-0:1.0: 8 ports detected
[12:42] <fabbione> lifeless: don't flood the chan dude!
[12:42] <lifeless> fabbione: oh this is interesting...
[12:42] <lifeless> sorry, didn't think 8 lines was a flood.
[12:43] <ups_> i've jut upgraded to hoary, does it install a x11.pc file?
[12:43] <Kamion> it's *so* not appropriate for base-files
[12:43] <lifeless> anyway, it looks like ehci and uhci are fighting for the device.
[12:43] <lifeless> when it fails, I see:
[12:43] <Kamion> something related to the package manager seems better
[12:43] <lifeless> usb 5-3: new high speed USB device using ehci_hcd and address 7
[12:43] <lifeless> usb 2-1: new full speed USB device using uhci_hcd and address 4
[12:43] <lifeless> usb 2-1: device descriptor read/64, error -71
[12:43] <lifeless> and when it works, the uhci line does not show up.
[12:43] <Mithrandir> Kamion: I think ubuntu-utils or distribution-utils would be the right place.
[12:44] <fabbione> lifeless: can you try to unload the uhci driver?
[12:46] <lifeless> fabbione: unloaded uhci_hcd, now it just lists 
[12:46] <lifeless> usb 5-5: new high speed USB device using ehci_hcd and address 10
[12:46] <fabbione> ok, but does the stick work?
[12:46] <lifeless> but not the new sda1 etc etc stuff
[12:46] <Kamion> "distribution-" bugs me as a prefix; it's so obviously a hack, instead of giving the thing a proper name :)
[12:46] <fabbione> hmmmm
[12:46] <fabbione> lifeless: try the other way around.. unload ehci and load uhci
[12:46] <lifeless> done that :)
[12:46] <lifeless> great minds and all that, and its working fine
[12:47] <Mithrandir> fabbione: any idea why I'm getting a zillion of:
[12:47] <Mithrandir> hub 5-0:1.0: over-current change on port 5
[12:47] <Mithrandir> hub 5-0:1.0: over-current change on port 6
[12:47] <fabbione> Mithrandir: no....
[12:47] <Mithrandir> seems to be triggered each and every time a keyboard, disk or network interrupt is received
[12:49] <fabbione> Mithrandir:
[12:49] <fabbione>  * See USB 2.0 spec Table 11-22
[12:49] <fabbione> #define USB_PORT_STAT_C_OVERCURRENT     0x0008
[12:49] <fabbione> ok.. who has these specs?
[12:50] <fabbione> that happens in a loop that verify the usb port status changes....
[12:50] <lifeless> fabbione: is uhci usb 2 ?
[12:51] <Mithrandir> fabbione: http://www.usb.org/developers/docs/usb_20.zip
[12:51] <fabbione> lifeless: nope.. usb1
[12:51] <lifeless> cause this laptop is meant to be usb2.
[12:51] <fabbione> lifeless: well please can you try usb1 in the meanwhile?
[12:52] <lifeless> fabbione: I'm just exploring the problem
[12:52] <fabbione> hey.. the usb specs are only 10MB compressed!
[12:52] <lifeless> as I said, uhci worked fine.
[12:52] <abelli> if gnome-volume-manager, should i check if my user is in the "plugdev" group?
[12:52] <fabbione> lifeless: ok.. than the driver is buggy as much as all the USB subsystem
[12:52] <abelli> fabbione: you should see the hardware ones :)
[12:53] <lifeless> fabbione: so, it sees the new device with ehci, but doesn't invoke the other stuff
[12:53] <abelli> i think i missed "doesnt automount usb things" :)
[12:53] <fabbione> abelli: nothing like that..
[12:53] <abelli> fabbione: because in users ive been suggested to do so..
[12:53] <abelli> fabbione: what should i do?
[12:56] <Mithrandir> 11.24.2.7.2.4 C_PORT_OVER-CURRENT
[12:56] <Mithrandir>    This bit is set when the PORT_OVER_CURRENT bit changes from zero to one or from one to zero. This
[12:56] <Mithrandir>    bit is also set if the port is placed in the Powered-off state due to an over-current condition on another port.
[12:56] <Mithrandir>    This bit will be cleared when the port is in the Not Configured state or by a
[12:56] <Mithrandir>    ClearPortFeature(C_PORT_OVER_CURRENT) request.
[12:56] <fabbione> abelli: pay us a few liters of beer?
[12:56] <abelli> fabbione: obviously
[12:56] <abelli> yes
[12:56] <abelli> ...italian discount beer.
[12:56] <fabbione> Mithrandir: yes.. i am reading.. that looks pretty much an hardware problem.. 
[12:57] <Mithrandir> fabbione: I hate you. ;)
[12:57] <Mithrandir> fabbione: I might need to whack the board, then
[12:57] <fabbione> YES YES YES I WIN YES YES!!!!!
[12:58] <Mithrandir> especially given that I don't see the error on another card of the same kind.
[12:58] <fabbione> my profecy that all the hardware that the kernel doesn't handle is BROKEN
[12:58] <Mithrandir> s/card/board/
[12:58] <fabbione> Mithrandir: mostlikely a shortcut?
[12:58] <fabbione> or something like that could cause that situation
[12:59] <Mithrandir> fabbione: not sure; the board is nice and stable.
[12:59] <fabbione> Mithrandir: a shortcut on one of the usb ports
[12:59] <fabbione> doesn't need to be everywhere
[12:59] <fabbione> what happens if you downgrade the kernel?
[12:59] <fabbione> or is it something completely new?
[12:59] <Mithrandir> seems like something was fixed in the kernel wrt my IDE controller as well, since I've stopped getting errors about DMA shit.
[12:59] <Mithrandir> fabbione: it's not new, but I don't see it with the live CD.
[01:00] <Kamion> getopt(1) is the best thing ever
[01:00] <fabbione> Mithrandir: the livecd had some issues with USB due to other reasons.. not sure which version you tested
[01:00] <fabbione> Kamion: i did upload a kernel for you
[01:00] <Mithrandir> fabbione: the one on archive.u.c about three hours ago.
[01:00] <Kamion> fabbione: I know, in the middle of the test cycle now
[01:01] <Kamion> got distracted by shiny new shell constructs
[01:01] <abelli> fabbione: real ale? is it ok?
[01:01] <fabbione> lifeless: i am trying to see if there is something mentioned anywhere in bk (other than pulling the entire new USB sybsystem)
[01:01] <fabbione> Kamion: roger :)
[01:01] <Kamion> real ale++
[01:01] <lifeless> fabbione: thanks! If I can provide any diagnostics, let me know
[01:01] <Kamion> fabbione: (unless you uploaded a new one since 10:59?)
[01:01] <fabbione> abelli: you can survive with it
[01:01] <fabbione> Kamion: it's a -10
[01:02] <fabbione> it's that one..
[01:03] <abelli> fabbione: long island?
[01:03] <fabbione> lifeless: i will....
[01:04] <fabbione> abelli: nah...
[01:04] <abelli> fabbione: please... 
[01:05] <fabbione> abelli: i am lost.. we were talking about beer.. and now you come up with a cocktail...
[01:05] <abelli> fabbione: martini... george... sambuca... limoncino... peroni... stella artois... :)
[01:05] <fabbione> nahhh that's for kids
[01:05] <abelli> im sorry i dont drink beer..
[01:06] <Mithrandir> abelli: what did you really ask about before you started offering us alcohol? :)
[01:06] <fabbione> abelli: 70% campari + 30% dry gin on ice
[01:06] <fabbione> one slice of lemon...
[01:06] <fabbione> or beer and whisky....
[01:06] <fabbione> it takes too long to get drunk with long island
[01:06] <abelli> Mithrandir: gnome-volume-manager doesnt automount usb dings on my laptop, what should i do
[01:07] <abelli> beer and whisky?!?
[01:07] <fabbione> abelli: the answer to that doesn't change...
[01:07] <fabbione> still pay us beer to know the solution
[01:07] <abelli> i will..
[01:07] <fabbione> abelli: yes.. beer and whisky
[01:07] <Mithrandir> fabbione: it does _not take long_ to get drunk on LIIT.
[01:07] <fabbione> LIIT?
[01:08] <abelli> fabbione: #define litres ?howmany?
[01:08] <thom> long island iced tea
[01:08] <abelli> thom: yeah mate
[01:08] <thom> fabbione: ^
[01:08] <Mithrandir> abelli: and your user is member of plugdev?  does pmount /dev/sda1 work?
[01:08] <fabbione> thom: gotcha.. but i still prefer other stuff
[01:08] <thom> sure, i was just expanding the acronym :P
[01:20] <fabbione> Mithrandir: the funny thing is that it looks fb related
[01:21] <fabbione> and i don't have fb here of anykind
[01:21] <fabbione> i am on console :-)
[01:21] <Mithrandir> fabbione: weird; what does the problem look like?
[01:21] <Mithrandir> kernel stufF?
[01:21] <Mithrandir> s/F/f/
[01:21] <fabbione> Mithrandir: accoding to jdub it fails to configure the fb and d-i starts looping
[01:21] <fabbione> but there are no sparc changes between the 2 kernels in ubuntu5 and ubuntu6
[01:22] <Mithrandir> huh
[01:22] <fabbione> Kamion: strace for sparc has been accepted.. it should be on the mirror pretty soon
[01:26] <smurfix> Kamion: got time for a few not-quite-trivial "need to extend cdebconf" questions, or should I take them to mail?
[01:38] <Kamion> smurfix: go ahead
[01:38] <Kamion> fabbione: still segfaults
[01:39] <pitti> mvo_: ping
[01:39] <pitti> mvo_: (no security, so don't flee :-) )
[01:39] <ogra> hehe
[01:39] <mvo_> pitti: pong
[01:39] <smurfix> Kamion: basically what I need to do is to ask the user to press a key, and get the resulting keycode back.
[01:40] <pitti> mvo_: you are doing the upgrade hooks, right?
[01:40] <mvo_> pitti: yep
[01:40] <smurfix> Kamion: either that, or interpret a whole list of such questions entirely within cdebconf
[01:40] <pitti> mvo_: can these somehow take care of installing the language packs?
[01:40] <pitti> mvo_: so, isntall all langpacks for current /etc/locale.gen
[01:40] <Kamion> fabbione: hm, damnit, not sure I have the right kernel installed actually
[01:40] <Kamion> smurfix: oh, gar, that non-debconfy thing
[01:41] <mvo_> pitti: a hook is basicly a information message + a optional script that the use can run (if he want). don't know if that suits your needs
[01:41] <mvo_> it's kind of per-use-debconf question with script runing in the desktop context 
[01:41] <mvo_> (and as the user itself)
[01:41] <Kamion> smurfix: the only sane way I can see to do that is with a custom widget
[01:41] <pitti> hmm, I think I rather need some system-level hook
[01:41] <Kamion> smurfix: but we don't have those yet
[01:42] <pitti> mvo_: any idea how/where we could do that?
[01:42] <mvo_> what do you need exactly? after a warty-hoary update install all language packs that are in /etc/locale.gen?
[01:42] <Kamion> smurfix: if I were you I'd implement an extra question type in debconf called "detect-keyboard" or whatever you want to call it, and implement support for asking that question type in the newt frontend
[01:43] <Kamion> er, s/debconf/cdebconf/
[01:43] <Kamion> smurfix: it'll have to be done again for gtk anyway
[01:43] <Kamion> smurfix: the value of that question on return should be just the keyboard type, not keycodes or anything
[01:43] <Kamion> that way it can be preseeded
[01:45] <pitti> mvo_: exactly that
[01:45] <smurfix> Kamion: Makes sense. Interpreting the mini-script I'm generating doesn't take much code
[01:45] <pitti> mvo_: and probbaly install language-support-$(default locale language)
[01:46] <Kamion> it'll have to be C, we don't have bindings to allow cdebconf widgets to be implemented in other languages yet
[01:47] <smurfix> Kamion: Didn't think I could use Python at netinstall time anyway ;-)
[01:47] <mvo_> pitti: tricky ... it could be done with the upgrade hook. tell the user about the language packs and ask if he wants to run a script that detects and installs it for them. the script can be a nice zenity dialog thing (or even python) that calls gksudo synaptic at the ends and feeds some packages into it
[01:48] <smurfix> Kamion: What happens if a frontend doesn't implement that kind of question?
[01:48] <pitti> mvo_: hmm, maybe just "gksudo apt-get install language-pack-* language-support-*"?
[01:48] <pitti> mvo_: however, if the upgrading involves calling synaptic anyway, then just markign the packages as to-be-installed is better
[01:49] <mvo_> pitti: sure, fair enough. you know that I'm biased about the front-end to use ;)
[01:49] <fabbione> Kamion: linux-image-2.6.10-2-amd64-generic_2.6.10-10_amd64.deb
[01:50] <pitti> mvo_: as long as it happens somehow, I don't care too much, too :-)
[01:50] <Kamion> smurfix: erm ... reading the code, I think it'll be silently ignored. This is probably a cdebconf bug.
[01:50] <Kamion> (feel free to send a patch for that one)
[01:51] <Kamion> fabbione: yeah, I'd just installed -11 by accident; downgrading now
[01:52] <Kamion> fabbione: (bearing in mind that I'm now not 100% sure that my previous test was valid)
[01:52] <fabbione> Kamion: argh...
[01:52] <fabbione> ok
[01:52] <fabbione> no big deal...
[01:53] <fabbione> this one incorporates old change + another one
[01:53] <fabbione> so if this still fails, the previous would have failed too
[01:58] <mvo_> pitti: is it correct that this script is about the warty-hoary upgrade?
[01:58] <pitti> mvo_: yes
[01:58] <pitti> mvo_: "this script" does not yet exist, however
[01:59] <mvo_> pitti: this is a problem then because a user upgrading from warty to hoary will not have update-notifier in it's session and there is no way (in gnome) to automatically add it to his session. so it will probably not run (only if the user starts it by hand)
[01:59] <pitti> mvo_: hmm, right
[02:00] <pitti> mvo_: OTOH we don't need this script any more for Hoary->Bendy
[02:00] <mvo_> yes ..
[02:00] <abelli> bon jour
[02:00] <pitti> mvo_: The brute approach would be to add yet another language-pack-meta package
[02:00] <pitti> mvo_: this package would install the actually required packs
[02:01] <pitti> mvo_: and ubuntu-desktop (or -base) would depend on l-p-meta
[02:01] <Kamion> uh
[02:01] <pitti> mvo_: the only question is how l-p-meta shall trigger the installation
[02:01] <Kamion> that breaks fresh installations
[02:01] <pitti> because callign apt in l-p-meta's postinst is out of question
[02:01] <pitti> Kamion: why?
[02:02] <Kamion> oh, um
[02:02] <pitti> or even better,
[02:02] <Kamion> I think I see - but I don't think this approach will work
[02:02] <pitti> Kamion, mvo_: could this be integrated into ubuntu-base/desktop directly?
[02:02] <Kamion> we need a script to do upgrade tasks anyway
[02:02] <Kamion> let's not, please
[02:02] <pitti> okay
[02:02] <Kamion> it doesn't belong there
[02:02] <mvo_> Kamion: what kind of stuff will this script do?
[02:02] <pitti> Kamion: if we already have a system-level upgrade script, then it can just be added there
[02:02] <Kamion> an upgrade script has been on the wishlist for a while - I don't think it should be crowbarred into ubuntu-meta though
[02:02] <HrdwrBoB> I think there are old debian 2.4 kernel packages in universe
[02:03] <HrdwrBoB> can they be removed?
[02:03] <pitti> Kamion: the only requirement is that this script is not called (transitively) from apt/dpkg
[02:03] <Kamion> mvo_: not sure :-)
[02:03] <Kamion> pitti: yes, it has to be post-upgrade, same kind of thing as base-config
[02:03] <mvo_> so we need upgrade-config :) ?
[02:03] <Kamion> I actually said once that it should be part of base-config, although I'm not sure about that
[02:03] <azeem> are universe packages still getting autobuilt when new versions in unstable appear?
[02:03] <Kamion> well, maybe 'base-config upgrade'
[02:04] <Kamion> azeem: no, that stopped at upstream version freeze
[02:04] <elmo> boggle, WTF is oidentd doing with the gateway ip
[02:04] <azeem> Kamion: ah, thought that was only for new upstream revisions, not new debian revisions
[02:05] <fabbione> elmo: iirc the client ip is embedded in the answer...
[02:05] <fabbione> so it needs to know to be able to answer properly
[02:05] <Kamion> azeem: new Debian revisions are allowed but you'd have to request them manually
[02:05] <azeem> Kamion: ok. To MOTU I assume
[02:07] <elmo> actually, probably to me, Cc'ed to MOTU
[02:07] <elmo> at least that's how we do main
[02:07] <azeem> ok. I have to check whether there was a new binary package added first, though (changelog is unconclusive)
[02:08] <elmo> jdub: ?
[02:16] <Kamion> does anyone object to passwd's root password question being put back at medium priority? I need it to be there for part of kickstart emulation
[02:17] <Kamion> it still won't be asked in default installations, only in expert mode
[02:17] <sladen_> thom: yes, the Eric bloke is on crack.  -centrino is failing to load because of a broken DSDT;  -acpi for probably the same reason;  -smi will work for lots more machines since it's in the BIOS in alot.  It's not the CPU detection in this case, but the machine detection
[02:17] <fabbione> Kamion: go ahead
[02:18] <Kamion> and actually even then only if you've preseeded base-config/priority=medium or below
[02:18] <Kamion> I think
[02:18] <Mithrandir> Kamion: keyboard selection (at least in the live cd) is on serious crack.  I only get mac-usb-* keyboards if I have an usb keyboard.
[02:18] <sladen> Kamion: if you're 'emulating kickstart', does that mean that you don't want to setup sudo aswell?
[02:18] <fabbione> Kamion: go and break the hell! we are still in time to do that :)
[02:19] <elmo> and OMG pidentd is a 50Mb Virtual process
[02:19] <Kamion> Mithrandir: can you clarify?
[02:19] <Kamion> sladen: not sure; I'll probably disable sudo by default if a root password is set
[02:19] <fabbione> elmo: use oidentd.. afaik is one of the best around (and it supports ipv6)
[02:19] <Kamion> or not do the "add initial user to /etc/sudoers" thing, anyway
[02:20] <Mithrandir> Kamion: I'm on an amd64 system with an usb keyboard, booting the live cd.  I get asked about language (norwegian), then keyboard and the choices don't include any norwegian ones.  And they are all called mac-usb-*
[02:20] <fabbione> pitti: ping
[02:20] <elmo> fabbione: it's masquerade by default crack scares me
[02:20] <pitti> fabbione: pong
[02:20] <fabbione> elmo: nah.. it's ok..
[02:21] <sladen> Kamion: I suppose it depends whether you are trying to emulate Red Hat, or provide the best /Ubuntu/ system possible
[02:22] <Kamion> Mithrandir: keyboard types vs. keymap names are very confusing; the actual names of the keymaps are best ignored ...
[02:22] <Kamion> Mithrandir: I don't know why you aren't seeing the translations though
[02:22] <Kamion> Mithrandir: what language/country did you select?
[02:22] <Kamion> (the translations of the keymap names, I mean)
[02:23] <Kamion>          * It was a mistake to tie "keymaps" to "architectures": all the keymaps
[02:23] <Kamion>          * in console-keymaps-usb are Mac-specific (at the moment); "PC" USB keyboards
[02:23] <Kamion>          * all use standard "AT" keymaps. But its too close to sarge release to change design,
[02:23] <Kamion>          * so we go with the following hack:
[02:23] <Mithrandir> Kamion: Norwegian
[02:23] <Kamion> oh, damnit, kbd-chooser tests for i386
[02:23] <Kamion> it needs to test for amd64 too
[02:23] <Mithrandir> ok :)
[02:23] <Mithrandir> care to fix, or do you want a bug?
[02:24] <Kamion> I'll just fix it
[02:24] <Mithrandir> thanks
[02:24] <Kamion> Mithrandir: is __x86_64__ or __amd64__ preferred?
[02:25] <Mithrandir> C code?  __amd64__, I think.
[02:25] <Kamion> ok
[02:26] <elmo> really?
[02:26] <Mithrandir> I think so, yes.
[02:29] <Kamion> Mithrandir: 1.09ubuntu4 uploaded; let me know if it works and I'll check it in upstream
[02:29] <Kamion> my amd64 doesn't have a USB keyboard so it's hard to test
[02:29] <Mithrandir> Kamion: ack.  Tomorrow's live cd should be ok?
[02:33] <Kamion> Mithrandir: kbd-chooser's in the initrd, might take 'til Thursday
[02:33] <thom> sladen: care to say that in the bug ? :-)
[02:34] <Mithrandir> Kamion: 'k
[02:36] <sladen> thom: I might miss the bit about crack out
[02:37] <smurfix> Kamion: DC_NOTIMPL patch to cdebconf: mailed to you.
[02:39] <sladen> thom: renaming -centrino to -speedstep2 would avoid a couple of these.
[02:40] <Kamion> smurfix: thanks
[02:41] <smurfix> Kamion: Don't thank me until you've checked that it works ;-)
[02:44] <thom> sladen: yeah
[02:50] <daniels> Kamion: ping
[02:54] <Kamion> daniels: pong
[02:54] <seb128>   File "/usr/share/dput/ftp.py", line 59, in upload
[02:54] <seb128>     if e.args and e.args[0] [:1] =='5':
[02:54] <seb128> TypeError: unsubscriptable object
[02:55] <seb128> I've to reupload 20M on my 128k upload, nice
[02:57] <daniels> seb128: mmm :\
[02:57] <jordi> seb128: heh
[03:02] <Kamion> this is a much neater patch to shadow than before; I think it must be good, on the elegant==right metric
[03:07] <i810> ouch
[03:07] <daniels> dude, if you want to voluntarily put yourself in as an i810, you'll get a neat torrent of abuse
[03:07] <daniels> including something involving the words 'Flatley'
[03:08] <daniels> so, right now, don't :)
[03:08] <Kamion> heh
[03:08] <Kamion> I'll have some neat whisky instead, thanks
[03:08] <daniels> it seems that mode validation is totally shot on i810 because the monitor sync ranges aren't getting propagated from DDC
[03:13] <daniels> (WW) I810(0): Extended BIOS function 0x5f05 failed.
[03:13] <daniels> (WW) I810(0): Failed to set refresh rate to 52Hz.
[03:13] <daniels> i think stratus would've been deeply unhappy with 1024x768 anyway
[03:14] <Mithrandir> Kamion: locales just configures UTF8 locales, it doesn't actually change anything so they are used, right?
[03:14] <Kamion> Mithrandir: correct
[03:16] <Kamion> Mithrandir: that might even be better, kill the /etc/environment brain-damage ...
[03:16] <Kamion> Mithrandir: you could implement a per-user equivalent of /etc/environment
[03:16] <Mithrandir> I'm already using ~/.environment for loads of stuff, so that's not a good name, though
[03:17] <Mithrandir> I need to look at where gdm stores the setting.
[03:17] <Kamion> I moved that to ~/.bash_environment when I heard ~/.environment being suggested for that purpose
[03:18] <Mithrandir> if so, it should be ~/.shell_environment as I use it for both bash and zsh
[03:18] <Mithrandir> but yes, that might be an idea.
[03:18] <wasabi> I like /etc/environment
[03:18] <wasabi> I mean, I dislike it... but I like it because some third party programs suck and need env settings. =/
[03:18] <wasabi> and i can't think of a better way
[03:18] <Kamion> wasabi: regardless, it's wrong for this purpose because it has to be per-user
[03:18] <wasabi> Kamion, not specifically. It could be both. It's very nice to be able to deploy, JAVA_HOME, for instance.
[03:19] <wasabi> For all the PCs in the office.
[03:19] <Kamion> wasabi: this purpose == UTF-8 migration tool.
[03:19] <smurfix> Anybody know if elmo'll be back today?
[03:19] <Kamion> you can't migrate all users at once because migrating to UTF-8 involves recoding filenames etc.
[03:19] <thom> smurfix: should be
[03:19] <wasabi> hmm.
[03:19] <ogra> is anybody else facing a weird font encodig change on amd64 after a while in X ?
[03:20] <Kamion> argh no
[03:20] <wasabi> gento does env.d
[03:20] <Kamion> then packages will be tempted to drop things in there
[03:20] <Kamion> then we have EVIL
[03:20] <wasabi> Yeah.
[03:20] <wasabi> Packages shouldn't require env settings. Only admins do. =)
[03:20] <Kamion> anyway this is http://www.ubuntulinux.org/wiki/UTFEightMigrationTool
[03:21] <wasabi> Hmmm
[03:22] <wasabi> I like the idea. Sounds hard to implement. ;)
[03:22] <wasabi> Also would be a bit concerned about NFS mounted ~.
[03:23] <Kamion> likewise, but that's why it's not a fully automatic transition; the user gets to say "aargh, no, leave my stuff alone"
[03:23] <wasabi> The admin needs to be able to say that too.
[03:24] <wasabi> So he can do it all at once on a network drive.
[03:24] <wasabi> Or you could just leave ~ alone, and leave the default locale set forever. ;)
[03:24] <Kamion> the admin could zap the update hook registrations ...
[03:24] <Kamion> leave ~ alone> that's what'll happen unless you do the migration task
[03:25] <wasabi> The user will log in. Some dialog will pop up. That dialog needs to be supressable in some fashion. I don't want to confront my users with that.
[03:25] <Kamion> I think the UI is that an icon appears discreetly on your panel saying "you should probably do this at some point"
[03:25] <Kamion> not a dialog
[03:26] <Kamion> anyway this is mvo/Mithrandir's task, not sure why I'm debating it ... :)
[03:26] <wasabi> Well, whatever. You get my drift? My users would go ape shit with that. I'd be flooded with help desk calls. ;)
[03:26] <wasabi> Oh. heh.
[03:26] <Mithrandir> Kamion: I can't get rid of the locale in /etc/environment, actually.  But we could stop installing it if we have /etc/skel/.environment which is created by base-config (or locales?)
[03:26] <Kamion> yeah, I know, I'd be amazed if there wasn't a way to suppress it though so I'm not that worried :)
[03:27] <Kamion> Mithrandir: I didn't mean getting rid of the locale there so much as getting rid of the meme that /etc/environment is the place to put all your custom environment variables
[03:27] <Kamion> it's as bad as autoexec.bat :P
[03:27] <Mithrandir> Kamion: oh, yeah, I agree.
[03:27] <wasabi> Hmm. MS fixed autoexec.bat by just leaving it there and making sure nobody NEEDED to use it. ;)
[03:28] <Kamion> indeed, that's the right answer ...
[03:28] <wasabi> They provided a UI for setting global env vars haha.
[03:30] <sivang> pitti: server problems?
[03:30] <Kamion> erm, yes, well.
[03:30] <sivang> pitti: (Morning ;-)
[03:30] <pitti> sivang: I currently experinemt with port forwarding
[03:30] <sivang> pitti: ah, from where to where?
[03:30] <wasabi> That sounds like a good GTK project for somebody to do (like me) to get their heads around writting simple gtk utilities.
[03:31] <sivang> pitti: my session got killed on the server last night, was it experiencing problems?
[03:31] <pitti> sivang: I replaced my dircproxy on my server with iptables SNAT/DNAT
[03:31] <sivang> pitti: eh cool
[03:31] <daniels> bychristfontstakealongtimetobuildevenonadecentmachine
[03:32] <stratus> daniels, huh?
[03:32] <stratus> daniels, wtf with the bios ?
[03:32] <daniels> stratus: the reason I'm building X right now is to try to track down your problem :P
[03:32] <pitti> sivang: as I said, I had to reboot due to a kernel upgrade
[03:32] <daniels> stratus: unfortunately i8xx desktop chipsets are one of the few things I don't have
[03:33] <wasabi> Hmm. ~/.environment is going to require modifying pam_env.
[03:33] <daniels> i'm trying to borrow one for a couple of days, but I think I know where the problem is, and I'm building a debug i810/i830 driver for you now so I can get more information
[03:33] <sivang> pitti: not a problem, I just wish my irssi would also log the away log, which it didn't to some strange reason.., and logged everything else :)
[03:33] <Mithrandir> wasabi: correct
[03:33] <stratus> daniels, i'll lunch now but in a hour i can download your build and test it with you.
[03:33] <daniels> ok
[03:33] <stratus> daniels, thanks i'll be back in a hour.
[03:38] <Kamion> Mithrandir: if you do do ~/.environment, I think it would be worth having a special marker to distinguish it from other random dotfiles people might have by that name
[03:38] <Mithrandir> Kamion: ~/.pam_environment might be better
[03:39] <Kamion> yeah
[03:39] <Mithrandir> I imagine I'm not the first person who has ~/.environment and confusing all those is kinda bad.
[03:40] <Treenaks> ~/.environment.d !
[03:49] <Mithrandir> I think implementing support for both system-wide conversion by the admin and per-user conversion makes sense.
[03:50] <Mithrandir> mvo_: how would something like that fit into the hooks?
[03:51] <mvo_> Mithrandir: the hook script runs as the user. you could asks a question about system-wide stuff and use gksudo in the script
[03:52] <Mithrandir> mvo_: how would I then mark the user as run for the other users?
[03:53] <mvo_> Mithrandir: hmmm ... tricky as the hooks are strictly per-user now
[03:53] <Mithrandir> mvo_: yes, but if a system-wide migration has been performed, it doesn't make sense to do a per-user as well
[03:53] <Mithrandir> and I think having support for doing it system-wide makes sense.
[03:55] <mvo_> I agree. a generic solution might be to have a addtion stamp-file/flag that magically marks a hook as completted for all users
[03:55] <Mithrandir> can you whip something up?  :)
[03:55] <mvo_> this involes gksudo because it needs to be writen in a update-notifier controlled directoy
[03:56] <Mithrandir> yeah, but that's ok, since you can't do system-wide stuff without being root
[03:58] <mvo_> ok, here is a simple one :) what about just moving the hook file into /var/lib/update-notifier/user.d/completed/ once it's no longer usefull (or remove it complettly)? no more magic needed ;)
[03:58] <Mithrandir> it'll confuse dpkg
[03:59] <Mithrandir> but I guess that's doable, yes.
[03:59] <mvo_> anything we can do about dpkg?
[04:00] <Mithrandir> I can put the file there with the postinst, or let it be a symlink or something
[04:01] <mvo_> ok. so I need to add a /var/lib/update-notifier/user.d/completed/  directory? or will you just delete the hook afterwards?
[04:02] <mvo_> do you need additonal support? like calling the script with the name of the hook-file as first argument (so that you always know what hook called the script)
[04:03] <Mithrandir> nah, it'll ask by itself, I think
[04:03] <Mithrandir> I don't think I need any extra support
[04:03] <mvo_> ok, thanks
[04:13] <daniels> stratus: please grab http://people.ubuntu.com/~daniels/i810_drv.o, put it in /usr/X11R6/lib/modules/drivers/, start xorg with sudo Xorg :1 -ac -logverbose 99999 (and then kill it) and send me /var/log/Xorg.1.log
[04:13] <Mitario> hi guys
[04:32] <stratus> daniels, fetching the driver...
[04:34] <daniels> stratus: cool
[04:34] <stratus> let's do it.
[04:36] <stratus> i like all that verbosity, i'll send the output to you now...
[04:37] <daniels> thanks a heap
[04:39] <lamont> good morning all
[04:39] <Mithrandir> lamont: AMD64 daily works mostly.
[04:40] <fabbione> hey lamont 
[04:40] <stratus> daniels, mail sent.
[04:40] <daniels> stratus: rad
[04:40] <sladen> thom: just looked at the cpuinfo, same as Kinni's desktop box.  No 'est' (enhanced speedstep) flag....
[04:40] <stratus> daniels, :)
[04:40] <lamont> Mithrandir: it should - turns out partimage refuses to run there, so it's dropped.
[04:41] <lamont> Mithrandir: you still get rsync-able images, but they'll continue to grow until we flush them
[04:41] <Mithrandir> lamont: hm, ok
[04:41] <Mithrandir> lamont: it sucks in a bunch of places, but not really related to amd64.
[04:42] <lamont> (partimage is used on i386/ppc to zero out the unused blocks of the livecd rootfs....)
[04:42] <Mithrandir> ok, so it should work still?
[04:42] <Mithrandir> that is, it's not a useless test?
[04:43] <Mithrandir> I burn to DVDs, so size isn't a problem
[04:45] <lamont> should work still
[04:45] <stratus> daniels, it's trying to set refresh rate to 52hz and fails, it seems to be using 43hz, but before this set we've
[04:45] <stratus> daniels, [...]  Not using mode "1024x768" [...] 
[04:46] <lamont> the amount of growth in the image size is still limited to new blocks, but we don't get to delete all the old blocks.  So your rsync's should be about the same as i386, but we'll need to watch the image and see when we cause you to take a hit and re-download the whole image, just to get it back down to ~525MB of rootfs.
[04:46] <stratus> daniels, line 1908 (not using mode) and line 2252 (refresh rate to 43hz)
[05:06] <daniels> the 80mhz pixel clock thing seems weird
[05:06] <daniels> to debug this further i'll need to give you a new xorg binary
[05:06] <daniels> but i need to sleep first
[05:07] <stratus> daniels, np i'll wait for the new xorg let me know.
[05:07] <daniels> ok, will do, thanks
[05:08] <stratus> daniels, good sleep it's still 14pm here.
[05:08] <stratus> s/14/2/
[05:33] <seb128> grrrrr
[05:33] <seb128> eds and evo need to be uploaded together, eds need to build first, so there is like 1 hour of unstable situation
[05:34] <seb128> and some people send bugs during this hour saying that evolution is broken, grrrrr
[05:34] <seb128> that's a devel branch!!
[05:34] <opi> hehe
[05:34] <opi> my Evolution just died
[05:34] <opi> :)
[05:35] <opi> crash everytime
[05:35] <seb128> good one
[05:35] <seb128> very funny :p
[05:35] <opi> really
[05:35] <opi> ;p
[05:36] <seb128> really ?
[05:36] <opi> I've cliked a ,,work offline'' and since then all I see is ,,aplication crashed''
[05:36] <seb128> what version ?
[05:36] <opi> I was browsing around to look for some kind of lock
[05:36] <opi> 2.2
[05:36] <opi> morning update
[05:36] <opi> I see there's a new one in queue
[05:37] <opi> I'll apt-get it and raport back
[05:37] <seb128> 2.2 is not released
[05:37] <seb128> 2.1.3.2 or 2.1.4 in hoary
[05:37] <opi> hum
[05:37] <opi> emil@rude:~ $ ls -l /usr/bin/evolution-2.2
[05:37] <opi> -rwxr-xr-x  1 root root 168056 2005-01-17 19:16 /usr/bin/evolution-2.2
[05:39] <lamont> squirrelmail is in main?
[05:39] <opi> haha
[05:39] <opi> :)
[05:40] <opi> not on the floor, I've just polished it
[05:40] <seb128> opi: that's a name, not a version
[05:40] <opi> seb128, so it should have different name :)
[05:40] <opi> becuase it's confusing
[05:40] <opi> wait, I'm dist-upgrading
[05:40] <seb128> opi: that's stupid to change the name between 2.1 and 2.2
[05:40] <seb128> opi: the stable release will be 2.2
[05:40] <lamont> opi: no, it should have the name it will have when it releases
[05:40] <opi> +'t
[05:41] <opi> it shouldn't
[05:41] <seb128> ?
[05:41] <opi> bah, ignore me for a second :)
[05:41] <opi> my boss was talking to me
[05:41] <seb128> :)
[05:42] <opi> I hope Evolution won't die on me
[05:42] <lamont> opi: in that case, why are you running hoary? :-)
[05:42] <opi> who's in charge of Pyton addons
[05:43] <opi> lamont, I can't snowboard or skydive
[05:43] <opi> lamont, I need a risky hobby :>
[05:43] <lamont> opi: so accept that lots of things are in pre-release status, like evo-2.2
[05:44] <opi> I accept that
[05:44] <opi> I'm running it, to help you guys develop it
[05:44] <lamont> so it needs to be called evolution-2.2, so as to not introudce major file-name changes right before release.
[05:45] <opi> Version: 2.1.4-0ubuntu1 fixed my issue
[05:47] <crimsun> jdub: I apologize if I'm pinging the wrong person, but why does polypaudio default to module-oss in /etc/polypaudio/default.pa?
[06:00] <shaya> anyone using the new evolution?
[06:00] <shaya> it's severely screwed up IMAP
[06:00] <tseng> it seems to have switched to the new rev1 plugin by default
[06:01] <shaya> and the old one isn't available
[06:02] <shaya> build a new evo with the old imap :)
[06:03] <seb128> don't use hoary if you don't want to use devel branch
[06:03] <shaya> also doesn't do threading anymore
[06:03] <seb128> I know
[06:03] <shaya> also cant find my inbox on a wu imap server
[06:04] <seb128> that's not cool ...
[06:04] <opi> ups..
[06:04] <shaya> works fine for that on a dovcot imap server
[06:04] <shaya> but on the dovecot, seems to only allow one level of directories
[06:05] <tseng> thats false
[06:05] <shaya> took out my mail/sent/ directory and mae it sent/
[06:05] <tseng> i have dovecot
[06:05] <shaya> I said it works for me on dovecot inbox
[06:05] <tseng> how do your dirs look in the maildir
[06:05] <ogra> tseng: why are you not on the CC agenda ? to become a MOTU ?
[06:05] <shaya> tseng: i'll msg it to you
[06:05] <tseng> ogra: i didnt apply yet, i said i need to reread the docs a bit
[06:06] <tseng> shaya: ok
[06:06] <shaya> it's .mailboxlist for me it seems
[06:06] <ogra> tseng: heh, since your packages already get uploaded,i think its only some bureocracy thingie
[06:06] <shaya> actually, it's .subscriptios
[06:06] <shaya> .subscriptions
[06:06] <tseng> well, subdirs in maildir need to look like .ubuntu.hoary-changes
[06:07] <tseng> where hoary-changes is a subdir of ubuntu
[06:07] <tseng> not like dir1/dir2
[06:08] <tseng> yes, it shouldnt look like that shaya 
[06:08] <tseng> .maildir/.folder/{cur,new,tmp}
[06:08] <tseng> .maildir/.folder.subfolder/{cur,new,tmp}
[06:08] <tseng> follow?
[06:08] <shaya> I dont use maildir
[06:09] <shaya> these are mbox's
[06:09] <tseng> then what are you using that has folders..
[06:09] <shaya> just regular file system
[06:09] <shaya> always used to work before
[06:09] <tseng> erm.. i had no idea you could have dirs of mboxes
[06:09] <shaya> always worked before
[06:09] <shaya> outlook express, outlook, mozilla mail, thunderbird, evo since 1.0
[06:21] <tseng> ogra: yeah.. im not as comfortable with the tools and policies as I'd like to be
[06:21] <tseng> ogra: i definately intend to apply, however.
[06:22] <ogra> so go on, we need manpower ;)
[06:33] <pitti> anybody here who could look up something for me on ia64?
[06:37] <mdz> pitti: look up what?
[06:38] <pitti> mdz: dpkg -s locales | grep ^Depends:
[06:39] <elmo> pitti: halley is a porting box
[06:39] <mdz> pitti: locales is arch: all
[06:39] <pitti> oh, right
[06:40] <pitti> Depends: glibc-2.3.2.ds1-20ubuntu3
[06:40] <pitti>         ^^^
[06:40] <pitti> this somehow looks very odd
[06:40] <mdz> it's provided by libcX.Y on each architecture
[06:40] <mdz> since the package has different names
[06:40] <pitti> but if that really does depend on a particular glibc version, then it is the very thing I need
[06:40] <jbailey> pitti: We do this for localesm, etc.
[06:40] <pitti> mdz: great!
[06:41] <jbailey> pitti: The better solution would be versioned provides/depends, but ah well. =)
[06:41] <pitti> mdz: this morning I discussed with Kamion about doing some dynamic dependency generation in debian/rules according to the architecture
[06:41] <pitti> but with this my job gets much easier :-)
[06:42] <Kamion> pitti: it's not a good idea to use that!
[06:42] <Kamion> pitti: that doesn't give you >= dependencies, only exact-version dependencies
[06:42] <pitti> Kamion: I need to depend on locales >= 2.3.2.ds1-20ubuntu3
[06:42] <Kamion> pitti: nothing outside the glibc source package should be using those provides AFAIK
[06:42] <pitti> Kamion: but since locales already depend on a newer glibc, I don't need the libc6 dependency at all any more
[06:43] <pitti> Kamion: that's what I mean by easy :-)
[06:43] <Kamion> oh, ok
[06:43] <Kamion> yeah, that's fine, sorry, just panicked for a second :)
[06:43] <pitti> thanks, guys, that saved some work :-)
[06:43] <Kamion> yeah, of course the dynamic dep generation wouldn't have worked for you anyway since language-pack-* are arch: all ...
[06:43] <Kamion> (d'oh)
[06:43] <pitti> hmm, right
[06:44] <pitti> Kamion: in that case I would have needed alternative deps, I guess
[06:57] <Mithrandir> jbailey: multiarch!
[06:57] <Mithrandir> root@shonap:/# ls -l /lib/libc-* /lib/ld-linux.so.2
[06:57] <Mithrandir> ls: /lib/libc-*: No such file or directory
[06:57] <Mithrandir> lrwxrwxrwx  1 root root 22 Jan 25 18:56 /lib/ld-linux.so.2 -> i386-linux/ld-2.3.2.so
[06:57] <jbailey> Mithrandir: Is this a declaration of success?
[06:57] <Mithrandir> jbailey: absolutely.
[06:58] <jbailey> Sweet. =)
[06:58] <Mithrandir> root@shonap:/# ls /lib/i386-linux/ | wc -l
[06:58] <Mithrandir> 41
[06:58] <jbailey> Now all we need to do is hit LSB  in the head with a board until they accept it. =)
[06:58] <jbailey> *nice*
[06:58] <jbailey> How invasive are the patches to the linker?
[06:59] <Mithrandir> jbailey: makefile changes only ; seven lines added to Makeconfig
[06:59] <Mithrandir> (including one comment line)
[06:59] <jbailey> !! Awesome
[06:59] <Mithrandir> T-Bone: multiarch.
[07:00] <jbailey> T-Bone: Sane co-existance of multiple architectures on a single drive.
[07:00] <Mithrandir> T-Bone: http://err.no/debian/amd64-multiarch-3 for a bit more discussion around it
[07:00] <jbailey> T-Bone: Targetted at crazy people who might want to run i386-linux, ia64-linux, hppa-linux, and i386-freebsd libraries on one box. =)
[07:00] <T-Bone> jbailey: how would they do that? :)
[07:00] <Mithrandir> jbailey: a bit bigger changes to the debian build system, but nothing really invasive.
[07:00] <T-Bone> i mean, i can imagine amd64 & i386, but the 4 of them?
[07:01] <Mithrandir> T-Bone: ia64 runs hppa and i386 natively.
[07:01] <T-Bone> doh
[07:01] <Mithrandir> T-Bone: linux doesn't support hppa yet, but that's just missing kernel support, the cpu supports it
[07:01] <T-Bone> Mithrandir: i thought the mess with ia64 was that i386 code had to be emulated?
[07:02] <jbailey> T-Bone: It's emulated in-processor, but poorly.
[07:02] <T-Bone> jbailey: ah ok so i'm not mistaken
[07:02] <jbailey> T-Bone: It can be emulated much better in software, AIUI, but then..  Why would you pay $3k for a chip to have it run ia32 binaries? =)
[07:02] <T-Bone> jbailey: and it's the same for hppa, right?
[07:02] <T-Bone> jbailey: to have something to run on it? :^)
[07:03] <T-Bone> jbailey: to play Doom3 maybe ? :)
[07:03] <jbailey> T-Bone: I don't know about hppa speed.  When I asked folks they just shuddered and said "Well, I *spose* it can do that..." =)
[07:03] <jbailey> T-Bone: I had been asking about having an hppa partition on my ia64 box to test glibc. =)
[07:03] <Mithrandir> jbailey: according to bdale, it's faster than an hppa, so.. :)
[07:03] <T-Bone> jbailey: ah ok, so we're both at the same knowledge point. I'm reassured. I thought I missed some /. headline :^)
[07:04] <jbailey> T-Bone: Nope, nope.  I get all my information from the same channel you do. ;)
[07:04] <Mithrandir> jbailey: I'm going to get a bunch of other libs up and running tomorrow, also I need to fix up pkg-config, autoconf, maybe some gcc stuff and libtool, then I can work on dpkg, apt and the packaging side of things.
[07:04] <T-Bone> Mithrandir: heh, I'd like to see that, given the ridiculous perfs of ia64 linux in general
[07:05] <T-Bone> now let's pretend lamont has fixed some instability issue on ia64 and download the last daily roll for testing purposes
[07:05] <Mithrandir> T-Bone: (bdale is CTO Linux at HP); he talked about customers upgrading their PBX-es by ripping out all the HPPA CPU modules and putting ia64 in instead.. the boxes were running HP-UX, though, not linux.
[07:05] <jbailey> Mithrandir: Nice.  You're not really targetting full mutiarch at Hoary, are you? =)
[07:05] <T-Bone> s/instability/instalability/
[07:06] <Mithrandir> jbailey: no, etch and hoary+1.
[07:06] <jbailey> Mithrandir: Oh good. =)
[07:06] <T-Bone> Mithrandir: yeah I know bdale.
[07:06] <Mithrandir> jbailey: it's my master's degree, so.
[07:06] <jbailey> Mithrandir: So I can deal with the glibc insanity in Debian next year sometime ;)
[07:06] <T-Bone> Mithrandir: if they're running hpux that's a complete different story
[07:07] <Mithrandir> jbailey: it's not really insanity, it's a neat and small patch.  (Which I imagine _will_ cause havoc all over the place, but that's a different story ;)
[07:07] <T-Bone> but i have reasons to believe that the late parisc CPU gens are still doing rather well compared to ia64. And even more when dealing with linux.
[07:07] <Mithrandir> T-Bone: I don't know ia64 at all, so I'm merely retelling what bdale has told me.
[07:08] <T-Bone> Mithrandir: hehe. Well, if bdale told you something, it outta be true ;)
[07:09] <lamont> T-Bone: you're operating under the assumption that I actually have time to _do_ something that's ia64 specific...
[07:09] <lamont> although I did fetch the install CD last night
[07:10] <T-Bone> lamont: who said i was *operating* ? :^)
[07:10] <T-Bone> lamont: i'm mostly executing random instructions :)
[07:10] <no0tic> from dmesg--> powernow: No PST tables match this cpuid (0x7a0)  I have an Athlon-XP-M 2800+ that was correcly recognized by warty kernel (correct freq & scaling)
[07:11] <T-Bone> lamont: but if you tell me what i'm supposed to look at to fix the issue I've pointed, i'll gladely use my maintainer-fu to fix it ;)
[07:11] <lamont> T-Bone: sounded like there were uninstallable packages that ubuntu-desktop depended on... those need to be made installable.. :0)
[07:12] <T-Bone> ubuntu-base actually, which is even worse
[07:12] <T-Bone> lamont: sure, how am i supposed to do that? :)
[07:12] <T-Bone> lamont: i suppose there's some file i outta change in the ISO tree?
[07:13] <lamont> generally, it's (1) figure out _why_ it's uninstallable, then (2) fix that.
[07:13] <T-Bone> lamont: in order to fix that kind of issue, is rsyncing the ISO tree enough or do i need something else?
[07:13] <no0tic> I have to file a bug for this?
[07:15] <thom> no0tic: yes please
[07:15] <Kamion> T-Bone: you may find http://people.ubuntu.com/~cjwatson/testing/hoary_probs.html helpful
[07:15] <Kamion> there's a pile of ia64 issues there for you ...
[07:15] <Kamion> ubuntu-base seems installable at the moment, though
[07:15] <lamont> T-Bone: it's frequently because something didn't build, and something else (arch all) depends on it
[07:16] <T-Bone> Kamion: the problem was:
[07:16] <T-Bone> "ubuntu-base: Depends: lsb-release but it is not going to be installed"
[07:17] <mdz> amu: ping?
[07:18] <mdz> has anyone seen amu today?
[07:18] <T-Bone> Kamion: as a matter of fact, i'd like to save time: it's counter productive to list a bug, wait for you/lamont to do whatever is need, wait for the ISO to be built, download the new ISO and fail again a few step further. I'd like to skip the "wait [...]  and download" steps, if possible, and perform them locally
[07:18] <mako> mdz: do you know if sabdfl got any thing done on the newmaintainer stuff?
[07:19] <amu> mdz: pong
[07:19] <mdz> mako: he said he had written it, and it was no good, and he rewrote it, something like that
[07:19] <mdz> amu: reportbug
[07:19] <mako> mdz: when was that?
[07:19] <mdz> mako: hmm...last thursday or so?
[07:19] <mdz> before he left
[07:19] <amu> mdz: working on it .... 
[07:19] <mdz> amu: ok, I just saw another Ubuntu bug report go to Debian
[07:19] <no0tic> for the powernow module issue, the package is powernowd or kernel?
[07:20] <mdz> no0tic: kernel ('linux' component)
[07:20] <amu> mdz: *g* 
[07:20] <no0tic> mdz: thanks
[07:20] <mdz> amu: this is serious; it is bad for the community
[07:20] <thom> mdz: um, all the other powernow module problems are against powernowd
[07:20] <mako> mdz: well, he didn't put anything in the wiki that i can find
[07:20] <thom> no0tic: tell me the bug # after you file it, please? :-)
[07:21] <mdz> thom: powernowd decides which module to load, but the driver itself is saying it doesn't support that CPU, no?
[07:21] <T-Bone> Kamion: anyway I can do that?
[07:21] <mako> mdz: hopefully there are no process conflicts or too much redundancy of work
[07:21] <mako> mdz: i'll send him a link
[07:21] <mdz> mako: ok
[07:21] <thom> mdz: yeah, but for consistency's sake we've been tracking them all under powernowd for the time being 
[07:21] <thom> not fussed if they move to the kernel
[07:21] <mdz> thom: sure, whatever works for you
[07:22] <haggai> crimsun: do you have the .orig.tar.gz for the rox diff you sent?
[07:23] <Kamion> T-Bone: you can modify packages and, if necessary, Packages and Packages.gz index files in the ISO image
[07:23] <crimsun> haggai: in hoary/universe
[07:23] <crimsun> haggai: oh sorry
[07:23] <crimsun> haggai: the rox diff needs to be rewored
[07:23] <T-Bone> Kamion: i'd need to rsync the ISO tree for that, right?
[07:23] <crimsun> reworked, rather.
[07:23] <Kamion> T-Bone: when modifying packages, change the md5sum/size/etc. in the Packages files; when modifying Packages files, change their md5sum/size in dists/hoary/Release
[07:24] <Kamion> T-Bone: loop-mount the ISO
[07:24] <Kamion> T-Bone: that lsb-release issue is odd, I don't see it here
[07:24] <haggai> crimsun: ah, thanks
[07:24] <Kamion> here> in the various reports I mean
[07:24] <crimsun> haggai: a new diff.gz this evening for rox-filer along with an upstream url for the orig.tar.gz
[07:24] <T-Bone> Kamion: i'm downloading today's iso, will see what happens.
[07:24] <no0tic> from lsmod I found powernow_k7 is not used, it's correct this behaviour?
[07:25] <T-Bone> Kamion: btw, the "built on <oddvernum>" is considered as a feature?
[07:25] <Kamion> T-Bone: but yeah, I do this sort of thing for testing very regularly, ping me if you need help with the details
[07:25] <Kamion> T-Bone: it's the version number of the debian-installer source package
[07:25] <dholbach> hai
[07:25] <crimsun> haggai: (sorry, my keyboard's eating words: that was supposed to read "I will be sending a new diff.gz ..."
[07:25] <haggai> crimsun: ok :)
[07:25] <Kamion> T-Bone: not totally sure whether it's a feature or not; it's certainly handy for tracking problems
[07:26] <crimsun> haggai: shall I CC: ogra for it?
[07:26] <Kamion> maybe the wording should simply be changed
[07:26] <T-Bone> Kamion: yeah, but not that handy to identify several ISOs ;)
[07:26] <Kamion> T-Bone: sure, it's not the only thing you need
[07:27] <Kamion> T-Bone: I may be able to figure out a way to embed the ISO build date into the bootloader config
[07:27] <stratus> Will smartbattery stuff be included in hoary?
[07:27] <Kamion> T-Bone: I think the wording is a bug but the information that's there now should remain in possibly a slightly different form
[07:27] <T-Bone> ok
[07:28] <haggai> crimsun: yes good idea.  Then if I delay it he can remind me :)
[07:28] <crimsun> haggai: acked.
[07:29] <ogra> and can look into it for seeing what he has to expect in the future by others ;)
[07:29] <thom> no0tic: the message you're reporting is from powernow-k7
[07:31] <no0tic> thom: are you asking?
[07:31] <thom> no0tic: no, i'm telling you
[07:31] <thom> that's why it's not in lsmod
[07:31] <no0tic> thom: #5874
[07:31] <Kamion> to re-mkisofs an ia64 ISO, it looks to me as if you need to create a boot1 directory alongside the CD tree, put images/cdrom/boot.img from a d-i build tree into boot1/boot/boot.img, and run "mkisofs -r -V 'Ubuntu 5.04 ia64 Bin-1' -o hoary-install-ia64-hacked.iso -no-emul-boot -J -b boot/boot.img -c boot/boot.catalog boot1 new-ia64"
[07:32] <thom> thanks
[07:32] <Kamion> I think
[07:32] <T-Bone> gah
[07:32] <no0tic> thom: there is in lsmod but it is unused: powernow_k7 8680  0
[07:32] <Kamion> where the CD tree is new-ia64
[07:32] <Kamion> constructing ISOs is a pain
[07:33] <Kamion> at least bootable ones ...
[07:33] <T-Bone> Kamion: ok,  you've convinced me, I'll do the loopmount way :)
[07:33] <Kamion> T-Bone: ... this is what you have to do *after* the loopmount thing
[07:33] <Kamion> there's no way around this
[07:33] <T-Bone> *UGH*
[07:33] <thom> no0tic: can you run /usr/share/powernowd/cpufreq-detect.sh and attach the output, also add /proc/cpuinfo 
[07:33] <Kamion> you have to loop-mount, copy the tree to new-ia64, munge, do the above
[07:33] <thom> no0tic: thanks
[07:33] <T-Bone> holly sh*t
[07:34] <Kamion> unless you want to try to get debian-cd up and running for Ubuntu, which I haven't dared to attempt outside of cdimage.ubuntu.com yet
[07:34] <T-Bone> heh
[07:34] <Kamion> you need a local mirror for that
[07:35] <Kamion> but TBH I'm not sure you'll find it significantly easier, if at all; it's a pile of hacks
[07:35] <T-Bone> heh
[07:35] <T-Bone> Kamion: there's no way I can use a netinstall system?
[07:35] <T-Bone> ie: instead of having to burn an iso, i could just netboot and then use a nfs rep?
[07:35] <Kamion> oh, sure
[07:36] <Kamion> well, probably not NFS, but HTTP/FTP will work
[07:36] <Kamion> (nobody's written an NFS retriever)
[07:36] <T-Bone> yeah whatever
[07:36] <Kamion> so, er, do that :) netboot image should be in the archive ...
[07:36] <T-Bone> because the problem isn't the installer, afaics, so if i could spare the CD-related pain...
[07:37] <Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-ia64/current/images/netboot/netboot.tar.gz should have everything you need
[07:37] <Kamion> alternatively, if it's not the installer at all, why not use debootstrap?
[07:38] <Kamion> on an existing Ubuntu system, 'debootstrap hoary /path/to/new/hoary/chroot'
[07:38] <T-Bone> Kamion: good point, but i'd rather be able to tell at the end "installation worked fine from A to Z"
[07:38] <T-Bone> debootstrap doesn't handle system configuration as d-i does
[07:38] <Kamion> T-Bone: you can do that later - if it's just dependency fixups and things it is much more efficient to use debootstrap during development
[07:38] <T-Bone> Kamion: besides, it needs an existing ubuntu system, which i don't have yet, given i've ripped my box to test ubuntu ;)
[07:39] <Kamion> you don't have to do an install from scratch every time, and if you're working effectively you shouldn't
[07:39] <T-Bone> Kamion: agreed
[07:39] <Kamion> do you have an existing Debian system?
[07:39] <T-Bone> Kamion: doh! Dude, don't be so harsh on me :^)
[07:39] <Kamion> I'm not, just trying to help you avoid the stuff I wasted time on :-)
[07:39] <Kamion> I used to burn CDs for every test ... *shudder*
[07:39] <T-Bone> Kamion: i have an existing system on the zx6000 which heats alot and sucks lot of current. I'll try to setup a Debian system on the zx2000 instead :)
[07:40] <T-Bone> Kamion: lol
[07:40] <Kamion> ok, you can install Ubuntu's debootstrap.deb on a Debian system harmlessly
[07:40] <Mithrandir> Kamion: I used to make floppies 
[07:40] <Kamion> (make sure to pick the hoary version)
[07:40] <Kamion> Mithrandir: at least they're relatively quick to write ...
[07:40] <mdz> Kamion: is there a package we could tuck (a fixed version of) update-cd into?
[07:40] <Kamion> mdz: update-cd?
[07:41] <mdz> Kamion: that little script I wrote to fix up the checksums and such on the CD after modifying it
[07:41] <Kamion> oh, there's a script in debian-cd called update-cd too, heh
[07:41] <mdz> yeah, noticed that the other day
[07:41] <Kamion> can't think of one offhand ...
[07:41] <T-Bone> Kamion: for the install archive, i can use stuff on the ISO as the repo served by apache?
[07:42] <Kamion> T-Bone: not quite, I don't think everything that netboot needs is there
[07:42] <Kamion> (there's a bug about that - we remove the netboot stuff to save space)
[07:42] <Kamion> you can try though, I've never tested that on ia64
[07:42] <T-Bone> s/ko/kB/, for you english speakers ;)
[07:43] <T-Bone> Kamion: but if i complete with the tarball you pointed me at?
[07:43] <mdz> Kamion: when I was doing busybox init test cycles, I set up a grub entry on my laptop to boot an initrd from disk, and used that with the CD-ROM
[07:43] <mdz> so I could quickly modify the initrd and test, without writing a new CD
[07:43] <Kamion> T-Bone: it'll be extra udebs you need, not stuff from that tarball
[07:43] <mdz> even better would have been a grub stanza to netboot, but for some reason the grub package doesn't have networking enabled
[07:43] <Kamion> mdz: yes, that's what I do on powerpc often
[07:43] <T-Bone> Kamion: k. Any easy way to fetch these?
[07:44] <mdz> Kamion: do you know if there's any reason why networking isn't enabled in grub?
[07:44] <Kamion> T-Bone: try first to see if it works
[07:44] <Kamion> T-Bone: otherwise debmirror
[07:44] <Kamion> unfortunately our netboot sucks, it always goes to archive.ubuntu.com unless you fiddle about in expert mode
[07:45] <T-Bone> debmirror? *G*, I hope i don't have to mirror everything, i'll have disk space issues otherwise :P
[07:45] <Kamion> mdz: no ... I didn't know it had networking support
[07:45] <Kamion> T-Bone: main/debian-installer is not a large component, you don't need to re-mirror all the debs, just grab a few more udebs
[07:45] <mdz> Kamion: it's way cool, you can say things like kernel (nd)/vmlinuz; initrd (nd)/initrd.img and it will load them via tftp
[07:46] <T-Bone> Kamion: ok
[07:46] <Kamion> oh, tftp, right
[07:46] <Kamion> I don't know, maybe size issues or something?
[07:46] <mdz> I guess it would make stage2 bigger, but stage2 isn't small anyway
[07:48] <ogra> is stuart bishop around by chance ?
[07:55] <Kamion> ogra: he's 'stub', not on channel
[07:56] <ogra> Kamion: thanks....
[07:56] <dholbach> has anybody problems with evolution on AMD64? to be precise: "floating point exception"
[07:56] <ogra> nope
[07:56] <ogra> i got lots ofg others here, but evo is fine for me
[07:56] <dholbach> ogra you have the newest available?
[07:57] <ogra> oh, 35 updates....
[07:58] <ogra> since it works for me and there are only libs to update for evo, i would suspect one of these
[07:59] <dholbach> i had a floating point exception for gnome-launch-box (which depends on e-d-s too) the other day
[07:59] <ogra> i still have that one
[08:00] <dholbach> ogra: hm?
[08:00] <ogra> gnome-launch-box
[08:00] <ogra> floatingpoint error.....
[08:00] <dholbach> well, there was only one release yet
[08:00] <Nafallo> I got no answer in #ubuntu, so this question might be better asked here :-).
[08:01] <Nafallo> can someone explain why fluxbox is missing menuitems?
[08:01] <ogra> dholbach: did you have any strange keyboard behavior or broken encoding recently ?
[08:01] <dholbach> ogra: the imendio guys said it worked nice on their amd64, they reckon it's because of gcc3.3 *shrug*
[08:01] <dholbach> ogra: strange encodings: not more than in the last months
[08:01] <dholbach> ogra: strange encodings: not more than in the last months already
[08:01] <ogra> killall metacity ==  
[08:02] <ogra> it suddenly appeared out of the blue ....
[08:02] <dholbach> ogra: metacity in 2.9.5-0ubuntu1 behaved quite strange... 2.9.8-0ubuntu1 fixed it
[08:03] <ogra> i mean the encoding, not the command :-P
[08:03] <lamont> pitti: you around?
[08:03] <ogra> the right part is what i see.... the left what i type...
[08:03] <pitti> lamont: yep
[08:04] <dholbach> ogra: metacity seems to save itself from being wiped out :-p
[08:04] <dholbach> ogra: sorry... don't know what could cause this at all
[08:05] <ogra> dholbach: i suspect either xkb or the kernel, since i also have some weird key repetition probs 
[08:06] <dholbach> ogra: we seem to be the only ones having bugged computers :-)
[08:07] <ogra> maybe the arch.....
[08:07] <ogra> YOUR DOG ??
[08:07] <mdz> ogra: sounds like meta was stuck on?
[08:08] <dholbach> ogra: :-)
[08:08] <Nafallo> ogra: I have got no problems except that metacitybug some day ago :-P.
[08:08] <ogra> mdz: i wouldnt know how to switch it on or of 
[08:09] <ogra> mdz: i.e. meta has no lock function on my keyboard afaik
[08:09] <ogra> Nafallo: amd64 ?
[08:09] <Nafallo> ogra: indeed
[08:10] <ogra> and i really start to suspect xorg....
[08:10] <Nafallo> ogra: I haven't got any :-P
[08:12] <ogra> lspci also shows a whole lot of unknown devices.... probably this machine is simply to new...
[08:12] <ogra> (2 weeks old)
[08:13] <ogra> mdz: btw, is there a chance to get the new nediswrapper into amd64 for hoary ?
[08:13] <thom> it's in, isn't it?
[08:13] <ogra> oh, already ?
[08:14] <ogra> wow, thom is right
[08:15] <mdz> what is the point?  there's no ndiswrapper kernel module for amd64
[08:15] <ogra> /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
[08:15] <ogra> :-D
[08:15] <mdz> from which package?
[08:15] <thom> mdz: lrm
[08:15] <thom> daniel added it last week iirc
[08:16] <mdz> thom: weird, why?
[08:16] <mdz> on i386, it's built by linux-source
[08:16] <ogra> ndiswrapper-modules-2.6.10-2-amd64-k8: /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
[08:16] <ogra> hmm
[08:16] <mdz> ndiswrapper-modules? that's something you built yourself
[08:16] <ogra> looking
[08:17] <ogra> argh, yes
[08:17] <mdz> my word
[08:17] <mdz> lrm is bigger than the kernel
[08:17] <thom> hrm, i thought i saw it go past in the changelogs
[08:17] <mdz> mizar:[/tmp]  apt-cache showsrc linux-source-2.6.10 linux-restricted-modules-2.6.10 | grep orig
[08:17] <mdz>  063a64fc0efd9c9901cf07effef1b747 46244465 linux-source-2.6.10_2.6.10.orig.tar.gz
[08:17] <mdz>  71eda5caf8a927676e3ee573e2b0801e 46930820 linux-restricted-modules-2.6.10_2.6.10.3.orig.tar.gz
[08:18] <thom> yeesh
[08:18] <Kamion> nvidia rpms IIRC
[08:18] <ogra> isdn....avm drivers ?
[08:19] <Kamion> anaconda is giving me flashbacks to boot-floppies
[08:21] <azeem> the source?
[08:31] <Kamion> azeem: yes
[08:31] <azeem> I thought it was mostly in python?
[08:32] <Kamion> the early stuff is in C
[08:33] <Kamion> and is really horrible
[08:35] <wasabi> Is there a push for getting Mono in main?
[08:35] <thom> not for hoary
[08:36] <wasabi> k
[08:36] <thom> it's been in and been removed again
[08:36] <mdz> there's nothing which provides motivation for enduring the pain that is mono
[08:36] <wasabi> Beagle.
[08:37] <wasabi> Basically what Im fighting now.
[08:37] <Kamion> not in hoary
[08:37] <wasabi> Missing dbus-cil
[08:37] <wasabi> Yeah.
[08:37] <Kamion> beagle will likely be the motivation for hoary+1
[08:41] <whiprush> there's a link to sid .debs for dbus-cil in bugs.d.o
[08:47] <dholbach> maybe fate is giving a broad hint... evolution, streamtuner and mozilla-thunderbird don't work, maybe i'd better get working again :-)
[08:47] <Mithrandir> dholbach: how have you broken m-t?
[08:48] <ogra> Mithrandir: he installed it
[08:48] <dholbach> Mithrandir: just installed it (and the proposed plugins), then i selected "don't import anything" (since there was no alternative)) and it mysteriously broke off, then i started it again from the console and saw it tried to "Registering Enigmail account manager extension." over and over again
[08:49] <Mithrandir> dholbach: uhm
[08:49] <Mithrandir> dholbach: $arch?
[08:49] <dholbach> amd64
[08:49] <dholbach>  ***** Registering: Clean Compreg! ****    -      Registering Enigmail account manager extension.    -     Enigmail account manager extension registered.     -       observe:      -     nothing here: null      -      observe called       -      FILE: [xpconnect wrapped nsIFile] *** loading the extensions datasource
[08:50] <dholbach> over and over again :-)
[08:51] <Mithrandir> dholbach: weird, worksforme
[08:53] <ogra> Mithrandir: did you see some weird key repitition probs on amd64 in X or the encoding switching out of the blue ? 
[08:56] <thom> wasabi: dbus-mono is in universe i believe
[08:56] <thom> providing libdbus-cil
[08:56] <wasabi> gmmmm
[08:56] <wasabi> I thought apt-get install was supposed to find provides
[08:57] <wasabi> nope, not in universe
[08:58] <Mithrandir> ogra: I ran it through ssh, so no
[08:58] <ogra> hmm...
[08:58] <ogra> k
[08:59] <mdz> pitti: here?
[09:00] <pitti> mdz: yes
[09:00] <dholbach> Mithrandir: here's what it says in the end: DOUBLE-CLICK: 400 --> -1 THRESHOLD: 8 --> -1 Fontconfig error: Cannot load default config file
[09:00] <dholbach> /usr/lib/mozilla-thunderbird/run-mozilla.sh: line 159: 20852 Segmentation fault  "$prog" ${1+"$@"}
[09:00] <mdz> pitti: I was just thinking that we may have a problem with the language pack / -update arrangement
[09:00] <Mithrandir> dholbach: so it's probably related to some fontconfig problems you have
[09:01] <mdz> pitti: I think we will run into the dpkg bug where it doesn't handle replaces properly if the unpack order is different
[09:01] <mdz> since we are not removing the files from the replaced package
[09:01] <dholbach> Mithrandir: there are none i'm aware of... hmmmm
[09:01] <pitti> mdz: why should we remove them? they are just replaced by newer versions
[09:02] <mdz> pitti: we shouldn't remove them
[09:02] <mdz> pitti: I am saying that we will encounter this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164595
[09:02] <mdz> pitti: and probably we need to fix that bug before language packs can be considered releasable
[09:03] <pitti> mdz: hm, thanks for the pointer
[09:03] <pitti> mdz: I try to reproduce it
[09:03] <mdz> pitti: perhaps talk to Keybuk about it when he returns
[09:04] <pitti> yes, will do
[09:04] <Kamion> fixing that bug would be a Really Good Thing anyway
[09:05] <dholbach> Mithrandir: /usr/lib/mozilla-thunderburd/run-mozilla.sh says: MOZ_PROGRAM=""  which seems to be the problem
[09:05] <Kamion> I wonder if anyone's reviewed the patch in #184635
[09:06] <pitti> mdz: ah, now I understand
[09:06] <pitti> mdz: that means if I install an update pack the second time, I will get errors because the replaced files are not owned any more by the base package?
[09:07] <mdz> pitti: if you unpack a new language-pack and language-pack-update, and language-pack-update is unpacked first, it will fail
[09:07] <mdz> (assuming language-pack-update replaces some files)
[09:08] <pitti> mdz: hmm, the update package should always be unpacked first, because the base package conflicts to older versions
[09:09] <Mithrandir> dholbach: same here, no problem
[09:12] <Kamion> night all
[09:12] <pitti> Night Kamion!
[09:13] <ogra> night
[09:14] <pitti> mdz: okay, I can reproduce the problem
[09:24] <amu> mdz: bug confirmed, it's very strange, reportbug say all time, bug report will be send to ubuntu, it goes finally to debian  
[09:26] <dholbach> amu: my reportbug tells me it'd be sent to debian (at least for universe stuff)
[09:27] <amu> dholbach: warty or hoary? 
[09:27] <mdz> amu: as I said in the bug, all of the patches are in merge-o-matic
[09:28] <mdz> amu: you just need to apply the diff which was already there
[09:28] <tritium> from now on I'll stick to attaching patches rather than pasting in bugzilla.  The newlines only confuse.
[09:28] <mdz> amu: did you do that already?
[09:28] <dholbach> amu: hoary
[09:31] <amu> mdz: patching it, isnt the problem, i try to understand why the problem comes, since i merged the package.  
[09:32] <amu> dholbach: hmm on my hoary it says: Will send report to Ubuntu (per lsb_release)
[09:32] <mdz> amu: the old version contained a patch which set the default bts to 'ubuntu'
[09:32] <mdz> amu: you dropped that patch
[09:33] <amu> mdz: i set the default to ubuntu, it still sends to debian
[09:34] <amu> mdz: ok, as i understood it's urgend, so i'll just apply the patches and recheck it
[09:35] <mdz> amu: I don't know what you tried, but setting 'bts ubuntu' in reportbug.conf (i.e., restoring the dropped patch) does exactly what I expect (reports the bug to Ubuntu)
[09:35] <mdz> I just tested it to be sure
[09:38] <mdz> amu: I also tried it without that, using the autodetection, and that works too
[09:38] <mdz> amu: but ubuntu should be the default as a safeguard
[09:38] <ogra> while you are at it.... is there any chance that we can collect the OTU bugs anywhere else (additional) then the mailing list....?
[09:38] <mdz> because clearly there are some cases where it does not work correctly
[09:38] <ogra> MOTU even
[09:38] <mdz> ogra: that is up to you and haggai to decide
[09:39] <ogra> ok...great :)
[09:39] <amu> mdz: ok, testing it now
[09:41] <Nafallo> ogra: stealing malone, are you? ;-)
[09:41] <mdz> ogra: I talked to haggai and bradb about malone
[09:41] <mdz> ogra: you can review with them, but it seems that the consensus is that malone is not ready
[09:41] <ogra> is malone ready yet ?
[09:41] <mdz> ogra: so you must decide whether you can wait, or if you need something immediately
[09:41] <ogra> thats what i thought
[09:43] <ogra> it would be essential to have _something_ to stabilize for hoary at least and the mailing list is a pita to search all the bugreports in 19245 mails i got in there currently...
[09:44] <ogra> is it likely that malone gets stable enough before hoary preview ?
[09:44] <ogra> bradb ? ^^
[09:45] <bradb> ogra: We (kiko, mpt and I) intend to have something usable for distro by mid next-week.
[09:45] <bradb> They're on their way to Montreal as we speak.
[09:45] <ogra> hmm, sounds enough to me....
[09:46] <ogra> bradb so lets talk then again....
[09:46] <bradb> ogra: sure, sounds good
[09:48] <sivang> ogra: we should get gazpacho in universe also...
[09:48] <sivang> IIRC It's was not auto synced from debian
[09:49] <crimsun> ogra: I'll just email you diff.gzs against what's currently in universe ;)
[09:49] <ogra> sivang: look in the build logs if it ftbfs.... if not, trigger elmo for a sync....
[09:49] <sivang> ogra: yes, I should, do you where they are?
[09:49] <ogra> crimsun: thanks :)
[09:49] <sivang> lamont something? ;-)
[09:50] <crimsun> sivang: yes, under his dir on people.u.c
[09:50] <sivang> crimsun: ok, looking
[09:50] <ogra> https://www.ubuntulinux.org/wiki/BuildDaemons
[09:51] <mdz> ogra: they need more than rebuilds
[09:52] <ogra> sivang: if you plan to go for MOTU, you should also see the other pages listed here https://www.ubuntulinux.org/wiki/MOTURecruitment
[09:52] <ogra> mdz: as i understand it, mostly a build dep or a dep change against python2.4 is enough...
[09:53] <sivang> bad, all links in lamont's wiki page for the builddaemons are broken..
[09:53] <sivang> ogra: where I can see recent build logs?
[09:53] <ogra> assuming 2.4 is downwards compatible....
[09:53] <rcaskey_> what kind of hardware does the i386 buildd run on
[09:53] <ogra> sivang: http://people.ubuntu.com/~lamont/buildLogs/
[09:54] <mdz> ogra: for native module packages, you need to add a new python2.4-foo package and arrange for it to be built with the new version of python
[09:54] <ogra> sivang: most recent: http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
[09:54] <mdz> ogra: for python programs, sometimes it is enough to test with the new python and update a dependency
[09:54] <mdz> at any rate, source changes are required :-)
[09:55] <ogra> mdz: and thats the majority i guess...since most modules pkgs are in main anyway
[09:55] <mdz> ogra: will you remove support for 2.2 and 2.1 where it has not been done already?
[09:55] <mdz> I think doko has done many of them already
[09:55] <ogra> in universe ?
[09:55] <mdz> yes
[09:55] <ogra> i didnt know he also cares for that...
[09:56] <mdz> ogra: in general, if a change in main breaks many things in universe, we try to help with it
[09:56] <sivang> ogra: well, the talked package I was thinking about (gazpacho) is not there, where could it be elsewhere found?
[09:56] <mdz> but with a strong MOTU team, you guys can handle those things
[09:57] <bradb> ogra: sorry, one quick note: when i said "distro" by the way, i meant "universe" not that main can just drop Bugzilla.
[09:57] <ogra> mdz: currently the team is 4 ppl :/
[09:57] <bradb> ogra: but yeah, i get the impression that you're a MOTU, so you should be among the intended early adopters of distro Malone
[09:57] <ogra> bradb: great, thats exactly what i want as a MOTU
[09:58] <ogra> mdz: ... which i wouldnt consider ...strong....
[09:58] <shaya> hmm
[09:58] <shaya> ubuntu install kills vmware beta
[09:58] <rcaskey_> what is Malone?
[09:59] <ogra> mdz: and we all have other (big) tasks....
[09:59] <ogra> rcaskey_: https://launchpad.ubuntu.com/malone
[10:00] <rcaskey_> ahh
[10:01] <rcaskey_> universe has been very good to me, the only real issue is that I really needed to scrap esd in favory of polypaudio
[10:01] <rcaskey_> but that directly relates to base
[10:02] <ogra> rcaskey_: whats your favorite package from universe ?
[10:02] <rcaskey_> wesnoth ;)
[10:02] <ajmitch> ogra: heh, I've got some packages for you for universe ;)
[10:02] <ogra> rcaskey_: like to adopt it andbecome a MOTU ?
[10:03] <mdz> elmo: is python2.2 able to move into universe now?
[10:03] <mdz> ogra: that's why we need to grow the team :-)
[10:03] <ajmitch> ogra: the python programs mdz was talking about
[10:03] <rcaskey_> maybe, we will see, I'm still trying to find someone to sign my key ;)
[10:03] <ogra> mdz: thats hat i'm trying ;)
[10:03] <ogra> what even
[10:03] <ajmitch> ogra: I've started rebuilding some of the packages
[10:03] <crimsun> rcaskey_: I've already converted two hoary machines to polypaudio this afternoon.
[10:04] <rcaskey_> crimsun: was there ever a final decision on what was to be odne about that
[10:04] <rcaskey_> the BOF notes weren't very complete i'm afraid
[10:04] <crimsun> rcaskey_: not afaik. I've pinged jdub RE: polypaudio, but I believe he was/is asleep.
[10:05] <mdz> rcaskey_: www.biglumber.com
[10:05] <crimsun> rcaskey_: if the plan is to transition to polypaudio as transparently as possible, we can keep gst using esdsource and esdsink and just use the default polypaudio setup
[10:06] <ogra> ajmitch: send me a pointer where i can review them .... hostmaster@grawert.net
[10:06] <mdz> rcaskey_: polypaudio is likely to happen for Hoary, but it isn't ready yet
[10:06] <ajmitch> ogra: sure, each package needs modified, so it takes a little while..
[10:06] <ajmitch> grep-dctrl showed 155 of them at last count
[10:06] <crimsun> mdz: out of curiosity, what's keeping it in universe?
[10:06] <ogra> ajmitch: go on... we still have about 2 months.....
[10:06] <mdz> crimsun: nothing in main depends on it
[10:07] <rcaskey_> mdz: GA is very short on oSS types it sees
[10:07] <rcaskey_> the Debian devel map was very sparse  (yes I know Ubuntu is not Debian but...)
[10:07] <crimsun> mdz: hmm, ok. It is literally a drop-in replacement.
[10:07] <ajmitch> ogra: usually there'll be a new binary package built, so debian/control, rules, and install files generally need changed for each
[10:07] <mdz> rcaskey_: biglumber finds 16
[10:08] <ogra> ajmitch: i know.... jst put the source pkgs online anywhere, point me to them and i'll upload them if i consider them ok...
[10:09] <mdz> crimsun: I accept jdub's assessment that it is not time to switch everything over yet
[10:09] <crimsun> mdz: ok.
[10:10] <crimsun> mdz: oh, and regarding the earlier question whether my key is in the strong set, the answer is "yes"
[10:10] <crimsun> mdz: not many signatures at all, but 'yes'
[10:11] <mdz> crimsun: a link into the strongly connected set should be sufficient
[10:11] <ajmitch> mine ought to be in the strong set now
[10:11] <crimsun> ok, I'll try to make it to our next meeting and have our steering committee sign 
[10:13] <rcaskey_> I don't suppose the notary public signs ;)
[10:14] <sivang> mdz: what is the "strong" set?
[10:16] <crimsun> sivang: http://www.dtype.org/keyanalyze/explanation.php
[10:16] <ogra> sivang: everything valid/trustworthy you find at the keyservers
[10:16] <crimsun> my lug is the largest on biglumber.
[10:18] <seb128> lamont: could you kick nautilus with eel2 2.9.90-0ubuntu3 ?
[10:19] <lamont> seb128: kicked, I thikn
[10:19] <seb128> thanks
[10:20] <lamont> seb128: btw, ximian-connector is ftbfs: non-PIC (libexchange.a) in shared object. :-(
[10:23] <ajmitch> ogra: placing stuff on webserver now
[10:23] <ogra> ajmitch: fine :)
[10:23] <jdub> GOOD MORNING FREEDOM LOVERS!
[10:23] <jdub> happy australia day! :)
[10:23] <pitti> Hi jdub!
[10:23] <ajmitch> uh oh
[10:23] <ajmitch> hi jdub 
[10:24] <ogra> morning....jdub
[10:24] <opi> hi jdub :)
[10:24] <opi> morning, hehe, I'm going to bed now :}
[10:24] <lamont> creating libnautilus-private.la
[10:24] <thom> jdub: happy colony day
[10:24] <lamont> /bin/sed: can't read /usr/lib/libgnome-menu.la: No such file or directory
[10:24] <lamont> seb128: ^^^
[10:24] <crimsun> moin jdub :)
[10:24] <jdub> opi: waking australians is always a good alarm clock ;)
[10:24] <jdub> thom: haw haw ;)
[10:24] <ajmitch> unfortunately our national holiday falls on a weekend this year :)
[10:24] <seb128> lamont: it has picked 0ubuntu2 again, I said 0ubuntu3 :p
[10:25] <lamont> seb128: lol
[10:25] <lamont> I'll wait a little bit then
[10:25] <seb128> ok
[10:25] <seb128> or just put a dep-wait ?
[10:26] <opi> jdub: <kid voice>you'll beeeeeee sorrry</kid voice> :)
[10:26] <seb128> jdub: I'm not happy with ximian guys again, they release crappy versions every time, out of this should be fine :p
[10:26] <crimsun> gotta run out, see you guys.
[10:27] <ogra> ciao crimsun...and congrats ....
[10:27] <ogra> :)
[10:27] <opi> g'night all
[10:28] <lamont> seb128: depwaited this time :-P
[10:28] <ogra> OMG..... backports has xorg now ????
[10:28] <ajmitch> oh dear
[10:28] <lifeless> hhhaaaa
[10:28] <ogra> poor users
[10:29] <ajmitch> guaranteed to break everyones' systems on upgrade to hoary?
[10:29] <seb128> lamont: thanks :) BTW how the depwait works ? It looks for the deps every ... ?
[10:30] <lamont> seb128: the packages are 'dep-wait libeel2 (>> ...0ubuntu2)'
[10:30] <lamont> once a libeel2-dev  (actually) newer than that (>>) is in the archive, the package will automagically transition to needs-build
[10:31] <lamont> so it'll actually be triggerd by the needed package entering the archive.  If the build still fails, then the chroot is polluted, and I have more work to do.
[10:32] <seb128> lamont: but how does it notice the new package ? inotify ? :)
[10:33] <seb128> after each mirror update all the dep-wait are reconsidered ?
[10:33] <jdub> Setting up openoffice.org2-debian-files (1.9.64-0ubuntu2) ...
[10:33] <jdub> /var/lib/dpkg/info/openoffice.org2-debian-files.postinst: line 7: /usr/share/openoffice.org-debian-files2/install-hook: No such file or directory
[10:35] <ogra> ajmitch: pretty likely yes...
[10:35] <ajmitch> ogra: 3 done, on http://ajmitch.dhis.org/debuild/ubuntu/python/
[10:35] <tritium> jdub, I posted a patch to fix that
[10:35] <ajmitch> well, the 3rd one will be there soon :)
[10:35] <ajmitch> just grab the .dsc & .diff.gz, I think
[10:36] <ajmitch> hmm, I should make sure I only copy over the ubuntu-versioned ones
[10:36] <tritium> jdub, please see bug #5853.  I think my patch is correct.
[10:37] <jdub> thom: nooooooo!
[10:38] <ajmitch> python-ctypes done as well
[10:38] <lamont> seb128: as part of the mirror update, after new packages are installed, all the dep-waits are visited
[10:40] <seb128> ok, nice
[10:40] <ogra> ajmitch: -XubuntuX versions apply only if you made ubuntu specific changes to the package....
[10:41] <ajmitch> ogra: since python2.4 isn't default in debian, I made them ubuntu-versioned
[10:41] <ogra> ajmitch: ok
[10:41] <jdub> so dtrace has been released
[10:41] <ogra> ajmitch: just wanted to point it out, since i made this mistake ;)
[10:41] <jdub> the tarball is dtrace.tar.gz
[10:41] <jdub> no version
[10:41] <jdub> and the tarball is insane
[10:41] <jdub> usr/src/cmd/dtrace/
[10:41] <jdub> etc.
[10:41] <ajmitch> how evil
[10:41] <ogra> jdub: eternal version ;)
[10:42] <jdub> well, they have been talking about it like it's perfect ;)
[10:42] <ajmitch> looks like it was made for some 80s UNIX system ;)
[10:42] <dholbach> wow this is not friendly:  http://bugs.debian.org/292214  :-/
[10:44] <ajmitch> not unexpected :)
[10:45] <tritium> jdub, did that fix work for you?
[10:45] <ogra> dholbach: i warned you ;)
[10:45] <dholbach> ogra: i blame reportbug for it :-)
[10:45] <ogra> dholbach: it was a bug in reportbug....
[10:46] <ogra> dholbach: already fixed ;)
[10:46] <dholbach> ogra: i'll tell ari about
[10:47] <ajmitch> I should really try & build on a faster computer :)
[10:47] <ajmitch> either that or make a cup of coffee for each build I do..
[10:49] <dholbach> ajmitch: i could do with a fresh cup myself :-)
[10:53] <tritium> seb128, looks like evo-exchange can't authenticate OWA https:// urls
[10:54] <tritium> but, at least it's no longer contacting localhost instead of my exchange server
[10:56] <jbarroso_> hi people, I'm now on Ubuntu Hoary .... when I finish to move a window and I pup up mouse button, all my screen is redraw slowly. I'm using nvidia drivers from ubuntu repository
[10:57] <ogra> doko ?
[10:57] <kent> the bookmark-section of the Places menu in the panel seems to have issues with folders with spaces in it. For example, i added "/home/kent/Musik film och liknande" to the gtk-filechooser-widget as a bookmark. But when i try to open that with the Places menu, i get this message: http://leviatan.kicks-ass.org/dumps/places-bookmarks.png
[10:57] <jbarroso_> when I click on title-bar of a window, screen is redraw slowly too ....
[10:57] <jbarroso_> do you know about it ?
[10:57] <seb128> kent: what version of gnome-panel ?
[10:57] <kent> seb128, 2.9.4 (going to bugzilla in a few seconds.)
[10:58] <seb128> kent: fixed in 2.9.90, update
[10:58] <kent> seb128, oh. thanks. i wont bugger bugzilla then :)
[11:01] <ajmitch> ok, so python2.2 is segfaulting trying to build this package, which is a little worrying 
[11:06] <sivang> seb128: I have modified bits of the g-s-t pkg to allow a default profiledb to be installed with the package, it's failing on the "05_no_ubuntu_warning" patch, any idea? (I didn't change stuff wrt to that)
[11:07] <ogra> argh .....
[11:07] <seb128> sivang: nop
[11:07] <seb128> sivang: what have you changed ?
[11:07] <ogra> whats wrong with http://cdimage.ubuntu.com/ ????? !!!!!
[11:07] <ogra> elmo ^^^^^^^^^ !
[11:08] <mdz> whoa, that's a lot of punctuation there
[11:08] <mdz> it looks perfectly fine to me
[11:08] <dholbach> ogra: to me too
[11:09] <ogra> www.grawert.net/cdimage.png
[11:09] <sivang> seb128: first, I changed stuff in in file.pl.in, to split to storage of configuration files xml from the other cache and debug data.
[11:09] <kent> hmm,  bugzilla.ubunto wont send me my password (yep, forgot it). I did a search on bugzilla and found no bug on hoary gaim that when i kill gnome-panel it also kills gaim and gaim will not respawn. Seems lika gaims plugin for notific.area is buggy or something.
[11:10] <dholbach> ogra: well yes, that looks somehow wrong :-)
[11:10] <sivang> seb128: then I added 2 lines to the rules file, to create /etc/g-s-t and to install the config data there.
[11:10] <seb128> kent: yep, there is no bug open for that
[11:10] <ogra> http://cdimage.ubuntu.com/daily-live/current/: The requested URL /daily-live/current/ was not found on this server.
[11:11] <kent> seb128, will wait for bugzilla to send me my password. not sure where that mail went, and i cant get it to send it again.  its probably just taking a few min.
[11:11] <seb128> ok
[11:12] <Kamion> looks like it's broken on mirnyy, which is one of the two hosts that cdimage now round-robins to
[11:12] <ogra> ah...that explains it
[11:12] <Kamion> mirnyy's new in that round-robin, I guess elmo's still fixing it up
[11:36] <ogra> could someone change the topic in #ubuntu ? i think the metacity warning is obsolete
[11:41] <ogra> opi: morning ;)
[11:41] <opi> ogra: gaaa. I can not sleep.
[11:41] <opi> ogra: I've been flamed once again by gf, because instead of rest I'm doing some Wiki work at ubuntulinux.org ;)
[11:44] <opi> mine supports me too
[11:44] <opi> but she don't see me often nowdays, even in we live in same flat ;)
[11:44] <mdz> ogra: you can't change it?
[11:45] <ogra> mdz: i cant give me op status....
[11:45] <Kamion> you don't need operator privileges to change the topic unless the +t channel mode is set
[11:45] <ogra> opi: mine neither, but she knows everything i do is right ;)
[11:46] <opi> how do I make intend in moinmoin? :)
[11:46] <ogra>  #ubuntu :You need to be a channel operator to do that
[11:46] <ogra> :(
[11:46] <Kamion> ... evidently somebody set +t then, ok
[11:48] <thom> #3091 is such crack
[11:55] <nakeee> I have a glibc bug I'm trying to get people to apply a patch to for almost year and a half now if not more
[11:56] <nakeee> the guy who wrote the patch tried the glibc bugzilla/mailing list
[11:56] <nakeee> I tried debian bugzilla and I htink the maintainer didn't understand what the bug is
[11:56] <thom> nakeee: #debian-glibc might be more interested; or ping jbailey
[11:56] <azeem> there's no 'debian bugzilla'
[11:56] <nakeee> azeem: debian bug system:)
[11:57] <doko> ogra: pong
[11:58] <nakeee> no I move to ubuntu so if the patch would get there it's good enough for me:) jbailey is ubuntu's glibc person?
[11:58] <nakeee> now
[11:59] <azeem> nakeee: what's the bug number?