[12:03] <jdub> she's left for work
[12:03] <jdub> hrm
[12:03] <jdub> hold on
[12:05] <jdub> it's just using /dev/ttyUSB0
[12:05] <jdub> i was thinking
[12:05] <jdub> what might be biting you is udev
[12:05] <jdub> and hotpluggy things
[12:05] <jdub> where the device name isn't there by the time gnome-pilot wants it or something
[12:05] <lamont__> almost certainly udev race condition
[12:05] <jdub> pipka doesn't use udev or anything yet
[12:06] <jdub> the person to ask about these things is jpr on gimpnet
[12:06] <lamont__> bye bye gnome-volume-manager
[12:06] <Keybuk> udev doesn't really have race conditions, as such, just things get done in the wrong order
[12:06] <jdub> the weird thing about the pilot is that the device is really only there when you press the connect butto
[12:07] <jdub> which sucks arse
[12:07] <lamont__> yeh
[12:07] <lamont__> Keybuk: like lanching the waiting app before creating the device files?
[12:07] <jdub> and unavoidable afaics
[12:07] <Keybuk> lamont__: exactly :)
[12:07] <lamont__> that'd be a race
[12:07] <Keybuk> or going to create the device files before /sys has even been populated
[12:08] <lamont__> jdub: what rate is she using on ttyUSB0?
[12:08] <lamont__> and did she call it serial, or USB>?
[12:09] <jdub> 115000 or whatever
[12:09] <jdub> USB
[12:10] <lamont__> (gpilotd:8345): gpilotd-WARNING **: pi_accept_to: Connection timed out
[12:12] <lamont__> I'm tempted to see if network sync'ing works
[12:13] <lamont__> actually, I can snarf stuff from the device with pilot-link directly, but gpilotd just doesn't want to connect
[12:24] <daniels> mdz: does setting 'key off' or 'key open' with iwconfig key?
[12:24] <daniels> s/key?/help?
[12:28] <jdub> mdz: what to do about portmap?
[12:30] <mdz> daniels: doesn't seem to
[12:30] <jdub> mdz: oh, never mind
[12:30] <jdub> found #505
[12:30] <mdz> jdub: https://bugzilla.no-name-yet.com/show_bug.cgi?id=505
[12:30] <mdz> yep
[12:31] <mdz> filed my patch there now
[12:35] <jdub> should we always be loading the freq modules and so on?
[12:35] <daniels> mdz: weird
[12:36] <jdub> oh, must be hotplugged
[12:36] <mdz> I've loaded it with ultra debugging now
[12:36] <mdz> jdub: they're loaded by the powernowd init script
[12:37] <jdub> heh, eek:
[12:37] <jdub> ubuntu:~# /etc/init.d/powernowd start
[12:37] <jdub> Loading cpufreq modules:
[12:37] <jdub>      cpufreq_powersave
[12:37] <jdub>      cpufreq_userspace
[12:37] <jdub>      freq_table
[12:37] <jdub>      proc_intf
[12:37] <jdub> WARNING: Error inserting processor (/lib/modules/2.6.8.1-1-686/kernel/drivers/acpi/processor.ko): No such device
[12:37] <jdub> FATAL: Error inserting acpi (/lib/modules/2.6.8.1-1-686/kernel/arch/i386/kernel/cpu/cpufreq/acpi.ko): Unknown symbol in module, or unknown parameter (see dmesg)
[12:37] <jdub> Starting powernowd:
[12:37] <jdub> required sysfs objects not found!
[12:37] <jdub>         Read /usr/share/doc/powernowd/README.Debian for more information.
[12:37] <jdub> 
[12:38] <mdz> this produces a great deal of output but has brought me no closer to solving the problem
[12:38] <mdz> daniels: want to take a look?
[12:38] <mdz> jdub: ask thom
[12:39] <jdub> man, i wish the assign to field had sexy completion like the component field :)
[12:40] <daniels> mdz: at the ipw stuff, or hotplug mice?
[12:40] <mdz> daniels: ipw
[12:40] <daniels> not having an ipw myself, it's kind of hard, no?
[12:41] <mdz> well, I can send you the 800 pages of debugging output I have, if you want to look at it :-)
[12:41] <jdub> hrm, what's thom's email address in bugzilla?
[12:41] <mdz> debzilla@planetarytramp
[12:41] <jdub> debzilla@planetarytramp.net
[12:41] <jdub> ahr
[12:41] <jdub> ;)
[12:42] <lamont__> jdub: gimpnet == irc.wht?
[12:42] <lamont__> irc.what, that is...
[12:42] <daniels> mdz: yeah, I can do that later on; right now I'm fixing the discover mess (sounders@) by syncing the entire PCI device lists we have in the X driver for ATI/NVIDIA/Intel/S3 back to discover
[12:42] <jdub> hrm, still have missing components all over the place :|
[12:42] <daniels> lamont__: irc.gnome.org, irc.gimp.net (or irc.gimpnet.org)
[12:42] <jdub> lamont__: irc.gimp.org or irc.gnome.org
[12:42] <lamont__> ok
[12:42] <jdub> lamont__: he's away now though
[12:42] <daniels> mdz: (and have to run my sister out to school in a sec)
[12:42] <lamont__> figures
[12:43] <jdub> lamont__: based in boston
[12:43] <jdub> heh:
[12:43] <jdub> ACPI disabled because your bios is from 00 and too old
[12:44] <mdz> jdub: dude, we have never even tried to import all the components
[12:44] <jdub> # nmap -sU -T Insane 192.168.10.214
[12:44] <jdub> Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-02 08:34 EST
[12:44] <jdub> Skipping host 192.168.10.214 due to host timeout
[12:44] <daniels> jdub: acpi=force
[12:44] <jdub> 
[12:44] <jdub> bong
[12:44] <jdub> daniels: yeah, it says that right next to it... but i don't think i want to :)
[12:45] <daniels> worked fine on my laptop (albeit with the caveat that you could kill the machine)
[12:45] <daniels> ack, :45 -- school time. bbiab.
[12:45] <jdub> mdz: sounds like RH are going with LVM by default in FC3
[12:45] <jdub> mdz: would that make sense in the general case? (desktops, laptops, etc)
[12:45] <mdz> jdub: for the root filesystem?
[12:45] <mdz> hell no
[12:46] <jdub> (depending what your general case is, yada)
[12:46] <mdz> what filesystem do they use by default?
[12:46] <jdub> ext3
[12:46] <jdub> Device 'i823650' does not have a release() function, it is broken and must be fixed.
[12:46] <jdub> Badness in device_release at drivers/base/core.c:85
[12:46] <jdub>  [<c01a4848>]  kobject_cleanup+0x98/0xa0
[12:46] <mdz> er
[12:46] <jdub>  [<d08853c3>]  init_i82365+0x1c3/0x1d9 [i82365] 
[12:46] <jdub>  [<c0133030>]  sys_init_module+0x100/0x210
[12:46] <mdz> so they use LVM by default, and a filesystem that isn't online-resizable?
[12:46] <jdub>  [<c0105fe9>]  sysenter_past_esp+0x52/0x71
[12:46] <jdub> 
[12:47] <jdub> it *sounds* like they're looking at LVM by default
[12:47] <mdz> jdub: "looking at" or "going with"?
[12:47] <jdub> going with
[12:47] <jdub> i'll fidn otu
[12:47] <mdz> yeah
[12:47] <mdz> sounds like crack so far, but maybe there's more to it
[12:47] <Keybuk> is that the "impending release" FC ?
[12:47] <Keybuk> or the next one?
[12:48] <jdub> impending
[12:48] <Keybuk> eep
[12:48] <mdz> the only point is to be able to expand the thing
[12:48] <mdz> and if they're using ext3, they can only do that when it's unmounted
[12:48] <mdz> and unmounting the root filesystem to resize it is, er, inconvenient
[12:50] <lamont__> jdub: when is a good time to catch him?
[12:50] <Keybuk> http://www.mozilla.org/
[12:50] <Keybuk> ^ pretty
[12:50] <jdub> lamont__: hrm, a few hours ago
[12:50] <jdub> lamont__: i don't really know :)
[12:50] <jdub> business hours, i guess
[12:50] <jdub> Keybuk: mmm
[12:50] <lamont__> business hours which TZ?
[12:50] <jdub> boston
[12:51] <lamont__> ok
[12:52] <mdz> jdub: did you try that mouse test?
[12:52] <mdz> it works perfectly for me
[12:53] <jdub> haven't rebooted test machine yet
[12:53] <jdub> it sounds right though
[12:54] <jdub> mdz: so, we pretty much established that the mdadm daemon only did notification, right?
[12:55] <mdz> jdub: yes
[12:55] <jdub> happy for me to upload a version that doesn't run the daemon by default?
[12:56] <mdz> I suppose
[12:56] <jdub> yo aes
[12:56] <mdz> float the idea on sounder first?
[12:56] <jdub> ok
[12:56] <mdz> it's a shame they aren't separate packages
[12:56] <aes> hey jdub
[01:04] <jdub> hrm
[01:05] <jdub> tempted to take the disks out of my desktop and do the install
[01:05] <jdub> dum de dum...
[01:05] <jdub> yes
[01:09] <Keybuk> http://www.cryptography.com/cnews/hash.html
[01:09] <Keybuk> ^ reasonably informative
[01:13] <Kamion> Keybuk: certainly some nCipher people are a bit worried about the whole thing ...
[01:14] <Keybuk> odd really, algorithms like that are only useful until their broken; and it's inevitable that they'll be broken eventually
[01:14] <mdz> that's true of all known cryptosystems, no?
[01:16] <Kamion> yeah, MD5 has been rather extensively deployed in all sorts of places though
[01:16] <Kamion> no preimage attacks though, at least, which is something
[01:17] <Kamion> but it's not such a big deal for things like the Debian archive
[01:17] <Kamion> the adversary would also have to be able to upload to Debian/Ubuntu in order to do anything with a collision attack, and at that point they can exploit the system anyway
[01:18] <mdz> or get an upload sponsored
[01:18] <Kamion> (a binary-only upload ...)
[01:18] <mdz> why binary-only?
[01:18] <mdz> theoretically if they were clever enough they could produce a source package collision, no?
[01:18] <Kamion> reference to le flamewar du jour
[01:19] <Kamion> when sponsoring I generally rebuild the source package from the unpacked source tree, and gzip contains timestamps
[01:20] <Keybuk> plus we carry/verify md5+size, rather than just md5 ... which has got to make colliding harder ?
[01:20] <Kamion> I'm not sure that's really true
[01:20] <Kamion> (intuitive though it seems0
[01:20] <Kamion> )
[01:21] <Kamion> constructing meaningful collisions of gzipped data is probably a lot harder than constructing meaningful collisions of uncompressed data though
[01:21] <Keybuk> I don't really know, it could be that the collision is more likely to be the same size for all I know :p
[01:21] <mdz> the example collision data was of equal size
[01:22] <mdz> yeah, was thinking about the gzip case
[01:22] <mdz> seems hard with embedded checksums
[01:23] <Kamion> I think with the way the hash algorithm works it's a lot easier to construct a collision by taking one piece of data and twiddling a few bits
[01:23] <Keybuk> not to mention generating a collision where X is useful for a user and Y for a hacker <g>
[01:23] <Kamion> if you look at the example collisions they're almost identical save for a few bits
[01:23] <Keybuk> then again, I suppose noop->jmp is just a bit-twiddle
[01:24] <Kamion> "/usr" -> "/tmp" isn't that far
[01:24] <Kamion> or whatever
[01:25] <hrdwrbob> but there's the likelihood of a twiddle that is useful/bad/whateever colliding
[01:25] <hrdwrbob> it's pretty slim
[01:25] <hrdwrbob> it's not 0
[01:25] <Keybuk> or more clever, if you could generate a source package which produced a binary guaranteed to have an md5 equal to a collision you've pre-prepared
[01:27] <Kamion> binary .deb => control.tar.gz + data.tar.gz => timestamps
[01:27] <Kamion> not clear that's possible in Debian
[01:27] <Kamion> (as stated, at least)
[01:27] <Keybuk> you've sufficient control over those it is
[01:28] <bdale> Kamion: question from right field.  for apt-secure, is there a particular tool typically used to generate the detached signatures, or is gpg typically scripted directly?
[01:28] <Kamion> hm, yes, debian/rules gets to run gzip, ok
[01:28] <Keybuk> it wouldn't stand much scrutiny, but then half the sponsors don't bother
[01:28] <hrdwrbob> you still have to be GOOD
[01:28] <Kamion> bdale: have to say I'm not sure, mdz would be your man
[01:28] <bdale> mdz: dude...
[01:30] <bdale> principal objective is to tell folks how to get this right when they're building small repositories for locally generated packages
[01:35] <Kamion> now, if it were me, I'd hack debsign, but ...
[01:35] <Kamion> Package: debsigs
[01:36] <Kamion> Description: applies cryptographic signatures to Debian packages
[01:36] <Kamion>  debsigs is a package that allows GPG signatures to be embedded inside Debian
[01:36] <Kamion>  packages.  These signatures can later be verified by package retrieval and
[01:36] <Kamion>  installation tools to ensure the authenticity of the contents of the
[01:36] <Kamion>  package.
[01:36] <Kamion> is that the standard approach? not sure
[01:36] <mdz> bdale: here
[01:36] <mdz> bdale: it's just a simple detached signature of Release
[01:37] <bdale> mdz: ok, cool.  any particular words of wisdom to add if I'm telling folks how to do this?  is apt-ftparchive the cool tool, I've always just used dpkg-scanpackages and dpkg-scansource ...
[01:37] <mdz> bdale: yes, apt-ftparchive is the way to go
[01:37] <mdz> bdale: it can generate Release files as well
[01:37] <bdale> right.  ok, I'll go update that slide.  
[01:38] <bdale> any known big problems with running apt 0.6 from experimental, or is it all as good as it seems?
[01:38] <mdz> bdale: you'll probably want to do a slide on apt-key as well
[01:38] <mdz> bdale: the biggest problem, as usual with these things, is key management
[01:38] <bdale> mdz: yes.  what's the right url for the current archive key to give folks?
[01:38] <mdz> if all you're doing is pointing at Debian, it ships with that key and it Just Works
[01:38] <bdale> ah, ok
[01:38] <bdale> "it" in this case is the 0.6 versions of the apt package?
[01:40] <mdz> yes
[01:40] <bdale> k
[01:40] <mdz> you can get the key via http somewhere, but I don't know the URL offhand and as I recall, it's buried somewhere on d.o
[01:40] <bdale> no worries, if it's in the package (I couldn't recall), that's fine
[01:40] <Kamion> elmo: any chance of byhand processing of debian-installer/amd64, so that I can test the required debian-cd changes?
[01:41] <Kamion> lamont__: did you set up a daily-installer-amd64 build too, BTW?
[01:41] <lamont__> Kamion: can do.
[01:41] <Kamion> ta
[01:42] <lamont__> Kamion: done
[01:43] <Kamion> great
[01:50] <Kamion> is somebody actually fixing the evolution uninstallable?
[01:51] <mdz> evolution is uninstallable?
[01:52] <Kamion> http://ftp.no-name-yet.com/cdimage/daily/current/report.html
[01:52] <Kamion> couldn't be bothered writing out the package names :-)
[01:52] <mdz> ah, those are actually not part of the evolution{,1.5} source package I don't think
[01:53] <tvon|x31> Post-install I was able to install evolution1.5, but during install it failed
[01:54] <Kamion> at the moment you have to do it using aptitude by hand
[01:54] <Kamion> which is annoying
[01:57] <Kamion> yargh, and you have to set the debconf priority if you do that ...
[02:06] <jdub> hrm
[02:06] <jdub> the installer is much faster on decent hardware ;)
[02:06] <mdz> jdub: bugs incoming
[02:07] <jdub> mdz: evo stuff?
[02:07] <mdz> yes
[02:07] <mdz> -exchange and -webcal
[02:07] <jdub> need the new version for those
[02:07] <mdz> they break the desktop install
[02:08] <jdub> mmm, but i need the new version of evo and e-d-s
[02:11] <jdub> thom: around?
[02:11] <mdz> Kamion: why doesn't evolution1.5 install on its own?  was it missing when the CD was built or something?
[02:12] <bdale> mdz: what's this about?
[02:12] <bdale> wartylog: GPG error: http://www.gag.com unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
[02:12] <bdale> wartylog: You may want to run apt-get update to correct these problems
[02:12] <bdale> gah, xchat substitution strikes again...
[02:13] <mdz> bdale: you are pointing at an archive with a Release file signed by a key that you haven't told apt to trust
[02:13] <mdz> it only trusts the Debian key by default
[02:13] <bdale> mdz: well, that ought to be the current Debian unstable Release file...
[02:13] <Kamion> mdz: works for me; do you just mean the way aptitude won't install anything if one piece of the task is uninstallable?
[02:13] <mdz> 30B34DD5 is the current Debian one
[02:14] <mdz> Kamion: oh, so it's just fallout from the evolution-* uninstallability then?
[02:14] <Kamion> mdz: well, when I do it using aptitude by hand then I get evolution1.5 installed, so I guess so
[02:16] <bdale> mdz: installing apt 0.6.25 gave me this for a key:
[02:16] <bdale> pub  1024R/1DB114E0 2004-01-15 Debian Archive Automatic Signing Key (2004) <ftpmaster@debian.org>
[02:16] <mdz> ah, right. sorry
[02:16] <bdale> mdz: so, I gather this means the apt pkg in experimental is actually out of date relative to the current key...
[02:16] <mdz> that is the correct key
[02:16] <mdz> also
[02:16] <mdz> 30B34DD5 is the 2003v2 key
[02:16] <mdz> 1DB114E0 is the 2004 key
[02:17] <mdz> neither of those is 1F41B907, which is what the www.gag.com archive seems to be signed with
[02:18] <mdz> ced47e86013bedc052f5f2180131f523  /var/lib/apt/lists/debian_dists_unstable_Release.gpg
[02:18] <bdale> matches
[02:18] <bdale> checking local machine
[02:18] <mdz> mizar:[/var/lib/apt/lists]  gpg --verify debian_dists_unstable_Release{.gpg,}
[02:18] <mdz> gpg: Signature made Wed 01 Sep 2004 12:33:16 PM PDT using RSA key ID 1DB114E0
[02:18] <mdz> gpg: Good signature from "Debian Archive Automatic Signing Key (2004) <ftpmaster@debian.org>"
[02:19] <bdale> ced47e86013bedc052f5f2180131f523  /var/lib/apt/lists/www.gag.com_debian_master_dists_sid_Release.gpg
[02:19] <mdz> fascinating
[02:19] <bdale> hrm
[02:19] <bdale> maybe that's not the file it's bitching about
[02:20] <mdz> I've never seen that fingerprint before
[02:20] <bdale> on the other hand, that's the only Release.gpg file in my /var/lib/apt/lists dir 
[02:20] <mdz> mizar:[/var/lib/apt/lists]  gpg --keyserver keyring.debian.org --recv-keys 1F41B907
[02:20] <mdz> gpg: key 1F41B907: "Christian Marillat <marillat.christian@wanadoo.fr>" not changed
[02:20] <bdale> aha
[02:21] <bdale> I have one of Christian's repositories in my sources.list
[02:21] <mdz> on www.gag.com also, apparently
[02:21] <bdale> via apt-proxy
[02:21] <bdale> www.gag.com:9999_marillat_dists_unstable_Release
[02:21] <bdale> www.gag.com:9999_marillat_dists_unstable_main_binary-i386_Packages
[02:21] <Kamion> can't we make apt report the path as well as the scheme+host?
[02:21] <mdz> Kamion: we can, but it makes the output awfully unreadable
[02:21] <Kamion> that always struck me as a fundamental UI crapness
[02:21] <mdz> bdale: the .gpg doesn't get moved into place if it's no good
[02:21] <Kamion> the output is currently incomprehensible, which is worse I feel ...
[02:22] <bdale> mdz: aha
[02:22] <bdale> mdz: so, I need to give Christian's key to apt-key then...
[02:22] <mdz> yep
[02:22] <mdz> gpg --export ... | apt-key add -
[02:22] <Kamion> at the very least error messages should be complete, even if you'd prefer not to change progress messages (which I can sympathize with)
[02:23] <mdz> Kamion: they use the same method, which is the root of the issue I suppose
[02:23] <bdale> mdz: bingo.  thanks for the help.
[02:24] <mdz> Kamion: pkgSourceList::Describe, I believe
[02:25] <mdz> er, pkgIndexFile::Describe
[02:25] <mdz> bdale: no problem
[02:26] <mdz> string debSourcesIndex::Info(const char *Type) const
[02:26] <mdz> {
[02:26] <mdz>    string Info = ::URI::SiteOnly(URI) + ' ';
[02:26] <mdz> Kamion: hmm, it actually does that explicitly
[02:27] <mdz> I bet the default status display wraps >80 characters if it does the whole thing, which would be why it was done that way in the first place
[02:28] <Kamion> yeah
[02:33] <jdub> mdz: okay, so;
[02:33] <jdub> mdz: fixing gnome-system-tools itself is going to be error-prone and time-consuming.
[02:33] <jdub> mdz: so i'm going to fix their launchers to gksudo first,
[02:33] <mdz> jdub: :-(
[02:33] <jdub> mdz: and fix other places where they're launched
[02:34] <jdub> (from the clock applet, netstatus applet, etc)
[02:34] <mdz> that means the whole frontend would run as root
[02:34] <jdub> yes
[02:34] <mdz> so it goes
[02:35] <jdub> i'll talk to garnacho about how to deal with this better in future
[02:35] <jdub> it's pretty obvious that implementing all of this within g-s-t is a bad idea
[02:36] <jdub> mdz: sound okay?
[02:36] <mdz> jdub: doesn't make my skin crawl, if that's what you're asking :-)
[02:36] <jdub> :)
[02:37] <jdub> mdz: also, without samba, the windows networking section in g-s-t doesn't work
[02:37] <jdub> how much do we care?
[02:37] <mdz> jdub: ick, why not?
[02:37] <mdz> I thought it basically just let you set your workgroup name
[02:37] <jdub> "You don't have SMB support installed. Please install SMB support in the system to enable file sharing in Windows networks"
[02:37] <jdub> and wins server and so on, but samba needs to be there for that to work :)
[02:37] <bdale> grrr.
[02:37] <bdale> Provides: libapt-pkg-libc6.3-5-3.5
[02:38] <bdale> lots of stuff wants -3.3 ... any reason not to hack in a second provide to shut it up?
[02:38] <mdz> bdale: yes, because they are incompatible
[02:38] <mdz> bdale: welcome to my personal hell
[02:38] <mdz> stuff should generally recompile cleanly against the new lib
[02:39] <mdz> at one point I was doing regular NMUs of libapt-linking stuff to experimental to keep up
[02:39] <mdz> but it was a losing battle
[02:39] <bdale> yeah, I bet
[02:39] <mdz> the maintainer would upload a new version to unstable, and the one in experimental would disappear from the archive
[02:44] <bdale> mdz: so, I'm downgrading back to 0.5.27 for now... sigh
[02:46] <mdz> :-(
[02:46] <mdz> apt-get source -b is your friend :-)
[03:31] <bdale> mdz: I'll try again when I'm not t-minus a few hours from needing my notebook for a talk...  ;-)  Like, next week.
[03:44] <tvon|x31> wtf
[03:44] <tvon|x31> ah, nm
[04:38] <tvon|x31> unstable mono packages work in Ubuntu...without sucking in non-mono deps
[04:38] <tvon|x31> if...anyone cares
[04:40] <jdub> tvon|x31: cool
[04:41] <jdub> tvon|x31: we'll work out what we're doing with mono officially for hoary
[04:42] <tvon|x31> I realize there are bigger fish to fry at the moment :)
[05:05] <jdub> ugh
[05:05] <jdub> dpatch is poo
[05:47] <tvon|x31> Is gnome-system-tools slated to be patched to get around the root password (with some sudo setup)?
[05:47] <hrdwrbob> yes
[05:47] <tvon|x31> Nifty
 mdz: fixing gnome-system-tools itself is going to be error-prone and time-consuming.
 mdz: so i'm going to fix their launchers to gksudo first,
