[01:35] <slangasek> asac: bug #147913 is still shown as 'in progress'; surely the copyright update should be straightforward, so is it really in progress?
[01:35] <ubotu> Launchpad bug 147913 in gnash "[gutsy]  gnash shipped with GPLv2 debian copyright even though upstream uses GPLv3 since 0.8.1" [Critical,In progress]  https://launchpad.net/bugs/147913
[01:36] <cjwatson> "first reported 22 hours ago"
[01:36] <jdong> so Launchpad doesn't have a 1-hour delivery service like my local pizza shop?
[01:36] <jdong> (sometimes it can't even load a page before the pizza arrives.... :D)
[01:37] <cjwatson> damn, now I'm hungry
[01:45] <asac> slangasek: yes ... its in progress ;)
[01:45] <asac> slangasek: meaning its about to be uploaded
[01:45] <slangasek> ok :)
[01:45] <TheMuso> cjwatson: Re the problem with germinate and the ubuntustudio meta not treating ubuntustudio-desktop as a dependency, I'm just wondering whether its worth adding ubuntustudio-desktop as a hard-coded dependency in the meta package for now as a workaround?
[01:46] <slangasek> cjwatson: that's still a lot of progress! :)
[01:46] <asac> slangasek: i use in progress to show you (RMs) that you don't have to bother ;)
[01:47] <cjwatson> TheMuso: it's OK, I'll fix it tomorrow
[01:47] <cjwatson> shouldn't be hard
[01:47] <slangasek> asac: noted :)
[01:47] <TheMuso> cjwatson: Ok.
[02:31] <lamont> slangasek: could you be so kind as to move libgcc2/gutsy/hppa to universe?
[02:32] <lamont> FWIW, that package gets sucked in by debootstrap, but need not.
[02:33] <lamont> and yes, that'll make lots and lots of main not installable without universe, until the buildd catches up with things
[02:33] <lamont> OTOH, debootstrap now workd
[02:33] <lamont> works, even
[02:37] <slangasek> lamont: done, I think
[02:38] <lamont> heh.  thanks
[02:40] <lamont> hrm... why is gcc-3.4 still in main?
[02:42] <slangasek> for libg2c0 apparently?
[02:42] <lamont> if gcc-3.4 is supposed to still be in main for gutsy, then oops.  libgcc2 and gcc-4.0-base need to be in main for hppa (gcc-3.4 depends libgcc2 which depends gcc-4.0-base)
[02:43] <lamont> or if you don't mind, I'll kick a no-change gcc-3.4 build to get hppa current, and we'll see if that removes the libgcc2 depends...
[02:43] <lamont> I think the latter is actually the correct answer
[02:45] <lamont> anyway, I'll prepare an upload once I get back in a couple hours, if it makes sense
[02:46] <lamont> after all, the rest of the compilers got rebuilt this last week... doko just doesn't love gcc-3.4 anymore, it seems. :=)
[02:46] <slangasek> heh
[02:51] <lamont> rebuilding it might work.  gone
[02:51] <lamont> and I'll pester you when I'm back home
[03:34] <lee_pepper> could any one offer any insight in to this error in a LiveCD build by livcd-rootfs > $ ubiquity gtk \n sudo: must be setuid root
[04:05] <christian> hellp
[04:05] <christian> hello
[04:05] <christian> anybody in
[04:05] <Hobbsee> no
[04:05] <christian> ??
[04:05] <christian> no
[04:05] <christian> jeje
[04:05] <christian> hello
[04:05] <christian> where r u from hobbse
[04:05] <bddebian> Hobbsee: shh ;-)
[04:06] <christian> hobsee
[04:06] <Hobbsee> christian: australia.  you may be looking for #ubuntu-offtopic
[04:06] <christian> no
[04:06] <christian> i'm looking
[04:06] <christian> for something
[04:06] <christian> is putting me out
[04:06] <christian> and i cannot solve
[04:06] <Hobbsee> !enter
[04:06] <ubotu> Please try to keep your questions/responses on one line - don't use the "Enter" key as punctuation!
[04:06] <pwnguin> you know, complete sentences in a single line aren't that hard. even I can pull those off
[04:06] <christian> could u help me
[04:06] <christian> ??
[04:07] <Hobbsee> christian: please read the /topic
[04:08] <christian> i'm lookin for how could i run a c++ application
[04:08] <christian> in gnome terminal
[04:09] <Hobbsee> then you want #ubuntu
[04:09] <RAOF> christian: By asking in a support channel, such as #ubuntu.
[04:09] <christian> ok
[04:09] <christian> no problem
[04:11] <StevenK> Damn it, I hate it when debmirror is right.
[04:12] <pwnguin> aww crap. bryce actually responded to a bug report
[04:13] <pwnguin> now i have to go forth and regather the relevant data =/
[04:14] <Hobbsee> you could just close the bug :P
[04:14] <pwnguin> im sure it still exists
[04:14] <pwnguin> its just that using displayconfig-gtk tends to destroy xorg.conf
[04:14] <Hobbsee> pity
[04:26] <lamont> slangasek: any objections to a gcc-3.4 upload?
[04:26] <slangasek> lamont: nope
[04:27] <lamont> uploaded
[04:28] <lamont> mlton:                  10:21:54 (1 entry, sigma 00:00:00)
[04:28] <lamont> efh
[04:28] <lamont> feh
[04:28] <StevenK> It *seems* like every directory of this source bar one deals with -fPIC -DPIC
[04:28] <RAOF> Yay autofoo!  What is it?
[04:29] <lamont> RAOF: it's spelled autocrap
[04:29] <lamont> StevenK: ouch
[04:29] <StevenK> It's a guess on my part.
[04:30] <StevenK> I see -fPIC -DPIC in other parts of the build, and it seems like one object isn't getting -fPIC'd and when it comes time to link the whole thing together, it blows up.
[04:31] <lamont> how does it blow up?  and what arch?
[04:31] <ScottK> How big are the flames?
[04:32] <Hobbsee> |------------------|  <-- that big.  (not to scale)
[04:32] <StevenK> lamont: amd64
[04:32] <lamont> and the error?
[04:32] <bddebian> hehe
[04:32] <RAOF> Because amd64 *really* cares about PIC.
[04:32] <RAOF> i386, not so much.
[04:32] <StevenK> lamont: I'm getting there, my machine is building. :-)
[04:32] <lamont> ah, ok
[04:40] <StevenK> /usr/bin/ld: ../libtinymailui-gnome-keyring/libtinymailui-gnome-keyring.a(tny-gnome-keyring-password-getter.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
[04:40] <StevenK> lamont: ^
[04:41] <lamont> yeah - you need -fPIC, and probably -DPIC if that's what the rest of the build says...
[04:41] <StevenK> lamont: If I hack libtinymailui-gnome-keyring/Makefile and add -DPIC -fPIC to the LIBTINYMAIL_CFLAGS, it works. I'm just uncertain how to fix it with autobork
[04:42] <lamont> which gets us to why I hate autocrap
[04:42] <RAOF> StevenK: You could patch Makefile.am to add -fPIC to the CFLAGS.
[04:42] <lamont> look at Makefile.in in a directory that works?
[04:43] <lamont> or possibly Makefile.am, depending on which exists...
[04:43] <lamont> .am if present, then .in, then Makefile
[04:43] <RAOF> StevenK: But isn't autofoo meant to do that automatically for shared libs-on-amd64?
[04:43] <StevenK> -fPIC exist in none of the Makefile.{in,am}
[04:43] <lifeless> StevenK: its either something settings CFLAGS that should set AM_CFLAGS
[04:43] <lifeless> or similar on a per-target pasis
[04:43] <lifeless> StevenK: -fPIC is set by autoconf at configure time, it only ever exists in Makefile and config.status
[04:44] <StevenK> Ah ha.
[04:44] <lamont> so something in a Makefile.am or config* is causing it to not set it in that directory - grepping for that dir and a working one through the tree might bear fruit.
[04:44] <lamont> and lifeless knows far more about auto* than I ever want to
[04:49] <StevenK> Hum. -fPIC only appears in 3 makefiles
[04:52] <StevenK> The broken directory's Makefile.am sets INCLUDES without including AM_CFLAGS
[05:41] <thully> I've got an issue with gnome-power-manager that has been nagging for some time
[05:41] <thully> I've found a source of the problem, but am unsure of the exact solution (I'm not exactly a C whiz...)
[05:42] <thully> The bug is bug #137598
[05:42] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Undecided,Confirmed]  https://launchpad.net/bugs/137598
[05:42] <ScottK> thully: This is a pretty quiet time here.  Most devs are sleeping.
[05:43] <ScottK> thully: Are you sure it's a regression?
[05:43] <thully> OK - I guess I figured that they were scattered across many time zones...
[05:44] <ScottK> They are, but the concentration is in in US/Europe.
[05:44] <thully> It may not be a regression per se, but in any case Feisty didn't do it with the AC plugged in
[05:44] <ScottK> I'm not sure what that means.
[05:44] <ScottK> What did Feisty do wrong?
[05:45] <thully> When I had the AC adapter plugged in, the screen didn't "dim" to full brightness on idle
[05:45] <thully> That's what it does on Gutsy
[05:45] <thully> However, I've pinned it down to the idle/dim logic in gpm-backlight.c
[05:45] <ScottK> OK.
[05:46] <ScottK> I'll call that a regression.
[05:46] <ScottK> What I recommend you do is add your findings to the bug in as much detail as you understand it.
[05:46] <ScottK> I'm going to milestone the bug for RC since it's a regression (I think I have sufficient power to do that).
[05:47] <thully> OK - I'm looking at the code to see if I can fix it.  I understand the problem fairly well, but i'm no C expert
[05:47] <ScottK> thully: It's now milestoned for RC due to being a regression.
[05:47] <thully> thanks
[05:48] <ScottK> OK.  If you can figure a patch, your odds go way up.
[05:48] <ScottK> In any case take it as far as you can.  If you figure a patch, then subscribe ubuntu-main-sponsors to the bug.
[05:48] <Hobbsee> ScottK: you do, but dont be surprised if it gets dropped
[05:48] <Hobbsee> but if i'ts with a patch, then that'll elp it significantly
[05:49] <ScottK> Hobbsee: Sure.  No guarantees, but if it's a regression, I think an RC milestone is fair.
[05:49] <thully> I did have a few other regression issues, as well...
[05:49] <Hobbsee> ScottK: true.  assuming people have time to fix it.
[05:49] <ScottK> Which is why having a patch helps hugely.
[05:49] <thully> Those would be bugs 127101 and 137738
[05:49] <ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [High,Confirmed]  https://launchpad.net/bugs/127101
[05:49] <ubotu> Launchpad bug 137738 in ubuntu "[gutsy]  suspend / hibernate works fine, but after resume, I get a "Failed to suspend" popup" [Undecided,New]  https://launchpad.net/bugs/137738
[05:50] <ScottK> Hobbsee: On that basis, what do you think about milestoning Bug #127772?
[05:50] <ubotu> Launchpad bug 127772 in linux-source-2.6.22 "CPU fan no longer runs after upgrade to Gutsy" [Medium,Triaged]  https://launchpad.net/bugs/127772
[05:51] <Hobbsee> ScottK: i'd check with the kernel team
[05:51] <Hobbsee> ScottK: they get hit real soon nwo by kernel freeze anyway
[05:52] <ScottK> thully: The xserver one is assigned to the Ubuntu X maintainer, so I think your odds there are as good as they get already.
[05:52] <Hobbsee> ScottK: ah, there is a starting point on that one.
[05:53] <ScottK> thully: The suspend/hibernate one really needs to be narrowed down to the affected package before I'd feel confortable milestoning it.
[05:53] <thully> ScottK/Hobbsee: I see they're working on it, but I really think they should revert intel driver to i810 for supported cards if the fix doesn't make it
[05:53] <ScottK> Well we aren't the people to have that argument with.
[05:54] <thully> who would be?  I mentioned it on the bug itself...
[05:54] <ScottK> The person to whom it's assigned.
[05:54] <thully> ScottK: regarding the suspend one, I almost certain it's gnome-power-manager being uber-sensitive
[05:54] <thully> as my machine suspends/resumes fine
[05:55] <ScottK> OK.  I'm a Kubuntu kind of person, so I'm not going to weigh in on that one.
[05:55] <ScottK> thully: Good luck figuring the patch.
[05:56] <thully> I guess I'll look at the diff from feisty - it works OK there...
[05:57] <thully> Honestly, I can't believe this gnome-power-manager is an actual upstream release - it is uber-buggy in a glaringly obvious way
[05:57] <RAOF> thully: It's possible that no-one else has their display brightness set < max when on AC? :)
[05:58] <Hobbsee> but then, i don tuse gnome, so i think it's a bit brighter anyway
[05:58] <lifeless> ha!
[05:58] <thully> no one - that's mind of unbelievable, as many screens are EXTREMELY bright at full brightness
[05:58] <thully> kind
[05:59] <RAOF> thully: Ok.  No-one from the g-p-m team?
[06:00] <Amaranth> RAOF: the g-p-m team is ogra
[06:01] <RAOF> Amaranth: Heh.  Ok, that *ogra* has his brightness set to 100% on AC.
[06:01] <Amaranth> RAOF: What is a sane default if not 100?
[06:01] <RAOF> Indeed.
[06:02] <Amaranth> Just push the button on your keyboard to turn it down and it'll be remembered
[06:02] <Amaranth> or use the panel applet, or gconf-editor
[06:03] <RAOF> But that's not quite the bug, though.
[07:11] <Hobbsee> asb
[07:11] <Hobbsee> asac: btw, my wifi works at uni too now!  well done!  (ipw3945, unencrypted)
[07:14] <lifeless> Hobbsee: does NM work for you?
[07:15] <RAOF> lifeless: Works for me (ipw3945/iwl3945, WPA2/WEP/unencrypted)
[07:15] <lifeless> I have a iwl3945
[07:15] <lifeless> crashes for me
[07:15] <Hobbsee> lifeless: yes, fully now
[07:16] <lifeless> hmm, I'll update and try again
[07:16] <Hobbsee> lifeless: it didnt used to connect on open networks
[07:16] <RAOF> Worked, most of the time, with iwl.  Definitely works with ipw
[07:16] <lifeless> Hobbsee: 'kernel panic'
[07:16] <Hobbsee> lifeless: ouchy.  never had that from wifi
[07:16] <lifeless> indeed
[07:17] <StevenK> I've had ipw2200 cause kernel BUG and an Oops, but never a panic
[07:17] <RAOF> lifeless: Does ipw work, though?
[07:17] <lifeless> RAOF: I haven't tried replacing the driver; massively short on time to fiddle. I just nuked NM and ran up /etc/interfaces
[07:18] <RAOF> The iwl3945 have still got their pciid's patched out to ensure you deliberately load it, right?
[07:44] <lamont> then again, having disabled it, I find that my multi-homed-laptop life is much happier
[07:44] <StevenK> I don't have many problems with NM on Feisty
[07:45] <lamont> I have no problems with it either, since I killed it... :-)
[07:45] <lamont> it was its decision to switch networks for me, or re-up an interface and route lots of stuff down a default path that was currently bogus that caused me to decide that it must die
[07:46] <lamont> I suppose I should try enabling it in gutsy and see if it's any better
[08:11] <slangasek> lamont: "NM inspires in me a great capacity for hurling fire works at the people who thought it up"? ;)
[08:11] <StevenK> Hahaha
[08:11] <lamont> slangasek: you know I would never do that.
[08:11] <Hobbsee> fireworks would be too painless.
[08:12] <StevenK> lamont: What, not personally, anyway? :-)(
[08:12] <StevenK> s/(//
[08:12] <lamont> I think I would like NM more if it believed that there was more than one use-case
[08:12] <slangasek> I thought you weren't a volunteer firefighter anymore, it's no longer a conflict of interest ;)
[08:12] <lamont> Hobbsee: the trick is to get the right kind....
[08:12] <StevenK> Like napalm
[08:12] <lamont> slangasek: I did retire. makes it much harder to get useful fireworks. :-)
[08:12] <StevenK> Hah
[08:14] <StevenK> lamont: The one use case being "You are using only one of wired or wireless with DHCP" ?
[08:14] <RAOF> StevenK: And possibly using some form of VPN
[08:15] <StevenK> Actually, I think the one use case of NM is "You want to spend hours debugging network issues while I 'help' you, right?"
[08:15] <lamont> StevenK: "you only have one interface active ever, and you never manually set it up to anything other than what I think the default is."
[08:15] <lamont> for bonus points, postrm downs the interface
[08:15] <lamont> so never remove networkmangler remotely
[08:15] <liw> I'm a lucky member of the one NM use case (now that I figured out you mean NetworkManager and not the Debian thing :)
[08:15] <RAOF> Heh.  My use case is "my laptop moves around, and I'd like networking to work"
[08:16] <StevenK> lamont: Hah
[08:16] <lamont> StevenK: I guess the logic is that you don't want networking, since you removed network-mangler
[08:16] <lifeless> lamont: NM won't get better, its intended to be stupid
[08:17] <StevenK> So it kills networking on upgrades, too?
[08:17] <StevenK> This just smacks of dbus, "You can't restart the dbus daemon, you HAVE to reboot"
[08:17] <RAOF> Not that I've noticed.
[08:18] <lifeless> upgrades have been interesting on this laptop
[08:18] <lifeless> given that upgrades *start* NM
[08:18] <lifeless> and NM *stops the box*
[08:19] <StevenK> And then dpkg says, "Network Manager broke your upgrade. Let me start it for you."
[08:20] <lamont> bind9 is the only thing missing from ubuntu-standard/hppa... /me goes bug-report scanning
[08:20] <Hobbsee> soren: why is cups-pdf required to have the root's p/w now?
[08:21] <lifeless> say what
[08:21] <lifeless> *nothing* gets my root password
[08:21] <lifeless> thank you very much
[08:21] <Hobbsee> [16:20]  <Hobbsee> Setting up cups-pdf (2.4.6-3ubuntu7) ...
[08:21] <Hobbsee> [16:20]  <Hobbsee> Password for root on localhost?
[08:21] <Hobbsee> [16:20]  <Hobbsee> Password for root on localhost?
[08:21] <Hobbsee> [16:20]  <Hobbsee> lpadmin: Unauthorized
[08:21] <Hobbsee> [16:20]  <Hobbsee> dpkg: error processing cups-pdf (--configure):
[08:21] <Hobbsee> [16:20]  <Hobbsee>  subprocess post-installation script returned error exit status 1
[08:21] <slangasek> ...eew?
[08:21] <lifeless> fuckoffanddie
[08:21] <liw> ugh
[08:21] <Hobbsee> during a dist-upgrade in a chroot from feisty--> gutsy.
[08:21] <Hobbsee> slangasek: that was my thought.
[08:21] <lifeless> what was soren thinking
[08:21] <Hobbsee> i'm surprised it hasnt been picked up in update testing bfeore
[08:21] <StevenK> Yes...
[08:22] <lamont> especially since root doesn't have a password
[08:22] <soren> lifeless, Hobbsee: Huh?
[08:22] <LaserJock> ajmitch: ping?
[08:22] <ubotu> Launchpad bug 147731 in bind9 "This package prevent .local adresses to work" [Undecided,New]  https://launchpad.net/bugs/147731
[08:23] <Hobbsee> soren: just doing a kubuntu dist-upgrade in a chroot from feisty--> gutsy, and getting the above ^
[08:23] <StevenK> Hobbsee: Can you edit the postinst in /var/lib/dpkg/info/cups-pdf.postinst and add 'set -x' as the second line.
[08:23] <StevenK> Hobbsee: Then run 'dpkg --configure -a'
[08:23] <soren> Hobbsee: ...and how is that my fault?
[08:24] <Hobbsee> soren: (that's your domain, isnt it?)
[08:24] <lifeless> lamont: my roots do
[08:24] <soren> Hobbsee: cups-pdf? Heck no.
[08:24] <lamont> lifeless: mine too
[08:24] <Hobbsee> soren: drat, i'm sorry - i thought you were the last uploader, for some reason!
[08:24] <lamont> but that's just so I can deal with bad times during boot
[08:25] <Hobbsee> looks to be pitti's fault, or till's, or keescook
[08:25] <lifeless> sorry soren !
[08:25] <soren> :)
[08:25] <soren> You sure had me confused for a second there :)
[08:25] <lamont> ScottK: I'd be interested in seeing a patch fo rbug 42463
[08:26] <Hobbsee> StevenK: as in, a seperate set -x, or a set -ex?
[08:26] <soren> Hobbsee: Somehow I'd be a bit surprised if pitti or kees made anything ask for your root password..
[08:26] <Hobbsee> (there's already a set -e there)
[08:26] <StevenK> Hobbsee: Either is fine, latter prefered
[08:26] <Hobbsee> soren: that's what i woudl have thought.  which leaves q-funk.  'nough said.
[08:26] <soren> quite
[08:27] <Hobbsee> StevenK: pastebinning.
[08:27] <lamont> Hobbsee: you're sync-capable, yes?
[08:27] <Hobbsee> lamont: me?  hell no, i dont work for canonical.
[08:27] <lamont> nm.  /me isn't patient enough to wait for it to actually get _into_ sid.
[08:27] <Hobbsee> lamont: slangasek may be at this point.
[08:27] <lamont> he is.
[08:27] <Hobbsee> if rt has done his request
[08:27] <StevenK> lamont: If it's in Incoming, it can be sync'd
[08:28] <lamont> ah, true enough... and there's already a bug, so I can do it that way
[08:28] <Hobbsee> StevenK: http://rafb.net/p/XYd3ck61.html
[08:28] <lamont> Hobbsee: I
[08:28] <lamont> 'm a buildd-admin team member, and not a canonical emp.
[08:28] <Hobbsee> lamont: how the heck did you manage that?
[08:28] <lamont> history
[08:29] <StevenK> lamont has been a Debian porter since, well '.'
[08:29] <Hobbsee> lamont: ah right, you're thru debian, so get more privs.  that makes sense.
[08:29] <lamont> I _was_ canonical... and well, we decided that I could still be one of the cool kids, even though I left.
[08:29] <Hobbsee> oh right.
[08:29] <Hobbsee> that explains even more then.
[08:29] <lamont> nothing to do with debian, actually
[08:30] <StevenK> lamont: You went from HP to Canonical and then back again?
[08:30] <Hobbsee> no, but if you were at canonical, it would explain everything - not enough people have access to them to fix it as it is.
[08:30] <Hobbsee> hi Spads
[08:30] <lamont> StevenK: yes
[08:30] <Spads> hullo
[08:30] <StevenK> lamont: Interesting.
[08:30] <lamont> StevenK: well... actually that was HP IT -> unemployed -> Canonical -> HP Linux Division
[08:31] <lamont> which makes it much more understandable
[08:31] <StevenK> Ah, way cool. So now you're under Bdale?
[08:31] <lamont> I could be wrong, but I don't believe bdale actually has anyone reporting to him.
[08:32] <lamont> but he is Linux CTO
[08:32] <lamont> or some such
[08:32] <StevenK> lamont: Sounds about right.
[08:33] <StevenK> Hobbsee: Okay, it looks like the people to blame are Till Kamppeter or pitti
[08:33] <ion_> Blame Canada.
[08:34] <soren> If I don't get asked for my root password when I upgrade cups-pdf, am I doing something wrong?
[08:36] <slangasek> StevenK: ?
[08:37] <StevenK> slangasek: ari being, well, ari
[08:37] <slangasek> well, yes
[08:39] <torkel> soren: No. You probably already have the cups-pdf print queue before upgrading
[08:40] <StevenK> Where as Hobbsee probably doesn't
[08:40] <Hobbsee> print queue?
[08:41] <calc> davidm: hi! :) (yea you are probably asleep i should be too)
[08:41] <StevenK> Hobbsee: cups-pdf adds a "Print to PDF" queue on upgrade.
[08:41] <StevenK> Hobbsee: That's what that lpadmin command is trying to do.
[08:41] <Hobbsee> right
[08:45] <realist> That reminds me, printing a pdf from evince didn't work last week, yet piping pdf2ps output to lp worked - should I try and reproduce on a default install?
[08:46] <liw> realist, you should always try to make a bug reproducible :)
[08:47] <liw> http://www.debuggingrules.com/ -- I don't think I've mentioned this anywhere today :)
[08:50] <realist> liw: what if I can only reproduce the bug with said pdf file?
[08:51] <liw> realist, if you can share (privately) that pdf with evince maintainers (Ubuntu/upstream), that would be great, but if not, things may get difficult, unless you can debug it yourself
[08:52] <StevenK> I can remember wiggy complaining that OpenOffice always used to crash when he was playing with documents under a NDA
[08:52] <Spads> liw: that poster reminds me of the Reading Rainbow posters we used to have at school in the 80s.  They had Levar Burton on them and said "Reading.  It's not just FUN: It's FUN-damental!"
[08:52] <soren> torkel: Oh, right.
[08:52] <realist> Fortunately this isn't under NDA, but it may have personally identifiable information in it :-(
[08:53] <realist> I'll try on another machine first, then from gutsy.
[08:59] <Mirv> cjwatson: if you have time, bug 147612 links to remaining installer i18n problems besides being a bug itself. especially I'd really like to have the final "Install" button translated.
[08:59] <ubotu> Launchpad bug 147612 in ubiquity ""Advanced..." button untranslated" [Undecided,New]  https://launchpad.net/bugs/147612
[09:00] <mdke> iwj: around?
[09:19] <lamont> slangasek: still awake?
[09:27] <mdke> I need to batch rename a substantial number of files from filename-LANG.po to LANG.po, does anyone know how I can do that?
[09:29] <lamont> for f in filename-*.po; do mv $f ${f#filename-}; done
[09:29] <lamont> I imagine someone has crafted some special command to do that, but why bother? :-)
[09:30] <Mithrandir> rename s/filename-// filename-*.po ?
[09:31] <mdke> Mithrandir: do you think "svn rename" supports that too?
[09:31] <Mithrandir> it doesn't
[09:31] <mdke> ok
[09:31] <Mithrandir> but lamont's version could work with svn rename
[09:31] <lamont> Mithrandir: given tac-nukes...
[09:32] <lamont> s/given/once you have/
[09:32] <mdke> I replace "mv" with "svn mv"?
[09:32] <lamont> or mv with svn rename
[09:32] <Mithrandir> lamont: to you, everything smaller than a tac-nuke's not worth having.
[09:32] <lamont> or whatever svn wants
[09:32] <Mithrandir> s/everythin/anything/
[09:32] <lamont> heh
[09:33] <lamont> I will admit that it's not uncommon for people to scratch their heads when they have occasion to watch me type in a "one-liner" shell command that's a few hundred characters long, including some semi-complex regexps in sed or so...
[09:34] <StevenK> lamont: Hey, that happens to me too!
[09:34] <slangasek> lamont: sadly
[09:35] <lamont> slangasek: since Mithrandir admitted to being awake, I figured I'd abuse him for the sync. :-)
[09:35] <slangasek> ok then
[09:35] <Mithrandir> sync, schmynk?
[09:36] <lamont> Mithrandir: I have to actually upload it to debian first...
[09:36] <slangasek> calc: how's OOo doing?
[09:36] <Mithrandir> lamont: ahkay
[09:36] <lamont> they're all either trivial, or at least interesting in LP
[09:38] <mdke> lamont: I've tried http://paste.ubuntu-nl.org/39431/ (I've just put in one filename, "about-ubuntu" to test). Can you see where it's wrong?
[09:38] <lamont> I knew it was dangerous to answer that question... :-)
[09:38] <mdke> perhaps I haven't got the paths right
[09:39] <mdke> ok, if you're too busy, please don't worry
[09:39] <mdke> i'll try and play with it
[09:40] <mdke> lamont: yeah, sorted, sorry
[09:41] <slangasek> lamont: wrt the "BIOS clock" question - surely if there isn't such a question today, there's an assumed answer to this question?
[09:41] <lamont> for i in about-ubuntu ; do for x in $(cd $i/po && echo $i-*.po); do echo $x ; echo svn mv $i/po/$x $i/po/${x#$i-}; done ; done
[09:41] <lamont> slangasek: "utc"
[09:42] <slangasek> lamont: so what's the problem with going with that answer?
[09:42] <lamont> which, if you're dual-booting, tends to be wrong
[09:42] <lamont> since windoze insists that the BIOS clock == localtime
[09:42] <lamont> it's not like windoze gives you the option
[09:42] <slangasek> ok, so this is the "system assumes UTC, Windows resets to local time, fsck gets the time wrong on reboot" case
[09:43] <lamont> so the solution is to set BIOS==localtime, and always make sure that windoze is running when daylight-savigs time changes happen
[09:44] <lamont> this is the "kernel assumes UTC, we don't fix it, then we do (ntpdate), and now the timestamp on the about-to-be-checked FS is in the future, because you have the misfortune of living east of Greenwich" thing
[09:44] <slangasek> I have to say I'm a bit worried about changes in this area so close to release, because I'd believed this whole thing was sorted twice before now
[09:45] <lamont> slangasek: where as I knew it wasn't sorted... the last time I came close to it, there was no answer that worked... and then they made /etc/localtime not a symlink to /usr/ (which is frequently not on the root partition - major mess)
[09:45] <slangasek> hrm, "kernel assumes UTC" - at what point are you saying that's a problem, does the system even know the timezone at that point? .... or does it know the timezone because of the last fix?
[09:45] <lamont> and then Ted was kind enough to file a very detailed explanation
[09:46] <lamont> at the kernel boot time, it doesn't know the TZ, assumes UTC
[09:46] <lamont> as long as we get the time corrected before we mount /, then we haven't screwed over e2fsck
[09:46] <slangasek> ok, so... isn't that the same bug as always?
[09:46] <lamont> so we need to fix the clock before we mount -oremount,rw /
[09:46] <lamont> yep
[09:46] <slangasek> so is it *really* fixed this time? :)
[09:47] <lamont> picky picky.
[09:47] <lamont> for non-ubiquity installs, yes
[09:47] <slangasek> ok.
[09:47] <lamont> "we deeply regret any inconvenience this may cause ubiquity users in the eastern hemisphere who use BIOS=local"
[09:48] <lamont> we regret it so much that we might change ubiquity to let them fix it before hardy ships
[09:48] <slangasek> s/BIOS=local/Windows/
[09:48] <slangasek> ;)
[09:48] <lamont> nah - I use windoze with localtime==UTC
[09:48] <lamont> because, dammit.  BIOS==utc
[09:48] <slangasek> heh
[09:48] <lamont> so windoze gets to think we live in the UTC TZ
[09:49] <realist> That's how I would resolve it, if I used Windows, that is.
[09:49] <lamont> many users get very confused if they see UTC times
[09:49] <sladen_> so storing the timezone offset in the filesystem (with one of the offsets being "unknown"
[09:49] <sladen_> then anything within 24hours of unknonwn can be discounted
[09:50] <sladen_> and then in that case, the generic case could be to discount a timeout +/-12hours of the considered time
[09:51] <lamont> ew
[09:51] <lamont> hrm.. when did debootstrap become arch:any?
[09:51] <sladen> well that's actually the fix isn't it.  to turn a timeout of 180days into  179days +/- 1 day
[09:52] <lamont> no.  the hack solution for gutsy was to have e2fsprogs pick up a config option that says to ignore the fact that the filesystem time is in the future
[09:53] <slangasek> lamont: it... didn't?
[09:53] <lamont> distinguish between a system whose clock is off by two hours, and one that is in +0200
[09:53] <sladen> (...in the future /by less than 24hours/)
[09:53] <lamont> slangasek: ah... it's been arch:any for _quite_ sometime... my bad.
[09:54] <lamont> anyway, mind if I do 1.0.3build1
[09:54] <slangasek> lamont: er, what?
[09:54] <lamont> https://edge.launchpad.net/ubuntu/+source/debootstrap/1.0.3
[09:54] <slangasek> $ apt-cache show debootstrap|grep Arch
[09:54] <slangasek> Architecture: all
[09:54] <fabbione> slangasek: just to trigger a no-change rebuild
[09:54] <lamont> you'll note build records for far more than the i386 one would expect for arch:all
[09:54] <slangasek> yes, a no-change rebuild of /what/?
[09:55] <slangasek> ah, the udeb is arch: any
[09:55] <slangasek> wtf?
[09:55] <lamont> ah. of debootstrap-udeb
[09:55] <lamont> --> debootstrap source
[09:56] <lamont> once I get bind9 in, ubuntu-standard is installable from ports.u.c
[09:56] <lamont> OTOH, installing from ports.u.c is b0rked because of (so far) debootstrap
[09:57] <slangasek> lamont: ok, go for it (mutter binary udeb for arch: all deb grumble)
[09:57] <lamont> it appears to have been that way since antiquity, if that makes you feel any less sick
[09:58] <slytherin> seb128: ping
[09:59] <mdke> Mithrandir: lamont: all working fine, thanks a lot for the help
[10:00] <lamont> Hobbsee: what TZ you in?
[10:01] <seb128> slytherin: if you let some context with the ping you have a higher chance to get a reply ;)
[10:01] <slytherin> seb128: Ok. Waiting for your take on bug 145334
[10:01] <ubotu> Launchpad bug 145334 in libtheora "[Freeze Exception]  Please sync libtheora 1.0 beta 1 from Debian" [Undecided,New]  https://launchpad.net/bugs/145334
[10:02] <Hobbsee> lamont: sydney
[10:02] <lamont> ah.  makes sense then
[10:02] <seb128> slytherin: why my take? I don't know anything about libtheora
[10:02] <lamont> Mithrandir: you should have had me hold Hobbsee down before you tickled.
[10:02] <lamont> then your feet would hurt less
[10:02] <Hobbsee> hm
[10:03] <slytherin> seb128: You are the uploader, right? That is what Riddell said
[10:03] <Mithrandir> lamont: I run faster than her, so she's just _claiming_ to have stomped my feet.
[10:03] <Hobbsee> lamont: i fight fairly hard when held - so, you may be putting yourself up for a lot of pain with that.
[10:03] <Mithrandir> lamont: also, have you ever tried stomping the feet of somebody who's running?
[10:03] <lamont> Mithrandir: I find that tripping them first helps
[10:03] <StevenK> Usually, you end up either tripping, or tripping them
[10:03] <slytherin> seb128: That bug has some test packages I have created. Riddell has commented, but I am waiting for your comments too.
[10:03] <Hobbsee> hehe
[10:03] <seb128> slytherin: I did the sync with Debian for whatever reason but I'm not maintaining the package
[10:03] <lamont> Hobbsee: we call it ground-work at my dojo. :-)
[10:04] <Hobbsee> lamont: dojo?
[10:04] <StevenK> Place one goes to do karate
[10:04] <StevenK> Well, martial arts
[10:04] <slytherin> seb128: That complicates the matter. :-(
[10:04] <Hobbsee> oh right, yes
[10:05] <seb128> slytherin: BTW you can't sync this one Debian, there is Ubuntu changes required
[10:07] <slytherin> seb128: I will be very happy if you can find some time stating what changes. I will recreate the package accordingly. I am new to the packaging thing. :-D
[10:10] <seb128> slytherin: I'll have a look today don't bother
[10:10] <seb128> slytherin: better to start on some universe packages for you ;)
[10:10] <slytherin> seb128: Ok. Thanks a ton.
[10:10] <seb128> you're welcome
[10:10] <slytherin> seb128: will do when hardy repos open up.
[10:11] <seb128> cool
[10:11] <slytherin> seb128: I wanted to test theora beta, that is why I created the package. There seems to be no breakage and performance is good. :-)
[10:12] <seb128> do you notice any difference with the alpha version we have?
[10:14] <slytherin> performance improvement (less CPU usage), encoding as well as decoding.
[10:20] <lamont> Mithrandir: feel like reviewing 82178
[10:20] <lamont> and oops.  my bad on 131415
[10:20] <lamont> both are closed,  but the changelog is only in 82178
[10:21] <lamont> (I waited for the 'accepted' mail from debian.. see, I can be good... :-)
[10:22] <Mithrandir> lamont: did you time it for the 13-14-15 bug? :-P
[10:22] <lamont> no
[10:22] <Mithrandir> lamont: looks fine to me.
[10:22] <lamont> pure serendipity
[10:22] <lamont> syncage, por favor
[10:22] <Mithrandir> file sync bug, then. :-)
[10:22] <slytherin> Mithrandir: Are you currently maintaining bluez-utils package?
[10:23] <Mithrandir> slytherin: yes
[10:23] <lamont> I was told that we should just use existing bugs for the sync requests
[10:23] <lamont> if you want a separate one, I'll file it
[10:23] <Mithrandir> lamont: just make sure the existing one says "plz sync" and sub ubuntu-archive then
[10:24] <lamont> 82178 has that/.
[10:24] <Mithrandir> indeed.
[10:24] <lamont> OTOH, I simply subscribed ubuntu-archive to 131415, because I suck
[10:25] <slytherin> Mithrandir: I believe there is a problem with XSBC-Original-Maintainer field, currently it is specified as XSBC-Maintainer.
[10:25] <lamont> two bugs.  I had a 50-50 chance of hitting the right one when I subscribed u-a the first time...
[10:25] <Mithrandir> lamont: meh, syncing from incoming sucks, it'll be done friday.
[10:26] <lamont> Mithrandir: but... my patience.....
[10:27] <lamont> OTOH, I'll be good and wait
[10:27] <Mithrandir> slytherin: thanks; fixed.
[10:27] <lamont> actually, it'll hit sid in about 10.5 hours-ish... it could be done Wed. :-)
[10:28] <lamont> filing sync requests for things in incoming sucks, too, btw.
[10:28] <StevenK> Filing sync requests for things when packages.debian.org hasn't updated to have the new changelog sucks too.
[10:29] <slytherin> Mithrandir: Also, the homepage url should be changed to http://www.bluez.org because the old sf.net url doesn't work anymore. :-D
[10:29] <lamont> StevenK: I think that's the more general case of the pain I was referring to
[10:29] <StevenK> lamont: Yeah, but Incoming will sort itself out - in my experience packages.d.o sorts itself out much much slower
[10:30] <lamont> StevenK: but the reason filing the sync req for incoming-stuff is painful is because p.d.o isn't curent
[10:30] <lamont> current, even
[10:31] <stgraber> Has anyone be able to make crypted LVM to work on USB HDD with today Ubuntu alternate ? (even without splash, I see the kernel detecting the HDD, then nothing)
[10:32] <stgraber> hmm, after a while I have the initramfs prompt and "/dev/mapper/ubuntu-root does not exist" message :(
[10:32] <Fujitsu_> stgraber: A fix was uploaded about 11 hours ago.
[10:32] <Fujitsu_> It works, too.
[10:33] <stgraber> weird that it isn't in today daily then
[10:34] <Fujitsu_> stgraber: To boot it manually, just run `cryptsetup luksOpen /dev/sdaX something', and hit Ctrl+D.
[10:34] <stgraber> ok
[10:34] <Fujitsu_> Erm, hit Ctrl+D after entering the password and hitting enter, that is.
[10:58] <slytherin> Does nautilus really require libbeagle for compilation? Or does it work with libtracker?
[10:59] <seb128> slytherin: it requires libbeagle to work with beagle for users who decide to use this indexer
[11:01] <slytherin> seb128: Thanks for info.
[11:01] <seb128> slytherin: you're welcome
[11:02] <seb128> slytherin: I think I'll not do the libtheora update, I'm not comfortable enough with the SVN changes to apply them and I don't want to upload a version that crashes on powerpc
[11:03] <slytherin> seb128: Will do it then if they release beta 2? I had a conversation on #theora yesterday and they said they will release beta 2 if that is important for Ubuntu.
[11:03] <slytherin> seb128: So ball is in our court. :-)
[11:04] <seb128> slytherin: that will need another approval from slangasek or pitti but would make things easier
[11:05] <StevenK> elky!
[11:05] <slytherin> seb128: I am not a developer. All I can do is help (read as 'push'). :-)
[11:08] <Mithrandir> lifeless: are you still seeing bug 79666?
[11:08] <ubotu> Launchpad bug 79666 in bluez-utils "hcid crashdump" [High,Confirmed]  https://launchpad.net/bugs/79666
[11:19] <Hobbsee> morning Keybuk
[11:22] <Keybuk> morning
[11:22] <Keybuk> eurgh, that coffee was nasssty
[11:24] <Hobbsee> Keybuk: drink coke.  fixes everything.
[11:24] <Keybuk> except one's teeth
[11:24] <Hobbsee> not *that* much coke.  sheesh!
[11:42] <iwj> mdke: How can I help ?
[12:06] <elkbuntu> StevenK, hi :)
[12:22] <Riddell> seb128: how come trackerd autostart is OnlyShowIn=GNOME;KDE;XFCE; ?
[12:22] <Riddell> and if I remove KDE from there, will it still start when someone runs whatever the tracker application is?
[12:23] <seb128> Riddell: it should start, yes, the autostart is only to automatically start it
[12:23] <seb128> I mean when starting your session
[12:23] <seb128> the issue is that people will not open the preference dialog to run it at every session
[12:36] <Riddell> seb128: so ok for me to remove KDE from that list?  seems daft to have two disk indexers running
[12:36] <seb128> yes
[12:40] <Riddell> seb128: done
[12:40] <Riddell> seb128: New queue is almost empty but for packages I've touched, if you could look at those today it would be good
[12:41] <seb128> Riddell: ok, will do
[12:56] <seb128> StevenK: hi, could you have a look to bug #148380?
[12:56] <ubotu> Launchpad bug 148380 in gimp "Zooming to 150% makes image transparent.  New package please" [Undecided,Confirmed]  https://launchpad.net/bugs/148380
[01:12] <seb128> mdke: around?
[01:12] <mdke> seb128: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[01:13] <seb128> mdke: nice autoreply ;) Should the "manpages" item be in the "advanced topics" with the info pages?
[01:13] <Whoopie> hi asac, could you have a look at bug 96260 (https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/96260/comments/5)? this fixes one of my openvpn issues.
[01:13] <ubotu> Launchpad bug 96260 in network-manager-openvpn "n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers" [Low,Triaged] 
[01:13] <ubotu> Launchpad bug 96260 in network-manager-openvpn "n-m-openvpn: resolv.conf is erased if endpoint does not push DNS servers" [Low,Triaged]  https://launchpad.net/bugs/96260
[01:15] <seb128> mdke: oh, they are ;)
[01:29] <ScottK> lamont: I'd love to see a patch for Bug 42463 too, but it's beyond me to produce it (you asked me about it ~ 5 hours ago)
[01:29] <ubotu> Launchpad bug 42463 in bind9 "rndc hangs if lo iface is down, affects other packages" [Medium,Confirmed]  https://launchpad.net/bugs/42463
[01:32] <ogra> ScottK, i always wondererd if it wouldnt make sense to hardcode lo anyway
[01:33] <ogra> and to not tear it down at all (wrt to your bug)
[01:34] <StevenK> seb128: Right, the patch looks a little big.
[01:34] <StevenK> seb128: I shall sort out a patch and a test build, and come up with a large image to test.
[02:03] <seb128> carlos: could you look at bug #148509 opened by TomaszD?
[02:03] <ubotu> Launchpad bug 148509 in language-pack-gnome-pl "The "Extra effects" string is not translated [gutsy] " [Low,New]  https://launchpad.net/bugs/148509
[02:03] <carlos> sure
[02:04] <TomaszD> that's a weird one, yes
[02:04] <carlos> seb128: I guess that's gnome-control-center, right?
[02:05] <seb128> carlos: yes
[02:05] <TomaszD> I was under the impression that a conflicting accelerator key might be the culprit, so I changed the string today
[02:05] <seb128> TomaszD: nothing check conflicts for you
[02:05] <seb128> TomaszD: if you have one you will just a bug when using the accelerator in the dialog
[02:05] <TomaszD> uhuh, so that couldn't be a problem then
[02:05] <carlos> TomaszD: please, send me the file /usr/share/locale-langpack/pl/LC_MESSAGES/gnome-control-center-2.0.mo (carlos.perello@canonical.com)
[02:06] <seb128> carlos: the french one doesn't have the strings so I think they have not been exported (yet)
[02:06] <carlos> seb128: as far as I know, gtk+ handles well duplicated accelerator keys
[02:07] <carlos> seb128: hmm, latest export was on Saturday night
[02:07] <carlos> around UTC midnight
[02:07] <seb128> carlos: when has the current template being imported?
[02:07] <carlos> I'm checking it
[02:08] <TomaszD> carlos, sent
[02:09] <carlos> seb128: 28-09-2007
[02:09] <carlos> before latest update
[02:09] <seb128> carlos: looks like the export is buggy then
[02:09] <carlos> anyway, yesterday night we exported an update language pack so I guess today it should end in the archive (if pitti's scripts work well)
[02:10] <carlos> seb128: aren't those strings Ubuntu specific?
[02:10] <seb128> carlos: they are, why?
[02:11] <carlos> seb128: well, I guess there is a delay between the .pot file being imported and people translating it
[02:11] <seb128> carlos: TomaszD said he translated those
[02:11] <TomaszD> yes, all in one go
[02:12] <carlos> TomaszD: when ?
[02:12] <TomaszD> umm, let me check
[02:12] <carlos> in fact...
[02:13] <carlos> update to latest language packs
[02:13] <carlos> the ones exported yesterday are already in the archive
[02:13] <carlos> unless you translated it today or late yesterday this update must include your translations
[02:13] <TomaszD> checking now
[02:14] <carlos> hmm, there is a .pot file pending of being imported into gnome-control-center
[02:15] <TomaszD> hmm update doesn't show language-pack-pl
[02:15] <carlos> so another possible problem is that the string was updated with that other upload to the archive and thus, Launchpad is still missing it
[02:15] <TomaszD> last time I've updated was a few hours ago, there was a language-pack-pl and I've reloaded the session and then noticed that bug
[02:16] <carlos> TomaszD: I think is last thing I told you. I have the same problem in Spanish
[02:17] <carlos> so Launchpad is missing that concrete string
[02:17] <carlos> and thus, is not able to export it
[02:17] <carlos> or offer it for translation
[02:17] <TomaszD> but it does offer it for translation
[02:17] <carlos> once the import queue handles that pending .pot file the problem will be fixed
[02:17] <TomaszD> I've changed the string today to fix the accelerator key
[02:17] <carlos> TomaszD: are you 100% sure is that exact string?
[02:18] <TomaszD> 100% sure
[02:18] <TomaszD> E_xtra effects: blah blah blah
[02:18] <carlos> any comma, dots or accelerator changes will make it different
[02:18] <seb128> TomaszD: the string changed
[02:18] <seb128> it used to use computer
[02:18] <seb128> and not graphic-card
[02:18] <carlos> so that's it
[02:18] <TomaszD> ah! so the template is out of date
[02:18] <seb128> "Requires faster computer."
[02:18] <seb128> "Requires faster graphics-card."
[02:19] <seb128> yes
 hmm, there is a .pot file pending of being imported into gnome-control-center
[02:19] <TomaszD> the changelog didn't mention any string changes, it's already late into the game
[02:19] <carlos> seb128: that's what I just said
[02:19] <seb128> I didn't know about it
[02:19] <seb128> MacSlow did the change while cleaning the glade changes
[02:19] <seb128> that was not documented in the changelog
[02:20] <TomaszD> oh well, will have to wait for the new template and then translate it, dang keeping up with all the changes is hard
[02:20] <carlos> aren't we in string freeze?
[02:21] <MacSlow> seb128, ups... sorry :/
[02:22] <seb128> carlos: dunno, freezes are not announced and I didn't look at the schedule recently
[02:22] <seb128> carlos: let me look
[02:22] <TomaszD> that's what I wanted to say. :]  no problem though, as long as I know these things...
[02:22] <MacSlow> seb128, ehm... wait... that is documented in the changelog
[02:23] <carlos> seb128: seems like we don't have a string freeze
[02:23] <carlos> we used to have one, though
[02:23] <seb128> MacSlow: ""trimmed down diff against capplets/appearance/data/appearance.glade
[02:23] <seb128>       (restricting it to just the "Visual Effects"-tab) in order to fix
[02:23] <seb128>       http://bugzilla.gnome.org/show_bug.cgi?id=480667""
[02:23] <ubotu> Gnome bug 480667 in Appearance "gnome-appearance-properties doesn't resize the notebook widget" [Normal,Resolved: notgnome] 
[02:24] <seb128> MacSlow: that's the description you gave me
[02:24] <MacSlow> seb128, wasn't that enough or not verbose enough?
[02:24] <seb128> MacSlow: I though that you dropped the extra glade-3 changes to fix the resizing issue
[02:24] <seb128> MacSlow: not that you changed the wording of the options, which breaks translations
[02:25] <seb128> MacSlow: that's ok but we should really stop changing strings now or those items will not be translated for gutsy, it's already late for translators
[02:25] <MacSlow> seb128, ok
[02:27] <jdstrand> pedro_: are the backtraces for bug #146330 helpful?
[02:27] <ubotu> Launchpad bug 146330 in evolution "evolution addressbook crashes when selecting a 'Show' category" [Medium,Incomplete]  https://launchpad.net/bugs/146330
[02:28] <Keybuk> jamiemcc: ah, just the man I was looking for :-)
[02:28] <jamiemcc> hi Keybuk whats up?
[02:28] <Keybuk> jamiemcc: trackerd is hammering my disk sufficiently hard that things like evolution are almost unresponsive
[02:28] <Keybuk> tracker-status says it's Indexing
[02:28] <Keybuk> but none of the numbers in tracker-stats are increasing
[02:29] <jamiemcc> with latest version 0.6.3?
[02:29] <Keybuk> and, most strangely, EvolutionEmails remainds at 0
[02:29] <Keybuk> yes
[02:29] <Keybuk> (and rebooted after install)
[02:30] <jamiemcc> Keybuk: do you use imap with evo?
[02:30] <Keybuk> yes
[02:30] <jamiemcc> or is t pop
[02:30] <Keybuk> imap with local folder caching
[02:31] <jamiemcc> Keybuk: is it wqriting to disk or constantly reading?
[02:31] <Keybuk> how would I tell that?
[02:31] <jamiemcc> strace
[02:32] <Keybuk> strace on the second thread is all lseek() and read()
[02:32] <Keybuk> first thread is in futex(
[02:32] <jamiemcc> or check diskstats in proc
[02:32] <Keybuk> master is in poll(
[02:33] <pedro_> jdstrand, looking at it now
[02:33] <jdstrand> pedro_: I believe the first is not useful
[02:33] <jamiemcc> Keybuk: other thread? (there are 3)
[02:34] <Keybuk> there are two
[02:34] <Keybuk> wing-commander scott% ps Hax -L | grep track
[02:34] <Keybuk>  5770  5770 ?        SNl    0:02 trackerd
[02:34] <Keybuk>  5770  5912 ?        SNl    0:00 trackerd
[02:34] <Keybuk>  5770  5913 ?        DNl   16:23 trackerd
[02:34] <Keybuk> well, two threads and what I called the master :p
[02:34] <jamiemcc> yeah
[02:35] <pedro_> jdstrand, not at all, the second one is useful, thanks
[02:35] <jdstrand> pedro_: ok great :)
[02:35] <jamiemcc> Keybuk: second thread is constantly reading?
[02:35] <Keybuk> the reason I say it's weird that it's not counting evolution mails is that through strace, I've seen it looking at them
[02:35] <Keybuk> lstat64("/home/scott/.evolution/mail/imap/scott@imap.netsplit.com/folders/Sent/779.", {st_mode=S_IFREG|0600, st_size=222301, ...}) = 0
[02:35] <Keybuk> access("/home/scott/.evolution/mail/imap/scott@imap.netsplit.com/folders/Sent/3586.", F_OK) = 0
[02:35] <Keybuk> etc.
[02:36] <StevenK> seb128: Gimp built, just about to test.
[02:38] <Keybuk> (I have just upgraded to 0.6.3, so I'm willing to believe it's just catching up with things)
[02:38] <jamiemcc> Keybuk: it should write out every 200 emails indexed for imap
[02:39] <Keybuk> the numbers are going up now
[02:39] <Keybuk> could it have been rewriting its index or something?
[02:39] <jamiemcc> Keybuk: 0.6.3 reindexes automatically
[02:40] <Keybuk> every time I login, or just once?
[02:41] <jamiemcc> keybuk: just once when upgrading from prior versions
[02:41] <jamiemcc> Keybuk: new/deleted mail will be indexed at startup of course
[02:41] <Keybuk> EvolutionEmails : 19099
[02:41] <Keybuk> and climbing now
[02:41] <Keybuk> so maybe it was just upgrade blues
[02:41] <Keybuk> it's certainly noticing the mails now :)
[02:41] <Keybuk> and the disk is less hammering
[02:41] <jamiemcc> Keybuk: yeah or you had some bug file attachments
[02:41] <jamiemcc> big
[02:47] <StevenK> seb128: gimp patched, and built, and tested sucessfully. I'm uploading it now
[02:47] <seb128> StevenK: cool, thanks
[02:47] <StevenK> To be honest, the image being transparent was very cool.
[02:49] <seb128> StevenK: ;)
[02:54] <soren> mjg59: I see you disabled the reference to the pm-utils website in gnome-power-manager.. Would it perhaps make sense to collect the information from the gutsy users so we have everything ready and shiny for hardy?
[02:56] <mjg59> soren: Which information?
[02:57] <soren> mjg59: AFAIR they're redirected to that page in order to get them to gather information about what it would take to make their system suspend/resume properly?
[02:57] <soren> Is this where you're going to point out that those instructions of course rely on the presence of pm-utils?
[02:57] <mjg59> Yup
[02:57] <soren> THought so.
[02:57] <soren> Never mind, then. :)
[02:58] <mjg59> I'm really hoping that we can migrate over to pm-utils by hardy
[02:58] <soren> Me too.
[02:58] <soren> Especially due to how easy it makes it for users to help discover all the quirks needed for their specific system.
[03:28] <Ng> am I right in thinking that the difference between booting the livecd and booting it with safe graphics is that the latter uses vesa?
[03:39] <cjwatson_> Ng: yes
[03:39] <cjwatson> Ng: "safe graphics mode" translates to the xforcevesa command-line option
[03:39] <Ng> ok
[03:52] <\sh> moins
[04:17] <Hobbsee> dear thunderbird, you are on crack!  please get *off* it.  kthxbye.
[04:21] <lamont> Hobbsee: what's thunderbird? :-)
[04:24] <Hobbsee> lamont: :)(
[04:25] <lamont> I _thought_ it claimed to be a mail reader
[04:25] <lamont> MUA, rather
[04:26] <lamont> based on the depends, it's GUI-based, though, so it can't possibly really be an MUA.
[04:26] <_MMA_> cjwatson: re: Germinate. Thanx. We'll get right on it.
[04:27] <bddebian> Heya
[04:54] <cjwatson> _MMA_: np
[04:54] <cjwatson> sorry it wasn't straightforward to do centrally
[04:55] <_MMA_> Yeah. Its ok. At least we have a solution.
[04:56] <_MMA_> We'll get the fix do today so it hopefully hits the next daily.
[04:56] <_MMA_> s/do/done
[04:58] <tkamppeter> doko, Riddell, ping
[05:00] <doko> tkamppeter: pong
[05:22] <Keybuk> ext3 so needs an "undo" feature
[05:22] <Spads> so that you can restore your nethack save files
[05:22] <Spads> ^-- Enterprise-level feature.
[05:23] <dobey> Keybuk: mc has undelete
[05:23] <dobey> mc the file manager that is
[05:23] <dobey> i think you need to know the inode info though
[05:24] <Keybuk> I was more thinking of "rm -rf /*" ... D'OH! UNDO! UNDO! UNDO!
[05:24] <Spads> that has some interesting security implications, of course
[05:25] <dobey> heh
[05:25] <StevenK> In terms of "Damn! So the Federal Police *can* see my kiddie porn!" ?
[05:25] <StevenK> ... Or something.
[05:25] <Keybuk> Spads: go I have a goatee?  am I wearing a Serenity t-shirt?
[05:25] <dobey> StevenK: well, even if you write all 0s to the disk 3 times, they can still find stuff.
[05:26] <jdong> nothing like a massive network of LVM snapshots for fun
[05:26] <Spads> Keybuk: You are zippy and I claim my non-sequitur.
[05:26] <Keybuk> security's all well and good, if you like that kind of thing
[05:26] <Keybuk> but I'd rather know what files I just accidentally deleted
[05:26] <Keybuk> so I can put them back
[05:26] <jdong> dobey: I've been told that you can never really wipe a magnetic medium to the point of impossible recovery... just make it increasingly difficult.
[05:26] <Keybuk> I'm kinda hoping it just got stuck in to evolution's cache before I hit ^C
[05:27] <StevenK> I think burning the disks platters would make it nigh on impossible.
[05:28] <jdong> dobey: and encryption/wiping is a complete nonissue when you've got criminal charges against you for something.... they'll jst slap on charges for failing to provide the secret key or destroying/concealing evidence anyway.... :)
[05:28] <dobey> jdong: well, there is certainly a point. however, the number of times you have to write 0s to the disk to actually make everything be 0 again, can be pretty high
[05:28] <dobey> jdong: there's a reason there are encryption export laws in the US
[05:29] <dobey> jdong: "if the NSA can't hack it, it can't be legal."
[05:29] <jdong> dobey: considering the urgency that they are switching to elliptic curve, I cannot help but suspect they've made significant headway on that.
[05:30] <dobey> jdong: and if you're on the defendent end of a case with the US vs. You, and the NSA is poking through your data, you're already screwed.
[05:30] <jdong> dobey: agreed :)
[05:37] <tkamppeter> doko, riddell, another try, my box crashed and afterwards it fsck for half an hour.
[05:37] <Riddell> ouch
[05:37] <Riddell> tkamppeter: doko ponged, or I'm here
 doko, Riddell, ping
[05:38] <doko> * RAOF_ (n=chris@123-243-65-41.tpgi.com.au) hat #ubuntu-devel betreten
 tkamppeter: pong
[05:38] <tkamppeter> Riddell, doko, can one of you upload my system-config-printer packages (see your mail), as pitti is celebrating the reunification of Germany
[05:41] <Riddell> doko: shall we fight for it?
[05:41] <doko> Riddell: you won ;p
[05:42] <jdstrand> pitti, keescook, soren, and anyone else who wants to weigh in: I am close to having a fix for bug #119075 for dapper -> feisty
[05:42] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[05:42] <Riddell> ok
[05:42] <jdstrand> pitti, keescook soren: but I am not sure how to let the user know that the change was made
[05:43] <jdstrand> wrt string changes
[05:44] <tkamppeter> Riddell, doko, can you also upload hplip which fixes bug 147369 (see mail)
[05:44] <ubotu> Launchpad bug 147369 in hplip "MASTER: Printing via HPLIP does not work any more" [High,Fix committed]  https://launchpad.net/bugs/147369
[05:44] <jdstrand> the fix is based on soren's work, and will just generate a random password if the mysql password is determined to be blank.  There is also a mechanism in the init script to reset the password.
[05:45] <jdstrand> I could just document it in the REAMDE as well as the changelog, but wanted some feedback
[05:46] <Riddell> tkamppeter: system-config-printer uploaded
[05:46] <soren> I'm really not all that keen on randomly setting passwords on people's existing installations.
[05:47] <soren> Hobbsee: Again?
[05:47] <Riddell> tkamppeter: where is hplip?
[05:47] <tkamppeter> Thanks, Riddell, this eliminates 9 bugs.
[05:47] <tkamppeter> Riddell, you should have gotten another e-mail. Otherwise at http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/hplip/  (the usual place)
[05:49] <jdstrand> soren: another option is to just detect the password is blank, and then alert the user whenever mysql is started until it is not blank
[05:49] <cjwatson> Spads: nethack save files> so are you an evil savescummer? :P
[05:49] <Spads> cjwatson: no, but I was when I ran DR-DOS
[05:50] <jdstrand> soren: but I don't think the intent was to ever have it be blank, so I think there is something to the argument that it should be changed.  It is a real vulnerability that just was never fixed
[05:50] <jdstrand> soren: though I understand what you are saying
[05:52] <soren> Hobbsee: /me cries
[05:53] <Hobbsee> soren: get to it :)
[05:53] <soren> jdstrand: I like that idea much better (telling the user he should be setting a password real soon)
[05:53] <Hobbsee> bwah?
[05:53] <Hobbsee> ookay?
[06:01] <slangasek> seb128, MacSlow: wrt string freeze, pitti reorganized things so that this is subsumed in the UserInterfaceFreeze -- so yes, /long/ since frozen
[06:01] <slangasek> (https://wiki.ubuntu.com/UserInterfaceFreeze, Sep 13)
[06:11] <tkamppeter> Riddell, also thanks for uploading hplip, eliminating a high-priority bug
[06:12] <Riddell> you're welcome
[06:36] <mathiaz> keescook: so for the apparmor parser revision number, what about creating just one package for the parser ?
[06:36] <keescook> that could work -- having a totally separate source package for the old parser?
[06:36] <mathiaz> keescook: that way we'll have apparmor-parser-2.0.1
[06:37] <mathiaz> keescook: yes. And then apparmor, apparmor-profiles with a revision number of 2.1+993
[06:37] <keescook> it might be more painful that just mod'ing the orig.tar.gz (since we'd need to put all the abstractions and man pages into the new one)
[06:37] <keescook> oh, you mean literally _just_ the parser.
[06:37] <mathiaz> keescook: yes.
[06:38] <keescook> looks like the man page is the same between 2.1 and 2.0.1
[06:39] <keescook> mathiaz: okay, yeah, I like this.  I think it's the cleanest solution.  We can add a Depends for it to the "apparmor" package.
[06:39] <keescook> and drop the parser from "apparmor".
[06:40] <mathiaz> keescook: yop. However, there is a correlation between the profiles and the parser.
[06:41] <mathiaz> keescook: the kernel provides a apparmor-modules-2.0
[06:41] <keescook> mathiaz: how about this, instead of a new source package, why not just make a new orig for the current apparmor, and add the old parser tree to the root directory?
[06:41] <keescook> then we can change the build to just build out of the old parser dir instead of the new one.
[06:41] <mathiaz> keescook: hum.. How about revision number then ?
[06:42] <mathiaz> keescook: the reason to create a separate source package for the parser is that we can have an appamor-parser-2.0.1
[06:43] <mathiaz> keescook: if we don't really care about revision number, I would just drop the old parser code in the bzr tree.
[06:43] <keescook> well, I was thinking about the profiles syntax version
[06:43] <keescook> true.
[06:43] <keescook> maybe that's the best way to deal with it.
[06:43] <mathiaz> keescook: OTOH the revision number would indicate that we have 2.1, but we really have 2.0.1
[06:43] <keescook> just drop the entire old parser in.
[06:44] <keescook> right, but the utils will still be 2.1
[06:44] <mathiaz> keescook: that may confuse users that try to add profile.
[06:44] <keescook> either way, we'll have confusion either the profiles won't be 2.1 style or the utils won't be the 2.0 versions.
[06:45] <keescook> I think the bulk of the interaction for people is with the utils, so we should try to keep those at 2.1.
[06:45] <mathiaz> keescook: yes. The later is less confusing.
[06:45] <mathiaz> keescook: hum... 2.1 has lots of new feature on the kernel side.
[06:46] <keescook> mathiaz: yeah.
[06:46] <Keybuk> why does pbuilder have to be run as root?
[06:46] <mathiaz> keescook: moreover I think that the 2.1 utils should work well with a 2.0 module.
[06:46] <mathiaz> keescook: the other way around doesn't work at all.
[06:47] <mathiaz> keescook: now I wonder if the utils would generate incompatible profiles.
[06:47] <keescook> mathiaz: oooh.  hmmm.  wait, no I think it builds them based off the hints from the kernel, which would do the right thing, right?
[06:48] <mathiaz> keescook: yes. I hope so.
[06:48] <mathiaz> keescook: but then there is the new file vs directory change.
[06:48] <keescook> mathiaz: hmm
[06:49] <mathiaz> keescook: I'll go through the changelogs to see if there is something related to it.
[06:50] <mathiaz> keescook: what would be needed to realease an updated version of apparmor with a revision number of 2.0.1 ?
[06:50] <cjwatson> mathiaz: either an epoch (but personally I'd be cautious about that), or else 2.1+993+really2.0.1-0ubuntu1 or similar
[06:51] <keescook> how about a new orig.tar.gz, where the version is 1:2.0.1+2.1utils-0ubuntu1 ?
[06:51] <keescook> cjwatson: why "really" vs epoch?
[06:52] <cjwatson> keescook: if there's anyone else providing the package, you have to go round and persuade them to bump the epoch too
[06:52] <cjwatson> but if that's not the case here I guess it's not a big deal
[06:52] <cjwatson> either way, be careful about shlibs on libapparmor
[06:53] <cjwatson> did libapparmor1 2.1 introduce any new symbols?
[06:53] <keescook> cjwatson: no, it's virtually a stub.  :)
[06:53] <cjwatson> I notice the shlibs seem to just say "libapparmor1"
[06:53] <cjwatson> ok, you dodge that bullet then ...
[06:54] <cjwatson> (versioned shlibdeps break if you want to wind versions backwards)
[06:57] <mathiaz> hum... So if we choose to use 2.0.1 where should we start the the revision number ? 0ubuntu26 ?
[06:58] <mathiaz> (0ubuntu25 was the last one used for 2.0.1 - and feisty has 0ubuntu4)
[06:59] <mathiaz> keescook: hum... we could actually use 2.0.1+993
[06:59] <cjwatson> you should definitely never reuse a previous version number
[07:00] <mathiaz> cjwatson: 2.0.1+993 has never been used.
[07:00] <mathiaz> cjwatson: feisty has 2.0.1+510.dfsg-0ubuntu4
[07:00] <mathiaz> cjwatson: and gutsy has 2.1+993-0ubuntu2:
[07:01] <mathiaz> cjwatson: 2.0.1+993 has never been used.
[07:01] <cjwatson> I wasn't saying it had been, it was just a general comment
[07:03] <MacSlow> re
[07:12] <Whoopie> cjwatson: Hi, re bug 36964, it's just a driver to support these Ricoh SD/MMC reader? it doesn't work perfectly, but better then nothing.
[07:12] <ubotu> Launchpad bug 36964 in linux-source-2.6.22 "[dapper]  Asus sd/mmc card reader not working" [Low,Confirmed]  https://launchpad.net/bugs/36964
[07:17] <cjwatson> Whoopie: I'm not a member of the kernel team
[07:18] <cjwatson> Whoopie: I'm just pointing out (as a member of the release team) that it's *two weeks* before release and thus not generally a good time to insert new untried code
[07:18] <cjwatson> that could e.g. crash systems that previously worked fine even though the reader wasn't supported
[07:18] <Whoopie> cjwatson: ok
[07:19] <jdong> cjwatson: how's the unionfs thing look nowadays? Is it still random or is it resolved?
[07:19] <slangasek> still random
[07:19] <jdong> yikes...
[07:19] <jdong> do we have any idea what might be causing it?
[07:20] <slangasek> idea perhaps, but no patches; kernel team is talking about rolling back to a previous version of unionfs
[07:20] <cjwatson> (which also involves rolling back apparmor)
[07:21] <cjwatson> unionfs upstream is also looking at it
[07:26] <keescook> mathiaz: I think we should call it 2.0.1+993-0ubuntu3 for now, and if we need to roll back everything, use the "really" version suffix.
[07:27] <mathiaz> keescook: hum... 0ubuntu3 or 0ubuntu1 ?
[07:27] <keescook> er, sorry, I totally mis-typed
[07:27] <keescook> 2.1+993-0ubuntu3
[07:28] <mathiaz> keescook: you'd really stick with 2.1 ?
[07:29] <mathiaz> keescook: I think it's misleading.
[07:29] <keescook> mathiaz: for now, yes.  once we figure out what combination of things will work, we can resolve the version number for real.
[07:29] <mathiaz> keescook: If you look at http://en.opensuse.org/AppArmor/Changes_AppArmor_2_1, half of what's written there is not supported.
[07:29] <mathiaz> keescook: ah ok. So just as a temporary solution, we use 2.1.
[07:30] <keescook> right
[07:30] <mathiaz> keescook: but for the final release we'll update the version to the correct number.
[07:32] <keescook> mathiaz: right.  I think we'll need to do a lot of testing first anyway.  version really is the least of our problems.  :)
[07:33] <mathiaz> keescook: ok. WFM.
[07:41] <alesan> does anybody have an idea if it is possible to ship a Ubuntu cd with a hardware product? do we need to ask canonical first?
[07:47] <cprov> seb128:  hi, who is driving apport atm ?
[07:48] <siretart> Keybuk: can you please comment on https://bugs.edge.launchpad.net/upstart/+bug/62751/comments/91?
[07:48] <ubotu> Launchpad bug 62751 in cryptsetup "Upstart doesn't activate luks volumes (also non luks) in cryptsetup" [High,Confirmed] 
[07:49] <Keybuk> siretart: what would you like the comment to say?
[07:50] <siretart> is env a built-in in busybox?
[07:50] <Keybuk> which busybox?
[07:51] <seb128> cprov: "driving"?
[07:51] <siretart> err, that one in initramfs
[07:51] <cjwatson> siretart: no
[07:51] <Keybuk> siretart: yes
[07:51] <seb128> cprov: you mean hacking on it?
[07:51] <siretart> lol
[07:51] <Keybuk> CONFIG_ENV=y
[07:51] <cjwatson> siretart: it's provided as a command. it's not a built-in
[07:51] <Keybuk> yeah, what cjwatson said :)
[07:52] <siretart> ok
[07:52] <cjwatson> though, actually, it makes little difference, because the initramfs uses CONFIG_FEATURE_SH_STANDALONE_SHELL=y
[07:52] <cprov> seb128: not exactly ;) but I've received reports that apport crashes when it tries to report a bug in a PPA package.
[07:53] <cjwatson> so in the initramfs Keybuk is right and it is effectively a builtin
[07:53] <cjwatson> in busybox-udeb it's an external command
[07:53] <Keybuk> yes
[07:53] <Keybuk> it's a not-builtin builtin thingy
[07:53] <seb128> cprov: the program crash, the kernel intercept it and call apport
[07:53] <Keybuk> maaaagic
[07:54] <cprov> seb128: yes, I know, the problem is that apport reports the bug as if the PPA package was in ubuntu.
[07:55] <cprov> seb128: uhm, doesn't it already happens for packages installed from other repositories ?
[07:55] <seb128> cprov: it should not report bugs for non official packages, I'm not sure of what the logic to detect that is though, you want to speak to pitti he's the one writing apport ;)
[07:56] <cprov> seb128: yup, he's out, I will file a bug for now, thanks
[07:57] <seb128> cprov: alright, you're welcome, sorry for not being really useful there ;)
[07:57] <seb128> time for diner now, bbl
[07:57] <cprov> seb128: no worries, you did great ;)
[08:03] <slangasek> iwj: bug #145231 seems to be waiting for info from you?
[08:03] <ubotu> Launchpad bug 145231 in pidgin "cannot restart pidgin" [High,New]  https://launchpad.net/bugs/145231
[08:11] <mdke> iwj: still around?
[08:16] <slangasek> seb128: can I assign #145231 to you, so you can press iwj for details when you're both awake? :)
[08:18] <bdmurray> tkamppeter: my printer prints blank test pages until I change the printout mode
[08:33] <tkamppeter_> bdmurray, which model, which PrintoutMode gives blank pages, which one works? Please file a Launchpad bug.
[08:33] <tkamppeter_> Riddell, doko, can you also upload cups-pdf and cupsys for me (see mail). Note that cups-pdf needs the new cupsys (AppArmor fix).
[08:33] <seb128> slangasek: I'm assigned it to me, thanks for pointing it
[08:34] <bdmurray> tkamppeter_: Should the bug be filed about cupsys?
[08:34] <bdmurray> Or some other package?
[08:38] <jdong> is it safe in Ubuntu to isntall syslog-ng? (I see that it kicks off ubuntu-minimal)
[08:38] <carlos> nixternal: ping
[08:39] <mdke> iwj: ok, I'll leave a message. I wanted to check something re: https://wiki.ubuntu.com/DapperFirefoxStartPageTranslation. In the last section, is it correct that where a language is already in the list of translatable locales, but a translation isn't yet shipped in (e.g.) ubuntu-docs, the translation can simply be added without applying the procedure there? (example, en_GB)
[08:41] <tkamppeter_> bdmurray, it should be filed against the driver you are using, usually HPLIP for HPs, Gutenprint for most Epsons, ... See in system-config-printer which driver is used for your printer.
[08:42] <Keybuk> oh, that's right, before I got distracted by starting another round of daily tests, I was replying to an e-mail
[08:57] <slangasek> bug #125220 calls for adding default iocharset options to cdrom mounting; does it make sense for this to be a kernel default instead?
[08:57] <ubotu> Launchpad bug 125220 in hal "Question symbols (????) in filenames on CD" [Medium,New]  https://launchpad.net/bugs/125220
[09:07] <slangasek> Amaranth: is there still more info you're waiting for on bug #133609?
[09:07] <ubotu> Launchpad bug 133609 in compiz "No window decorations on compiz session statup" [Undecided,Incomplete]  https://launchpad.net/bugs/133609
[09:13] <minghua> slangasek: Does the kernel iocharset setting differentiate different filesystems?
[09:13] <Amaranth> slangasek: that bug should be closed, i guess
[09:14] <minghua> Actually, I'm pretty sure some of them don't, NTFS for example.
[09:35] <slangasek> I'm pretty sure ntfs supports iocharset=utf8, you just don't want to use it because it interferes with case-insensitivity
[09:36] <slangasek> at least that's the case for vfat
[09:36] <slangasek> though hmm, I guess I don't know if ntfs-3g supports it
[09:36] <jdong> slangasek: apparently you can do it but windows will hate your guts....
[09:36] <jdong> at least that's the gist I've heard
[09:36] <slangasek> er, why would that be? iocharset only controls how the filenames are exposed upwards, not how they're represented on disk
[09:39] <ion_> If an NTFS partition is mounted with a non-unicode charset and there are filenames in another encoding than the iocharset, they are hidden entirely.
[09:42] <slangasek> well, that's one instance of the same general problem of 125220
[09:43] <slangasek> i.e., a problem when iocharset != utf8
[10:02] <nixternal> carlos: pong?
[10:03] <minghua> slangasek: Last time I checked, the option for NTFS is "utf8", not "iocharset=utf8".
[10:04] <minghua> vfat, on the other hand, uses "iocharset=utf8"
[10:04] <carlos> nixternal: hi
[10:04] <minghua> I also vaguely remember that there were some changes from kernel 2.4 to 2.6.
[10:05] <carlos> nixternal: I wonder whether I should approve/reject the kubuntu/khelpdesktop/kubuntu/po/systemdocs.pot  template for kubuntu-docs package in Launchpad
[10:05] <carlos> nixternal: mdke told me I should ask you
[10:07] <lamont> g-p-m isn't iit (unless it's ignoring gconf)
[10:07] <nixternal> it needs to be translated...should I just send the po file to the list maybe?
[10:07] <nixternal> carlos: ^^
[10:08] <carlos> nixternal: I was not sure whether it was a mistake or not so it was not yet approved
[10:08] <carlos> nixternal: it should be available in Launchpad in next minutes
[10:09] <cjwatson> slangasek: with ntfs-3g, it's supposed to use the locale instead
[10:09] <cjwatson> i.e. it does character set interpretation based on the locale of the ntfs-3g process, which is typically inherited from /etc/default/locale
[10:10] <nixternal> carlos: you rock! if we ever meet, remind me that I owe you a drink of your choice :)
[10:10] <cjwatson> the old utf8, iocharset=utf8, nls=utf8, etc. options are ignored
[10:10] <carlos> nixternal: no need for that, but thanks ;-)
[10:11] <jdstrand> slangasek: I am working on fixes for bug #119075 for dapper -> gutsy.  dapper -> feisty will be handled simply by informing the user that the root account does not have a password, and provide a means to set it.
[10:11] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[10:12] <jdstrand> slangasek: I noticed your last comment, and I can very easily set a random password for gutsy
[10:12] <jdstrand> slangasek: with the same mechanism for changing it that I used in dapper -> feisty
[10:12] <carlos> nixternal: https://translations.launchpad.net/ubuntu/gutsy/+source/kubuntu-docs/+pots/systemdocs
[10:12] <jdstrand> slangasek: what do you think?
[10:13] <carlos> nixternal: hmm, that's a .desktop file...
[10:13] <jdstrand> slangasek: I can also just as easily use the same 'fix' for gutsy as for the other releases
[10:13] <carlos> nixternal: did you add the needed tag to get updates from language packs?
[10:14] <nixternal> carlos: dunno if I did or not...I am not 100% familiar with getting those done...I followed a tutorial somewhere I think
[10:14] <nixternal> but, since it doesn't sound like something I did, then I would have to say no
[10:14] <carlos> All .desktop and .directory files should have an: X-Ubuntu-Gettext-Domain=systemdocs line (although this should be kdesytemdocs so it's not so generic, maybe kubuntusystemdocs...
[10:15] <nixternal> hrmm
[10:15] <carlos> nixternal: with that, you will get translation updates even after release time
[10:16] <nixternal> OK, don't know if it is to late to work that out now, if not I will fix it in trunk so that gets straightened out for hardy
[10:16] <carlos> well, not you, but Kubuntu users
[10:17] <carlos> nixternal: if you change the translationdomain (the filename for that template, tell me it, I must change it in Launchpad too)
[10:17] <nixternal> I could go ahead and fix that, in our repos and then reupload if that is cool?
[10:17] <Keybuk> cjwatson: I've tested every combination I can think of, and I cannot replicate #139230
[10:17] <carlos> nixternal: yeah, that's it
[10:17] <nixternal> carlos: I will take a look at it here in a bit..I am finishing up some stuff here before my lovely evening class on "how to make a myspace website" :) just kidding, but it is javascript, so that is close enough :)
[10:18] <carlos> :-P
[10:18] <carlos> ok
[10:19] <cjwatson> Keybuk: get back to the submitter for details?
[10:19] <Keybuk> cjwatson: yup, am doing so; am going to remove the milestone as well since it works out of the box
[10:22] <lamont> mdz: you around/
[10:22] <lamont> ?
[10:25] <Keybuk> cjwatson: the other person who reported it definitely has the "/var/run and /var/lock don't exist on the root filesystem" bug
[10:29] <Keybuk> (which we have a cunning hack for in gutsy)
[10:31] <Kopfgeldjaeger> i cant find the bug about encryption@install (alternate cd, gutsy).. can somebody give me the bug number (maybe bookmarked?)
[10:34] <Kopfgeldjaeger> found it, its #144390
[10:48] <Kopfgeldjaeger> good night
[10:58] <glatzor> pign bryce
[10:59] <bryce> heya glatzor
[10:59] <glatzor> bryce: hello, have you made a decision about the temporarily fail safe mode?
[11:00] <bryce> yeah, I've got a new xorg package that I'm testing now
[11:00] <bryce> I expect to have it uploaded today
[11:01] <mjg59> bryce: Any chance you can change dexconf a touch?
[11:02] <mjg59> bryce: Rather than generating  "HorizScrollDelta" "0" it ought to be "HorizEdgeScroll" "0"
[11:02] <mjg59> Otherwise there's no sane way to enable edge scrolling
[11:02] <glatzor> bryce: would you then also upload displayconfig-gtk?
[11:02] <glatzor> please
[11:03] <bryce> mjg59: sure I can put that change in
[11:03] <glatzor> bryce: should I apply the patch, that I sent you this morning?
[11:04] <mjg59> bryce: Sweet, thanks
[11:04] <slangasek> jdstrand: in discussion, the conclusion was that setting a random password is a bad idea because it's non-obvious to users how to recover access
[11:04] <bryce> glatzor: yes please do
[11:05] <bryce> glatzor: I've not had a chance to test that patch myself, but it looks good
[11:05] <lamont> slangasek: now that it's in sid... could you sync bind9 for bug 82178 and bug 131415?  kthxbye
[11:05] <ubotu> Launchpad bug 82178 in bind9 "idnconv manual page exists, but no binary" [Low,Fix committed]  https://launchpad.net/bugs/82178
[11:05] <ubotu> Launchpad bug 131415 in bind9 "part of nslookup manpage not visible" [Undecided,Fix committed]  https://launchpad.net/bugs/131415
[11:05] <lamont> :-)
[11:06] <jdstrand> slangasek: agreed, but I was thinking I'd let them know via debconf how to change it
[11:06] <slangasek> jdstrand: personally I don't think that's very user-friendly
[11:06] <jdstrand> slangasek: ala 'if you press Enter, a random password will be generated.  you can reset this by..."
[11:07] <jdstrand> slangasek: that's cool.  I'm fine with the high priority message.  pre-gutsy it was medium and hidden
[11:07] <lamont> slangasek: would you be annoyed if the ppc, amd64, and sparc buildds went manual mode for a little bit?
[11:07] <lamont> I'll assume that's a "YES"
[11:08] <jdstrand> slangasek: just thinking out-loud basically
[11:08] <glatzor> bryce: done. you can now upload it
[11:08] <lamont> slangasek: details for the bind9 sync are in 82178
[11:08] <bryce> glatzor: ok
[11:09] <slangasek> lamont: bind9: looking then
[11:09] <slangasek> lamont: on manual: is this the bootstrappery you were discussing with cjwatson earlier?
[11:09] <bryce> glatzor: actually I've not rolled a displayconfig-gtk package before - is there a make dist-like procedure, or do we just make a snapshot?
[11:10] <lamont> turns out that I have to add a key to the real root on the buildd for the bootstrappery to not kill all builds that happen with that chroot there...  so my choices are to manually make everything wait on starting the builds of mlton, or go add the &*(^ key on all of the affected architecture buildds
[11:10] <glatzor> bryce: Good question. I have never uploaded one :)
[11:10] <lamont> so, I'll go do the add-it-everywhere thing... I was just kicking a little on the way down
[11:11] <bryce> hmm; perhaps we should ask mvo to do it this time, and write down the process for us?  ;-)
[11:11] <glatzor> bryce: you could use bzr bd --source
[11:11] <slangasek> lamont: so the fix for 82178 is to drop the manpage?
[11:11] <lamont> yeah
[11:12] <lamont> or rather, to be specific about what man pages we deliver, instead of delivering all of man1
[11:12] <slangasek> good, I like it when packages get smaller
[11:13] <lamont> otherwise, it's typo fixes in manpages and that one fix at the very bottom, which is low-risk
[11:14] <lamont> (changes from call something that might assert to "if (this condition that's perfectly OK but will cause an assert does not exist) { call }
[11:14] <lamont> )
[11:18] <slangasek> lamont: the sync howto isn't working for me, and I'm not keen to poke things randomly to figure out why
[11:21] <lamont> slangasek: you are a wise man.
[11:22] <lamont> so... should I just upload -2build1 then?
[11:22] <slangasek> if you like
[11:26] <cjwatson> lamont: hang on
[11:26] <cjwatson> slangasek: what's going wrong?
[11:26] <lamont> cjwatson: it's about an hour from now before I get to that step
[11:27] <cjwatson> lamont: you don't need the chroots prodded?
[11:29] <lamont> cjwatson: I was gonna have cprov do that once he's back.  Unless you want to do it now
[11:30] <cjwatson> lamont: no, I'm off to bed in a moment
[11:32] <lamont> cjwatson: so I have things were I'm nearly certain that I won't break anything except maybe PPA builds on virtual machines during the time between pushing the bootstrap-enabled beast, and the bootstrap-disabled beast
[11:32] <lamont> on the bright side, I can retry stuff if I do break it. :-(
[11:32] <cjwatson> lamont: which version of bind9 were you trying to get bind9 to sync?
[11:32] <cjwatson> er, "were you trying to get slangasek to sync"
[11:33] <lamont> oh.  bind9_1:9.4.1-P1-2
[11:33] <cjwatson> where is that?
[11:33] <lamont> should be in sid.
[11:33] <cjwatson>      bind9 | 1:9.4.1-P1-1 |      unstable | source, alpha, amd64, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
[11:33] <cjwatson> isnae
[11:33] <cjwatson> oh, only JUST landed in sid
[11:34] <cjwatson> if you give things a chance to propagate, it'll be syncable just fine ...
[11:34] <lamont> bind9_9.4.1-P1-2.dsc	2007-Oct-03 05:02:01	0.8K	application/octet-stream
[11:34] <lamont> ah, ok
[11:34] <lamont> so it needs rmadison to be done and aware of the upload...
[11:34] <lamont> I suppose we can forgive a few hours more..
[11:34] <cjwatson> no
[11:34] <cjwatson> it needs whatever mirror we're using to have it
[11:35] <cjwatson> p.s. would help if my link to drescher would stay up
[11:36] <cjwatson> slangasek: workaround:
[11:36] <cjwatson> slangasek: wget the .dsc and .diff.gz from wherever, maybe best grab the .orig.tar.gz for good measure, into ~lp_archive/syncs/
[11:36] <cjwatson> slangasek: dpkg-scansources > Debian_incoming_main_Sources
[11:36] <cjwatson> er, dpkg-scansources . /dev/null > Debian_incoming_main_Sources
[11:36] <cjwatson> sync-source -b lamont -S incoming bind9
[11:36] <cjwatson> flush-syncs # if that worked
[11:37] <cjwatson> my link to drescher is too flaky to attempt it at the moment, and it's bedtime
[11:37] <cjwatson> oh, and probably sync-source.py not sync-source
[11:39] <bryce> elmo: deb with patch is up + caveats; see bug 86072
[11:39] <ubotu> Launchpad bug 86072 in xserver-xorg-video-ati "ATI ES1000 515e not recognized" [Medium,Confirmed]  https://launchpad.net/bugs/86072
[11:40] <slangasek> cjwatson: the part where I got stuck was with sync-source not being executable? :)
[11:40] <cjwatson> slangasek: yeah, it's apparently sync-source.py this week
[11:41] <cjwatson> sync-source was our forked version which is clearly not kosher at the moment
[11:41] <cjwatson> but looks like sync-source.py ought to work well enough
[11:41] <cjwatson> I didn't know about the non-executability until I tried it - when I have time I'll look into the diff and merge
[11:41] <cjwatson> night folks
[11:41] <slangasek> heh, ok
[11:44] <thully> hi - I was on this channel last night regarding bug 137598 - a regression from Feisty.  Anyway, I do have a patch for that, and it is attached to the bug report (diff against the source file in question).
[11:44] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,Confirmed]  https://launchpad.net/bugs/137598
[11:45] <lamont> slangasek: later, I'll want you to sync mlton from sid.  I think that was the motu decision
[11:48] <thully> The patch may not be the prettiest in the world (basically, what it does is check the appropriate "idle_dim" setting in the idle callback and doesn't call the brightness adjust function if it isn't set)
[11:49] <thully> One may want to stop the callback from happening altogether, but that involves gscreensaver and may not be desirable (in case other things are being done on idle)
[11:51] <thully> Anyway, I hope the devs can look at Ubuntizing this fix for the Gutsy release.  I think it would look bad to have this kind of bug (screen brightness adjusting on idle, no matter what the setting is) in Gutsy final...
[11:57] <thully> I've been taking a peek at Ubuntu-related code, and I must say I've noticed an incredible amount of flaws in gnome-power-manager.  This one is quite glaring, but I've also stumbled upon another regression in 63543
[11:59] <thully> I posted a patch for that in the bug report, but it still will change the brightness on exiting idle - even if the brightness is < the idle brightness on idle...
[12:00] <thully> g-p-m 2.18 was fine in all these respects - it's just that g-p-m 2.20 has apparently fscked up the handling of idle and brightness with a rewrite of most of the relevant code...
[12:08] <Keybuk> thully: 63543 is a pretty old bug, so has been present for at least one release
[12:09] <thully> actually, I just reopened bug 63543 - it wasn't in Feisty, but is back in Gutsy since they rewrote most of the relevant code in g-p-m
[12:09] <ubotu> Launchpad bug 63543 in gnome-power-manager "Error in automatic diminuition of brightness when idle" [Undecided,Confirmed]  https://launchpad.net/bugs/63543
[12:09] <Keybuk> thully: have you talked to hughsie about your patches?
[12:09] <thully> no - I guess I probably should - do I need to file upstream bug reports first?
[12:10] <Keybuk> if it's the upstream code that's regressed, it's probably better to talk directly to him
[12:10] <Keybuk> since it seems like you know what you're talking about
[12:10] <Keybuk> and get it fixed upstream :)
[12:10] <thully> I think so, but I know there is a UVF in Gutsy that would seem to block said changes from being integrated from upstream
[12:11] <Keybuk> GNOME is in the same UVF right now :)
[12:12] <Keybuk> though if hughsie acks the patches, they're much more likely to be applied
[12:12] <Keybuk> since we'll know they're going upstream and can be dropped for our next release
[12:12] <kylem> win 34
[12:13] <Keybuk> lose 89
[12:13] <elmo> draw 23
[12:14] <Keybuk> hoot
[12:14] <kylem> right.
[12:16] <pwnguin> i do wish i could figure out why screen blanking doesn't work on nvidia
[12:16] <Keybuk> pwnguin: binary driver or free one?
[12:16] <pwnguin> rather, it does, but the backlight's still on =/
[12:16] <pwnguin> binary i think
[12:17] <pwnguin> i remember one was affected and the other wasnt
[12:17] <lamont> slangasek: so does that mean that bind9 didn't get synced and I should upload, or that it's inbound and I should STFU and wait like a good little boy?
[12:17] <Keybuk> pwnguin: we can fix one, but not the other
[12:17] <pwnguin> Keybuk: vbetool works, but not xset
[12:18] <lamont> Keybuk: any clues on why my backlight dims on battery, even though g-p-m has been told to 1) not dim, and 2) 100% is a good dimlevel, via gconf-editor?
[12:18] <Keybuk> lamont: sodomy non sapiens
[12:18] <lamont> is ATI M56P
[12:18] <Keybuk> I know next to nothing about g-p-m
[12:19] <lamont> heh
[12:19] <lamont> ok
[12:19] <slangasek> lamont: my attention drifted elsewhere, if you want to upload go ahead otherwise I'll look at it later on (at a point where the mirrors should have synced)
[12:19] <Keybuk> lamont: I didn't even know until just now that it does stuff with brightness
[12:19] <Keybuk> so I'm now curious whether it's the cause of my bug that the Dell's light sensor doesn't seem to work anymore
[12:19] <lamont> slangasek: well, as long as it's done before fabbione wakes up in about 7 hours
[12:20] <lamont> I have it spewing debug crap on my laptop for me to stare at later
[12:21] <lamont> hrm... with g-p-m _NOT_ running, unplugging the AC still dims backlight... I think that's pretty conclusive that gpm is not to blame.
[12:21] <Keybuk> that's probably BIOS :)
[12:21] <Keybuk> unplug power, increase brightness, plug power back in
[12:21] <lamont> how do I increase brightness, I wonder...
[12:22] <Keybuk> Fn+Something? :P
[12:22] <pwnguin> lamont: maybe there's an option in BIOS to twiddle
[12:22] <Ng> something keeps resetting my brightness to 100%, which I'd assumed was g-p-m
[12:22] <Keybuk> hmm
[12:22] <Keybuk> gpm doesn't seem to be involved in brightness on my laptop at all
[12:22] <lamont> (switch to something other than vt7, and use FN brightness up)
[12:23] <pwnguin> theres gpm and the backend
[12:23] <mjg59> Keybuk: I suspect your Dell is one generation too old
[12:24] <Trewas> brightness is some kind of a strobo now that intel driver always sets it to maximum with anything interesting happening (any xvideo/opengl app starting, going to console etc) together with g-p-m or something munging it when idling :)
[12:24] <mjg59> Yeah, I've got a patch for that
[12:24] <Keybuk> mjg59: it's ICH7
[12:24] <mjg59> Keybuk: It's BIOS-dependent, not chipset dependent
[12:24] <Keybuk> could be then
[12:24] <Keybuk> though it's weird the sensor has stopped working
[12:25] <pwnguin> what defines idle for the g-p-m "dim display on idle" feature? cuz id really like to turn that higher =/
[12:29] <thully> pwnguin: I think idle is your screensaver idle setting
[12:29] <Keybuk> (I blame keithp :p)
[12:30] <thully> Regarding the g-p-m idle situation, it has really seemed quite ugly in 2.20 - I have seen brightness randomly increase in many places...
[12:30] <pwnguin> thully: it says 15 minutes
[12:30] <pwnguin> feels closer to 15 seconds
[12:31] <thully> pwnguin: I guess I was wrong, it's a gconf key
[12:32] <thully> gconf-editor, and then open apps/gnome-power-manager/backlight
[12:32] <pwnguin> hmm
[12:33] <pwnguin> 30 seconds
[12:33] <pwnguin> sounds about right. any documentation on what this dpms_method_foo does?
[12:33] <Keybuk> almost certainly in the schema
[12:33] <Keybuk> ("click on it")
[12:34] <pwnguin> well, it's "default"
[12:34] <pwnguin> =/
[12:34] <thully> Regarding the dim on battery despite this being disabled, I just found the problem in the code...
[12:34] <pwnguin> capitol work