[12:34] <tvon|x31> Anyone have an idea how I could debug that? or where to even look?
[12:35] <tvon|x31> WIFI works fine, but signal strength has been broken for a while now.  Using the 2.6.8 right now, but it was the same with 2.6.7
[12:38] <tvon|x31> neeevermind
[12:38] <tvon|x31> ad-hoc vs managed
[02:17] <jdub> tvon|x31: which wifi card/driver?
[04:08] <HcE> hmmm
[10:04] <debianist> morning all
[10:05] <cef> morning
[10:06] <debianist> hey cef
[10:07] <debianist> I have some more issues regarding the livecd, should I address them or wait for the next livecd out of the daily snapshots?
[10:07] <debianist> besides the reolution probem,
[10:08] <debianist> the USB mouse was not operating. seemed to be recognized (According the X11 config files) and infra light was on etc.
[10:09] <cef> I've got no clue about the livecd.. you'd be best asking on the list methinks
[10:11] <debianist> is another team of people who produce the livecd?
[10:12] <cef> the software is the same.. but the livecd's don't tend to contain what the standard installs contain.. and plus (and this is the big one) i'm not a developer
[10:13] <cef> I just know enough to be dangerous
[10:14] <debianist> oh ok. say cef, aren't they any netinst ubuntu images?
[10:15] <cef> debianist: not netinst afaik.. netboot yes, netinst no
[10:20] <debianist> oh ok
[10:21] <debianist> this channel is also used to communicate between the developers?
[10:21] <jdub> yeah
[10:21] <jdub> so the livecd is a bit old now
[10:21] <debianist> hi jdub :)
[10:21] <jdub> alex makes them, but he's only on one day a week atm
[10:22] <debianist> jdub, I can take over that , is this possible? (ofcourse I'd need slight direction for starters)
[10:22] <debianist> maybe help him,
[10:22] <debianist> produce livecds another day in a week or two :)
[10:22] <jdub> cef: contrary to convention, the livecd contains the entire desktop install ;)
[10:22] <jdub> debianist: possibly a bit difficult at the moment
[10:24] <debianist> jdub : ok. I guess thing will get much clearer in 2 weeks or more
[10:26] <debianist> http://ftp.no-name-yet.com/cdimage/sounder-test/7/  holds a daily build? if not, where would I get it from?
[10:26] <cef> hrm, food
[10:27] <jdub> debianist: navigate from /cdimage/
[10:27] <debianist> or grab http://ftp.no-name-yet.com/cdimage/sounder-test/current/ ?
[10:28] <debianist> there supposed to be the daily
[10:28] <debianist> ?
[10:29] <debianist> ok, nm I am downloading cdimage/daily/current/
[11:32] <jdub> i'm so used to the ubuntu installer that d-i seems bizarre
[11:34] <debianist> jdub : oh goody, will I be surprised by the ubuntu installer? anxiuosly waiting for the download to complete..:)
[11:34] <jdub> it's a modified d-i
[11:34] <jdub> very minimal
[11:35] <jdub> not totally different :)
[11:35] <debianist> jdub : is it fb ? text ?
[11:35] <Mithrandir> mdz: awake?fb
[11:35] <Mithrandir> uhm
[11:35] <Mithrandir> s/fb$//
[11:35] <Mithrandir> mdz: awake?
[11:35] <Mithrandir> debianist: it's fb, but text.
[11:36] <jdub> debianist: (same as d-i)
[11:37] <debianist> not that I ever want it to be GUI , text is the best for a straight forward, no trick installer
[11:38] <jdub> ... next release will have a gui installer :)
[11:38] <Mithrandir> jdub: but it won't necessarily be the only option. :)
[11:38] <jdub> nah, probably not
[11:38] <jdub> if it ends up being based on d-i, it'll be easy to go back to the text one :)
[11:39] <Mithrandir> yup
[11:39] <debianist> jdub : who's working on it? me and a another guy wanted to continue the GUI installer project, however after long discussions with the folks over #debian-boot , 
[11:39] <debianist> I realized a complete redesign of d-i is needed.
[11:39] <Mithrandir> debianist: you are wrong.
[11:40] <Mithrandir> debianist: (and, FWIW, Kamion and joeyh agree with me, they have a bit of d-i experience as well)
[11:40] <debianist> that was what the guy who was the closes to the gui developers suggested, and he contributed it to the periority style, one question at a time charecter of d-i
[11:40] <debianist> sorry
[11:40] <debianist> cdebconf
[11:40] <debianist> Mithrandir : glad to here that!
[11:41] <Mithrandir> there is nothing stopping one from extending the debconf protocol a bit
[11:41] <debianist> I want to GUI installer for my winnie (As in windows) freinds :)
[11:41] <Mithrandir> yup, though, if one chooses UI based on the installer, I think they have the wrong focus. :)
[11:42] <debianist> I also.
[11:42] <debianist> But it should be JUST there, for the layman to try it over :)
[11:42] <debianist> is there any help needed for GUI isntaller tasks? 
[11:43] <debianist> I am fascinated with how the d-i interworkings act, and consider this a valuable oppurtunity to get involved :)
[11:43] <Mithrandir> you should probably talk to Kamion about it, he's a lot more active wrt both our installer works, and d-i.
[11:43] <debianist> oh ok thanks 
[11:44] <jdub> mmm, kamion, joeyh and i talked for a bit in oxford about doing a proper gui frontend
[11:44] <jdub> designed rather than generated
[11:44] <Mithrandir> one idea is to having something in cdebconf looking for magic templates, and if they come up, load a glade frontend which basically preseeds the questions based on the template.
[11:45] <jdub> yeah
[11:45] <Mithrandir> my idea is to have the postinst query whether an extension (say, a partitioner widget) is available, and if so, communicate with that using some predefined API.
[11:46] <Mithrandir> the problem with the first approach is magic in the frontend, which I dislike, the problem with my approach is more code paths and thereby some code which will be less tested.
[11:46] <debianist> Mithrandir : we can device a test plan carfeully test every code branching
[11:47] <jdub> easier said than done ;)
[11:47] <Mithrandir> debianist: realistically, I don't think that's very feasible.  You'll get _a lot_ of tests.
[11:47] <Mithrandir> remember that the installer is fairly well-connected, so you can't just test each component.
[11:47] <debianist> rigt
[11:47] <debianist> right
[11:47] <debianist> hmm
[11:49] <Mithrandir> once we get automated installations working, it will be a lot easier to test, though.
[11:49] <Mithrandir> jdub: who are responsible for our kernel images?
[11:50] <jdub> Mithrandir: mdz/herbert
[11:50] <Mithrandir> ok
[11:50] <Mithrandir> do you know of any plans for 2.6.8?
[11:51] <jdub> there's an x86 kernel in matt's webspace
[11:51] <jdub> see sounder list
[11:52] <Mithrandir> hm, I'm not on there.  Just subbed
[11:52] <jdub> ahr
[11:52] <jdub> one sec
[11:53] <jdub> deb http://www.no-name-yet.com/~mdz/kernel/ /
[11:53] <jdub> (e.g., apt-get install linux-image-2.6.8.1-686)
[12:01] <kagou> hi
[12:05] <Mithrandir> jdub: thanks.  Would anybody scream too much if I uploaded amd64 kernels, you think?
[12:06] <jdub> Mithrandir: built from that source?
[12:06] <jdub> perhaps making them available from your own spot20:05 < Mithrandir> jdub: thanks.  Would anybody scream too much if I uploaded amd64 kernels, you think?
[12:07] <jdub> BONG
[12:07] <jdub> sorry, slippery fingers ;)
[12:08] <Mithrandir> jdub: basically, what's in the archive today + bd_claim patch.
[12:14] <daniels> jdub: laptop progress?
[12:19] <debianist> bye guys, evening laters
[12:20] <Mithrandir> hm, no, I shouldn't need that, it seems to be in already
[12:20] <jdub> daniels: shipped
[12:47] <daniels> jdub: rad
[12:47] <daniels> jdub: where from?
[12:50] <jdub> no idea
[12:51] <HrdwrBoB> hoorah - I finally put this IDE CDROM on that machine and ubuntu installs, however it seems isolinux has some issues with some scsi drives
[12:52] <jdub> hmm, sounds like a problem with Hrdwr, BoB 
[12:52] <jdub> (haw haw haw)
[12:52] <jdub> ahem
[12:53] <HrdwrBoB> haha
[12:53] <HrdwrBoB> ironically there's nothing wrong with the hardware per se- it boots other CDs fine
[12:53] <jdub> that sounds bad
[12:54] <jdub> i wonder if i still have my scsi cdrom drives
[12:54] <jdub> can you lodge a bug about that?
[12:54] <daniels> hold on
[12:54] <daniels> it's nothing like ... *rummage*
[12:54] <HrdwrBoB> yeah
[12:54] <daniels> https://bugzilla.no-name-yet.com/show_bug.cgi?id=553
[12:55] <HrdwrBoB> no
[12:55] <daniels> damn
[12:55] <HrdwrBoB> it causes hardware to reboot before anything
[12:55] <HrdwrBoB> kernel never loads
[12:55] <daniels> oh, it's scsi anyway
[12:55] <HrdwrBoB> yeah it's a goat problem
[12:57] <HrdwrBoB> what should I file it against?
[12:58] <jdub> debian-installer or UNKNOWN
[12:59] <Mithrandir> isolinux should work with scsi, but some motherboards doesn't like it.
[01:00] <HrdwrBoB> Mithrandir: is there more information on thaT?
[01:00] <jdub> hey AndyFitz 
[01:00] <AndyFitz> hiya jdub
[01:00] <jdub> AndyFitz: so it seems the index.theme Size setting is being ignored :)
[01:00] <jdub> AndyFitz: tried the latest ubuntu-artwork?
[01:01] <Mithrandir> HrdwrBoB: I don't have a link about it no, sorry.
[01:01] <AndyFitz> index.theme size isnt ignored i dont think index.theme was present
[01:02] <jdub> $ du -sh /usr/share/icons/Human/index.theme
[01:02] <jdub> 4.0K    /usr/share/icons/Human/index.theme
[01:02] <jdub> example stanza:
[01:02] <jdub> 
[01:02] <jdub> [scalable/apps] 
[01:02] <jdub> MinSize=1
[01:02] <jdub> Size=48
[01:02] <jdub> MaxSize=256
[01:02] <jdub> Context=Applications
[01:02] <jdub> Type=scalable
[01:02] <jdub> 
[01:03] <AndyFitz> size should be 128
[01:03] <AndyFitz> it will automatically display as 48
[01:03] <jdub> it seems to display as 128 or 256 atm :)
[01:04] <AndyFitz> yeah size isnt being ignored.  
[01:04] <AndyFitz> if you specify size=128  it will shrink to 48
[01:04] <jdub> bong!
[01:06] <Mithrandir> could somebody on i386 do me a small favor?
[01:06] <Mithrandir> build grub with http://raw.no/patches/grub-amd64.diff applied and tell me that I didn't break anything?
[01:06] <AndyFitz> [scalable/apps] 
[01:06] <AndyFitz> MinSize=1
[01:06] <AndyFitz> Size=128
[01:06] <AndyFitz> MaxSize=512
[01:06] <AndyFitz> Context=Applications
[01:06] <AndyFitz> Type=scalable
[01:07] <AndyFitz> [scalable/filesystems] 
[01:07] <AndyFitz> MinSize=1
[01:07] <AndyFitz> Size=128
[01:07] <AndyFitz> MaxSize=512
[01:07] <AndyFitz> Context=FileSystems
[01:07] <AndyFitz> Type=Scalable
[01:07] <AndyFitz> [scalable/devices] 
[01:07] <AndyFitz> MinSize=1
[01:07] <AndyFitz> Size=128
[01:07] <AndyFitz> MaxSize=256
[01:07] <AndyFitz> Context=Devices
[01:07] <AndyFitz> Type=scalable
[01:07] <jdub> eek, ok
[01:07] <jdub> i just sedded it
[01:08] <jdub> it's all there
[01:09] <doko> Mithrandir: any packages already built and uploaded with gcc-3.4?
[01:09] <Mithrandir> doko: not to my knowledge.
[01:10] <Mithrandir> doko: I want to fix grub first, as soon as that is there, base should be fully installable
[01:11] <jdub> AndyFitz: alrighty,
[01:11] <jdub> AndyFitz: thanks - that's sorted
[01:13] <doko> ok, so that should be no problem: http://gcc.gnu.org/ml/gcc/2004-09/msg00205.html (anyway, the current ubuntu package is a one week snapshot)
[01:13] <AndyFitz> any news back about the style?   im not in a hurry to design 200 icons style dependant icons without the go ahead.  Mark hasnt gotten back to me
[01:13] <Mithrandir> doko: do you have an i386 system nearby and could test that the patch doesn't break i386?
[01:14] <doko> Mithrandir: which patch?
[01:14] <Mithrandir> http://raw.no/patches/grub-amd64.diff
[01:14] <Mithrandir> build and install grub and see that it doesn't blow up
[01:15] <doko> Mithrandir: ok, will do tonight.
[01:15] <Mithrandir> thanks
[01:48] <HrdwrBoB> will ubuntu have dualhead support? (afaik it hasn't got it at the moment)
[01:49] <HrdwrBoB> I mean eventually.. obviously it's not going to happen overnight
[01:49] <Mithrandir> we are going to rock, so of course.
[01:49] <HrdwrBoB> heh
[01:50] <jdub> HrdwrBoB: you can do dualhead, but there isn't a nice configuration thingy for it yet :)
[01:50] <HrdwrBoB> it's fast becoming (become?) a standard
[01:50] <HrdwrBoB> I'm aware you can do it :)
[01:50] <HrdwrBoB> I can write my own X config files any time I like, and I do, and I hate the damn things :)
[01:51] <HrdwrBoB> but dualhead always bites me in the bum, nvidias twinview is a terrible hack, and you end up with 3d games across two monitors, xinerama tends to eat glx and X dualhead isn't quite enough, and some apps get really confused
[01:51] <HrdwrBoB> you can't win
[02:13] <cef> yeah well.. once X.org get their arses into gear mebbe they'll get something officially done about it
[02:34] <Kamion> npmccallum: ping?
[03:33] <kagou> Sometime i lost my dvd/cdrom :/
[03:34] <kagou> ide-cd: cmd 0x1e timed out // hdc: lost interrupt // hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
[03:35] <kagou> same error with kernel 2.6.7-i386 2.6.7-k7 and 2.6.8-k7
[03:36] <kagou> dma problem ?
[03:38] <kagou> No more splash image on grub menu ?
[03:38] <kagou> (i'm up to date)
[03:38] <daniels> cef: ha ha ha
[03:38] <daniels> cef: how much time do you have?
[03:39] <daniels> cef: there is no right answer, and not fixing it right now is the least stupid option
[03:40] <daniels> HrdwrBoB: basically, my position on dualhead stuff is that we should never ask a question during install unless we're doing some amazing crap that is impossible to auto-detect
[03:40] <daniels> HrdwrBoB: this means a single head; dualhead is out of scope for installer stuff, and perfectly in scope for an (as-yet-unwritten) userspace x configuration tool
[03:41] <daniels> cef: btw, we've already done a bit about bad xinerama<->glx interactions with mergedfb, meaning you can now do that meaningfully on radeon
[03:41] <daniels> but it really is a difficult problem which spans both political and technical issues (yay!)
[04:24] <seb128> daniels: we can remove licence displaying like that (ie: your xsane upload) ?
[04:25] <Mithrandir> seb128: had a look at my epiphany bug?
[04:26] <seb128> Mithrandir: seen it, I'll do an upload soon
[04:26] <Mithrandir> thx
[04:26] <Mithrandir> it's completely broken on amd64 right now
[05:45] <mdz> Mithrandir: herbert will be adding amd64 support to that package shortly
[05:45] <mdz> Mithrandir: regarding grub, it doesn't seem to be built on amd64 yet
[05:48] <Mithrandir> weird:
[05:48] <Mithrandir> Date: Sun,  5 Sep 2004 12:45:01 +0100 (BST)                                     
[05:48] <Mithrandir> Upload package to host jackass
[05:48] <Mithrandir> Uploading via ftp grub_0.95+cvs20040624-3ubuntu13.dsc: done.
[05:48] <Mithrandir> Uploading via ftp grub_0.95+cvs20040624-3ubuntu13.diff.gz: done.
[05:48] <Mithrandir> Uploading via ftp grub_0.95+cvs20040624-3ubuntu13_source.changes: done.
[05:48] <Mithrandir> Successfully uploaded packages.
[05:49] <mdz> yes, the source is there
[05:49] <mdz> and i386 binaries
[05:49] <mdz> I CCed lamont on the bug
[05:49] <Mithrandir> ok
[05:49] <Mithrandir> it might be in PaS
[05:49] <Mithrandir> lamont: is grub in PaS?
[05:49] <Mithrandir> lamont: it should work on amd64 now
[06:20] <Kamion> Mithrandir: the P-a-s entry looks fine to me
[06:20] <Kamion> http://buildd.debian.org/quinn-diff/Packages-arch-specific
[06:20] <Kamion> unless our local copy needs to be updated or something
[06:25] <mdz> Mithrandir: eek
[06:25] <mdz> checking for C compiler default output file name... configure: error: C compiler cannot create executables
[06:25] <mdz> Mithrandir: that's what happens when I try to build it on warty/amd64
[06:25] <mdz> configure:2413: x86_64-linux-gcc -m32   -static conftest.c  >&5
[06:25] <mdz> /usr/bin/ld: skipping incompatible /usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../
[06:26] <mdz> libc.a when searching for -lc
[06:26] <mdz> /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
[06:26] <mdz> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
[06:26] <mdz> /usr/bin/ld: cannot find -lc
[06:26] <mdz> Mithrandir: missing build-dep?
[06:32] <mdz> Mithrandir: installing ia32-libs-dev lets the build succeed
[06:32] <mdz> I'll do an upload
[06:33] <mdz> Mithrandir: you wrote this in the changelog, but did not actually add it to debian/control :-)
[06:35] <Kamion> I'm worried that bug #1019 may show up in a lot of other places with the new initscripts
[06:35] <Kamion> the idiom is: do stuff; log_end_msg $?
[06:36] <Kamion> which fails badly in set -e scripts, which per Debian policy (and sanity) ought to be most shell scripts
[06:37] <Kamion> set +e around the affected area is possible, but loses a lot of safety
[06:37] <Mithrandir> mdz: ew, ok, thanks
[06:39] <mdz> Kamion: that alone should not cause the script to fail, should it?  if it were set -e, then whichever command actually produced the nonzero $? would have terminated the script, no?
[06:39] <mdz> and so the log_end_msg would never be executed
[06:39] <mdz> that doesn't sound right either, of course
[06:39] <Kamion> mdz: look more closely at bug #1019; the && means set -e doesn't trigger
[06:39] <mdz> oh, i see what happened in #1019
[06:40] <Kamion> I guess one possibility would be:
[06:40] <Kamion> hm, no
[06:41] <Kamion> I can't actually think of a good way to do what we want in shell with the current API, which suggests to me that the API may need some rethinking
[06:42] <Kamion> I suppose something like this would work:
[06:42] <Kamion> CODE=0
[06:42] <Kamion> do stuff || CODE="$?"
[06:42] <Kamion> log_end_msg "$CODE"
[06:42] <Kamion> could wrap that up in a function
[06:42] <mdz> isn't there an expansion which produces the exit code of the specified command?
[06:43] <Kamion> not unless you want to do grotty stuff with command substitution, which will break if the command outputs anything
[06:43] <Kamion> I'm sure you could get around that with strategic redirections, but then you'll run into even more exciting issues
[07:01] <Kamion> mdz: can we have a debian-installer component in bugzilla so that people stop assigning bugs to libdebian-installer?
[07:01] <mdz> Kamion: yes
[07:01] <mdz> I'm surprised it hasn't seen any RC bugs in Debian
[07:02] <mdz> Kamion: done
[07:02] <Kamion> they tend to go on installation-reports in Debian, not debian-installer
[07:02] <Kamion> if they get reassigned to debian-installer they usually get un-severity-inflated first :)
[07:02] <Kamion> ta
[07:17] <pitti> mdz,Kamion: regarding bug #996: do you know any reason why to keep the IDE and SCSI device nodes root:disk 660?
[07:18] <pitti> mdz,Kamion: if we left them at 640, hald could run in this group and do media check
[07:18] <pitti> mdz,Kamion: I find'ed the whole fs for group 'disk', only the device nodes itself have it. In addition, even base-passwd's doc questions the usage of 'disk'.
[07:19] <Kamion> stuff following HELP: tags in base-passwd's documentation is not authoritative
[07:20] <pitti> Kamion: I know, but what's the actual purpose of group disk? It essentially means root access
[07:20] <Kamion> I don't think allowing hald only read access to the disk devices is all that much better than allowing it write access too
[07:20] <Kamion> given read access, you can extract the contents of /etc/shadow and elevate yourself to root
[07:20] <Kamion> so you might as well not worry about the write access
[07:20] <pitti> Kamion: but you cannot decrypt the root password
[07:21] <Kamion> in theory ...
[07:21] <pitti> Regardless of the particular group, if hald is not in the same group as (at least) the removeable device nodes, we cannot do media checking.
[07:21] <Kamion> shadow is still non-world-readable for a reason :)
[07:21] <pitti> Kamion: :-)
[07:21] <Kamion> doesn't udev allow us to put removable device nodes in a different group?
[07:21] <pitti> Kamion: Then we need a way to change the group of only the removeable devices
[07:21] <pitti> Kamion: that's exactly what we needed
[07:21] <pitti> Kamion: I can try to find a sane way
[07:22] <Kamion> group disk is fairly historical I think, but I'm reluctant to rock that particular boat because people may be using it locally
[07:22] <pitti> Kamion: I was just wondering about the purpose of disk in general
[07:22] <pitti> Kamion: agreed. 
[07:22] <pitti> Kamion: I basically see two hacks of udev:
[07:22] <pitti> either we find a way to tell them apart by bus
[07:23] <pitti> or we dynamically change the permissions file to create root.disk at the initial boot process, and then root.plugdev
[07:23] <pitti> I don't really like the second one :-)
[07:23] <pitti> Kamion: Okay, I will try to find a way to tell the devices apart in udev.
[09:17] <mdz> pitti: we definitely need to limit hal's access so that it can neither read nor write system disks
[09:17] <mdz> it must be limited to removable devices
[09:35] <pitti> mdz: yes, that would be fine. If we can modify udev to tell apart removable from fixed devices, this is no problem
[09:52] <seb128> we need a "NEEDINFO" status in the warty bugzilla
[10:22] <mako> jdub: you around?
[10:52] <jdub> mako: yo
[10:55] <mako> jdub: oh, i just sent you an email 
[10:56] <mako> jdub: i've been working on the text for the cd cover and wanted your advice.. i also knew that you had some suggestions for stuff on the front or whatever that was not pure text so that should probably go into the same doc that we give the design company
[10:56] <jdub> yo seb128 
[10:56] <jdub> mako: got it, will read :)
[10:57] <jdub>    * New upstream release:
[10:57] <jdub>      - fix osssink and alsasink broken on nforce2 (intel8x0) soundcard.
[10:57] <jdub> ^ woo ;)
[10:57] <mako> ossssssssik?
[10:58] <mako> i want ossssssink to be configurable in dssssssssl
[11:01] <ploum> jdub, I've reported this bug
[11:01] <ploum> It was fixed in 0.8.2
[11:01] <ploum> but there's a regression in 0.8.4
[11:01] <jdub> i'm quoting from seb's upload :)
[11:01] <ploum> That doesn't work anymore
[11:02] <ploum> I've reported this bug against 0.8.1
[11:02] <ploum> And I've closed it when I saw that 0.8.2 was working
[11:02] <seb128> jdub: I'm quoting the upstream NEWS file :p
[11:05] <spiv> Hmm, keyboard shortcuts seems to think Super_L is an ordinary key rather than a modifier.
[11:06] <Keybuk> yes
[11:07] <Keybuk> something between X and metacity is broken
[11:07] <jdub> that's because we all like to see daniels in his mechanic's costume
[11:08] <Keybuk> basically Super_L is missing from modifier_map Mod4
[11:58] <lamont> wow - grub built on amd64, eh?