[05:48] <tvon|x31> ah, nice
[05:48] <hrdwrbob> well, not entirely optimal
[05:48] <hrdwrbob> but yeah, the basic end user effect is it will work :)
[05:48] <jdub> definitely not claiming it's optimal
[05:48] <tvon|x31> 'nice' == 'working' a lot of the time for me :)
[05:49] <jdub> currently wrangling gnome-cups-manager and libgnomecups to do the same
[05:49] <jdub> though i might just be stuck with gksudo in the gnome-cups-manager launcher again :|
[05:50] <jdub> gnome-cups-add is fine
[05:50] <jdub> but the 'become administrator' bit in gnome-cups-manager isn't
[05:50] <jdub> mdz: around?
[06:26] <mdz> jdub: yep
[06:27] <jdub> mdz: might be wiser for pitti to look into the gnome-cups-manager issue
[06:40] <mdz> jdub: I CCed him on the bug
[06:40] <mdz> since he has already done some work with it
[06:42] <jdub> ok
[06:42] <jdub> oh, thought that was him being interested
[06:42] <jdub> ;)
[06:43] <fabbione> morning guys
[06:43] <lamont__> mdz: what's the current thinking on ruby1.8?
[06:44] <mdz> lamont__: you requested a sync, and I approved it
[06:44] <mdz> the rest is up to elmo
[06:44] <jdub> hrm
[06:44] <jdub> why isn't contact-lookup-applet in the archive?
[06:45] <mdz> because it's only in experimental, and nobody requested that it be added to warty?
[06:51] <jdub> hrm, it's on germinate :|
[06:51] <jdub> we're still manually syncing experimental stuff?
[06:53] <lamont__> jdub: all of the syncs are now manual...
[06:53] <lamont__> that is, nothing autosyncs for warty anymore
[06:53] <lamont__> since upstream version freeze... :)
[07:10] <AndyFitz> night
[07:10] <fabbione> night lamont__ 
[07:20] <pitti> mdz: still awake?
[07:25] <pitti> elmo: there?
[07:45] <fabbione> oh finally i got my d-i test machine back
[07:56] <fabbione> i don't want to go to the dentist :((((
[07:56] <fabbione> i want to hack on X today :(((
[07:59] <pitti> fabbione: Ugh, dentist? My condolence!
[07:59] <pitti> fabbione: chmod 700 /dev/teeth? Then he cannot hurt you any more?
[08:00] <fabbione> pitti: i am not scared of the dentist or the pain
[08:00] <fabbione> it pisses me off the time i have to spend to go there, get treated and come back
[08:00] <fabbione> and the money i have to pay
[08:01] <hrdwrbob> yes, LOTS of money
[08:01] <fabbione> i consider myself lucky
[08:01] <fabbione> i had to do only a few holes and a couple of root canals (together)(
[08:02] <fabbione> and today i only have to do the final refill for the root canals
[08:05] <pitti> fabbione: this _does_ sound scary. I don't like dentists.
[08:05] <pitti> fabbione: good luck!
[08:06] <fabbione> well it's like opening two temporary holes and close them again
[08:06] <fabbione> but thanks
[08:15] <fabbione> Developers: Gnome 2.8 RC1 Released
[08:15] <fabbione> :-)
[08:15] <fabbione> i expect seb to do a lot of uploads today :)
[08:23] <mdz> pitti: yes
[08:24] <pitti> mdz: In the meantime I wrote a mail on sounders about the sudo stuff.
[08:24] <pitti> mdz: I looked at your patches, looks good.
[08:24] <pitti> mdz: but why do you think snprintf is better than strncat?
[08:25] <pitti> mdz: printf is quite expensive and has a lot more code than strncat, doesn't it?
[08:32] <fabbione> daily is broken... evo needs to be fixed
[08:33] <fabbione> jdub: are you going to fix it???
[08:41] <mdz> pitti: snprintf operates in terms of the available storage
[08:41] <mdz> pitti: while strncat requires that you calculate it
[08:41] <mdz> so snprintf is less error prone
[08:42] <pitti> mdz: okay; I already incorporated the fixes; I will also restrict it to the plugdev group in today's upload
[08:42] <mdz> ok
[08:42] <pitti> mdz: if we leave mount/umount unrestricted this does not really fulfill the SecurityPolicy because all users still can mount CD-ROMS (with are in fstab)
[08:42] <pitti> mdz: s/with/which/
[08:43] <mdz> pitti: can't we stop adding CD-ROMs to fstab if we use pmount?
[08:43] <pitti> mdz: of course we can; yesterday's upload added the CD-ROM file systems
[08:43] <pitti> mdz: but before we actually do this, unmounting in Nautilus should work
[08:44] <ik5pvx> fabbione, running an upgrade from aptitude right now, X asked me what about my video card... I have not reinstalled the autodetection tools since the tests of 2 days ago
[08:44] <ik5pvx> I suppose this is a good thing
[08:44] <fabbione> hmmm 
[08:44] <fabbione> it shouldn't ask on updates
[08:45] <ik5pvx> after those tests, I put back the working config and also restored the corresponding md5 in /var/whateveritis
[08:48] <fabbione> yes.. that's not the problem...
[08:48] <fabbione> i missed a check in postinst
[08:48] <fabbione> thanks for noticing it
[08:49] <daniels> fabbione: 1792 is busted
[08:49] <fabbione> daniels: you are busted
[08:49] <fabbione> i tested it
[08:49] <fabbione> try before and after
[08:49] <daniels> fabbione: no it's not, my bad
[08:49] <daniels> i misinterpreted the ")
[08:49] <fabbione> and tell me what is busted :)
[08:49] <daniels> (read "$(date "foo") ..." as "$(date foo")
[08:51] <pitti> mdz: if you install pmount on a system without the plugdev group, what do you think should be done?
[08:51] <daniels> fabbione: sorry
[08:51] <pitti> mdz: installation fails, unrestricted pmount, create group plugdev?
[08:51] <fabbione> daniels: tsk :P
[08:59] <cef_work> daniels: typical.. sometimes I do wonder how you actually write any code.. *grin*
[09:01] <daniels> cef_work: ber
[09:08] <mdz> pitti: I need to go to sleep; let's talk about it in the morning
[09:08] <pitti> mdz: good night!
[09:31] <ik5pvx> fabbione, fwiw the config works as is
[09:35] <fabbione> ok thanks
[09:42] <daniels> fabbione: backporting the ati driver from x.org cvs this late in the game for r4xx support (or even just the relevant patch from ati); thoughts?
[09:50] <fabbione> daniels: nope.. we are too close to release to introduce new bugs
[09:50] <fabbione> it will hoary stuff
[09:50] <fabbione> sorry
[09:52] <daniels> sux :\
[09:52] <daniels> what about the ati code drop only, which only introduces new code paths for new cards?
[09:53] <daniels> without this, we don't have 2d support for new cards
[09:53] <daniels> i can see both sides, tbh
[09:56] <fabbione> dude.. no new untested code
[09:56] <fabbione> it won
[09:56] <fabbione> it won't get enough testing
[09:57] <fabbione> but also.. discuss the issue with mdz
[09:57] <fabbione> because if there are important bug fixes than it's ok by me
[09:57] <fabbione> later guys
[10:01] <daniels> ok
[10:02] <daniels> basically, it's new card support only: not touching existing codepath. it's r4xx (x800, pci-x cards) support. depends whether you think relatively untested (it'll be in the x11r6.8 release, due tomorrow) ati code or vesa is better :)
[10:02] <daniels> mdz: ^^ thoughts?
[11:06] <seb128> hello
[11:07] <seb128> Oskuro: here ?
[11:07] <Oskuro> yes
[11:09] <seb128> Oskuro: 2 things
[11:09] <thom> jdub: yes ;-)
[11:09] <seb128> first I've a problem with OO.o because of the ca translation in a patch
[11:09] <seb128> which is not valid utf-8 and fuck the desktop file totally
[11:09] <Oskuro> ok, that's easy to fix.
[11:10] <seb128> openoffice.org-1.1.2/ooo-build/patches/OOO_1_1/sysui-translations.diff
[11:10] <Oskuro> well, nothing is valid utf here
[11:10] <Oskuro> there's a mixture of charsets
[11:10] <seb128> hum
[11:11] <seb128> the only problem here is the ca translation for "calcul" (with some accents)
[11:11] <seb128> if I remove the 3 lines with this I can open it with gedit in utf-8 and the MimeType parser doesn't fail
[11:12] <Oskuro> is "presentaci" ok where french reads  fr = "Modle de prsentation %PRODUCTNAME"
[11:12] <seb128> others translations are perhaps not utf-8 but they don't screw gedit :)
[11:12] <seb128> hum, I don't get the question
[11:13] <seb128> I'm extraction de oo.o source, a min
[11:14] <greebo> rah!
[11:21] <seb128> Oskuro: still here ?
[11:33] <seb128> Oskuro: !!
[11:33] <daniels> seb128: ping
[11:33] <daniels> greebo: dude!
[11:34] <seb128> daniels: I've seen your comment on the bug, let it open if you want but we have no build problem so that's no a priority for the moment (the hal support is not even turned on)
[11:35] <daniels> seb128: yeah, i'll downgrade severity
[11:35] <daniels> ahr, normal will do just fine i think
[11:38] <seb128> yes
[11:38] <seb128> and let Oskuro searching where is the problem :p
[11:44] <daniels> heh
[11:48] <greebo> daniels: yo
[11:52] <Kamion> mdz: stopping adding /cdrom to fstab is non-trivially fiddly, because integration between d-i and base-config is involved there
[11:58] <jdub> thom: hrm, yes to which? :)
[11:59] <ross> jdub: new install mockup in the mail to you
[12:03] <jdub> ross: got it
[12:03] <jdub> ross: will reply after dinner :)
[12:04] <ross> ok
[12:04] <crevette1> hello
[12:04] <thom> jdub: to being awake ;-)
[12:04] <jdub> thom: ah :)
[12:06] <crevette> How to get the behaviour of password/sudo of a vanilla ubuntu applied on my debian 'ubuntued' ?
[12:06] <thom> jdub: what's up?
[12:16] <pitti> Kamion: with the current pmount policy IDE CD-ROMs cannot be pmounted anyway because IDE devices are not "removeable"
[12:17] <pitti> Kamion: I did not think about that this morning
[12:17] <pitti> Kamion: so the CD-ROMs should stay in fstab until we change this policy
[12:37] <jdub> thom: i don't remember
[12:38] <Mithrandir> pitti: how about scsi devices?
[12:38] <thom> loser :-)
[12:47] <pitti> Mithrandir: by now we only accept USB and FireWire
[12:47] <pitti> Mithrandir: But I just made an interesting discovery: from kernel 2.6.8 on, there is a /sys/block/*/removeable file
[12:48] <pitti> Mithrandir: of course we accept SCSI devices that are actually USB devices
[12:54] <seb128> is ubuntu-artwork supposed to be a debian native package ?
[12:55] <Oskuro> sounds like a debian native package to me
[12:56] <thom> seb128: that sounds reasonable
[12:56] <seb128> ok, because it has no orig.tar.gz but the version number is 0.1-14
[12:57] <seb128> that's not coherent
[12:57] <Oskuro> I would make it 0.1.14
[12:58] <Kamion> agreed
[12:58] <seb128> ok, I'm going to do this, thanks
[01:01] <Mithrandir> pitti: ok.
[01:01] <thom> Kamion: i think pbbuttonsd has a library, i believe
[01:02] <thom> wow, i sound really sure of that
[01:02] <Mithrandir> thom: I think you forgot "possibly" or "maybe" in your sentence.
[01:02] <thom> heh
[01:09] <jdub> seb128: don't depend on suede-icons though
[01:10] <seb128> jdub: why ?
[01:10] <seb128> jdub: we got 2 reports in one day because of "paper icons"
[01:10] <jdub> yeah, but that's not the right fix
[01:10] <jdub> i'll upload tonight
[01:10] <seb128> what's the right fix ?
[01:10] <seb128> it's fair to get the artwork depending on an icon theme
[01:11] <jdub> yes, but we don't want suede icons in ubuntu :)
[01:11] <jdub> the right fix is to fix the theme definition fallbacks
[01:11] <seb128> it fallbacks on hicolor I think
[02:10] <fabbione> re
[02:10] <thom> imendio is the company that wrote gossip
[02:10] <SteveA> oh
[02:11] <SteveA> ok, that figures
[02:11] <SteveA> I thought my l10n had gone wrong
[02:11] <SteveA> and was telling me something in spanish / latin / italian ;-)
[02:11] <SteveA> romainan
[02:19] <Kamion> aha, base-config's pkgsel error path is much nicer now
[02:21] <Oskuro> It's not very good looking, that imendio branding.
[02:21] <Oskuro> but oh well.
[02:22] <Oskuro> I considered not adding it in the ca translation. :) But that's evil.
[02:34] <fabbione> Kamion: in today's install i noticed some errors while base-config was starting, but i could catch them
[02:34] <fabbione> Kamion: i think it was something about perl
[02:34] <fabbione> but i really can't be sure
[02:37] <Kamion> yes, I've noticed those, I transcribed them once
[02:37] <Kamion> Use of uninitialized value in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 83.
[02:37] <Kamion> Use of uninitialized value in exists at /usr/share/perl5/Debconf/Template.pm line 66.
[02:37] <Kamion> Use of uninitialized value in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 29.
[02:37] <Kamion> Use of uninitialized value in exists at /usr/share/perl5/Debconf/Template.pm line 66.
[02:37] <Kamion> Use of uninitialized value in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 29.
[02:37] <Kamion> joeyh and I think it's something to do with the debconf database not being set up properly yet, but we aren't sure
[02:38] <Kamion> it's hard to catch because at least four of them go away after base-config runs :(
[02:39] <Kamion> should the pop-up text on the Help button say "Get help with Ubuntu" rather than "Get help with GNOME"?
[02:39] <fabbione> Kamion: ok..
[02:40] <Kamion> hm, and Firefox starts up with the lower panel overlapping it by default ...
[02:40] <fabbione> you can still stick a sleep before base-config runs
[02:40] <fabbione> and see what happens.. do you want me to do it?
[02:40] <Kamion> if you like
[02:40] <Kamion> you'll have to perl -d your way through debconf, though, I suspect
[02:41] <fabbione> Kamion: well i can grab the errors, but my priority is to fix some more bugs in X and fix evo build-dep
[02:41] <fabbione> jdub: dude?
[02:41] <Kamion> fabbione: it's ok, I've got the errors
[02:41] <fabbione> ok than
[02:42] <Kamion> you get the first error if you invoke 'base-config new' again, but not the others
[02:44] <fabbione> weird
[02:44] <fabbione> but it's the first time i notice them
[02:44] <Kamion> presumably because it's set up the debconf database by after that
[02:44] <Kamion> oh, it's been there for some time, I've seen it ...
[02:45] <Kamion> ok, so at least the first one is from debconf-copydb
[02:45] <Kamion> aha, removing /var/cache/debconf/* reawakens the errors
[02:46] <Kamion> I'll do a fresh install, make sure base-config doesn't get to run, and try it by hand
[02:46] <Kamion> scratch-laptops++
[02:46] <fabbione> lib64 aren't installable in warty
[02:50] <Kamion> elmo: is katie configured to be happy to e-mail anything@canonical.com?
[02:56] <fabbione> ok.. evolution-webcal is fixed
[02:56] <fabbione> the other one it's also a FTBFS
[02:57] <fabbione> so we need jdub for it
[02:59] <fabbione> Mithrandir: for / on lvm2 on raid, my best guess is lvm2.
[03:00] <fabbione> Mithrandir: but i will check it, if you didn't do it already
[03:03] <ross> is there a schedule for another test CD shortly?
[03:12] <Kamion> fabbione: aha, I see the problem
[03:13] <fabbione> cool
[03:14] <seb128> fabbione: jdub is waiting for the new libsoup/gtkhtml/evolution packages to fix evolution-*
[03:14] <seb128> fabbione: I was kind of waiting for kitame packages in debian to spare some work, usually he packages them pretty quickly
[03:15] <Kamion> fabbione: base-config needs to have entries in debian/templates for all the questions whose values it copies from the d-i cdebconf database
[03:16] <Kamion> YA base-config upload coming up
[03:16] <Kamion> was missing ubuntu/install-type
[03:18] <Kamion> ross: this coming Monday (in theory; might end up being Tuesday)
[03:18] <Kamion> if all the uninstallables are fixed by Monday it'll be then :-)
[03:18] <ross> cool
[03:18] <ross> we might roll it onto another machine or two here
[03:19] <ross> i take it the gksu/sudo magic will still handle the case where normal users don't have any sudo rights?
[03:19] <ross> normal users here are *not* getting root access :)
[03:19] <Kamion> if they don't have sudo rights, gksu won't let them in ...
[03:20] <Kamion> s/gksu/gksudo/
[03:20] <ross> at the moment pressing synaptic calls gksu which asks for the root password
[03:20] <HcE> hmmm
[03:20] <ross> i understand this is changing to asking for the users password for sudo
[03:20] <Kamion> yeah
[03:21] <fabbione> Kamion: ahhhh i see..
[03:21] <fabbione> seb128: well the problem is that warty is not installable atm.
[03:21] <fabbione> seb128: and all dailys are crack
[03:21] <fabbione> at 2 weeks from release we can't really wait too long
[03:21] <seb128> fabbione: outch, ok
[03:21] <fabbione> evolution-webcal is fixed.. a recompilation was enough
[03:22] <fabbione> just to fix the dependencies
[03:22] <Kamion> I can roll a daily which does the drop-to-aptitude thing, which is less bad
[03:22] <fabbione> but the other one is FTBFS
[03:22] <Kamion> well, I can once some buildd uploads it, that is
[03:22] <seb128> I'll try to update evolution this afternoon
[03:23] <fabbione> seb128: ok thanks.
[03:23] <fabbione> oh and hoary season is open from yesterday :-)))
[03:24] <Kamion> hoary Packages files look empty to me
[03:24] <fabbione> Kamion: i was kidding.. really
[03:25] <fabbione> but yes.. they are empty...
[03:25] <fabbione> elmo: is there any reason for that?
[03:32] <HcE> anybody knows about a ftp-mirror to the sounder-test7?
[03:32] <HcE> preferably in Norway
[03:32] <HcE> Mithrandir machine perhaps :)
[03:33] <fabbione> HcE: there are no official mirrors atm
[03:33] <HcE> fabbione: I know, but AFAIK Mithrandir got the .img on his computer
[03:53] <HcE> Mithrandir: don't need you mirror now, finnaly got the image down
[04:11] <SleepBoB> jdub: why is mp3 encumbered?
[04:11] <Kamion> mp3 is patented up the wazoo
[04:13] <SleepBoB> as far as I was aware playback was not particularly encumbered
[04:13] <SleepBoB> but encoding was a problem
[04:14] <SteveA> f'hofer want money for playback software.  they have a webpage listing their rates.
[04:14] <SleepBoB> ah
[04:14] <SleepBoB> bastards
[04:15] <SteveA> less money than for encoding
[04:15] <SteveA> but still...
[04:15] <SleepBoB> We (and Thomson) have (as far as we can determine, of course) unavoidable patent rights on Layer-3 encoding and decoding. We just are not enforcing the decoder rights on decoders which are software only and have been written by some freeware author (i.e. are freeware). Please understand that this sentence does not mean that I give an implied decoder license to everybody writing freeware code, I am not in the formal position to do this.
[04:15] <SleepBoB> http://www.mpeg.org/MPEG/mp3-licensing.html
[04:16] <SleepBoB> though that's from 1998
[04:21] <Kamion> SleepBoB: right, Debian are probably reasonably OK, but we're actually backed by money that it would be worth Fraunhofer's time suing for
[04:22] <SleepBoB> yeah just curious about the exact legalities
[04:22] <SleepBoB> it seems sort of similar to the prism thing
[04:22] <SleepBoB> 'we probably won't sue you'
[04:22] <SleepBoB> where it's not worth the risk
[04:23] <Kamion> also we don't want to screw over potential commercial derivatives of us
[04:23] <SleepBoB> software patents make bob angry :(
[04:31] <fabbione> seb128: pinf
[04:31] <fabbione> f = flood :-)
[04:34] <seb128> ponf ? :p
[04:34] <fabbione> seb128: gnome-games
[04:34] <seb128> yes ?
[04:34] <fabbione> iagno claims to have network support
[04:34] <fabbione> how is it supposed to be configured?
[04:36] <seb128> good question ...
[04:36] <fabbione> i guess the same goes for other "standard" gnome games
[04:36] <fabbione> or goodies
[04:36] <seb128> "The game server for iagno is now
[04:36] <seb128> available for local use, it can be found in the libgames-support
[04:36] <seb128> directory."
[04:36] <seb128> hum
[04:38] <seb128> the content of this dir is not build, perhaps a missing configure flag
[04:42] <lamont__> mdz around?
[04:43] <lamont__> ./me thinks the author of 972 is on crack - non-world-readable homedirs is the answer he's looking for, not a different default umask
[04:44] <thom> lamont__: +1
[04:54] <Kamion> god yes, he's mad
[04:56] <elmo> haha, jari alto's famous
[04:59] <Hrdwr_BoB> ctrl+x is not cut in xchat.
[04:59] <seb128> in the text entry section ?
[04:59] <seb128> it is here
[05:00] <Hrdwr_BoB> maybe I have a slightly old version
[05:00] <Hrdwr_BoB> 2.0.8
[05:00] <lamont__> fabbione: nvidia-kernel?  puke
[05:00] <seb128> afaik it works for ages
[05:01] <Hrdwr_BoB> maybe I wasn't focused correctly in the text entry section, but it quit :/
[05:01] <lamont__> Hrdwr_BoB: that's a feature. :-)
[05:01] <fabbione> lamont__: that's what debian does..
[05:01] <fabbione> i don't want a nvidia kernel
[05:02] <lamont__> fabbione: even if mdz didn't kill you, I would....
[05:02] <lamont__> I agree 1000%
[05:02] <fabbione> ehehhe
[05:03] <fabbione> lamont__: probably the easiest is to just compile locally the module and make a deb out of it
[05:03] <lamont__> yeah
[05:04] <fabbione> since it needs the running kernel and all that nice crap
[05:04] <lamont__> bbiab
[05:04] <fabbione> later
[05:22] <Hrdwr_BoB> If there was no users - the fact that mail was broken wouldn't even matter.
[05:23] <Hrdwr_BoB> and with that, I bid you goodnight
[05:24] <thom> which other binary kernel modules do we have?
[05:32] <fabbione> no idea.. afaik only the nvidia
[05:33] <fabbione> that needs manual compilation on i386 and amd64
[05:33] <fabbione> because it needs the running kernel
[05:33] <fabbione> because it needs to be compiled on the running kernel
[05:33] <thom> 'swhat i thought
[05:34] <thom> why is mark claiming otherwise
[05:34] <fabbione> we need to take a look at how debian does
[05:34] <fabbione> thom: no idea...
[05:37] <fabbione> we also decided not to ship binary drivers..
[05:37] <fabbione> and stick them in restricted
[05:38] <fabbione> on fresh install is impossible for me to know that the nvidia driver will be eventually installed
[05:38] <fabbione> possibly a "wrapper" driver could do
[05:38] <thom> yeah
[05:38] <ross> so why is warty "ubuntu 4.1" in the login prompt?
[05:38] <fabbione> if it finds nvidia than goes for it
[05:38] <thom> 2004 10
[05:38] <ross> i see
[05:39] <thom> next will be 5.4 :-)
[05:39] <ross> seems like a lame excuse for a crack-brained versioning scheme to me
[05:39] <ross> hp's metacity versioning was far better
[05:39] <thom> random numbers
[05:39] <thom> ?
[05:39] <ross> fibonacci series
[05:40] <spiv> ross: Two version "1"s? ;)
[05:40] <thom> heh
[05:41] <ross> spiv: early versions were unreleased, i guess one of those was the first "1"
[05:43] <Keybuk> ross: it's Mark's versioning scheme
[05:44] <Mithrandir> HcE: you don't make sense, but I guess that's ok.
[05:44] <Keybuk> isn't it 4.10 anyway?
[05:45] <HcE> Mithrandir: do you have a ftp/apache running on your machine at school/samfundet with sounder images?
[05:46] <Mithrandir> HcE: I'm rsyncing it down to vawad now, but the wlan here sucks a bit.
[05:46] <Mithrandir> only 250kB/sec.
[05:46] <Mithrandir> so ~30 minutes
[05:47] <HcE> Mithrandir: ok
[05:47] <HcE> Mithrandir: I got the image burned already now
[05:47] <Mithrandir> ok, I'll just stop it, then
[05:47] <Mithrandir> no use in wasting precious battery on that
[05:47] <HcE> haha
[05:48] <HcE> Mithrandir: by a pentium-m laptop :P
[05:48] <Mithrandir> HcE: I'm going to get an X40 for xmas, I think.
[05:48] <HcE> *grmf*
[05:48] <Mithrandir> with all the extra batteries I can get my hands on.
[05:48] <HcE> hehe
[05:49] <thom> *g*
[05:55] <ross> man, i'd love it if ubuntu asked "do you want to allow ldap logins" on install, and magically fiddled nsswitch/pam.d
[05:55] <tvon|x31> I think fedora allows fairly simple setup of things like that on install
[05:56] <tvon|x31> Granted I've never actually tried it beyond clicking a few buttons to see what it asked for next
[05:56] <ross> the pam.d fiddling isn't totally trivial, which is the annoying part
[06:00] <thom> tvon|x31: i've never seen it work right, plus there are 3 ldap.conf uder /etc in fedora
[06:04] <npmccallum> does james henstridge idle in here?
[06:06] <thom> don't think i've seen him here, #warthogs or #g-h is probably a better bet...
[06:06] <Keybuk> no, I think he tends to /quit anyway
[06:06] <Keybuk> he's on .AU time, so it's about 3am there
[06:27] <npmccallum> Keybuk: with English becoming such a universal language, we should just switch everyone to EST as well ;) (JK!!!)
[06:28] <thom> well, since it's English, we're sorted. Universal time is GMT :P
[06:32] <Keybuk> thom: and what time (GMT) did you get up? :p
[06:33] <thom> 08:30
[07:07] <tvon|x31> Should gnome-vfs have hal support?
[07:08] <tvon|x31> s/should/does/
[07:10] <seb128> no
[07:10] <seb128> we turned it off
[07:10] <seb128> some serious issue with it and no real benefit
[07:37] <pitti> mdz: I fixed jackd/jackstart. Want to take a look at the interdiff before I upload?
[07:46] <pitti> mdz: http://www.no-name-yet.com/patches/jack-audio-connection-kit.fix-capabilities.diff
[08:05] <mdz> pitti: ok, will do
[08:06] <mdz> pitti: looks good to me
[08:08] <mdz> lamont__: ping
[08:16] <pitti> mdz: regarding pmount, I lied this morning: it is not currently possible to pmount CD-ROMs since they are usually IDE devices which we don't consider removeable
[08:16] <mdz> pitti: ah
[08:16] <pitti> mdz: one thing that could help comes with kernel 2.6.8
[08:16] <mdz> pitti: have you tested the 2.6.8 kernel yet?
[08:16] <pitti> mdz: there are now files /sys/block/whatever/removable :-)
[08:17] <mdz> I posted information to the sounder list
[08:17] <pitti> mdz: not the ubuntu one; is there already a ppc build?
[08:17] <pitti> mdz: I currently run upstream
[08:17] <pitti> mdz: we could extend the policy of pmount: if removable exists and contains 1, we could allow the pmount. What do you think?
[08:18] <mdz> pitti: no, the powerpc build is not available yet
[08:18] <pitti> mdz: but eventually we will ship 2.6.8 with warty, will we?
[08:19] <pitti> mdz: the problem is that for finding this removable file, a lot of new code had to go into pmount since then it needs to recursively scan the whole /sys/block hierarchy
[08:19] <lamont__> mdz: yo
[08:19] <pitti> mdz: I'm almost apt to say 'let CD-ROM stay in fstab and handle this in Hoary'...
[08:20] <mdz> lamont__: what's the story on those tetex bugs?  I thought we synched those
[08:20] <mdz> pitti: that sounds like a reasonable approach
[08:20] <pitti> mdz: I agree. Especially because Kamion said that removing CD-ROMs from fstab is not as trivial as it sounds
[08:21] <lamont__> mdz: I was working on looking at them to confirm that they were really dead before I closed them.  I'll force it above the cutline after my late lunch today.
[08:21] <lamont__> I also get to figure out how to pick up the horse from the hospital today
[08:26] <Keybuk> gah, warty is spoiling me ... I was getting angry at my desktop for not showing me appointments in the clock calendar
[08:27] <Keybuk> (it's running just Debian unstable)
[08:38] <lamont__> Keybuk: the clock calendar - is that evo, or something else that's doing that?
[08:40] <Keybuk> evolution-data-server
[08:41] <Keybuk> it's useful
[08:41] <Keybuk> I can click on Sunday ... and guess what it says? :p
[08:44] <elmo> Sunday?
[08:44] <thom> Saturday
[08:53] <kagou> hi everybody
[08:54] <seb128> hey kagou 
[08:55] <kagou> hi seb128 :)
[08:55] <kagou> frontends configuration for Internet access are planed ?
[08:59] <pitti> npmccallum: Did you already upload the pmount-enabled gvm?
[09:00] <mdz> pitti: yes, he did
[09:00] <pitti> great
[09:01] <mdz> pitti: http://rince.africaninspace.com/mailman/listinfo/warty-changes
[09:01] <pitti> mdz: i'm getting the digests, but cannot remember seeing it
[09:01] <mdz> kagou: there is a network configuration tool already, though it may not be so featureful yet
[09:01] <pitti> mdz: thanks
[09:01] <mdz> pitti: people still use digest mail? :-)
[09:02] <kagou> yes mdz. Gnome network tool wozard complain about no installation of wvdial by default
[09:03] <kagou> and no entry for a pppoeconf hacked to use gdialog insteat whiptail
[09:04] <seb128> oh yes, the ppp stuff uses wvdial
[09:06] <kagou> seb128, i have re tested my smb share access problem . With or without .... (you ?!) smbfs, i can't enter in shared dirs
[09:06] <kagou> i don't know how to see debug message for this problem
[09:07] <seb128> -> query
[09:10] <Kamion> npmccallum: hm, that eject change is going to need some testing to make sure it doesn't break d-i
[09:12] <Kamion> actually, it will break d-i unless pmount is moved to Base
[09:12] <Kamion> mdz: ?
[09:14] <seb128> Kamion:  the debian d-i business card (rc1) for ppc is known to have some problems in the base packages ?
[09:15] <Kamion> not sure, TBH dealing with warty d-i has left me with not a lot of time for upstream ...
[09:15] <Kamion> businesscards are notoriously unreliable across archive changes though; try a netinst instead
[09:16] <seb128> a french gnome guys has some problems with it: http://dejean.benoit.free.fr/tmp/SargeNetinstall-BzCardRC1-PPC32/IMG_1180.JPG
[09:17] <Kamion> those errors are totally harmless
[09:17] <Kamion> debootstrap always does that, it's part of life when you're installing Essential stuff
[09:17] <Kamion> there's a reason that stuff is on tty3 and not shown to curious users by default :)
[09:18] <Keybuk> *nods* note the "but co
[09:18] <seb128> he he :)
[09:18] <Keybuk> *nods* note the "but configuring anyway as you suggest" and "ignoring pre-dependency problem" :p
[09:18] <Kamion> if it fails anyway, it'll be for some other reason
[09:18] <seb128> BTW the install is failing, i'm asking for details
[09:18] <seb128> he'll try with a netinstall
[09:18] <Kamion> there may well be other problems that actually matter, certainly
[09:19] <seb128> http://dejean.benoit.free.fr/tmp/SargeNetinstall-BzCardRC1-PPC32/IMG_1197.JPG
[09:19] <seb128> the final errors are here
[09:19] <seb128> exim4/libgnutls10
[09:20] <Kamion> ah, right, that's normal archive bitrot
[09:20] <Kamion> the problem is that businesscards include debootstrap-udeb but not the rest of the base system, so if the base system changes in ways that require debootstrap changes then you're stuffed
[09:20] <seb128> he get a red screen about deboostrap failure 
[09:20] <Kamion> the netinst will be fine.
[09:21] <seb128> oh ok
[09:21] <seb128> thanks !
[09:24] <npmccallum> Kamion: pmount just wraps mount, so long as you are a. root or b. have the device in fstab it should be fine
[09:25] <npmccallum> Kamion: pmount also gives you other priviledges, like mounting removeable non-fstab devices as non-root
[09:26] <Kamion> npmccallum: that's not my point at all
[09:26] <Kamion> as previously mentioned, if you change the dependencies of packages in Base you have to tell me so that I can update debootstrap and debian-cd, otherwise CD images break.
[09:27] <Kamion> and you probably ought to get an ack from mdz for that, since he seemed unsure about moving pmount to Desktop ...
[09:27] <Kamion> hence why I asked after I spotted the changelog entry :-)
[09:28] <Kamion> also, I wonder if this will break the udeb
[09:28] <Kamion> since there's no pmount in d-i
[09:29] <Kamion> perhaps the location of umount should be made a #define so that it can be different in the .deb from in the .udeb; at any rate, I think it needs discussion ...
[09:30] <sabdfl> hey warthogs
[09:30] <Kamion> yo
[09:30] <Keybuk> evening boss
[09:31] <sabdfl> should i have instant auto-mounting usb drive nautilus-showing happiness?
[09:31] <pitti> sabdfl: actually yes, if you use the latest packages
[09:32] <sabdfl> hmm... seems my upgrade missed gvm and pmount, will try again
[09:32] <sabdfl> brb
[09:33] <Kamion> mobile sabdfl
[09:33] <HcE> *hmpf*
[09:33] <HcE> were going for a disconnect, and ended up doing a /quit
[09:35] <thom> mdz: agree with sync of tetex-base
[09:36] <mdz> Kamion, npmccallum: when I looked at the eject upload, it did not look like it depended on pmount. did I miss something?
[09:36] <mdz> g-v-m depended on it, but not eject
[09:37] <Kamion> -Depends: ${shlibs:Depends}, ${misc:Depends}
[09:37] <Kamion> +Depends: ${shlibs:Depends}, ${misc:Depends}, pmount
[09:37] <Kamion> and:
[09:37] <Kamion> -                         execl("/bin/umount", "/bin/umount", fullName, "-n", NULL);
[09:37] <Kamion> +                         execl("/usr/bin/pumount", "/usr/bin/pumount", fullName, "-n", NULL);
[09:37] <Kamion>                   else
[09:37] <Kamion> -                         execl("/bin/umount", "/bin/umount", fullName, NULL);
[09:37] <Kamion> -                 fprintf(stderr, _("%s: unable to exec /bin/umount of `%s': %s\n"),
[09:37] <Kamion> +                         execl("/usr/bin/pumount", "/usr/bin/pumount", fullName, NULL);
[09:37] <Kamion> +                 fprintf(stderr, _("%s: unable to exec /usr/bin/pumount of `%s': %s\n"),
[09:38] <Kamion> (remind me why pmount doesn't divert mount?)
[09:38] <Keybuk> ok, so maybe I'm being thick here, but how do you mount a cd drive now?
[09:38] <pitti> Kamion: because it cannot do the root tasks of mount
[09:38] <Kamion> can't/doesn't it call mount for that?
[09:38] <pitti> Kamion: it is a wrapper for users, no replacement
[09:38] <Kamion> it could call mount.real or whatever
[09:39] <Kamion> hm, ok
[09:39] <mdz> Kamion: yes, it is actually a bit higher level than mount
[09:39] <mdz> no need to duplicate handling of mtab, etc. either
[09:39] <pitti> Kamion: it could be a diversion, but wouldn't that create confusion?
[09:40] <Kamion> possibly; I think I'm persuaded it's not important for the moment, though
[09:40] <mdz> Kamion: which version of eject is that from?
[09:40] <Kamion> mdz: 2.0.13deb-6ubuntu1
[09:40] <mdz> ahh
[09:40] <mdz> it's only the udeb
[09:40] <Kamion> uhhh ... that's even worse
[09:40] <mdz> which begs the question...
[09:40] <mdz> "???"
[09:41] <Kamion> mdz: quite :-)
[09:41] <mdz> npmccallum: ping
[09:41] <Kamion> in general please can people talk to me if they're unsure about udebs; I'm happy to offer advice about what's safe/unsafe
[09:43] <mdz> I think it was just a simple mistake of looking at the wrong stanza in debian/control
[09:43] <Kamion> oh, sure, but just a general remark :)
[09:43] <Kamion> eject.c affects eject-udeb, anyway
[09:44] <npmccallum> mdz: yeah, I actually caught it just after the upload
[09:44] <mdz> I'm fixing it now
[09:44] <npmccallum> mdz: I've been waiting for the source package to enter our archive before a new upload
[09:44] <Kamion> so, should I make that debootstrap change?
[09:44] <mdz> since I saw something else I wanted to change anyway
[09:44] <mdz> Kamion: no
[09:44] <Kamion> mdz: by "fixing" do you mean moving the dependency to eject, or removing it altogether?
[09:45] <mdz> Kamion: removing the dependency and having it fall back to standard umount
[09:45] <Kamion> mdz: ah, good
[09:45] <Kamion> ok, I'll butt out then
[09:45] <sabdfl> no joy
[09:46] <pitti> sabdfl: I just tried it myself, does not work for me either. Funny, it worked with Nathaniel's test package
[09:47] <pitti> npmccallum: I just plugged in a normal USB stick with a partition, it appears in HAL, but nautilus does not do anything. Is this really the same package you announced for testing in your homedir?
[09:48] <mdz> the one from npmccallum's home dir worked for me as well
[09:48] <mdz> haven't tested the one in warty yet
[09:49] <sabdfl> npmccallum: any other changes from the test package in your homedir?
[09:49] <mdz> hmm, doesn't seem to be working for me
[09:50] <Keybuk> me neither
[09:50] <mdz> hmm, hal is not running
[09:52] <mdz> ah
[09:52] <mdz> Keybuk, sabdfl: adduser <you> plugdev
[09:52] <pitti> npmccallum: at least one good piece of news: still remember my partitionless USB stick? it doesn't work with sid's hal, but does with Warty's
[09:52] <mdz> log out, log in, try again
[09:53] <pitti> mdz: Geez! I even wrote a mail about it and forgot it myself.
[09:53] <mdz> pitti, npmccallum: works perfectly for me after adding myself to the plugdev group
[09:53] <mdz> now how do I unmount it from the GUI again?
[09:54] <pitti> mdz: beep - next question
[09:54] <pitti> mdz: Nautilus must be modified not to look in fstab, but in /etc/mtab
[09:54] <mdz> sounds simple enough
[09:55] <Keybuk> so it doesn't unmount if you close the window?
[09:56] <mdz> Keybuk: no, it does not
[09:56] <pitti> Keybuk: this would be a nice feature, but other apps may still access it
[09:56] <Keybuk> wouldn't that be the most logical thing ?
[09:56] <mdz> it would be nice if it would at least try
[09:56] <Keybuk> we've hidden the filesystem icons so well there'd be no other way to unmount it?
[09:56] <mdz> seb128: is that difficult to implement?
[09:56] <pitti> Keybuk: it would. If it works, then it shoudl be done
[09:57] <pitti> npmccallum: although hal shows a proper volume node for my partitionless USB stick, it is not recognized by gvm. Any idea?
[09:57] <Kamion> testing changes to the initrd is a pain
[09:57] <mdz> Kamion, pitti: is the initial user added to plugdev?
[09:57] <pitti> mdz: yes
[09:57] <mdz> thanks
[09:58] <npmccallum> sabdfl: a new upstream release mad the patch slightly different, but basically the same
[09:58] <Kamion> yeah, pitti did that earlier today
[09:58] <Keybuk> pitti: this is what I get ...
[09:58] <pitti> Kamion: yesterday :-)
[09:58] <Keybuk> syndicate scott% pmount sda1
[09:58] <Keybuk> Error: could not determine real path of the device: No such file or directory
[09:58] <Keybuk> zsh: exit 255   pmount sda1
[09:58] <pitti> Keybuk: pmount /dev/sda1
[09:58] <Kamion> pitti: oh, was it? sorry, I lose track of the days :-)
[09:59] <Keybuk> pitti: ok that worked ... but it didn't do it automatically
[09:59] <npmccallum> pitti: I'm not sure what you mean by partitionless USB stick, it has to have a partition of some kind, no?
[09:59] <pitti> npmccallum: no, what for? Its just a waste of space
[09:59] <mdz> eek, the sed in warty also had that nasty fchmod bug
[09:59] <Kamion> on some USB sticks you just write the filesystem straight onto the device
[10:00] <mdz> good thing we synched it
[10:00] <pitti> npmccallum: I just mount /dev/sda straight
[10:00] <pitti> npmccallum: do you only consider partitions?
[10:00] <pitti> npmccallum: CD-ROMs don't have partitions either
[10:00] <pitti> (usually)
[10:00] <Kamion> mdz: yes, it just occurred to me earlier today (after joeyh asked about it) that that might be why our /etc/default/gdm was ending up mode 0600
[10:00] <SteveA> gpg seems not to be set up knowing about keyservers
[10:00] <mdz> Kamion: that was only filed as important(!)
[10:00] <npmccallum> gvm actually does the mounting and the loading nautilus/autorun/etc seperately
[10:01] <mdz> so it didn't get pulled into debzilla
[10:01] <Kamion> *nod*
[10:01] <npmccallum> if the device is mountable, gvm mounts it
[10:01] <pitti> npmccallum: the stick is not mounted
[10:01] <npmccallum> then, hal notices the mounted status has changed and sends a dbus message, which gvm gets and does something with the new mounts
[10:02] <Keybuk> ok, hal is definitely seeing the device ... but not getting a window for it :(
[10:02] <pitti> npmccallum: so obviously it fails already at the first stage
[10:02] <npmccallum> pitti: do dbus-monitor --system and insert the key
[10:02] <npmccallum> pitti: tell me if you see a new device notification
[10:03] <pitti> npmccallum: I don't have this program???
[10:03] <Keybuk> pitti: dbus-1-utils iirc
[10:03] <pitti> npmccallum: I'm right back, I have to go over to get network on my laptop. I left my crossover cable in Oxford
[10:04] <mdz> npmccallum: oh, gvm learns about mounts through hal?  I thought it just noticed /etc/mtab or /proc/mounts
[10:04] <npmccallum> mdz: hal is the center for everything
[10:04] <Keybuk> npmccallum: ok, from hal-device-manager's stdout I get:
[10:04] <Keybuk> DeviceAdded, udi=/org/freedesktop/Hal/devices/usbif_usb_4cb_100_1000_-1_Y-248^^^^^011116XFJX0017001826_0
[10:04] <Keybuk> but nothing on the system dbus
[10:04] <mdz> npmccallum: all hail hal
[10:05] <npmccallum> Keybuk: check out hal-device-manager -- does it have the right properties of something mountable?
[10:06] <Keybuk> npmccallum: how do I tell?
[10:06] <pitti> npmccallum: I did that. I just get the kernel notifications of the new device, but dbus-monitor does not print anything
[10:07] <mdz> npmccallum: if hal were lying about something, it couldn't cause gvm to do anything untoward, could it?
[10:07] <pitti> npmccallum: but I do see a node "OTI-6803 Flash Disk" (the device) which has one child "Flash Disk" which has a block.device property (/dev/sda)
[10:07] <mdz> it seems like hal is pretty gullible
[10:07] <npmccallum> Keybuk: block.is_volume, block.storage_device, info.capabilities = *block volume*
[10:07] <Keybuk> doesn't have any of those
[10:07] <pitti> mdz: that's why pmount has to do its own checks, we cannot trust hal since users can overwrite all properties
[10:07] <Keybuk> doesn't even have an info.capabilities
[10:08] <mdz> pitti: right, but gvm listens directly to hal
[10:08] <npmccallum> Keybuk: that may be the problem, perhaps hal isn't aware of your devices
[10:08] <Keybuk> npmccallum: it's got a name for it
[10:08] <pitti> mdz: I know, but even if hal tries to fool gvm, gvm cannot mount invalid devices
[10:08] <mdz> Keybuk: I think it gets the name as a string from sysfs
[10:08] <Keybuk> mdz: the string's different
[10:09] <mdz> pitti: yes, it can't fool pmount, but gvm itself runs as a user, and so one user could forge information in hal which could be acted upon by another user automatically
[10:09] <mdz> pitti: I'm not sure what other actions might be taken by gvm apart from calling pmount
[10:09] <npmccallum> Keybuk: it may get the string from the device itself
[10:09] <mdz> this issue isn't specific to our modifications
[10:09] <pitti> mdz: that's the problem. hal must not be trusted
[10:09] <npmccallum> Keybuk: though, I'm not sure
[10:10] <Keybuk> syndicate scott% cat /sys/bus/usb/devices/1-1/1-1:1.0/host4/4:0:0:0/model
[10:10] <Keybuk> FinePix 1400Zoom
[10:10] <npmccallum> pitti: hal (as it stands now) is very naive
[10:10] <pitti> npmccallum: must block.is_volume be 1 to be recognized by gvm? The property exists, but it is 0. Can this be the cause?
[10:10] <npmccallum> pitti: yes probably
[10:10] <Keybuk> hal has "FinePix 1300 / 1400 / 4700 Zoom digital camera"
[10:10] <pitti> npmccallum: but it has the correct block.major and block.minor property values
[10:11] <pitti> npmccallum: info.capabilities is "block storage"
[10:11] <npmccallum> pitti, Keybuk: if block.is_volume < 1 i don't think gvm will mount it, let me check
[10:11] <Keybuk> npmccallum: there is no block.is_volume key
[10:12] <pitti> Keybuk: is this an USB stick?
[10:12] <Keybuk> pitti: it's a digital camera that appears as a usb storage device
[10:12] <pitti> Keybuk: should work as well...
[10:13] <pitti> Keybuk: what's your info.capabilities?
[10:13] <npmccallum> Keybuk, pitti, mdz: if a device does not have block.is_volume = 1 (or doesn't have block.is_volume at all), gvm ignores it
[10:13] <mdz> npmccallum: right, but anyone can change that, can't they?
[10:13] <pitti> npmccallum: can we extend this to look at info.category or info.capabilities?
[10:13] <Keybuk> pitti: that key doesn't exist
[10:13] <Keybuk> npmccallum: ok, so how do I fix hal?
[10:13] <mdz> never mind, different issue
[10:15] <pitti> mdz: we should really only regard the hal information as hints
[10:15] <npmccallum> hal will have to be made aware of your device, have you guys tried the newest hal (either from debian or from cvs)?
[10:15] <pitti> npmccallum: as I already said, 0.2.97 is even a regression
[10:15] <pitti> npmccallum: whereas the Warty hal properly recognizes my USB stick, the sid version does not any more
[10:16] <pitti> Keybuk: do you have storage.drive_type
[10:16] <pitti> Keybuk: ?
[10:16] <Keybuk> nope
[10:17] <pitti> Keybuk: do you actually have a proper volume node as a child of the actual device node?
[10:17] <jdub> hey hey hey
[10:17] <npmccallum> pitti: I believe that hal requires a partition table (it sounds like your device doesn't?)
[10:17] <Keybuk> pitti: well, there's a /dev/sda1
[10:17] <sabdfl> mdz, pitti: I'm in group plugdev, it's still not working.
[10:18] <pitti> sabdfl: what do you use for testing?
[10:18] <pitti> sabdfl: i. e. what kind of device?
[10:18] <pitti> jdub: good morning! :-)
[10:18] <npmccallum> pitti: the storage.xxxx properties are only for the master device, (ie. /dev/hda) you don't get those entries in specific volumes (ie. /dev/hda1)
[10:19] <pitti> npmccallum: so maybe we could use the master device if no partitions are present?
[10:19] <pitti> npmccallum: if we drop CD-ROMs from fstab in the future (probably not for Warty any more), this must work anyway
[10:22] <npmccallum> pitti: the real place this needs to change is in hal
[10:22] <npmccallum> pitti: not gvm
[10:22] <npmccallum> pitti: hal already handles cdroms seperately
[10:23] <pitti> npmccallum: okay. but how is hal supposed to handle that? Do the check if no partitions are present, and if not, set block.is_volume to 1?
[10:23] <Keybuk> hrm, hal in unstable isn't any better
[10:23] <Keybuk> what I don't get is why it it doesn't understand that its a storage device seeing as it's reacting to the hotplug scsi thingy
[10:24] <pitti> Keybuk: unstable's hal is even worse, it still runs as root
[10:25] <pitti> Keybuk: does your camera have partitions?
[10:25] <npmccallum> pitti: it can't do that because you may insert a device without any paritions on it or without direct access and it would still have block.is_volume = 1 (though you can't mount it)
[10:25] <Keybuk> yeah, one
[10:25] <npmccallum> pitti: we actually need to profile these devices within hal
[10:26] <pitti> npmccallum: I thought only partitions get is_volume=1?
[10:26] <npmccallum> pitti: I believe cdroms get it as well
[10:26] <npmccallum> pitti: if there is a session on the disk that is
[10:27] <pitti> npmccallum: does it really hurt to try mounting the whole device if no partitions are present? If there's no filesystem, the mount will just fail
[10:27] <pitti> npmccallum: BTW, Warty's hal cannot detect file systems any more, I deprived it from group 'disk'
[10:30] <jdub> is there a dpkg-source "check me" function?
[10:30] <jdub> verify...?
[10:30] <jdub> summat
[10:30] <jdub> grr
[10:31] <Keybuk> "check me" ?
[10:31] <Keybuk> what do you wish?
[10:31] <jdub> like, verify the source packages against the dsc
[10:31] <jdub> looks okay
[10:32] <Keybuk> just unpack it?
[10:34] <jdub> hrm, didn't really want to unpack it
[10:34] <jdub> plus, that seemed to work
[10:34] <jdub> while the upload b0rked
[10:34] <jdub> whoa, my laptop shipped
[10:35] <mdz> jdub: what did you decide on?
[10:35] <thom> jdub: you did the silly thing, didn't you? :-)
[10:35] <jdub> mdz: x300
[10:35] <mdz> jdub: I'm sorry :-(
[10:35] <mdz> jdub: I mean, I hope you like it :-)
[10:35] <thom> jdub: my condolences
[10:36] <jdub> whatever
[10:36] <Keybuk> jdub: you have my sympathy
[10:37] <jdub> grr, fabio
[10:37] <jdub> seb128: status on new evo bits?
[10:39] <jdub> haha
[10:39] <jdub> if usplash uses kdrive
[10:39] <jdub> we'll have reimplemented rhgb :)
[10:40] <dieman> is that post warty?
[10:40] <jdub> yeah
[10:46] <tvon|x31> I'm hoping usplash will end up a little nicer than rhgb
[10:46] <tvon|x31> rhgb fires up about 1/2 to 2/3 through the boot
[10:47] <tvon|x31> I've always been a bootsplash supporter, weather the code belongs in the kernel or not its much nicer for the end user
[10:49] <sabdfl> pitti: flash card watch, i think keybuk and daf have the same
[10:49] <pitti> sabdfl: USB?
[10:50] <pitti> sabdfl: Ah, I remember daf's one. I did not test it at the conference
[10:50] <sabdfl> pitti: yess
[10:50] <sabdfl> yes :-)
[10:51] <pitti> sabdfl: does it have partitions?
[10:51] <pitti> sabdfl: (or, at least, one?)
[10:51] <sabdfl> pitti: yes
[10:52] <pitti> sabdfl hmm. seems like hal still needs a lot of work. Can you see the thing in hal-device-manager?
[10:52] <pitti> sabdfl: there should be a device node with a proper name with a child node which is a volume
[10:54] <mdz> Mithrandir: ping
[10:54] <mdz> thom: have you tried an amd64 warty install?
[10:58] <mdz> my first test has been, shall we say, less than successful
[10:58] <[Clint] > i heard a failure story too
[10:59] <mdz> the base system seems to have installed successfully
[10:59] <mdz> but grub doesn't work at all, so my system is left unbootable
[10:59] <tvon|x31> Thats not so good
[11:02] <[Clint] > mark0: what was broken about amd64?
[11:03] <mark0> ah right
[11:03] <mark0> it wouldnt complete the last filesystem
[11:03] <mark0> or was that debian..
[11:04] <mark0> lemme try it again
[11:07] <jdub> mako: you're going to be like, the centre of the mame blogging world, dude
[11:10] <sabdfl> pitti: yes
[11:10] <sabdfl> OTI-6828 Flash Disk
[11:10] <sabdfl> underneath that is an icon with a twisty and no name
[11:10] <pitti> sabdfl: that's the device node. does it have any children, which are volumes? With a rectangular gray box as icon
[11:10] <mark0> clint, 1st thing is it doesnt recognize the ethernet adapter
[11:11] <sabdfl> and under neath that a similar icon with the word volume
[11:11] <pitti> sabdfl: the volumes should have a property block.is_device
[11:11] <sabdfl> nope
[11:11] <sabdfl> block.device
[11:11] <sabdfl> and  block.is_volume
[11:11] <pitti> sabdfl: sorry, block.is_volume
[11:11] <pitti> sabdfl: is it 1?
[11:11] <sabdfl> yes
[11:12] <sabdfl> int 1
[11:12] <mark0> FATAL: Error inserting floppy )/lib/modules/2.6.8-1-amd64-generic/kernel/drivers/block/floppy.ko): No such device
[11:12] <pitti> npmccallum: hmm. Any idea about sabdfl's odd device?
[11:12] <pitti> npmccallum: I thought that gvm uses devices with is_volume=1?
[11:12] <[Clint] > there's a floppy drive it won't recognize?
[11:13] <mark0> no there wasnt one plugged in
[11:13] <mark0> which i guess is ovious
[11:13] <mark0> so any chance i can put a network driver on that floppy
[11:13] <[Clint] > which nic is it?
[11:15] <makoshark> jdub: i just got home so i can now post roms along with descriptions
[11:16] <makoshark> mame is just the beginning, i wrote a dozen entries on the plane yesterday. only a couple about mame
[11:17] <npmccallum> sabdfl: can you file a bug on it with a screenshot of the properties in hal-device-manager?
[11:17] <mark0> clint, it hink its the VIA rhine II
[11:17] <pitti> sabdfl: can you pmount it manually? I. e. 'pmount /dev/sda1' (it is sda1, I suppose)
[11:19] <[Clint] > mark0: does it show up in lspci like
[11:19] <[Clint] > 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]  (rev 74)
[11:19] <[Clint] > ?
[11:20] <mark0> can i scroll back/
[11:20] <mark0> yeah it says vt6102 
[11:20] <mark0> on console f4
[11:20] <mark0> missing modules
[11:21] <mark0> missing modules via-ircc, via-rhine, ide-mod, ide-probe-mod, ide-detect, ide-floppy, eth1394
[11:23] <jdub> mdz: i've cleaned up the gstreamer plugins a bit
[11:23] <jdub> mdz: so jackd is no longer in desktop
[11:24] <[Clint] > it's kernel 2.6.7?
[11:24] <pitti> jdub: Yeeeeaahh!
[11:24] <mark0> i think 2.6.8-1
[11:24] <[Clint] > which image are you using?
[11:24] <mark0> ok i was able to make one / fs and install the base
[11:24] <mark0> couldnt make any swap
[11:24] <mark0> 4.10 
[11:26] <[Clint] > what happens when you try to make swap?
[11:26] <mark0> it wouldnt let me resize the partition
[11:26] <mark0> it was 22.3 gig and i trid to resizeit to 21.0gb
[11:26] <mark0> wouldnt do it
[11:26] <mark0> i probably dont need swap anyway
[11:26] <mark0> does linux still require it
[11:27] <[Clint] > no
[11:27] <mark0> ok cuz ive got 1.25 gigs of ram
[11:27] <pitti> good night everybody!
[11:27] <mark0> ok it says its installing 2.6.7-5-amd64-generic
[11:29] <mark0> crap
[11:29] <mark0> it didnt install a boot loader
[11:29] <mark0> ah fuck!
[11:29] <mark0> and screwed up the windows boot
[11:29] <mark0> fuck fuck fuck
[11:33] <mark0> maybe cuz i told it to make hda5 bootable
[11:33] <mark0> which isnt possible
[11:35] <[Clint] > did your mbr get overwritten?
[11:35] <mark0> probably
[11:35] <mark0> im reinstalling and gonna see if it lets me install a bootloader
[11:35] <mark0> if i can get into windows i can download those modules and hopefully mount ntfs
[11:36] <mark0> doh didnt offer to install boot loader
[11:37] <[Clint] > that's not good
[11:37] <mark0> its not on the menu either
[11:38] <[Clint] > I wonder where everybody went.
[11:39] <mark0> so 30 more days in teh academy
[11:43] <jdub> jdub@lazarus ~/src $ gnome-cd
[11:43] <jdub> (gnome-cd:22354): GLib-CRITICAL **: file gstrfuncs.c: line 1743 (g_ascii_strcasecmp): assertion `s1 != NULL' failed
[11:43] <jdub> Segmentation fault
[11:43] <jdub> nice one
[11:43] <mark0> ok got windows to boot again
[11:43] <mark0> how do i install a better boot loader
[11:49] <lamont__> mdz about
[11:49] <lamont__> ?
[11:51] <[Clint] > i dunno, what bootloaders are on the amd64 cd?
[11:55] <mark0> where on the cd should I look
[11:56] <mark0> grub is in /pool/local/g/grub
[11:56] <mark0> in .deb format
[11:57] <mark0> can i install that via the install shell?
[11:58] <moquist> i'm trying to submit a bug in bugzilla, and apparently I have to enter somebody's email address in "Assign To".  Did I miss the memo about this?