[12:18] <lamont> mdz: amd64/i386 built, ppc still chunking along.
[12:18] <lamont> you want log files?
[12:36] <mdz> justdave: at the point of the last message you see, does the system hang, power off, do anything?
[12:36] <mdz> lamont: logs are not necessary; just copy the debs to rookery so I can put them up for download
[12:39] <lamont> mdz: source and binaries (all 3 arch) at http://people.ubuntu.com/~lamont/mozilla - feel free to toss them somewhere else.
[12:40] <mdz> lamont: thanks
[01:12] <justdave> mdz: it just hangs
[01:58] <mdz> elmo_: there seem to be packages in DesktopSeed which are lacking Task: ubuntu-desktop headers; is that normal?
[01:58] <mdz> seem to be all gstreamer stuff
[01:58] <mdz> e.g, gstreamer0.8-alsa
[01:59] <elmo_> mdz: I just do it based on the 'desktop' output file of my germinate run
[01:59] <mdz> elmo_: I think that stuff was added on 09-02; whet was the last time that was updated?
[01:59] <elmo_> hmm, and gstreamer0.8-alsa is in there
[02:00] <mdz> they show up in my germinate output
[02:00] <mdz> hmm, I think apt is just being weird
[02:00] <mdz> yeah, it's showing me the status file entry rather than the Packages file entry
[02:01] <mdz> which is a very weird thing for dumpavail to do
[02:02] <mdz> I guess it's playing its "the version numbers are the same so everything is cool" game
[02:06] <jono> hi all
[02:06] <jono> I am writing Linux Desktop Hacks for O'Reilly and we are looking for contributors to write a few hacks - would anyone be interested in getting involved?
[02:07] <sivang> jono : what are those Desktop Hacks? :)
[02:07] <jono> well, we are taking suggestions
[02:08] <jono> we are writing 80 hacks and 20 are available for contributors
[02:08] <jono> any cool ideas, mail them to me at jono AT jonobacon D-O-T org
[02:11] <elmo_> heh, 'ubuntu-desktop' in Section: base
[02:11] <justdave> mdz: new lead.  added ramdisk_size=8192 to the yaboot boot parameters, and successfully booted non-smp
[02:11] <justdave> dropping a dmesg on the bug as soon as it finishes logging in
[02:12] <mdz> justdave: how big is your initrd?
[02:12] <elmo_> mdz: good god, that is the Depends line of doom - are you sure that doesn't overflow one of apt's static buffers at least in woody?
[02:14] <justdave> mdz: the smp initrd is 4 MB even, the non-smp initrd is 3.8 MB
[02:14] <mdz> elmo_: no clue about woody
[02:14] <mdz> but woody users won't get that package upgraded anyway
[02:15] <mdz> ubuntu apt is fine with it afaik
[02:15] <mdz> justdave: stinks of weird bootloader problems
[02:16] <mdz> elmo_: the stanza is only slightly larger than the d-i Sources one
[02:20] <justdave> it's a fluke
[02:20] <justdave> just booted without the ramdisk_size thing and succeeded
[02:20] <mdz> justdave: have you upgraded since the last time you tried?
[02:21] <justdave> still has devfs in there though.
[02:21] <justdave> no.  I did update the kernel yesterday, but before my previous attempts.
[02:22] <justdave> oh, and yaboot does let you pass kernel params from the boot prompt
[02:24] <justdave> took all the garbage out of yaboot.conf, and experimenting from the boot prompt now that I proved that
[02:26] <justdave> ok, just got it to hang again
[02:26] <justdave> only changed from the previous boot was the "idebus=66" got removed.
[02:27] <justdave> one more attempt, same params, just to make sure, still hangs
[02:28] <justdave> added idebus=66 back in, still hangs.
[02:28] <justdave> so there's apparently no pattern to it
[02:31] <justdave> added video=ofonly in addition to the idebus=66 and it booted
[02:32] <justdave> btw, the new startup sound is cool, I like it :)
[02:35] <justdave> ok, just successfully booted it with the default command line.
[02:35] <justdave> so the command line options are another red herring
[02:36] <justdave> appears to be just luck or timing or something
[02:39] <mdz> justdave: so basically, it happens on UP and SMP systems, and regardless of the kernel command line
[02:40] <Kamion> sivang: ':syntax on'
[02:40] <justdave> seems that way.
[02:40] <mdz> justdave: try unplugging all your USB devices when you boot
[02:40] <mdz> and 1394
[02:41] <Kamion> justdave: yaboot lets you pass kernel parameters from the boot prompt as long as they aren't initrd= (well, you can pass it, but it's not useful), which is kind of annoying
[02:41] <sivang> Kamion : you're replying my vim question? :)
[02:41] <Kamion> sivang: yes
[02:41] <justdave> no 1394 on it right now.
[02:41] <sivang> Kamion : boy that was a while, thanks!
[02:41] <justdave> I'll have to change the default kernel in yaboot to do that. :)  my keyboard is USB :)
[02:41] <mdz> Kamion: any idea about #1379?
[02:42] <mdz> justdave: you can plug it in after boot if it works
[02:42] <mdz> justdave: just try it and see if it makes a difference
[02:42] <mdz> oh, you mean you need to change yaboot.conf
[02:42] <Kamion> sivang: it's IRC, it often has a big delay built-in
[02:42] <justdave> yep, done.
[02:43] <justdave> booting...
[02:43] <sivang> Kamion : yes, I've got used to it by now ;-)
[02:43] <Kamion> mdz: I haven't had any idea about that since the start
[02:43] <justdave> (well, powered up -- still waiting for yaboot prompt to timeout)
[02:43] <justdave> ok, all USB and 1394 removed, it hung
[02:43] <mdz> Kamion: I've searched around a bit and haven't found anything in Debian land
[02:43] <mdz> besides that bug report you pointed out
[02:44] <mdz> which doesn't seem to have any leads
[02:44] <mdz> there goes my last idea
[02:44] <mdz> that was from the YDL website
[02:44] <mdz> Hang after install: If after install your computer hangs on re-boot, unplug any USB hubs you may have. An intermittent problem causes the hub to interact poorly with the CUPS printer software. 
[02:44] <mdz> that sounded fairly promising, since the CD boot was working and not the HDD boot
[02:45] <mdz> of course, this is hanging way before CUPS starts
[02:46] <mdz> what bootloader does the CD use on ppc?
[02:46] <Kamion> yaboot
[02:47] <Kamion> there's no other sensible option
[02:51] <justdave> plugged the USB stuff back in and booted, and it worked.
[02:57] <Kamion> bah, linux-kernel-di-{i386,powerpc}-2.6 failed to build
[02:58] <Kamion> ... and it was because I'm dim
[03:04] <carlos> do we want a kind of howto about it?
[03:05] <mdz> carlos: only with BIG BOLD BLINKING warnings :-)
[03:05] <carlos> sure :-)
[03:05] <carlos> wiki or website ?
[03:05] <mdz> wiki, I suppose
[03:06] <carlos> ok, I will do it tomorrow. Good night
[03:18] <sivang> why would someone like to downgrade from sid to warty anyways? :-) 
[03:26] <sivang> wow, just noticed the girl on the artwork....the best default livecd background I've yet to see...
[03:31] <sivang> mdz : would it be reasonable to push in stuff to yelp before the release (no further than the 17th) as this does not fall even under special circumstances? although yelp might not be effecting too much I suppose.
[03:33] <mdz> sivang: what kind of stuff?
[03:39] <sivang> mdz : I am not sure it will be ready for this, but just in case it will. It this listed under "roadmap" in http://wiki.ubuntulinux.org/DocumentationTeam.
[03:43] <sivang> mdz : if you have any comments, suggestions I'd be glad if you could mail me in , or on -devel. I'm hitting bed now, this time _for_real :)
[03:43] <sivang> nighters everybody
[06:01] <daniels> ha ha ha, oh man
[06:30] <fabbione> oh god
[06:31] <fabbione> mdz: LATER is not even documented
[06:31] <fabbione> and imho it means that it will be fixed later
[06:31] <fabbione> that also means that after release all LATER bugs will be reopened
[06:35] <justdave> that should be a status, not a resolution, if we have it at all
[06:35] <daniels> RESOLVED/LATER is interesting
[06:36] <daniels> because then the bug just falls out of our BTS
[06:36] <daniels> i think setting the target milestone to Hoary is far better, IMO
[06:42] <justdave> the only reason that's not gone from Bugzilla upstream already is because customizable statuses was coming down the pike, and we didn't want to screw over people that were actually using it before they had an easy way to put it back.
[06:42] <justdave> except the guy who was working on the customizable statuses dropped off the face of the planet
[06:48] <fabbione> daniels: 2153 is your ;)
[06:48] <daniels> fabbione: yeah
[07:05] <mdz> fabbione: yeah, I am not so sure why we would use that rather than leaving the bug open and setting its milestone
[07:05] <fabbione> mdz: same reason as i posted in the comment :-)))
[07:06] <fabbione> it is not something that we can fix for sure for hoary
[07:06] <mdz> fabbione: I don't want those bugs to vanish from the list of open bugs though
[07:06] <fabbione> mdz: it's not vanished...
[07:06] <fabbione> it's still in bugzilla
[07:06] <fabbione> and i did plan to reopen tham afterwards
[07:06] <mdz> to me, 'resolved" means it has been dealt with
[07:06] <mdz> I know, I understand
[07:06] <fabbione> well bugzilla is wrong
[07:06] <mdz> heh
[07:06] <fabbione> LATER is a "tag" not a status
[07:07] <mdz> it is best if we all use the same semantics for handling bugs
[07:08] <mdz> if you are using LATER and someone else is using a milestone, that's unnecessarily confusing for everyone
[07:10] <fabbione> mdz: i don't disagree, what i wrote in the bug is: LATER because we don't know if it can be fixed for hoary
[07:10] <fabbione> mdz: that's kinda different from a milestone
[07:10] <justdave> maybe add a milestone called "Future"
[07:10] <mdz> fabbione: "hoary" is our name for all of the time between the warty release and when the world crumbles into dust :-)
[07:11] <mdz> anything that is not now or the past is "hoary"
[07:11] <mdz> our list of feature goals is long enough to fill that time
[07:12] <fabbione> whatever
[07:12] <fabbione> i will reopen the bugs and mark them hoary
[07:15] <fabbione> mdz: 2119 -> for me it's invalid
[07:16] <mdz> fabbione: I didn't read the logs; what is the deal?
[07:18] <fabbione> mdz: it's 24 to 16 bit and no DRI
[07:18] <fabbione> + one obscure option that for sure i am never going to set by default
[07:20] <mdz> fabbione: wait, I am rereading it and he is saying Ubuntu is faster
[07:20] <mdz> and his problem is with userlinux?
[07:20] <fabbione> no the other way around
[07:21] <mdz> Ubuntu is
[07:21] <mdz> marginally faster
[07:21] <mdz> than UserLinux -- moving a card in freecell takes 5-8 seconds
[07:21] <mdz> instead of 10-15 seconds.
[07:21] <mdz> moving a card in freecell in UserLinux takes 10-15 seconds.  
[07:21] <mdz> I think he has reported his bug to the wrong BTS
[07:22] <chrisa> Someone is using freecell as a benchmark? That terrifies me
[07:22] <fabbione> either he wrote to the wrong BTS or the wrong order of distros
[07:22] <fabbione> both cases -> INVALID
[07:22] <mdz> yep
[07:22] <mdz> I did not see that before for some reason
[07:23] <fabbione> wait
[07:23] <fabbione> we can check in the logs
[07:23] <fabbione> XFree86 Version 4.3.0.1 (Ubuntu 4.3.0.dfsg.1-6ubuntu23 20041004140652 root@terranova.warthogs.hbd.com)
[07:23] <fabbione> he is talking about ubuntu
[07:25] <mdz> uhh
[07:25] <mdz> fabbione: both the fast and slow logs say Ubuntu
[07:25] <hazmat> is it possible to have packages not install themselves into the rc.d directories by default.. ie make an admin explicitly enable them.. i just got myself locked out of my ubuntu system after installing openldap, and watching slapd hang the system during startup.. had to fix things with the install cd.
[07:25] <mdz> fabbione: so either UserLinux is borrowing Ubuntu packages, or he is confused
[07:30] <fabbione> mdz: exactly
[07:34] <fabbione> mdz: do you where the userlinux archive is?
[07:34] <fabbione> i can't find the pool
[07:34] <jdub> fabbione: userlinux == sarge
[07:34] <jdub> fabbione: apart from a few meta packages
[07:35] <fabbione> It also doesn't configure the national language keyboard for X. It certainly shouldn't install any such thing without asking first. The country the box happens to sit in may determine it's time zone, but that's about it. Certainly not the language (there are often several in the same country anyway, and chances are none of them is English, but the admin still wants his computer in English)
[07:35] <fabbione> That's from their wiki
[07:35] <fabbione> it looks sooooo much as the bugs we get
[07:35] <fabbione> jdub: they released an update the 17th of Sept.
[07:36] <jdub> fabbione: sarge is updated all the time :)
[07:39] <fabbione> jdub: our code is not in Debian
[07:39] <fabbione> at least not the autodetection stuff
[07:40] <jdub> fabbione: it seems, from the bug, they're saying userlinux but using ubuntu. simplest explanation.
[07:44] <jdub> so, a couple of people have mentioned that they're not getting any sound at all
[07:44] <jdub> and i think i've hit a similar situation
[07:44] <jdub> snd-intel8x0 driver, nforce2 hardware
[07:44] <fabbione> mdz: your announce is on distrowatch
[07:44] <jdub> no amount of alsamixer tweaking has helped
[07:45] <mdz> fabbione: I sent that Tuesday, and didn't realize it was waiting in the moderation queue :-(
[07:45] <jdub> oof, really?
[07:45] <jdub> i thought it had gone through
[07:45] <mdz> live-i386.iso	634MiB	57	50	179	110.95GiB
[07:45] <jdub> did you send it to deve or user too?
[07:45] <mdz> jdub: mako just pushed it out today
[07:46] <mdz> no, I think only -announce
[07:46] <jdub> hrm
[07:46] <mdz> some folks were listening, though -> 50 torrents
[07:46] <jdub> sorry about that
[07:46] <mdz> (more than the install CD right now)
[07:46] <mdz> jdub: for some reason I don't think I got a notification saying it was held for moderation
[07:46] <mdz> or I would have just taken care of it
[07:46] <jdub> might've been the double-auth mailman thing i'm getting
[07:47] <jdub> oh wait
[07:47] <jdub> i'm not even on -announce moderation
[07:49] <mdz> I thought the sender was notified too?
[07:49] <jdub> should've been, yeah
[07:50] <jdub> but you're also moderator
[07:50] <jdub> i think
[07:50] <jdub> oh, that's just ubuntu-security-announce
[07:51] <jdub> could sharing an interrupt with ehci be an issue?
[07:51] <mdz> depends on what with
[07:51] <mdz> if it's a parallel  port or something, yeah :->
[07:51] <jdub> the sound card
[07:51] <mdz> oh
[07:52] <mdz> is this the mixer-volume-is-up-and-it-looks-like-it's-working-but-no-sound issue?
[07:52] <jdub> yeah
[07:52] <mdz> haven't seen that one myself
[07:52] <mdz> could be IRQ stuff, yeah
[07:52] <jdub> a few locals are asking about it
[07:52] <jdub> only *just* started happening on this machine
[07:52] <jdub> previously, i was enjoying the just works sound/volume foo ;)
[07:53] <mdz> interesting
[07:53] <jdub> stuff under /proc/asound looks fine
[07:59] <mdz> jdub: pci=noacpi?
[07:59] <mdz> noapic?
[07:59] <mdz> those are my stock answers to everything these days :-)
[07:59] <mdz> headache? noapic
[07:59] <jdub> haven't tried them... will do now
[07:59] <mdz> toothache? pci=noacpi
[07:59] <jdub> haha
[08:00] <mdz> people look at me funny
[08:01] <fabbione> ahaha
[08:59] <daniels> mdz: no more jellybeans
[09:17] <daniels> thom: ping
[10:02] <mojo> hi all fellow developers!
[10:02] <mojo> I'm getting stuck with stupid Bug #1552
[10:03] <mojo> too shit I am, can't find other way around to fix this, hope someone here give me a hand, let SSH to my box and fix it with me
[11:24] <carlos> jdub: should we report missing icons from ubuntu-artwork?
[11:28] <thom> daniels: ack?
[11:28] <daniels> thom: ack-ack
[11:35] <jdub> carlos: nah, they're known
[11:54] <thom> daniels: heh
[11:54] <thom> you're too young to be going senile
[11:55] <daniels> thom: and you don't have that problem? :)
[11:56] <thom> no, but i work around this problem by asking at the time :P
[11:56] <daniels> thom: heh, fair cop
[11:56] <daniels> oh, right.
[11:56] <daniels> suspending on the X40.
[11:56] <thom> ah?
[11:57] <daniels> even when removing ehci, can't get it going with echo 3 > /proc/acpi/sleep, then coming back with echo 0 > /proc/acpi/sleep
[11:57] <daniels> it never comes back, it just sits there with both the battery and sleep lights on
[11:57] <daniels> any known issues?
[11:57] <daniels> i.e. is this your acpi-support bong gone wrong? :)
[11:57] <thom> no, acpi-support does nothing with suspend
[11:58] <thom> hit the power button when it's suspended, what happens?
[11:58] <daniels> suspended with ecoh 3 > /proc/acpi/sleep?
[11:58] <daniels> (the /proc/acpi/sleep stuff being my additions to lid.sh)
[12:00] <thom> daniels: grab http://www.planetarytramp.net/acpi-x40.tgz
[12:07] <carlos> jdub: ok
[12:07] <daniels> thom: do I need the tpbutton stuff or whatever?
[12:08] <daniels> thom: (fwiw, it froze, and I needed to reboot)
[12:10] <thom> daniels: shouldn't do
[12:10] <thom> hrm
[12:10] <daniels> well, it works fine with x40
[12:11] <daniels> but with mangling /proc/acpi/sleep, it freezes when resuming
[12:11] <daniels> with your x40 stuff it doesn't actually suspend, however
[12:11] <daniels> it just chvts
[12:11] <thom> it'll only suspend if you're on battery
[12:12] <daniels> ahr(se)
[12:16] <daniels> hm
[12:17] <daniels> so I did it on battery, and it hung :)
[12:17] <thom> i've not tried with the current kernel tree, i have to admit
[12:18] <daniels> this is just with 2.6.8.1-3-686
[12:19] <thom> yeah
[12:20] <thom> i (or rather mjg59) had a custom 2.6.7 where it worked
[12:20] <daniels> any known gotchas?
[12:20] <daniels> ah
[12:20] <daniels> what were the patches -- acpi.sf.net?
[12:21] <thom> that and one other i don't remember
[12:25] <daniels> mjg59: ping?
[12:25] <daniels> (own reference to avoid senility-related troubles: x40 acpi)
[01:15] <sivang> morning/afternoon all
[01:49] <thom> daniels: btw, you really need to push freedrtools, since otherwise we're gonna wind up with about 50 forks
[02:19] <doko> anybody around who can/wants to review #2193?
[02:26] <Kamion> doko: patch looks good to me, I'd been hoping somebody would investigate that
[02:29] <doko> ok, so I'll upload that.
[02:31] <doko> while you are here: did a fresh powerpc install, sound works, keyboard not.
[02:31] <doko> kamion: which package writes /etc/environment on installation?
[02:46] <Kamion> doko: prebaseconfig
[02:46] <Kamion> combined with base-config
[02:46] <Kamion> which reminds me ...
[02:47] <Kamion> doko: keyboard doesn't work in what way?
[02:49] <Kamion> anyone object to this patch to base-config?
[02:49] <Kamion> -                       grep -v "^LANG=" /etc/environmment > /etc/environmment.new || true
[02:49] <Kamion> -                       mv /etc/environmment.new /etc/environmment
[02:49] <Kamion> (lib/menu/finish)
[02:49] <carlos> mdz: ping
[02:49] <Kamion> +                       grep -v "^LANG=" /etc/environment > /etc/environment.new || true
[02:49] <Kamion> +                       mv /etc/environment.new /etc/environment
[02:57] <doko> kamion: no, don't object. could you have a look at #2195
[02:58] <Kamion> so my patch fixes the first half at least
[02:59] <Kamion> and almost certainly the second; what breaks exactly?
[02:59] <Kamion> "The file /etc/enviroment (without typo)"
[02:59] <Kamion> :-)
[03:00] <doko> how do I force dpkg-reconfigure console-common to ask for the language?
[03:00] <doko> the grep in line 47 prints two lines.
[03:00] <Kamion>         for var in LANG LC_ALL LC_CTYPE; do
[03:00] <Kamion>                 value=$(egrep "^[^#] *${var}=" /etc/environment | cut -d= -f2)
[03:01] <Kamion>                 eval $var=$value
[03:01] <Kamion>         done
[03:01] <Kamion> right, ok
[03:01] <Kamion> so you mean /etc/init.d/keymap.sh I'm guessing
[03:01] <doko> correct, thanks for thinking for me :)
[03:01] <Kamion> that's such a crap script; why doesn't it just source the damn file?
[03:02] <Mithrandir> it should use the interface provided by PAM, shouldn't it?
[03:02] <Kamion> oh, yeah, duh, /etc/environment not a shell script
[03:03] <Kamion> yes, it should use pam_getenv then
[03:04] <Kamion> anyway, fixed
[03:07] <doko> ok, keyboard works, after I manually reconfigure console-data to use the german keyboard.
[03:07] <doko> why isn't this done correctly by the installer? wondering ...
[03:09] <Kamion> doko: hm? it should be, isn't it just that base-config bug?
[03:10] <doko> which one?
[03:10] <Kamion> console-data is very bizarre, but the installer should set up the keymap
[03:10] <Kamion> (even if it doesn't look like it has when you reconfigure console-data)
[03:10] <seb128> doko: not sure than #2194 is a bug
[03:10] <Kamion> doko: /etc/environmment for /etc/environment
[03:11] <Kamion> if that screws over /etc/init.d/keymap.sh then it's maybe not too surprising that the keymap's broken?
[03:11] <doko> seb128: believe me, it is. if you use two nomens in the singular form, you have to use the verb in the plural form.
[03:11] <doko> s/nomen/noun/
[03:12] <seb128> doko: on an another chan I've 2 people saying that "ist" is correct
[03:12] <Kamion> doko: isn't it like English where if you use "or" the verb is singular, whereas if you use "and" the verb is plural?
[03:12] <seb128> Kamion: I think so
[03:13] <doko> ah, ok. I'll review that with the next installer.
[03:13] <seb128> that's a "or" in this case .. so "ist" seems to be right
[03:13] <doko> hmm, I'll review that in the "Duden", but it sounds wrong.
[03:13] <Kamion> although I do remember a German class where we were told there was some weird grammar rule, but I don't remember exactly which way it went, hmm
[03:13] <Kamion> I could believe either
[03:14] <doko> seb128: which channel?
[03:14] <seb128> doko: a gnome, but they are not translators afaik
[03:15] <seb128> I'll try to ping a i18n guy
[03:18] <carlos> seb128: we are missing some spanish translations for our gnome-panel changes, could you give me an updated .po so I could finish it?
[03:18] <seb128> arg
[03:18] <azeem> doko: use "ist/sind fehlerhaft" :)
[03:18] <seb128> you (i18n guys) need to set a system up
[03:19] <seb128> I can't keep to synchronize all sort of translations in all the packages in that way
[03:19] <Kamion> The i386 daily CD image I just built should have support in the installer for ipw2100 and ipw2200 cards.
[03:19] <Kamion> allegedly acx_pci too, but that didn't work for me
[03:19] <seb128> carlos: that's not manageable
[03:19] <Kamion> I guess I have a bunch of d-i translations lying around in bugs somewhere to integrate, too.
[03:20] <Kamion> mdz: if you could test the current i386 CD on your ipw* box, that'd be good
[03:21] <carlos> seb128: O:-)
[03:21] <carlos> seb128: hoary time
[03:21] <seb128> carlos: no seriously, people keep reporting translation updates/changes on different GNOME pieces
[03:21] <seb128> carlos: merging the changes are a pain each time
[03:21] <carlos> seb128: btw, changing the talk subject... the trash applet does not sees my iPod trash directory
[03:21] <carlos> seb128: how do you handle that under Debian?
[03:22] <Kamion> seb128: in fairness this *is* what carlos is working on full-time :-)
[03:22] <seb128> carlos: we don't, that's upstream job
[03:23] <carlos> Kamion: yes, that's the idea :-P
[03:23] <seb128> carlos: BTW for the trash, please check with jamesh, he made the changes for monitor extra drives
[03:23] <carlos> seb128: ok
[03:24] <carlos> and I'm able to use my iPod under Ubuntu as a normal user, finally !!
[03:27] <doko> seb128, kamion: as usual: both things are ok, altough they say the singular finitum is more common.
[03:29] <seb128> carlos: I've updated #941 to include the list of strings, if you do a translation include the full file with this format (no information about lines or so, it's problematic for updates when code change)
[03:29] <seb128> doko: ok, so NOTABUG, ok ?
[03:37] <carlos> seb128: ok, thanks
[03:45] <doko> seb128: yes
[04:40] <elmo_> hmm, lshw on amd64 is interesting...
[04:41] <elmo_> it seems to be peeking through every single byte of memory
[04:41] <Mithrandir> how so?
[04:42] <Mithrandir> apart from it listing a fair bunch of hw, it seems fine here.
[04:43] <elmo_> read(3, 0xb2e41811, 1428514031)         = -1 EFAULT (Bad address)
[04:43] <elmo_> read(3, 0xb2e41810, 1428514032)         = -1 EFAULT (Bad address)
[04:43] <elmo_> read(3, 0xb2e4180f, 1428514033)         = -1 EFAULT (Bad address)
[04:43] <elmo_> read(3, 0xb2e4180e, 1428514034)         = -1 EFAULT (Bad address)
[04:43] <elmo_> root      4560 32.1  0.0  2692  860 pts/48   R+   15:24   6:01  |           \_ lshw
[04:44] <Mithrandir> weird, doesn't do that on my box.
[04:44] <elmo_> heh, 'dpkg: warning 'amd64' not in the remapping table'
[04:55] <carlos> pitti: here :-P
[04:55] <pitti> carlos: yes, I remember
[04:55] <pitti> carlos: the "I have to unload the module first" problem?
[04:56] <carlos> no, that's not the bug I'm talking about
[04:56] <carlos> pitti: the one that does not let me use the iPod after mount
[04:56] <carlos> because the owner is root
[04:56] <pitti> ah
[04:56] <pitti> yes
[04:56] <carlos> I did a patch (https://bugzilla.ubuntu.com/show_bug.cgi?id=2197)
[04:56] <pitti> all files should be owned by you, but only the mount point itself is wrong?
[04:57] <carlos> no, all files are owned by root
[04:57] <carlos> well, in fact the problem is that all files have their original values, like when you mount an ext2/ext3 filesystem
[04:58] <pitti> hmm, can you add the patch to the bug as attachment?
[04:58] <carlos> it's in the upstream bugzilla, but yes, I could do it
[04:58] <pitti> I think I cannot decide that, but mdz should. Maybe you should assign the bug to Herbert and CC mdz for approval?
[04:58] <pitti> Would be great if that finally worked
[04:58] <pitti> iPods are quite common
[04:59] <carlos> pitti: no, that's not why I want to ask you :-P
[04:59] <carlos> after reading some code, seems like my fix is wrong
[04:59] <pitti> So?
[04:59] <chrisa> The number of ipods I see on campus frightens me
[05:00] <carlos> the hfsplus code implements the uid/gid options like a fallback when they don't have any posix information for a file
[05:00] <pitti> ugh, that's ugly
[05:00] <carlos> that information exists with iPods so the driver just ignore it
[05:00] <pitti> I thought it should just map any root to the given uid
[05:00] <carlos> me too :-)
[05:01] <carlos> the problem with my patch is that if you mount it as root without uid/gid arguments, all files are owned by root
[05:01] <carlos> that's why I'm not sure if my fix is valid
[05:02] <carlos> no matter if you have a file owned by uid=500, next mount will show it as owned by root
[05:03] <pitti> whatever you modified, can't you just check if uid != 0 before changing anything?
[05:03] <carlos> so, the question is... How do you think it should be fixed?
[05:03] <carlos> so if the current uid == 0 I don't change anything?
[05:04] <carlos> yes, it's possible
[05:04] <pitti> well, this is just my first thought, I've never seen the code
[05:04] <carlos> don't worry about the code.
[05:04] <carlos> think about ext2/ext3
[05:05] <carlos> it does not have any feature that lets you map all uid/gid to one concrete uid/gid
[05:05] <carlos> same as hfsplus
[05:05] <elmo_> hmm, after upgrading the buildds to 2.6.8.1, I've had two in a row hang on apt-extracttemplates - strace shows it stuck in a futex.. anyone else seen this/know about it?
[05:05] <carlos> I just need a suggestion (under your point of view) about a way to implement it :-P
[05:05] <pitti> this uid= option is certainly supposed to be a hack anyway :-)
[05:06] <pitti> but if some fs support it, all others should, too
[05:06] <pitti> hmm, just by looking at the patch I cannot see how it works
[05:07] <pitti> so inode->i_uid is the uid that the file really appears under?
[05:07] <Mithrandir> fabbione: around?
[05:07] <pitti> carlos: and HFSPLUS_SB(inode->i_sb).uid is the uid that is saved on the iPod?
[05:08] <pitti> carlos: in the patch I don't see the value of the uid=XXX mount option
[05:08] <carlos> pitti: that's a "general" uid value that it's set on startup to the current uid or to the uid argument
[05:08] <pitti> carlos: where is that stored=
[05:08] <elmo_> nm, it's #1854
[05:08] <pitti> carlos: s/=/?/
[05:08] <carlos> pitti: inside that structure
[05:09] <carlos> HFSPLUS_SB(inode->i_sb) is a kind of superblock struct
[05:10] <carlos> pitti: it's initialized as:
[05:10] <carlos> opts->uid = current->uid;
[05:10] <carlos> 	opts->gid = current->gid;
[05:10] <carlos> opts is HFSPLUS_SB(inode->i_sb)
[05:10] <carlos> and then, it parses the options
[05:10] <carlos> and updates those values if they are present
[05:10] <pitti> carlos: phone, brb
[05:11] <carlos> no problem
[05:15] <pitti> carlos: back
[05:15] <carlos> I'm looking at MacOSX for the way they handle it
[05:17] <pitti> carlos: as you describe it, it should be fine to only update opts->uid to the override value if the latter is != 0
[05:18] <pitti> carlos: since uid=0 makes not really sense, it can be regarded as "not set"
[05:18] <carlos> latter == uid option or current->uid?
[05:18] <pitti> carlos: the override value, so the uid= option
[05:18] <pitti> carlos: but AFAICS you should not delete the lines in the patch then
[05:18] <pitti> carlos: just override them afterwards if uid= != 0
[05:19] <pitti> carlos: I did not see the whole code, but does that make sense?
[05:19] <carlos> pitti: well the check should be if uid argument is given or not
[05:19] <pitti> carlos: if you can decide that direcly, so much the better
[05:19] <carlos> the problem comes when you don't use the argument :-)
[05:20] <pitti> carlos: I thought that 0 (or -1) or whatever could be a default value if no uid= option is givne
[05:20] <pitti> carlos: the code should work correctly if uid== is not given, right?
[05:21] <carlos> if there is no uid given, the uid that is used is the process uid
[05:21] <carlos> current->uid
[05:21] <carlos> so perhaps I could do that check
[05:21] <pitti> but that sounds wrong as well
[05:21] <carlos> if current->uid ==  HFSPLUS_SB(inode->i_sb).uid, then I do nothing
[05:21] <pitti> if no uid is given, it should use the uid that is saved on the ipod?
[05:22] <carlos> pitti: yes, it does it that way, the problem comes with my patch :-)
[05:22] <carlos> seems like hfsplus let you store files without posix permissions information
[05:22] <pitti> carlos: ah, I see.
[05:22] <carlos> and they are using the uid and gid options to give a default value for that case
[05:22] <pitti> carlos: hmm, but if it does not have POSIX permissions, it should default to root, to be sure
[05:22] <pitti> (which is then mapped to uid= of coruse)
[05:23] <pitti> which is essentially the same, as I see now
[05:23] <pitti> carlos: now I understood what they use the uid and gid options for currently
[05:24] <carlos> well, the way they do it let a normal user mount it and all files with that information will be owned by that user
[05:24] <pitti> so my proposal would be: set uninitialized uid/gid of files to root:root
[05:24] <carlos> if I change it to 0 then I will break that case
[05:24] <pitti> and later, when you evaluate the mount options, change all root files to uid=XXX
[05:25] <carlos> makes sense, but there is still the problem when you mount it as a normal user from a fstab entry with the "user" option
[05:26] <pitti> doesn't that imply uid=getuid() and gid=getgid()?
[05:26] <pitti> it should
[05:26] <pitti> ^^^ (as mount options)
[05:26] <pitti> jdub: here
[05:26] <carlos> don't know
[05:26] <carlos> pitti: is that possible inside fstab?
[05:27] <pitti> what?
[05:27] <carlos>  uid=getuid(),gid=getgid()
[05:27] <pitti> carlos: no, not in fstab
[05:27] <pitti> carlos: it should be in the option parsing
[05:27] <carlos> hmm
[05:28] <pitti> carlos: if no uid= option is set, but 'user' is set, it should imply uid=getuid()
[05:28] <carlos> so if there is a "user" option, then I should assume that?
[05:28] <carlos> let me check...
[05:28] <pitti> just as VFAT
[05:28] <pitti> well, I had to try that out
[05:29] <pitti> no, please forget that
[05:30] <pitti> user does not imply uid=getuid(), sorry
[05:30] <carlos> true I don't see that option inside the fat driver
[05:30] <pitti> this is not done with VFAT, I just mixed that up, pmount explicitly gives uid=getuid() options
[05:31] <pitti> if you use pmount, the 'user' option is not important anyway
[05:31] <pitti> I think we don't need to consider the case where the iPod is in fstab
[05:31] <pitti> it should work with pmount, so uid= and gid= has to work correclty
[05:31] <carlos> well, it's not iPod but any hfsplus drive
[05:31] <pitti> (more correct than my spelling, that is :-) )
[05:31] <carlos> :-)
[05:31] <pitti> right
[05:32] <carlos> apple has the uid and gid options like vfat has
[05:32] <carlos> so I suppose it's a good argument to use it that way
[05:32] <pitti> so conclusively, you revert the patch and instead set the effective inode uid to the mount option only if the mount option != 0?
[05:33] <pitti> and maybe implement defaulting to root:root if no posix info is available for a file?
[05:33] <carlos> pitti: yes, something like that
[05:33] <pitti> carlos: well, anyting other than root makes no sense
[05:33] <carlos> I will read the documentation first to be sure I'm not breaking anything
[05:35] <pitti> carlos: anything other than root makes no sense
[05:35] <pitti> carlos: of course it should be overridden by uid= afterwards
[05:35] <carlos> yes
[05:37] <carlos> pitti: funny:
[05:37] <carlos> ownerID
[05:37] <carlos>     The Mac OS X user ID of the owner of the file or folder. Mac OS X versions prior to 10.3 treats user ID 99 as if it was the user ID of the user currently logged in to the console. If no user is logged in to the console, user ID 99 is treated as user ID 0 (root). Mac OS X version 10.3 treats user ID 99 as if it was the user ID of the process making the call (in effect, making it owned by everyone simultaneously). These substi
[05:37] <carlos> tutions happen at run time. The actual user ID on disk is not changed.
[05:38] <pitti> phone again... sorry ...
[05:38] <carlos> don't worry
[05:38] <pitti> party this evening...
[05:39] <carlos> :-)
[05:39] <pitti> back
[05:39] <Mithrandir> scary
[05:39] <pitti> who invented this crap?
[05:40] <carlos> pitti: Apple :-P
[05:40] <pitti> the actual user ids on the disk should not be changed anyway
[05:40] <carlos> groupID
[05:40] <carlos>     The Mac OS X group ID of the group associated with the file or folder. Mac OS X typically maps group ID 99 to the group named "unknown." There is no run time substitution of group IDs in Mac OS X.
[05:40] <pitti> so they have "root stays root" and "99 becomes the user in uid="?
[05:41] <carlos> pitti: no
[05:41] <carlos> root stays root, 99 becomes the user that is logged in
[05:41] <pitti> oh no, sorry
[05:41] <pitti> right
[05:41] <carlos> and with latest MacOSX 10.3
[05:41] <carlos> 99 becomes getuid()
[05:42] <pitti> dynamically for every process then
[05:42] <carlos> and then, they have the uid, gid options to change it at mount time
[05:42] <pitti> so if both you and me are accessing the same file, both of us would think that the file belonged to us, right?
[05:42] <carlos> pitti: no, dynamically for the mount command
[05:42] <carlos> hmm
[05:42] <carlos> perhaps you are right...
[05:42] <pitti> well, what is "the call"?
[05:42] <carlos> let me check it :-)
[05:42] <pitti> file access or mount?
[05:43] <pitti> but they say "making it owned by everyone simultaneously"
[05:43] <carlos> we will know it soon, let me create a new user in my imac
[05:43] <carlos> :-)
[05:43] <pitti> but anyway, if that were already implemented like this in linux, the files should belong to you no matter whether it is mount or file access
[05:44] <Mithrandir> could somebody review http://err.no/patches/linux-restricted-modules-2.6.8.1.2-3_2.6.8.1.3-1.amd64.diff ?
[05:44] <pitti> so the current implementation neither fulfils the apple specs nor the usual uid=/gid= semantics
[05:45] <carlos> pitti: true
[05:45] <pitti> carlos: I think we should not use the uid 99 semantics
[05:46] <pitti> carlos: because it could be a regular system user on somebody's computer
[05:46] <pitti> carlos: and this could even be a security hole (because any user could then access files which are meant only for the user with id 99)
[05:46] <carlos> pitti: it's owned by the process that access the device not the mount command
[05:46] <pitti> carlos: so it's really the 'I belong to everybody' sematics?
[05:46] <pitti> odd
[05:47] <Mithrandir> pitti: 99 is statically allocated and in the range owned by base-passwd, though.
[05:47] <pitti> Mithrandir: I know, but you know, there is always one person.. never mind
[05:47] <carlos> pitti: yes
[05:47] <pitti> It's not a big deal, but  I learned to be paranoid :-)
[05:48] <Mithrandir> unix gives you enough blackpowder and rope to kill yourself in various ways.
[05:48] <Mithrandir> that's a feature. :)
[05:48] <carlos> pitti: if I'm root, I'm the owner, if I'm carlos, I'm also the owner :-)
[05:48] <pitti> Mithrandir: yes, but if I shoot myself in the foot, then I should know what I'm doing
[05:48] <pitti> carlos: probably it's not too bad to just implement Apple's semantics
[05:49] <pitti> carlos: although I don't really like it
[05:49] <carlos> pitti: the fact is that it's a hfsplus volume and the designer did it that way...
[05:49] <pitti> carlos: I would not want to enable other users to overwrite my hfsplus files
[05:49] <carlos> pitti: yes, that's my point
[05:49] <carlos> pitti: btw, that will not happen if you use the uid/gid options
[05:49] <pitti> carlos: OTOH I'm not really the one who can overrule Apple :-)
[05:49] <pitti> carlos: oh, not?
[05:49] <carlos> no, because it will not be 99 :-)
[05:50] <carlos> it will be the uid you say :-D
[05:50] <pitti> Mithrandir: I meant that I would not expect my files go world-writeable if I create an user with id=99
[05:50] <pitti> carlos: but the file on disk has still 99
[05:50] <carlos> pitti: but it's the hfsplus driver which changes it
[05:51] <carlos> I will prepare a patch to follow Apple rules
[05:51] <Mithrandir> pitti: well, true, but you shouldn't create a user with uid = 99. :)
[05:51] <carlos> pitti: when it's ready i will show you it, perhaps it's easier to understand that way...
[05:51] <pitti> Mithrandir: now I know that
[05:51] <pitti> Mithrandir: :-)
[05:51] <pitti> carlos: agreed. "Use the Source, Luke"
[05:52] <carlos> :-P
[05:52] <pitti> carlos: I think I now understood the problem
[05:52] <pitti> carlos: BTW, you should put this Apple spec into the bug report
[05:52] <pitti> carlos: then the patch can be verified against it
[05:53] <pitti> guys, I've gotta go. In an hour 10 friends will arrive and I have to prepare the meal
[05:53] <pitti> See ya later!
[05:53] <pitti> carlos: Have fun implementing the stuff! :-)
[05:55] <carlos> :-D
[05:55] <carlos> pitti: have fun
[06:53] <sivang> am trying to build a package, and I get this :" found. Your intltool is too old.  You need intltool 0.29 or later.
[06:53] <sivang> "
[06:54] <sivang> can anybody tell me why it does that? do we have a newer version of intltool ?
[06:54] <sivang> it's a gnome package btw
[06:57] <seb128> apt-get install intltool
[06:57] <seb128> warty has 0.31.1
[06:58] <sivang> seb128 : ok, thanks
[06:59] <sivang> seb128 : it tells it's already the newest version 
[06:59] <seb128> ok, so fix the upstream soft
[07:00] <sivang> k
[07:19] <|trey|> sivang: apt-get update && apt-get install intltool
[07:20] <sivang> |trey| : thanks, already solved it. I had done something bad to my packages, so reinstalled from source and applied the changes back everything went to normal.
[07:32] <elmo_> gar, how did we end up shipping without ethtool
[07:45] <Mithrandir> mdz: ping?
[08:07] <daniels> thom: yeah
[08:08] <daniels> thom: the red hat guys are getting a little antsy
[08:46] <mdz> Mithrandir: pong
[09:00] <mdz> what's all this gs-esp stuff about?
[10:10] <doko> mdz: see #2193, after a fresh install the installer wants to fetch tcl8.0, gs-gpl and gs, which are not on the CD. these patches resort the recommends/depends so that gs-esp (which is on the CD) satisfies the dependencies/recommendations.
[10:20] <mdz> doko: did you test that it has the desired effect?
[10:23] <doko> well, difficult to test. I hand edited the package list before the download started and no more packages were fetched from the net. no, I didn't build a new CD.
[10:36] <mdz> ok