[12:48] <asac> bryce: bug 147676 ... could this be done properly?
[12:48] <ubotu> Launchpad bug 147676 in imwheel "Any Logitech mouse buttons does NOT work in FireFox LTSP xorg gpm imwheel yelp icedove iceweasel" [Undecided,New]  https://launchpad.net/bugs/147676
[01:19] <bryce> asac, thanks I'll take a look
[01:24] <Chipzz> man, that bugreport is CRAP :p
[01:25] <Chipzz> "Any Logitech mouse buttons does NOT work in FireFox xorg gpm imwheel yelp icedove iceweasel etc."
[01:25] <Chipzz> first of all this is not even a sentence
[01:25] <sladen> and even if it was, it's quite long for a subject line :)
[01:25] <Chipzz> 2nd of all the guy is just throwing a whole bunch of unrelated program names together and expects that to be a valid bugreport
[01:26] <dobey> that is totally a sentence
[01:26] <Chipzz> firefox/xorg/gpm/imwheel ok
[01:26] <Chipzz> but the rest?
[01:26] <dobey> you just need to learn Engrish better :)
[01:27] <Chipzz> he's confusing consumers apps (like firefox, icedove, iceweasel and yelp) with daemons or servers (xorg, gpm, imwheel)
[01:28] <Chipzz> *and* I don't think we support gpm + X config?
[01:28] <Chipzz> do we?
[01:28] <dobey> i i just like how firefox is listed N times
[01:28] <dobey> i didn't realize that imwheel still existed
[01:29] <dobey> gpm probably is supported
[01:29] <Chipzz> it's deprecated IMHO
[01:29] <dobey> i don't know what it has to do with X though
[01:29] <bryce> asac: generally I've been holding off on doing much work on improving input stuff, since with Hardy when we go to xserver 1.4, we should be able to take advantage of input hotplug and avoid all these configuration tweaks
[01:29] <Chipzz> dobey: you have to correctly set your mouse type in order for gpm to work
[01:29] <mjg59> If you want cut and paste on the console, it's kind of important
[01:29] <dobey> Chipzz: you have to correctly set your mouse type for X to work
[01:29] <dobey> :)
[01:29] <mjg59> dobey: No, the kernel does most of that now
[01:29] <Chipzz> mjg59: I *know* what gpm is :) I have used it for errr, over 7 years :)
[01:30] <mjg59> Chipzz: I wasn't talking to you
[01:30] <dobey> mjg59: the kernel deals with mouse buttons and ZAxisMapping in xorg.conf?
[01:30] <mjg59> It depends what level you're looking at
[01:30] <dobey> or X is smarter about dealing with it now?
[01:30] <asac> bryce: ok, please drop a note in bug and set to won'tfix?? ... maybe verify if the bugs he mentions are of the same class and will be gone with 1.4 was well. Thanks!
[01:30] <mjg59> It abstracts away the mouse protocol stuff that used to be required in X
[01:31] <dobey> so X is smarter about it
[01:31] <mjg59> I believe that the ZAxis stuff is still required, though
[01:31] <bryce> asac, will do.  Think I'll try to dupe some of these while I'm at it, if they are indeed dupes
[01:31] <dobey> you still have to tell it what buttons are scroll/etc... i think
[01:31] <mjg59> No, now the kernel recodes everything to look like the Microsoft extended protocol
[01:31] <asac> bryce: if there are others with a firefox target, feel free to invalidate them ;)
[01:31] <mjg59> But yeah. It's not practical to programmatically determine which buttons are which under certain cricumstances
[01:31] <mjg59> 4 and 5 will always be the wheel, but 6 and 7 might be side buttons or a horizontal wheel
[01:32] <bryce> asac, okie
[01:33] <asac> ;)
[01:49] <Chipzz> bryce: when will hardy have xorg 1.4? soon after opening or late in the cycle?
[01:50] <bryce> soon after opening
[01:50] <Chipzz> btw
[01:50] <Chipzz> are serial mice autodetectable?
[01:50] <bryce> once the tree opens I'll make that my top priority
[01:51] <Chipzz> serial mice or getting xorg 1.4 in hardy?
[01:51] <mjg59> Chipzz: Not trivially
[01:51] <bryce> Chipzz: xserver 1.4
[02:41] <slangasek> evand: bug #123425 is still only 'fix committed', not 'fix released'?
[02:41] <ubotu> Launchpad bug 123425 in ubiquity "[gutsy]  Passwords intead of Full Names" [High,Fix committed]  https://launchpad.net/bugs/123425
[02:57] <slangasek> lamont: bug #63175 - eww, do we really still have issues with timezones and fsck?
[02:57] <ubotu> Launchpad bug 63175 in e2fsprogs "fsck on every (re)boot" [Medium,New]  https://launchpad.net/bugs/63175
[03:10] <mneptok> slangasek: at least we don't leave New Zealand in the wrong timezone because "tzdata is not a security issue" ;)
[03:11] <Hobbsee> mneptok: bah.  new zealand.  are you telling me that they're whining for gettign australia's eastern timezone?
[03:12] <mneptok> Hobbsee: no, Debian won't push the new daylight savings tzdata to Etch as it's not a security issue
[03:12] <slangasek> mneptok: you might be well advised to not get your information about Debian from Slashdot
[03:13] <Hobbsee> but mneptok lives for slashdot!
[03:14] <StevenK> Like Slashdot would talk about Debian - it doesn't happen within 3 blocks of CmdrTaco's house
[03:15] <mneptok> slangasek: it's still an issue that's unaddressed until a point release instead of a rolling update. which seems silly.
[03:15] <mneptok> slangasek: it's tzdata. we push this stuff out every week. why does Debian need to wait for a point release?
[03:15] <slangasek> mneptok: anyway, I don't think this is a conversation you want to have with me; I don't think much of governments who make changes to their timezones with less than a year's notice, because regardless of whether Debian happens to be able to accomodate them, such changes are expensive for the IT industry and serve no purpose.
[03:16] <slangasek> mneptok: so you're arguing that it should be pushed out as a "security" release when it's not security related?
[03:16] <mneptok> slangasek: i agree. but pouting and refusing to make life easier for users isn't helping. what's done is done, for good or ill. address it.
[03:16] <slangasek> mneptok: this would be the part where you're getting your information from Slashdot...
[03:17] <mneptok> slangasek: i'm saying it doesn't need to be either/or
[03:17] <mneptok> slangasek: the fact that others have coped is ample evidence of this.
[03:18] <slangasek> there are four update channels available for fixes to Debian stable.  security.d.o, volatile.d.o, proposed-updates, and point releases.  The tzdata fix is *already available* in two of these, is targetted for a third but can't be made available yet for practical reasons, and doesn't belong in the fourth
[03:18] <mneptok> slangasek: but i can understand why production server admins might be put off by "volatile"
[03:19] <slangasek> mneptok: proposed-updates contains only those changes which have been accepted by the Debian stable release managers for the next point release; from etch forward, production server admins can reasonably make use of p-u
[03:21] <mneptok> i don't see it in p-u
[03:21] <slangasek> it's definitely there.
[03:23] <mneptok> http://ftp.debian.org/debian/dists/proposed-updates/tzdata_2007f-1etch1_amd64.changes
[03:23] <mneptok> august 17
[03:25] <mneptok> wait, no, July 31
[03:26] <mneptok> we con get a release done in the time it takes Debian to fix a timezone. :P
[03:27] <ajmitch> ah, the tzdata fun
[03:28] <ajmitch> slangasek: don't worry, we don't think much of our government either
[03:29] <StevenK> Hah
[03:33] <StevenK> bddebian: Why? And, ajmitch's quip was pointed at New Zealand's government.
[03:33] <bddebian> I know :-)
[03:34] <bddebian> Because Howard (I belive his name is?) is like Hey, it's Australia, love it or leave it. :-)
[03:35] <StevenK> Yes, (John) Howard.
[03:35] <RAOF>  Not the actor :)
[03:36] <mneptok> isn't that sorta antithetical to a penal colony? i mean, prisoners choosing to leave?
[03:37] <lifeless> mneptok: even prisons have standards
[03:38] <mneptok> lifeless: explains my rejected visa application :/
[03:38] <lifeless> mneptok: I thought you were usian?
[03:40] <mneptok> lifeless: the UN has asked that all nations require a visa in my case. they ... just want to be sure.
[03:40] <lifeless> I'd have though a GPS ankle collar would be safere
[03:40] <Hobbsee> he never said that he didnt have one of them either, though
[03:40] <lifeless> he didn't have one last time I saw him
[03:41] <mneptok> lifeless: it's a genital cuff
[03:41] <Hobbsee> who said it was on his ankle?  if it was on his ankle, it coudl be cut off...
[03:41] <lifeless> Hobbsee: it can still be cut off
[03:41] <lifeless> with the added benefit of no-breeding
[03:41] <Hobbsee> lifeless: good point.
[03:42] <mneptok> lifeless: now you sound like my girlfriend
[03:42] <mneptok> Unilag would be a great name for a Cisco competitor
[03:42] <lifeless> mneptok: sensible lady:)
[03:42] <bddebian> mneptok: heh
[03:43] <StevenK> bddebian: Do I? I don't think I do.
[03:43] <Hobbsee> lifeless: although insane.  being with mneptok, and all.
[03:43] <lifeless> Hobbsee: there may be coercion involved.
[03:43] <bddebian> StevenK: Suure you do :-)
[03:43] <mneptok> lifeless: you may meet her at/around/adjoining All-Hands
[03:43] <lifeless> Hobbsee: we should organise a rescue party
[03:44] <Hobbsee> lifeless: indeed.
[03:44] <lifeless> mneptok: somehow I'm amazed you didn't make that statement dirty. 'seeing her around all-hands' is just ripe for suggestive deviation
[03:45] <mneptok> lifeless: after Hobbsee's comment this weekend i had to turn off those receptors. there was danger of circuit overload.
[03:47] <Hobbsee> lifeless: he wished to live, methinks.
[03:50] <Hobbsee> !away | cypher1
[03:50] <ubotu> cypher1: You should avoid changing your nick in a busy channel like #ubuntu - it causes unrequired scrolling which is unfair on new users. The same goes for using noisy away messages : use the command "/away <reason>" to set your client away silently - See also !Guidelines
[04:24] <wasabi> I am somehow missing how restarting NetworkManager can cause my keyboard to cease working.
[04:24] <wasabi> Just not seeing the link.
[04:33] <EvanCarroll_home> is anyone else having a problem with amd64 and nvidia with newest patch?
[04:33] <EvanCarroll_home> gutsy*
[04:34] <Hobbsee> EvanCarroll_home: you probably wanted #ubuntu+1?
[04:34] <bddebian> Should glade files be in a binary package or data package?
[04:34] <EvanCarroll_home> seems as if volatile/nvidia.ko, was renamed to volatile/new_nvidia.ko, without symlink
[04:34] <EvanCarroll_home> Hobbsee: yes, i forgot about that chan
[05:06] <ScottK> paran: Dunno if you noticed yet or not, but your gnupg fix got uploaded today.  Thanks for the heads up.
[05:10] <nrdb> I have created a unionfs in initrd of the from the what was the root and another rw partition.  I have checked the unionfs and it appears ok.  The problem is that when I boot it seems to get stuck in a loop using 100% CPU and never actually boots, any ideas on how to find out what the problem is ?
[05:22] <lamont> slangasek: fsck/timezone issues are fixed in -6ubuntu1
[05:22] <lamont> maybe
[05:23] <lamont> slangasek: see https://bugs.debian.org/443487
[05:24] <slangasek> or http maybe :)
[05:24] <lamont> yeah - that
[05:24] <lamont> that's what I get for adding $mumble:// at the front
[05:24] <lamont> :-(
[05:25] <lamont> note the small amount of grumbling from the submitter.  also note who he is
[05:25] <slangasek> so ok, it should be fixed in util-linux and this bug should be reassigned to there?
[05:28] <lamont> yes
[05:28] <lamont> and note that fixing it requires adding an installer question...
[05:28] <lamont> so I'll leave that to TPTB
[05:33] <lamont> slangasek: the only outstanding issue is if you have BIOS=localtime (presumably because you dual-boot), and live east of greenwich
[06:04] <slangasek> lamont: you've lost me; why is an additional installer question needed?
[06:13] <lamont> either "what time zone are you in" or "is time UTC or local" or some such.
[06:14] <lamont> I really have no clue - just know that ted was grumbling
[06:22] <lamont> slangasek: feel free to look at util-linux_2.13-8 in debian (just uploaded now).  if there's anything that we want for -6ubuntu2 (or if we want to do -8ubuntu1) say so: I don't think there's anything so pressing as to justify hitting gutsy now.
[06:23] <lamont> hrm.. still uploading....
[06:28] <dcode>  I want to build packages for amd64 from an unofficial repository that provide the original sources and patches, but only i386 binaries...when I do apt-get -b source foo, it downloads the version in the official repository...how do I fix this?  Do I need to pin the packages?
[06:29] <lamont> dcode: apt-get source foo=1.2.3-1 is certainly an option
[06:30] <dcode> thanks, lamont
[06:30] <dcode> there's just so many way to use apt....I find new stuff all the time
[06:42] <nrdb> with vmware and 7.04 the message "BUG: soft lockup detected on CPU#0!" means ?
[06:53] <tepsipakki> slangasek: ok to upload a new discover-data (bug #133385)?
[06:53] <ubotu> Launchpad bug 133385 in discover-data "[gutsy]  "nv" is not new enough to support my chipset (Quadro FX 570M)" [Medium,In progress]  https://launchpad.net/bugs/133385
[06:54] <tepsipakki> it's not new upstream, but adds a number of nvidia pci-id's that the current driver supports (also some that the previous 2.1.x supported, but were missing)
[06:55] <tepsipakki> debdiff attached
[07:07] <slangasek> lamont: I'm confused, isn't gutsy already asking for the time on install?
[07:08] <lamont> slangasek: dunno - like I said, I haven't paid any attention to that part of the issue....
[07:09] <lamont> if we do, then it might make sense to bring back hwclockfirst.sh here too, OTOH, ISTR that comes from the rtc module getting loaded via udev rules now.
[07:10] <lamont> slangasek: I've pretty much ignored hwclock.sh issues in ubuntu and let keybuk lead on that, since he did the udev conversion
[07:10] <lamont> of course, the big diff is that ubuntu requires udev (or seems to?), while debian avoids depending on it.
[07:11] <lamont> slangasek: and I wasn't in on the ted/whomever discussion that ted alludes to.
[07:12] <lamont> hrm... eject spits the CD tray out... is there a command to pull it back in?
[07:13] <lamont> slangasek: I'll break out a livecd and check tomorrow.
[07:14] <lamont> and maybe poke keybuk et al here on the issue once I have more knowledge
[07:14] <StevenK> lamont: Try eject -t <device> to pull the tray back in
[07:14] <lamont> StevenK: cool
[07:15] <lamont> I'll do that later - drives are kinda busy atm
[07:22] <slangasek> tepsipakki: discover-data, looks fine
[07:25] <ScottK> If someone is looking into TZ and the installer, it'd be really nice to be able to use UTC after you admit to being in North America.
[07:28] <lamont> ScottK: you mean you can't say NorthAmerica/UTC?
[07:28] <ScottK> lamont: First it asks you where you are and then gives you a list of applicable TZ.
[07:29] <ScottK> It doesn't consider UTC in North America.
[07:29] <ScottK> This is D-I and a server install.
[07:29] <ScottK> It's just not on the list.
[07:31] <lamont> feh.  db4.5 is blocking python2.5
[07:34] <slangasek> you can specify that the system clock is in UTC
[07:36] <lamont> slangasek: but not that the local TZ is NorthAmerica/UTC
[07:36] <slangasek> correct
[07:52] <tepsipakki> slangasek: thanks
[07:53] <bryce> heya tepsipakki
[07:54] <tepsipakki> hi bryce
[07:55] <dholbach> good morning
[07:57] <Hobbsee> hi dholbach
[07:57] <dholbach> hey Hobbsee
[08:02] <pitti> Good morning
[08:03] <dholbach> mdke: do you plan to sync with gnome-user-docs 2.20.0 again?
[08:03] <Hobbsee> morning pitti!
[08:03] <pitti> hey Hobbsee, good morning
[08:04] <Hobbsee> pitti: i discovered the morning today.  it wasnt good.
[08:04] <StevenK> If mornings really exist, why are there only 12 hours on a clock...
[08:05] <Chipzz> they're extremely late evenings, at best
[08:05] <Hobbsee> heh
[08:05] <StevenK> Chipzz: Heh
[08:18] <stgraber> moin
[08:19] <Hobbsee> hiya
[08:22] <StevenK> pitti: Oh, libevolution2.0-cil can be NBS'd out if you haven't already done it.
[08:23] <pitti> StevenK: ah, doing
[08:23] <StevenK> pitti: Danke
[08:23] <pitti> StevenK: I also ponder killing the other libs now, and thus break sear and silky
[08:24] <StevenK> pitti: silky can die as far as I'm concerned. Upstream is dead, and getting it work with the new SILC looks to be a shedload of work. However, there is a bug about silky, so someone could be working on it.
[08:25] <pitti> swoosh, killed them all; we should not ship gutsy with NBS packages
[08:25] <StevenK> pitti: sear on the other hand is known about, and I keep bugging man-di in -motu in terms of where it's up to. He is fighting with the Debian maintainer, last I heard.
[08:28] <StevenK> pitti: Agreed.
[08:35] <soren> NBS?
[08:35] <StevenK> Not Built from Source
[08:36] <soren> Well..
[08:37] <soren> How can you NBS something?
[08:37] <StevenK> Okay, so you have a library package - libfoo, that builds libfoo1.
[08:37] <soren> Uhuh.
[08:38] <StevenK> libfoo's upstream releases a new version that bumps the SOVER, so now you build libfoo2.
[08:38] <soren> Uhuh.
[08:39] <StevenK> The binary packages still exist in the archive, and shouldn't be removed until nothing depends on it.
[08:39] <soren> Yes...
[08:39] <StevenK> The binary package libfoo1, that is
[08:39] <soren> Let me rephrase..
[08:39] <soren> When you tell pitti that a package can be "NBS'd out", what does he then do?
[08:39] <pitti> soren: I remove it from the archive
[08:40] <pitti> soren: we should not release gutsy with pacakges which are not built by any source, since that makes them unmaintainable
[08:40] <soren> Oh...
[08:40] <soren> Sure, sure.
[08:40] <soren> I get it now.
[08:40] <pitti> but it does not happen automatically, since with library soname changes, that would break hard
[08:41] <dholbach> doko_: would it be ok, if you took a look at bug 139928?
[08:41] <ubotu> Launchpad bug 139928 in cpio "[gutsy]  cpio segs on bad input" [Medium,Confirmed]  https://launchpad.net/bugs/139928
[08:41] <soren> So "NBS a package out" doesn't mean "make it not build from source", but "remove it because it's already not built from any source". YEs, that makes perfect sense :)
[08:41] <soren> pitti: Sure.
[08:42] <StevenK> pitti: I'll hunt down that silky bug and comment on it when I'm on a link that isn't so dreadful.
[08:43] <dholbach> Riddelll: bug 136425, bug 121872?
[08:43] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
[08:43] <ubotu> Launchpad bug 121872 in qt4-x11 "*-qt4 tools should be present in $QTDIR/bin" [Undecided,In progress]  https://launchpad.net/bugs/121872
[08:43] <dholbach> calc: bug 135086?
[08:43] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
[08:55] <Mithrandir> dholbach: what's the policy you've been using for accepting or not accepting people for the telepathy team?
[08:56] <dholbach> Mithrandir: none
[08:56] <Mithrandir> dholbach: as in, just accept everybody?
[08:56] <dholbach> Mithrandir: I directly subscribed them to the mailing list too :)
[08:57] <siretart> asac: around? Wanted to ask you about NM/wpasupplicant integration
[08:58] <soren> StevenK: Did you ever figure out why the dpkg output in gutsy sbuilders was in all upper case?
[08:59] <RAOF> soren: Oooh, you're seeing that too?
[08:59] <StevenK> soren: Nope. Mainly because I've not looked yet.
[08:59] <StevenK> RAOF: Me three.
[08:59] <soren> StevenK: Same here. :)
[09:00] <StevenK> Between the three of us we should be able to sort it out. :-)
[09:01] <soren> :)
[09:02] <soren> StevenK: Do you save your build logs from sbuild? Could you check when it happened to you the first time?
[09:03] <StevenK> soren: I do. And what do you mean, the first time?
[09:03] <mdke> dholbach: yes, I updated our branch from upstream trunk on sunday, if possible we could do another upload, yes
[09:03] <soren> StevenK: Has your sbuilder *always* done it?
[09:03] <StevenK> soren: Ah, no.
[09:04] <pitti> \sh_away: did you have a chance to test the fix for bug 103291?
[09:04] <ubotu> Launchpad bug 103291 in lilo-installer "lilo-installer fails on HP (Compaq) SmartArray controllers (/dev/cciss)" [Medium,In progress]  https://launchpad.net/bugs/103291
[09:05] <dholbach> mdke: I'll look into it later
[09:06] <StevenK> soren: Right, the first log I have with the upper-casing is courier_0.56.0-2ubuntu1_20070917-2341
[09:07] <soren> StevenK: So mid-september-ish?
[09:07] <StevenK> Looks like it.
[09:08] <dholbach> mdke: I'll update the version number
[09:08] <StevenK> I think the next step is to compare base tool versions between that log and the previous.
[09:08] <mdke> dholbach: thanks. We haven't made any other changes except synching with upstream; which was a couple of extra translations, and upstream applying one of our patches
[09:09] <dholbach> mdke: great
[09:09] <dholbach> mdke: next time please update debian/changelog :-)
[09:09] <dholbach> it's just a matter of   dch -i; debcommit   :-)
[09:09] <mdke> dholbach: yes, I would have done, sorry
[09:10] <soren> StevenK: Interesting. You had schroot 1.1.5-1.1 synced on September 13th :)
[09:10] <mdke> :)
[09:15] <dholbach> mdke: pushed changes to my branch
[09:15] <dholbach> hey thekorn
[09:16] <thekorn> hi dholbach
[09:19] <dholbach> mdke: uploading package...
[09:22] <mdke> dholbach: thanks very much. for ubuntu-docs I'll be adding translations during this week... we are going to have to be careful with the package size when that happens... I'll ping you early next week if that is ok?
[09:22] <dholbach> mdke: alrightie, you can also file a sponsoring bug, that's fine too
[09:23] <mdke> ok
[09:26] <pitti> \sh: good morning
[09:27] <\sh> pitti, hey...good morning...:)
[09:28] <geser> Guten Morgen \sh, pitti
[09:28] <pitti> hi geser
[09:38] <StevenK> soren: Hmmm.
[09:41] <soren> StevenK: Hm, indeed.
[09:45] <StevenK> soren: But schroot isn't installed inside the chroot, and my base machine is Feisty
[09:46] <soren> StevenK: Oh.
[09:49] <twb> What is dh_iconcache, why is it undocumented and why is it in Ubuntu's debhelper and not Debian's?
[09:50] <pitti> twb: it is the old name of dh_icons
[09:50] <pitti> twb: we had it first, Debian used a different name, so it's just a backwards compatibilty shim nowadays
[09:51] <twb> I can replace it 100% with dh_icons in this package I'm re-building under Debian?
[09:51] <pitti> twb: given that dh_iconcache just does system("dh_icons @ARGV");, I'd say yes
[09:52] <twb> OK, thank you.
[09:52] <dholbach> everything should use dh_icons
[09:52] <twb> The package in question is vmware-server 1.0.3, from feisty-commercial.
[09:53] <dholbach> twb: oh ok, I think in feisty we still had dh_iconcache - let me check
[09:53] <twb> I would've used gutsy, but it has no -commercial yet.
[09:54] <dholbach> yes, feisty still has dh_iconcache :-/
[09:54] <dholbach> I think somebody is working on setting up gutsy-commercial
[09:55] <twb> I hate non-Free software.  It's nothing but a PITA.
[09:55] <twb> -commercial isn't listed on packages.u.c either, which confused me for days.
[09:57] <tepsipakki> isn't it called something else nowadays?
[09:59] <Mithrandir> cjwatson: is it possible to get user-setup-apply to set a completely blank password?
[10:10] <tepsipakki> twb: it's being changed to "partner", but that doesn't exist yet
[10:12] <TheMuso> Is the apport retracer for i386 running?
[10:12] <pitti> TheMuso: seems it got stuck, I restarted it
[10:13] <dholbach> hey mvo
[10:13] <pitti> TheMuso: thanks
[10:13] <pitti> hey mvo
[10:13] <TheMuso> pitti: Thank you.
[10:13] <mvo> hey dholbach, pitti!
[10:17] <dholbach> hey seb128
[10:17] <seb128> hello dholbach
[10:17] <mvo> hey seb128
[10:17] <seb128> hello mvo
[10:17] <simira> morning guys
[10:17] <simira> :)
[10:18] <Mithrandir> simira!
[10:22] <seb128> hey simira
[10:25] <RicardoPerez> pitti: ping
[10:25] <pitti> hi RicardoPerez
[10:25] <RicardoPerez> pitti: hi! i have a problem with the openoffice.org menu entries... i'm talking with carlos, and he told me to talk with you
[10:27] <RicardoPerez> pitti: the menu entries shows untranslated in my Spanish desktop
[10:27] <RicardoPerez> pitti: i have the ooo-build.mo file with the translations
[10:28] <pitti> RicardoPerez: the bubble help is untranslated, too?
[10:28] <RicardoPerez> pitti: and I've add a line containing 'X-Ubuntu-Gettext-Domain=ooo-build' in the .desktop files
[10:28] <RicardoPerez> pitti: the bubble IS translated
[10:28] <RicardoPerez> pitti: but the menu entries isn't
[10:28] <RicardoPerez> aren't
[10:28] <dholbach> doko: where was the page that listed ubuntu-specific packaging decisions?
[10:29] <pitti> right, same here
[10:29] <pitti> RicardoPerez: it seems that they consider "OO.o writer" as a proper noun and thus do not translate it
[10:29] <doko> dholbach: UbuntuPackagingChanges
[10:30] <pitti> RicardoPerez: e. g. I never saw MS "Word" or "Excel" getting translated
[10:30] <dholbach> doko: thanks
[10:30] <pitti> RicardoPerez: (except in jokes :) )
[10:30] <pitti> RicardoPerez: the desktop file does have some Arabic translations, etc., though
[10:30] <RicardoPerez> pitti: oh, that's right, but the menu entries doesn't must be "OpenOffice.org Writer", but "OpenOffice.org Word processor"
[10:31] <pitti> hm, no, that's just the GenericName
[10:31] <RicardoPerez> pitti: "OpenOffice.org Word processor" => "OpenOffice.org Procesador de textos" (in spanish)
[10:31] <RicardoPerez> pitti: oh
[10:31] <pitti> RicardoPerez: we do not show this by defautl
[10:31] <RicardoPerez> pitti: but shows in that way in Feisty
[10:31] <RicardoPerez> pitti: in Feisty, it shows "OpenOffice.org Procesador de textos"
[10:32] <pitti> hmm
[10:32] <RicardoPerez> pitti: and not "OpenOffice.org Writer"
[10:32] <pitti> seb128: did we change anything wrt. the display of GenericName in menus?
[10:32] <seb128> The openoffice menu item are translated on my gutsy
[10:32] <seb128> pitti: GenericName is not used by GNOME
[10:32] <seb128> it uses Name= for the item
[10:32] <pitti> that's what I thought, too
[10:32] <seb128> and Comment= for the tooltip on mouseover
[10:33] <seb128> and that has always been the case
[10:33] <carlos> seb128: the problem is that it's not using the .mo files
[10:33] <pitti> right, but that's something entirely different
[10:33] <carlos> and even adding the translation domain
[10:33] <pitti> (oo.o needs to add X-Ubuntu-Gettext-Domain:)
[10:33] <carlos> the entries are still untranslated
[10:33] <carlos> pitti: we added it by hand
[10:33] <carlos> restarted the session and still the same problem
[10:33] <RicardoPerez> carlos: me too, without luck
[10:34] <carlos> RicardoPerez: we == you and me ;-)
[10:34] <seb128> carlos: do you have the correct .mo file installed?
[10:34] <seb128> carlos: and the .mo has the translations?
[10:34] <RicardoPerez> carlos: sorry :)
[10:34] <seb128> works fine in french so I don't think the system is b0rked
[10:34] <carlos> seb128:  RicardoPerez said that we do
[10:34] <carlos> I didn't check it
[10:34] <seb128> k, I think you don't
[10:34] <RicardoPerez> seb128: I have the .mo file
[10:35] <carlos> seb128: well, I doubt you are using the same unless you added the translation domain too
[10:35] <RicardoPerez> seb128: and strings ooo-build.mo shows translated strings
[10:35] <carlos> seb128: there is a bug with the package that is not adding the translation domain to the .desktop file
[10:35] <seb128> carlos: it works for other menu items, didn't try openoffice but the panel has no reason to behave differently for it
[10:35] <carlos> seb128: so you use the translations inside the .desktop file
[10:35] <pitti> carlos: however, since OO.o does not use gettext, it does not have an obvious place where to put them
[10:35] <carlos> seb128: yeah, I know, that's why I was so confused
[10:35] <carlos> pitti: it does
[10:35] <carlos> ooo-build
[10:36] <carlos> pitti: we had a template specific for it and it's included in language packs
[10:36] <seb128> carlos: oo-build.mo doesn't contain the menu item strings there
[10:36] <seb128> $ msgunfmt /usr/share/locale-langpack/en_GB/LC_MESSAGES/ooo-build.mo | grep Writer
[10:36] <seb128> $
[10:36] <pitti> ah, indeed
[10:37] <RicardoPerez> seb128: It isn't Writer, but Word Processor
[10:37] <carlos> hmm
[10:37] <carlos> indeed
[10:37] <carlos> RicardoPerez: but the .desktop uses Writer
[10:37] <RicardoPerez> carlos: not in Feisty...
[10:38] <carlos> RicardoPerez: aren't you using Gutsy?
[10:38] <RicardoPerez> carlos: I don't know if this is intentional
[10:38] <pitti> carlos: so, calc should add the X-U-G-D: field
[10:38] <RicardoPerez> carlos: yes, I'm in gutsy
[10:38] <carlos> RicardoPerez: then, why do you mention Feisty?
[10:39] <RicardoPerez> carlos: because in Feisty shows "OpenOffice.org Word Processor" (in English) and in Gutsy shows "OpenOffice.org Writer"
[10:39] <cjwatson> Mithrandir: sure, casper does it, look at scripts/casper/10adduser
[10:39] <Le-Chuck_ITA> Hi there, I just tried to install openssh on feisty from main archive (ubuntu.com) and it said it was _not_ authenticated, while taking it from an italian mirror went fine!
[10:39] <carlos> pitti: yeah, I just got confused because the translations were not appearing and it was weird because it works for others (as seb128 already noted)
[10:39] <cjwatson> lamont: it's just the "is your clock in UTC" question that we haven't wedged into ubiquity yet
[10:39] <carlos> RicardoPerez: that just means that the different packages use different strings
[10:39] <cjwatson> Le-Chuck_ITA: sometimes happens transiently due to minor glitches; wait an hour and 'sudo apt-get update' again
[10:39] <seb128> carlos: works fine for me
[10:40] <seb128> carlos: I did that
[10:40] <RicardoPerez> carlos: mmmmm.... i'm confused
[10:40] <Le-Chuck_ITA> ok so if you're not worried about that I've done my job :)
[10:40] <seb128> - edit /usr/share/applications/ooo-writer.desktop, change the french translation
[10:40] <RicardoPerez> carlos: ooo-build didn't change from feisty to gutsy... contains the same strings
[10:40] <seb128> - add X-Ubuntu-Gettext-Domain=ooo-build to it
[10:40] <seb128> - sudo touch /usr/share/applications/ooo-writer.desktop,
[10:40] <carlos> RicardoPerez: which is the problem you are having
[10:40] <seb128> and the menu item has the mo translation now
[10:40] <carlos> RicardoPerez: the .desktop file did change
[10:40] <seb128> not the modified one
[10:40] <Mithrandir> cjwatson: no, that gets you a hash in /etc/shadow.  I want it to be ume::1000... in /etc/passwd.
[10:41] <Chipzz> Le-Chuck_ITA: normal install, or debootstrap?
[10:41] <carlos> RicardoPerez: so the .desktop file needs to be updated
[10:41] <seb128> carlos: works fine for me
[10:41] <RicardoPerez> carlos: mmmmmm wait, please
[10:41] <seb128> carlos: read what I just wrote
[10:41] <carlos> seb128: yeah, thanks, as said got confused with what RicardoPerez said, and didn't check the content of the .mo file
[10:41] <Mithrandir> seb128: is it a known bug that you get reasked for your keyring password when you resume from hibernate?
[10:42] <seb128> Mithrandir: yes
[10:42] <pitti> erm, 'bug'?
[10:42] <cjwatson> Mithrandir: are you disabling shadow passwords?
[10:42] <pitti> shuoldn't this be a feature?
[10:42] <Mithrandir> cjwatson: no.
[10:42] <Chipzz> pitti: heh. I was thinking the same thing ;)
[10:43] <cjwatson> Mithrandir: then no, you can't
[10:43] <Mithrandir> pitti: no?  I have my machine protected by a screensaver and login password.  Having me enter the login password again so I can connect to the wlan doesn't gain me any kind of security.
[10:43] <Mithrandir> cjwatson: I could, if that makes it easier, though
[10:43] <cjwatson> Mithrandir: regardless of what you preseed in user-setup, having shadow passwords turned on will hash it anyway
[10:43] <pitti> Mithrandir: ah, so the screensaver should unlock it again, right
[10:44] <pitti> Mithrandir: I just mean, putting the unencrypted password on disk during hibernation would be "eww"
[10:44] <cjwatson> Mithrandir: ah, user-setup-ask won't allow it though
[10:44] <Mithrandir> cjwatson: I'm preseeding and using -apply, though
[10:44] <cjwatson> Mithrandir: so preseeding an encrypted password is the only way to do it
[10:44] <cjwatson> you're using -apply directly rather than going via user-setup/
[10:44] <cjwatson> ?
[10:45] <Mithrandir> pitti: I think that's fine.  If people don't want that, use encrypted swap.
[10:45] <Mithrandir> cjwatson: yes, I've basically copied what's in casper, but I want you to be able to log in using "ume" without even having to press enter for password.
[10:45] <Mithrandir> but I guess I can live with having the user press enter.
[10:46] <cjwatson> Mithrandir: um
[10:46] <cjwatson> Mithrandir: if you set an empty encrypted password, they don't have to press enter for the password
[10:46] <cjwatson> Mithrandir: try 'exec /sbin/getty 38400 tty1' at a vt on the live CD
[10:46] <cjwatson> oh, hang on, that's not quite right
[10:48] <Mithrandir> cjwatson: http://paste.ubuntu.com/539/ shows what I'm seeing
[10:48] <cjwatson> Mithrandir: ok, sorry, I guess I'm confused
[10:48] <cjwatson> Mithrandir: does pam handle the ume:: case specially then?
[10:48] <Mithrandir> cjwatson: it seems so, yes.
[10:48] <cjwatson> (empty password in /etc/passwd)
[10:48] <Mithrandir> but if it's hard, I'll just document the password to be blank and people will have to live with that.
[10:49] <Mithrandir> pitti: saving passwords on disk during hibernate> or are you advocating that ssh-agent should drop all keys when hibernating and all encrypted devices should be torn down?
[10:49] <cjwatson> Mithrandir: ok, disable shadow passwords then
[10:50] <cjwatson> you can reenable them afterwards if need be (I don't remember if shadowconfig calls pwconv, but I don't think so)
[10:51] <Mithrandir> cjwatson: same problem
[10:51] <Mithrandir> http://paste.ubuntu.com/540/
[10:51] <pitti> Mithrandir: hm, certainly not; ah, ssh-agent doesn't use gnome-keyring?
[10:51] <cjwatson> how did you disable shadow passwords?
[10:51] <cjwatson> oh, I see
[10:51] <Mithrandir> (I ran a deluser in between)
[10:51] <Mithrandir> pitti: my ssh-agent doesn't use gnome-keyring at least.
[10:52] <Mithrandir> (my ssh-agent is gpg, but that's slightly beside the point here. :-)
[10:53] <cjwatson> Mithrandir: ah, it checks for the length of user-password-crypted
[10:53] <cjwatson> Mithrandir: TBH, I'd just do it by hand rather than using user-setup if I were you
[10:53] <Mithrandir> cjwatson: yeah, I can do that.  Or do user-setup-apply and then sed.
[10:53] <cjwatson> I don't think it's buying you much
[10:54] <Mithrandir> it's setting up sudo and putting the user in the right groups and such.
[10:54] <Mithrandir> which is nice.
[10:58] <cjwatson> Mithrandir: then sed sounds reasonable
[11:10] <ringe> What program provides the password dialog when using update-manager? I need to adjust the Norwegian translation.
[11:11] <mvo> ringe: gksu and libgksu
[11:16] <seb128> carlos: why did you change the po export to use the application-po naming?
[11:18] <carlos> seb128: you mean translationdomain-languagecode.po ?
[11:18] <seb128> carlos: yes
[11:18] <seb128> carlos: that was much nicer before
[11:18] <seb128> carlos: to update the po of a package you just had to copy the po, now you have to script rename everything
[11:18] <carlos> seb128: we got many complains about people not knowing for which translation was each file
[11:19] <seb128> couldn't you use the domain as a directory?
[11:23] <carlos> seb128: even with a single file download
[11:23] <carlos> ?
[11:23] <seb128> carlos: no, just when downloading the tar.gz for a package
[11:27] <carlos> seb128: yeah, that should be doable. Could you file a bug report, please?
[11:28] <seb128> carlos: will do, thanks
[11:42] <pitti> carlos: ah, dapper delta langpack  export seems to have worked fine
[11:42] <carlos> pitti: well, that's the idea of moving it to production servers ;-)
[11:42] <Nafallo> why does trackerd eat one of my cores?
[11:43] <Fujitsu> Nafallo: Because it is hungry, and seems incapable of not reindexing everything on boot.
[11:43] <Nafallo> :-(
[11:43] <seb128> Fujitsu: did you open a bug about that?
[11:44] <carlos> pitti: are you going to upload that update to Dapper's -updates archive?
[11:44] <pitti> carlos: no, to the PPA first
[11:44] <Fujitsu> seb128: No, I presumed it was vaguely intended behaviour or I was doing something wrong. I fixed it with the usual apt-get remove :P
[11:44] <carlos> pitti: ok
[11:44] <pitti> carlos: when it has gotten some testing, to -proposed
[11:44] <seb128> Fujitsu: ok, not really an useful comment nor behaviour
[11:44] <carlos> and then to -updates, yeah, I was talking about the standard procedure :-P
[11:45] <Nafallo> I've had this laptop on for quite some time though... I have no idea why it started chewing now.
[11:45] <carlos> seb128: there is a bug about trackerd performance problem already
[11:45] <carlos> Fujitsu: do you have latest version installed?
[11:45] <seb128> carlos: it's about io though, no?
[11:46] <Fujitsu> carlos: I removed it about a week ago.
[11:46] <seb128> carlos: and not about reindexing everything at every reboot
[11:46] <Fujitsu> I might try again, as the laptop isn't doing much useful at the moment.
[11:46] <carlos> seb128: well, for me was a problem of IO and CPU with older versions
[11:46] <carlos> I though the problem was that it was eating a lot of CPU
[11:46] <Nafallo> I use latest (ofcourse)
[11:46] <carlos> not that is reindexing everything
[11:46] <seb128> carlos: if it's still doing it you should open a bug
[11:46] <carlos> ok
[11:46] <carlos> sorry
[11:47] <Nafallo> I don't see much I/O either
[11:47] <seb128> that's alright
[11:47] <carlos> mixed Nafallo problem with Fujitsu one :-(
[11:47] <Fujitsu> It's understandable that it would eat CPU initially, but not each time it starts.
[11:47] <mjg59> It needs to rescan your home directory on every startup
[11:47] <carlos> seb128: no, it's not doing it anymore with latest update
[11:47] <mjg59> Otherwise it has no way of knowing whether new files have been created in between
[11:47] <carlos> at least for me
[11:48] <Nafallo> mjg59: you mean when the laptop has been off? it should detect that somehow...
[11:48] <mjg59> But it should just scan, not actually re-index anything
[11:48] <mjg59> Nafallo: How?
[11:48] <Nafallo> mjg59: have no idea yet, but it would be damn nifty :-)
[11:48] <carlos> time to leave, see you later
[11:50] <Nafallo> stealing one core, bringing me CPU to 100% scaling and 54C isn't really good...
[11:50] <seb128> Nafallo: is it chocking on a file maybe?
[11:50] <seb128> Nafallo: look at the running processus?
[11:51] <Nafallo> hmm
[11:51] <Fujitsu> I also noe that it didn't respond to SIGTERM when I tried to get rid of it.
[11:52] <Fujitsu> *note
[11:53] <Nafallo> ehrm... should `lsof | grep tracker` show /usr/share/locale-langpack stuff?
[11:53] <Nafallo> I thought it would be in my homedir, not on the whole system
[11:53] <seb128> Nafallo: yes, you can try with other applications as well they do the same
[11:55] <Nafallo> hmm
[11:55] <Nafallo> .evolution. my INBOX/summary.
[11:56] <Nafallo> that should not bring the systems to it's knes though. can't be more then 15k mails...
[11:56] <mjg59> Nafallo: tracker will have langpack stuff open in order to allow its messages to be localised
[11:57] <Nafallo> mjg59: including rhythmbox.mo, eog.mo, serpentine.mo?
[11:57] <mjg59> Nafallo: Oh, interesting. No clue in that case (and I don't see it here)
[11:58] <Nafallo> hal, rhythmbox, eog, update-manager, gnome-control-center-2.0, serpentine...
[11:58] <Nafallo> gnome-screensaver, glib20, tracker
[11:58] <Nafallo> I can understand the last two... ;-)
[11:59] <Nafallo> ofcourse they doesn't ship some debugtool...
[12:00] <seb128> Nafallo: you can install tracker-utils
[12:00] <Nafallo> ah, just noticed :-)
[12:00] <Fujitsu> Or run trackerd with -v.
[12:01] <Nafallo> mjg59: I love that thinkfinger btw. we should have it OOTB in next release ;-)
[12:02] <slangasek> bdmurray: bug #105682 - do we know the minimum memory requirement yet for LiveCD?
[12:02] <ubotu> Launchpad bug 105682 in casper "[gutsy]  Tribe 5 amd64 needs more than 256MB of memory" [Medium,Confirmed]  https://launchpad.net/bugs/105682
[12:04] <cjwatson> slangasek: the CD sleeves had to be finalised before beta, and we've put 384MB on them
[12:04] <ogra> slangasek, it should still be 256M, the problem is shared vide ram here
[12:04] <cjwatson> ogra: that's not clear
[12:04] <ogra> at least i can install on 256M virtual machines here
[12:04] <cjwatson> on the basis that if we had to blow past 256MB, going to 384MB wasn't much worse than 320MB
[12:04] <ogra> with no probs ... (just slowness)
[12:04] <slangasek> cjwatson: hum, ok. move to "wontfix"?
[12:04] <cjwatson> slangasek: well. I'd like to fix it for hardy ...
[12:05] <slangasek> ok
[12:05] <slangasek> but for now it's not a milestoner
[12:05] <cjwatson> right
[12:06] <cjwatson> ogra: that's good to know, but it's pretty close to the wire and I think things like having firefox running are enough to push it over
[12:06] <cjwatson> which is pretty hard to explain to users
[12:07] <ogra> cjwatson, yeah, if i install on one of my thin clients with shared video ram it usually drops to 192M free ram or so that doesnt work
[12:07] <ogra> (some of the via ones i have haven no acessible BIOS to change the values)
[12:08] <cjwatson> humph, where did my post to the unionfs list go
[12:08] <StevenK> cjwatson: It's waiting for another post to link it to.
[12:08] <cjwatson> hah
[12:08] <StevenK> :-)
[12:10] <slangasek> nah, unionfs has changed to strikefs for the day in solidarity with the DeutscheBahn workers
[12:10] <ogra> LOL
[12:11] <StevenK> Muahahaha
[12:13] <Fujitsu> Nafallo: Running it with -v 3 or so tells you what it's doing.
[12:14] <Nafallo> Fujitsu: that would mean I have to kill it, and from what I've seen so far I don't want to risk another re-index ;-)
[12:14] <slangasek> pitti: how's the size on amd64 CDs at this point? (bug #134565)
[12:14] <ubotu> Launchpad bug 134565 in ubuntu-meta "[tribe 5]  The installation CD does not contain full support for your language? (english-us dvorak)" [Medium,Confirmed]  https://launchpad.net/bugs/134565
[12:14] <Fujitsu> Nafallo: True.
[12:16] <Nafallo> Fujitsu: any idea where it logs stuff if I bump -v in the conf?
[12:16] <Fujitsu> Nafallo: No idea.
[12:16] <Fujitsu> Probably still to stdout, so probably /dev/null.
[12:17] <Nafallo> yea. a bit silly.
[12:17] <pitti> slangasek: almost full; I had a look at putting it back yesterday, but it's still overflown
[12:17] <pitti> slangasek: erm, I mean, it would be if we put it back
[12:17] <slangasek> right
[12:17] <pitti> slangasek: ATM I think we should look into OO.o downsizing
[12:17] <pitti> slangasek: in particular, sanely drop ooo-base from the CDs and keep out lots of Java stuff that comes with it
[12:18] <slangasek> could I assign this bug to you then?
[12:18] <slangasek> hmm, does dropping portaudio out of OOo make much of a size difference? (bug #140673)
[12:18] <ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
[12:18] <TheMuso> slangasek: No, as there will be a version of portaudio around on the disk, for espeak's use.
[12:18] <pitti> slangasek: nope, 40KB or so
[12:25] <slangasek> TheMuso: ah, didn't realize it was there already, ok
[12:25] <slangasek> pitti: so how much do we have to trim?
[12:25] <slangasek> (to fit lang-mumble-en back on)
[12:25] <ogra> cjwatson, will bug #22930 be fixed in libgtk or do you only work around it in ubiquity ?
[12:25] <ubotu> Launchpad bug 22930 in gtk+2.0 "Newly-sensitive button ignores clicks until cursor re-enters it" [High,Confirmed]  https://launchpad.net/bugs/22930
[12:26] <cjwatson> ogra: I've worked around it
[12:26] <ogra> i imagine just fixing up the button click events centralized would make sense
[12:26] <pitti> slangasek: 20.3 MB
[12:26] <cjwatson> ogra: look at the upstream bug, it's nowhere near that simple
[12:26] <ogra> hmm :/
[12:26] <pitti> slangasek: that would be the full language-support-en; we can just install subsets, of course
[12:26] <cjwatson> 110 comments and counting with a substantial design discussion
[12:27] <cjwatson> ogra: and yes, it would make sense; however I don't know about you but I don't feel like overriding the design judgement of GTK+ upstream
[12:27] <slangasek> pitti: so what's needed to make the dropping of ooo-base "sane"?
[12:27] <cjwatson> :-)
[12:27] <ogra> indeed, we wont fix the design now ...
[12:28] <[miles] > hi
[12:28] <ogra> i was more thinking about a general wrapper function
[12:28] <pitti> slangasek: calc has details, but one thing I know of is to make writer say "please install -base" isntead of crashing when you try to open the bibliogrpahy
[12:28] <slangasek> oh fun
[12:28] <ogra> but i'm not much enough into gtk to judge it ...
[12:28] <[miles] > I'm using kvm-45 and doing a boot on a ubuntu kernel image and initrd (off the CD), as /usr/local/kvm-45/bin/qemu-system-x86_64 -m 384 -hda gusty.img -cdrom /home/miles/Documents/isos/xubuntu-7.04-alternate-i386.iso -kernel /mnt/install/vmlinuz -initrd /mnt/install/initrd.gz -append "framebuffer=false" -std-vga
[12:29] <[miles] > but it seems to ignore the append ....
[12:29] <\sh> pitti, keescook , jdstrand : could you review #129771 and upload?
[12:29] <[miles] > I actually need vga=791
[12:29] <[miles] > or similar
[12:29] <[miles] > when booting the vmlinuz can I not use the same options as I would if I was booting from the menu?
[12:31] <pitti> siretart: I updated bug 144390 with new data after testing the current daily alternate
[12:31] <ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [High,Confirmed]  https://launchpad.net/bugs/144390
[12:32] <Nafallo> jamiemcc: hi. are you here? I'm seeing oddities.
[12:32] <pitti> slangasek: 20.3 MB is at least what apt-get install l-s-en wants to download on a freshly installed amd64 alternate
[12:33] <[miles] > -append "install fbcon vga=791"
[12:33] <[miles] > that neither
[12:33] <[miles] > :-\
[12:33] <pitti> slangasek: to be a 100% sure, I could just put it back and create new alternate images, so that we'll see what is left (some packages are already pulled in as dependencies of other packages, I figure)
[12:33] <pitti> slangasek: doing that now
[12:34] <slangasek> pitti: ok. and is alternate as full as Live?
[12:34] <siretart> pitti: can I see somewhere which version of partman-crypto is on the alternate cd installed?
[12:34] <pitti> slangasek: traditionally, alternate has more pressing space problems
[12:34] <slangasek> ok then
[12:34] <pitti> siretart: yes, in the .list files on cdimage
[12:34] <pitti> siretart: however, I already checked that it is current
[12:35] <siretart> pitti: and is /dev/mapper/ubuntu-root an LVM? didn't we agree that LVMs must not be UUID mangled?
[12:35] <jamiemcc> Nafallo: hi whats up?
[12:35] <siretart> wait. there is more fishy.. hmm
[12:35] <pitti> siretart: yes, it is; sda5 is an encrypted partition with an LVM on it (swap and root)
[12:35] <pitti> siretart: right, the udev update was supposed to not use UUIDs for lvm devices in fstab, AFAIUI
[12:36] <Nafallo> jamiemcc: trackerd steals one of my cores at 100%, setting the cpufreq to 100% and temp to 54C. I'm trying to figure out why :-)
[12:36] <siretart> pitti: hm. it would have worked if you wouldn't have named the LV ubuntu-root, but ubuntu-root_crypt
[12:36] <cjwatson> ogra: not a good plan IMO
[12:36] <pitti> siretart: maybe, but I didn't name them
[12:36] <Nafallo> jamiemcc: tracker-status says indexing, attaching strace only shows LOTS of open("/proc/acpi/ac_adapter/AC/state", O_RDONLY|O_LARGEFILE) = 39
[12:36] <siretart> cjwatson: is there some what we can enforce that naming?
[12:36] <pitti> siretart: it's what partman-auto-crypt chose
[12:37] <siretart> pitti: I see. I'd suggest then to fix partman-auto-crypt then..
[12:37] <pitti> siretart: and we don't want to generally disable using UUIDs for LVM LVs?
[12:37] <siretart> pitti: was that a statement or question?
[12:37] <pitti> well, I figure the labels are much less unique than an UUID
[12:37] <pitti> two parallel Ubuntu installations would clash
[12:37] <pitti> siretart: a question, but I think I  just answered it myself
[12:38] <cjwatson> siretart: um, if detecting it by name is unreliable then perhaps there's a better way
[12:38] <slangasek> pitti: can the kernel successfully handle two VGs/LVs with identical names, anyway?
[12:38] <siretart> what really fishy here is this:
[12:39] <slangasek> (it would certainly be a pain to manage after the fact...!)
[12:39] <pitti> slangasek: hm, I guess not
[12:39] <siretart> the /etc/fstab was mangled from /dev/mapper/ubuntu-root to UUID, while according to /etc/cryptab, it should be /dev/mapper/sda5_crypt
[12:39] <cjwatson> siretart: how about checking for the existence of the crypt_active file in partman's devices directory?
[12:39] <pitti> slangasek: and I hope that the autopartitioner checks if a name is already present
[12:40] <siretart> cjwatson: I didn't really understand yet how partman works in total. - need to look further at it
[12:40] <cjwatson> though it does seem odd that the device isn't _crypt; partman-crypto seems to enforce that in some places at least
[12:41] <pitti> well, the LV is *not* encrypted
[12:41] <pitti> that might confuse it
[12:41] <pitti> the PV is
[12:41] <siretart> oh
[12:41] <pitti> sda5 is a LUKS encrypted device which hosts the entire LVM
[12:41] <siretart> good point
[12:41] <pitti> and within that LVM there are just normal LVs
[12:41] <siretart> pitti: how did you manage to boot the system then?
[12:42] <pitti> i. e. from LVM's standpoint, not even the PV is encrypted
[12:42] <pitti> siretart: just with the workaround mentioned in the bug: calling cryptsetup manually
[12:42] <pitti> siretart: with this setup you already need to enter the passphrase during initramfs time, of course
[12:42] <siretart> ok
[12:42] <pitti> it's just a bit silly that the init script asks for it again
[12:42] <Whoopie> Nafallo: the open("/proc/acpi/ac_adapter/AC/state") is a new feature that disables indexing while on battery.
[12:43] <siretart> ok, so probably partman-crypto is fine then, and perhaps only the cryptroot hook that's broken
[12:43] <TheMuso> ogra: Re edubuntu and accessibility/speech etc, as you said, portaudio isn't capable of whats required, and as it is, we have to go back to v18, due to some headaches v19 is causing. I'm hoping to spearhead some movement towards using something more uniform upstream, relating to how gnome-speech works. Either that, or Orca may use a different speech framework in the future. Either way, I'd like to keep the thin client framework in mind.
[12:44] <Nafallo> Whoopie: I know. I was more amazed at the one per second poll ;-)
[12:44] <ogra> TheMuso, well, if it would use the libasound2-plugins stuff that would suffice already for thin clients
[12:45] <TheMuso> ogra: Right. I'm actually trying to push for a nice way for users to select which sound device is used for speech from the sound preferences.
[12:45] <TheMuso> Or something along those lines.
[12:45] <Whoopie> Nafallo: oh, that's quite counterproductive for battery saving ;) if it's also polling 1 per sec on battery.
[12:46] <ogra> TheMuso, i suspect it reads /proc/asound/cards somehow instead of leaving that kind of stuff to alsa
[12:46] <ogra> TheMuso, the virtual cards dont show up there
[12:46] <Nafallo> Whoopie: didn't come that far ;-)
[12:46] <ogra> we have a similar prob with kmix
[12:46] <siretart> pitti: do you have the system still around and can do some tests for me?
[12:46] <TheMuso> ogra: Right, nice to know, as I'd really like to get this done properly.
[12:46] <pitti> siretart: I do
[12:46] <pitti> siretart: yeah, happy to
[12:47] <TheMuso> Its not right that thin clients miss out, particularly when accessibility is a big thing for education.
[12:47] <ogra> yeah
[12:48] <ogra> i would have at least esound support or something ... we have not many apps in ltsp that dont work since the sound system was switched
[12:48] <TheMuso> Luckily, just about all hardware synths support callbacks, passing audio data directly back to the calling app, so its just a matter of making this all easy for the user.
[12:48] <siretart> pitti: first please look at this file: http://codebrowse.launchpad.net/~ubuntu-core-dev/cryptsetup/ubuntu/annotate/siretart%40tauware.de-20070927173931-61pmahu54rhwhjri?file_id=readme.ubuntu-20070908164419-gq3j3r0yhc0bkymq-1
[12:48] <ogra> s/have/have expected/
[12:48] <siretart> the first tweak is in /etc/lvm/lvm.conf, please add a types line like in that file
[12:48] <siretart> please check if the system boots with that change only
[12:48] <mjg59> jamiemcc: If you don't have time to switch to using hal to determine battery events before release, could you change the g_timeout_add to g_timeout_add_seconds?
[12:48] <pitti> siretart: booting... (it takes a while due to the 60 second timeout until I get the initramfs shell)
[12:48] <TheMuso> ogra: I don't know whats planned at this point, but all I can do is keeep you posted about upstream's plans speech wise.
[12:49] <siretart> pitti: you can shorten the timeout
[12:49] <jamiemcc> mjg59: we use libhal in svn
[12:49] <siretart> pitti: use rootdelay=10 for a 10 sek timout
[12:49] <ogra> TheMuso,  that wuld be nice
[12:49] <pitti> siretart: ah
[12:49] <mjg59> jamiemcc: And that's going to make final?
[12:49] <jamiemcc> we will release in next few days along with bug fixes and applet
[12:49] <mjg59> bryce: Any chance of a fix in dexconf?
[12:50] <siretart> pitti: if the lvm.conf change isn't enough, please also adapt /etc/crypttab like in the README.ubuntu
[12:50] <mjg59> bryce: Rather than disabling horizontal edge scrolling with HorizScrollDelta, it should be using HorizEdgeScroll
[12:51] <pitti> siretart: update-initramfs after changing lvm.conf?
[12:51] <siretart> pitti: yes
[12:52] <pitti> siretart: not sure whether that lvm.conf change makes sense; after all, I only need to cryptsetup luksOpen in initramfs; as soon as I do that, /dev/mapper/ubuntu-root etc. is created automatically
[12:52] <siretart> pitti: you have a point somewhere
[12:53] <siretart> pitti: perhaps the 2nd change is the important one then? 'lvm=sys-root'?
[12:53] <pitti> trying
[12:56] <siretart> pitti: it should be this for you, I think: "sda5_crypt /dev/disk/by-uuid/cfb63807-6da8-4dc9-93da-892e336c2fb7 none luks,lvm=ubuntu-root"
[12:57] <pitti> siretart: that's what I added
[12:57] <pitti> siretart: I updated initramfs, booting now
[12:58] <pitti> siretart: it didn't help, and it would have been surprising, too
[12:58] <pitti> siretart: after all, the initramfs cannot see *anything* LVMish at all until it luksOpens sda5
[12:58] <siretart> pitti: okay. did you edit /etc/crypttab as well?
[12:59] <siretart> read, append ',lvm=ubuntu-root'?
[12:59] <pitti> ATM, root=/dev/mapper/ubuntu-root, but nothing tells the initramfs that this is actually on /dev/sda5?
[12:59] <pitti> siretart: yes, that's what I did
[12:59] <pitti> siretart: oh, I didn't do the lvm.conf change
[12:59] <siretart> ok
[12:59] <pitti> siretart: but crypttab is not in the initramfs
[01:00] <siretart> not as crypttab, but it shoudl be as /conf/cryproot.conf or something
[01:00] <pitti> siretart: does the initramfs script have code to invoke luksOpen and thus ask for the password?
[01:00] <pitti>  /conf/conf.d/cryptsetup just has "KEYMAP=y"
[01:00] <siretart> err, sure. thats the point of the cryptroot hook
[01:01] <siretart> ok, this means the cryptroot-hook didn't find the root volume then
[01:01] <siretart> I need to look deeper in the cryptroot hook then, perhaps the output of dmsetup looks different in ubuntu to debian or something
[01:01] <pitti> siretart: shall I try mangling fstab to use /dev/mapper names instead of UUIDs?
[01:02] <pitti> Fujitsu: no UUIDs in Debian
[01:02] <Fujitsu> pitti: Ah, that'd do it.
[01:02] <pitti> siretart: trying
[01:03] <pitti> slangasek: http://cdimage.ubuntu.com/daily/20071002.1/
[01:03] <pitti> slangasek: so yes, we indeed need 20.3 MB
[01:03] <slangasek> ok
[01:03] <siretart> try it, but I haven't understood yet how the cryptroot hook is supposed to find a crypted pv
[01:04] <pitti> slangasek: I wonder why it is so much bigger than the i386 one...
[01:05] <slangasek> pitti: because every pointer or long takes up twice as much space in each binary? :)
[01:06] <pitti> slangasek: well, yes, but I don't remember that the size differences were that drastic
[01:06] <StevenK> I thought devmapper names weren't UUID-converted ...?
[01:06] <pitti> slangasek: hm, it just occured to me: traditionally the i386 alternate had much more language pack stuff on it
[01:06] <pitti> StevenK: apparently they are
[01:07] <siretart> StevenK: I'm surprised, too
[01:08] <slangasek> pitti: looks like a 2% difference in size between amd64 and i386 alternate, that doesn't seem out of line with what I'm familiar with
[01:08] <pitti> siretart: oh, update-initramfs complains about "invalid line in cryptsetup"
[01:08] <seb128> StevenK: could you look at bug #148049? That has been introduced with your update
[01:08] <ubotu> Launchpad bug 148049 in gimp "[Gutsy]  Please, add the 'X-Ubuntu-Gettext-Domain=gimp20' line into the .desktop file" [Undecided,New]  https://launchpad.net/bugs/148049
[01:08] <pitti> slangasek: right; it's just because gutsy is the first release without any langpacks on the alternates
[01:08] <pitti> yay @ growth
[01:08] <slangasek> (hey, at least it's not alpha, which is 64-bit /and/ RISC instruction set... :)
[01:08] <siretart> pitti: that'll be the bug
[01:09] <siretart> pitti: I'm currently installing a similar system on real hardware right now, but that will take some time (a few hours, I'd expect)
[01:09] <pitti> siretart: ah, in the recipe you gave me, the crypttab line mentions the real HW partition, I think
[01:09] <StevenK> seb128: Shall do.
[01:09] <seb128> StevenK: thanks
[01:09] <asac> siretart: ... what kind of integration of NM/wpasupplicant do you mean?
[01:11] <pitti> siretart: hm, it still considers "sda5_crypt /dev/sda5 none luks,lvm=ubuntu-root" as invalid
[01:13] <slangasek> pitti: what's the 'lvm=' option for?
[01:14] <pitti> slangasek: just following the recipe on http://codebrowse.launchpad.net/~ubuntu-core-dev/cryptsetup/ubuntu/annotate/siretart%40tauware.de-20070927173931-61pmahu54rhwhjri?file_id=readme.ubuntu-20070908164419-gq3j3r0yhc0bkymq-1
[01:15] <siretart> asac: I had a strange behavior before: I moved to my office, where I have wired, and no wireless
[01:15] <siretart> asac: so I switched the wifi kill switch on
[01:15] <siretart> asac: NM was complaining in daemon.log that it couldn't scan, and wouldn't use my wired interface
[01:15] <siretart> asac: however, it was complaining that wpasupplicant wouldn't respond. no suprise, since there was no wpa_supplicant daemon running
[01:16] <siretart> asac: ah, that was right after a resume
[01:16] <siretart> asac: my question now is: why doesn't nm detect that there is no wpa_supplicant running anymore?
[01:17] <asac> siretart: good question ... why did wpasupplicant die in the first place?
[01:17] <slangasek> pitti: well, at least under Debian I had no need for an "lvm=" option in my crypttab, and it's not documented in crypttab(5)
[01:17] <slangasek> (incl. in gutsy)
[01:17] <pitti> right, trying to remove that now
[01:18] <pitti> WTH? It still complains about "sda5_crypt /dev/sda5 none luks"
[01:18] <asac> siretart: did it crash?
[01:20] <siretart> asac: I don't have a crashreport for it, but I'm not sure if it crashed or not
[01:21] <pitti> ah, it might stumble over the two different plaintext dm devices that I used: 'mylvm' in initramfs, and sda5_crypt in crypttab
[01:23] <asac> siretart: but suspend/resume usually works for you?
[01:24] <pitti> siretart: right, if I use "sda5_crypt" in the initramfs cryptsetup call, then I don't get asked again, and things seem to be a bit saner
[01:26] <pitti> siretart, slangasek: yay! works now
[01:26] <jono> are other people experiencing trackerd taking up the majority of CPU time?
[01:26] <jono> its hammering my system
[01:26] <pitti> ok, I'll reinstall the system from scratch, do a vmware snapshot this time, and investigate further
[01:26] <StevenK> jono: The queue starts over -----> there
[01:26] <jono> StevenK: right :)
[01:26] <TheMuso> StevenK: heh
[01:27] <StevenK> seb128: I see what's going on with gimp. Just firing off a test build.
[01:28] <pitti> siretart: wow, that even works with usplash now, although it's dark blue on black and hard to read
[01:29] <StevenK> pitti: Security through making you squint and guess?
[01:29] <pitti> StevenK: the entire initramfs scripts chain is still miraculous to me
[01:29] <StevenK> Hah
[01:30] <pitti> StevenK: well, it can't get more secure than in current gutsy - nobody *at all* can access the HD :)
[01:30] <StevenK> "So Martin, how does an Ubuntu system boot?" '*shrug* Magic!'
[01:30] <pitti> but I guess we should poke a hole for the legitimate user
[01:31] <Keybuk> StevenK: I have to keep some people in awe of me, otherwise everyone would be able to boot Ubuntu by hand and I'd need a new party trick
[01:31] <StevenK> Keybuk: :-)
[01:32] <Keybuk> (more seriously, I'm happy to answer to answer any questions you might have)
[01:32] <ogra> StevenK, Keybuk prepares for later ... if he once stops at canonical he'll sell support for upstart users ;) indeed that requires some eastereggs to generate enlough :)
[01:33] <StevenK> Bwahaha
[01:36] <siretart> pitti: what?!
[01:36] <Fujitsu> Wasn't the usplash patch dropped?
[01:36] <pitti> siretart: (just kidding with StevenK)
[01:36] <siretart> asac: suspend does work
[01:37] <siretart> pitti: so what's wrong in the end? what change is needed now?
[01:37] <pitti> siretart: hold on, I'll find it out and comment in the bug; new install is running (I screwed up too much without making proper backups, and I want to be sure)
[01:37] <ogra> siretart, lucky you ... i'd be happy if nm-applet would actually survive switching networks here
[01:37] <asac> siretart: do you still have the daemon.log of that incident?
[01:37] <pitti> siretart: I think we only need to put the right physical device into crypttab
[01:38] <asac> ogra: bug?
[01:38] <pitti> siretart: lvm.conf and even fstab might be just fine
[01:38] <pitti> siretart: it would be cool to leave the lvm UUIDs in fstab, just for general compatibilty with handling of non-LVM devices
[01:38] <asac> ogra: does nm crash? or applet?
[01:38] <ogra> asac, none yet, i just discovered that nm-applet doent want to connect to a new one if the network i'm currently connected to gets out of reach
[01:39] <pitti> siretart: just need to find out whether get_root_device() etc. in /usr/share/initramfs-tools/hooks/cryptroot get along with UUIDs
[01:39] <ogra> asac, after about 20 min manual fiddling with iwconfig i get online with the network i want but n then vanishes from the panel after some time
[01:39] <ogra> s/n/nm/
[01:39] <asac> ogra: can you show me your syslog?
[01:40] <ogra> ogra@laptop:~$ ps ax|grep nm
[01:40] <ogra> 22171 ?        S      0:00 nm-applet
[01:40] <ogra> btw ...
[01:40] <siretart> asac: http://paste.ubuntu.com/544/
[01:40] <ogra> it just doesnt show up
[01:40] <asac> ogra: thats likely because NetworkManager has crashed
[01:40] <siretart> pitti: yes, that function is critical here..
[01:40] <asac> ogra: please paste the log so i can verify
[01:41] <asac> siretart: ok is that reproducible?
[01:41] <siretart> asac: I'll investigate. right now I'm a t work, and have no wireless
[01:41] <asac> siretart: this might be fixed by patch in bug 145683
[01:41] <ubotu> Launchpad bug 145683 in network-manager "Network manager crash with WPA" [High,Incomplete]  https://launchpad.net/bugs/145683
[01:41] <ogra> asac, http://people.ubuntu.com/~ogra/nm-syslog
[01:42] <siretart> asac: I fixed it by manually restarting nm: /etc/dbus*/event.d/2{6,5} {stop,start}
[01:42] <asac> ogra: same for you: would be great if you could test patch from bug 145683
[01:42] <siretart> asac: the patch looks promising, indeed
[01:43] <ogra> i use WEP btw
[01:44] <siretart> pitti: with the right physical device, you men /dev/sda5 instead of /dev/disk/by-uuid/dead-beef-...?
[01:44] <pitti> siretart: it would be a step backwards, yes :/
[01:44] <pitti> siretart: I'll have a deeper look at those scripts
[01:45] <siretart> still installing my test machine
[01:45] <pitti> siretart: add_device() in the hook is responsible for translating crypttab and fstab into a /conf/conf.d/cryptroot option in the initramfs; if we could get that to work with UUIDs, we would have won
[01:45] <siretart> slangasek: how about introducing a new release goal for lenny: "make /etc/fstab use UUID by default"? ;)
[01:47] <siretart> pitti: yes, I was looking at that part before, but I abandoned it by rethinking the case. that's the part that assumes that /etc/fstab and /etc/crypttab are in sync
[01:47] <asac> ogra: siretart: just uploaded a test package with that patch to my ppa: https://edge.launchpad.net/~asac/+archive ... should show up there soon
[01:48] <asac> ogra: yes WEP or WPA doesn't make a difference ... both use wpasupplicant
[01:49] <ogra> asac, will test it, thanks
[01:54] <lamont> cjwatson: and yet I would guess that we're more likely to have dual-booters than debian...
[01:56] <seb128> pitti: what do you think about moving gimp-gnomevfs to the desktop seed?
[01:56] <pitti> indeed :)
[01:56] <soren> |<------->|  This big.
[01:57] <soren> (not to scale)
[01:57] <ogra> soren, at what DPI ?
[01:57] <pitti> 384 kB
[01:57] <soren> ogra: All of them.
[01:57] <ogra> whee
[01:57] <ogra> thats tiny then :)
[01:57] <soren> That's what she said :(
[01:57] <ogra> lol
[01:57] <pitti> well, given that we are 20 MB oversized, nothing is tiny
[01:57] <seb128> and most of it is NEWS and changelogs
[01:57] <soren> \o/
[01:58] <seb128> the plugin itself is 13k
[01:58] <cjwatson> lamont: Ted is mistaken if he thinks I ever claimed this wasn't a bug
[01:58] <cjwatson> he is simply confusing "haven't done it yet" with "refuse to do it"
[01:59] <asac> pitti: are we really going to release oversized?
[01:59] <cjwatson> asac: no
[01:59] <lamont> cjwatson: ah, ok
[01:59] <seb128> pitti: bug #146290 for some context
[01:59] <pitti> asac: of course not; we'll need to chop off some things from OO.o
[01:59] <ubotu> Launchpad bug 146290 in gimp "gimp "open from url" doesn't work" [Low,Triaged]  https://launchpad.net/bugs/146290
[01:59] <cjwatson> asac: oversizedness (at least of certain images) is a release blocker and MUST be fixed
[01:59] <ogra> asac, we'Re working on it, but the bad pitti always interferes
[02:00] <pitti> Also, we could take off language-support-en from amd64 alternate again
[02:00] <asac> cjwatson: yes ... i hoped so. Was just a bit confused
[02:00] <lamont> cjwatson: so does that mean that there will need to be an upload that adds back in hwclockfirst.sh?
[02:00] <pitti> I just added it because usually we'd want it to be there
[02:00] <cjwatson> lamont: I don't understand
[02:03] <seb128> pitti: so about gimp-gnomevfs?
[02:04] <pitti> seb128: TBH I'd put a ban on seed additions until we sort out the existing overflow
[02:04] <seb128> ok
[02:04] <pitti> also, we are well past FF and everything
[02:04] <seb128> pitti: well, that's a binary from the gimp source
[02:05] <seb128> and it'll create regressions on upgrade
[02:05] <seb128> it was not splitted in feisty
[02:05] <seb128> opening a location
[02:06] <seb128> or clicking on an image from nautilus in a non local directory will not work
[02:06] <lamont> cjwatson: hwclockfirst is setting the clock according to UTC prior to mounting root, so that fsck isn't b0rked wrt mounting it.
[02:06] <seb128> which is something users probably expect to work correctly
[02:06] <lamont> specifically, users east of Greenwich, who keep BIOS in localtime (because of dual boot), are the affected class.
[02:07] <jdstrand> \sh thanks for the debdiff for #129771
[02:07] <cjwatson> lamont: I don't understand enough of this (by which I mean I don't have enough state because I haven't spent enough time with it) to claim anything with certainty. Somebody who does understand it needs to propose the correct fixes, which may or may not involve installer changes (although new UI is out of the question at this point).
[02:08] <cjwatson> lamont: but anyone asking me what to do about this issue is on a hiding to nothing. :-)
[02:09] <Whoopie> asac: Hi, latest update to network-manager-openvpn breaks my VPN. I get :"Oct  2 12:47:41 gutsy nm-openvpn[3523] : script failed: shell command exited with error status: 139" in syslog. Any ideas?
[02:10] <Whoopie> seb128: could we fix bug 144122? I could make a patch if needed.
[02:10] <ubotu> Launchpad bug 144122 in pidgin "Pidgin 2.2.0 Forgets Plugin Selections (Ubuntu Gusty x86 Tribe 5)" [Undecided,New]  https://launchpad.net/bugs/144122
[02:11] <seb128> Whoopie: could you summarize the issue, I'm sort of busy and the comments go on several pages there
[02:12] <Whoopie> seb128: sure, let me make a patch. It's a two-liner. problem is in the default prefs.xml.
[02:13] <asac> Whoopie: maybe ask pkern who uploaded the last update
[02:14] <asac> Whoopie: and open a bug
[02:15] <asac> Whoopie: #147941 looks like your bug
[02:17] <Whoopie> seb128: http://en.pastebin.ca/722882
[02:17] <Whoopie> seb128: type must be changed to "pathlist" and the docklet doesn't exist anymore.
[02:18] <Whoopie> asac: ah, right. thanks
[02:21] <StevenK> seb128: gimp fixed, I'll upload shortly.
[02:21] <seb128> StevenK: thanks
[02:21] <lamont> cjwatson: without the "UTC or local" quesiton in ubiquity/gutsy, we're looking at hardy to fix the issue for ubuntu --> no need to upload a new util-linux at this point;
[02:22] <cjwatson> lamont: I've added it to my UDS agenda in progress
[02:23] <cjwatson> lamont: can't we make it better for those east of Greenwich all the same?
[02:23] <cjwatson> lamont: actually, bear in mind that d-i often still does ask the UTC/local question
[02:23] <lamont> cjwatson: ok.  with the question, it's a trivial fix (add hwclockfirst.sh back in - already done for debian, just need to stop dropping that change on merge...
[02:23] <cjwatson> lamont: so given that that's there, can we do better for d-i?
[02:24] <lamont> ah, ok
[02:24] <lamont> if the question is there, then we can certainly do better for those who were able to answer 'local' (those saying 'UTC' already win)
[02:24] <cjwatson> in fact, our d-i asks the question under slightly *more* circumstances than Debian does
[02:25] <cjwatson> we ask it (defaulting to UTC) even if we appear to be the only OS on the system
[02:25] <cjwatson> cf. bug 28961
[02:25] <ubotu> Launchpad bug 28961 in clock-setup "installer assumes system time is UTC" [High,Fix released]  https://launchpad.net/bugs/28961
[02:25] <lamont> so.. the question the becomes: after reviewing the change log for 2.13-8 in incoming, would you prefer -6ubuntu2, or -8ubuntu1 ?
[02:26] <pkern> I got an apport crash dump and I need a retrace. apport-retrace chokes on me, what should I do?
[02:26] <cjwatson>      - mount: doesn't drop privileges properly when calling helpers
[02:26] <cjwatson> lamont: is that a security issue?
[02:26] <cjwatson> lamont: anyway, release team's call
[02:26] <lamont> doh
[02:27] <lamont> -		 setuid(getuid());
[02:27] <lamont> -		 setgid(getgid());
[02:27] <lamont> +		 if(setgid(getgid()) < 0)
[02:27] <lamont> +			 die(EX_FAIL, _("mount: cannot set group id: %s"), strerror(errno));
[02:27] <lamont> could be.
[02:27] <lamont> (there's more, chopped for brevity)
[02:28] <lamont>     {,u}mount calls setuid() and setgid() in the wrong order and doesn't checking
[02:28] <lamont>     the return value of set{u,g}id(() when running helpers like mount.nfs.
[02:28] <lamont> for the longer commit comment part
[02:28] <lamont> we probably want that one...
[02:33] <\sh> jdstrand, np
[02:42] <pkern> pitti: How could I file a bug having only a .crash file for a different architecture to request a retrace?
[02:47] <pitti> pkern: Can you please try /usr/share/apport/apport-gtk -c /path/to/crash/file?
[02:47] <Whoopie> pkern: Hi, just fyi, I'm also affected by latest nm-openvpn update. If you need any testing...
[02:47] <pitti> pkern: it might complain about a few things, the tag will be wrong, and the backtrace entirely unusable, but once we fix the need-$arch-retrace tag, things should work
[02:49] <Kopfgeldjaeger> hi
[02:49] <seb128> Whoopie: thanks for the patch, I've uploaded a new package revision with it now
[02:50] <pkern> pitti: apport-cli refuses to work (see https://bugs.edge.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/148088)
[02:50] <ubotu> Launchpad bug 148088 in network-manager-openvpn "[apport]  need retrace" [Undecided,Invalid] 
[02:50] <pkern> pitti: i.e. it reports a bug but does not attach s.th. sensible
[02:51] <pkern> And apport-gtk reports "obsolete" packages (for which I have reported a seperate bug...)
[02:51] <pitti> pkern: that does not have a core dump, hmm
[02:51] <pitti> pkern: obsolete packages> hm, that's kind of a feature
[02:51] <pkern> pitti: But I need an override for this.
[02:51] <pkern> pitti: My gutsy is current.
[02:51] <pitti> pkern: you cannot retrace the crash file on the system where it crashed?
[02:52] <pitti> pkern: oh, I almost forgot: congratulations for becoming an official dev!
[02:52] <pkern> pitti: I got it submitted via a bugreport. They were vary because of private information (but then still posted it... meh.)
[02:52] <pkern> pitti: Thank you. (:
[02:52] <pitti> ah
[02:52] <pitti> pkern: which arch?
[02:52] <pkern> pitti: i386
[02:53] <pitti> pkern: so someone on i386 could just manually use apport-retrace on the crash file
[02:53] <pkern> pitti: ACK
[02:54] <Whoopie> seb128: great, thanks!
[02:54] <seb128> Whoopie: thank you for working on the patch ;)
[02:54] <pkern> *debootstrap --arch i386 gutsy /opt/gutsy-i386 http://de.archive.ubuntu.com/ubuntu*
[03:00] <jdstrand> pitti: re bug #119075
[03:00] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[03:00] <jdstrand> pitti: what are your thoughts on a retroactive fix back to dapper?
[03:00] <pitti> jdstrand: so, the root of all evil from what I can see, is that mysql needs a root password in the first place
[03:00] <jdstrand> pitti: yes
[03:01] <pitti> jdstrand: so the Debian packages both set a root password and also install this weird system user which somehow circumvents the auth mechanism for upgrades, etc. (not sure about the details)
[03:01] <jdstrand> pitti: and dapper through feisty one is not created, as the user is never prompted
[03:02] <pitti> jdstrand: I'm not so sure about a retroactive fix; once this is set up, it's hard to upgrade that setup to a new system
[03:02] <jdstrand> pitti: I haven't gone through all the debconf in great depth, but feisty has a mechanism to get the password
[03:02] <pitti> but for new installations that shuold be fixed
[03:02] <jdstrand> pitti: it just never happens
[03:02] <jdstrand> pitti: dapper has only a note about needing to set it, but it is never seen
[03:02] <pitti> jdstrand: so for dapper to feisty we should just reactivate the root pw question, I think
[03:02] <pitti> jdstrand: and for hardy I think that the root pw should disappear entirely
[03:03] <pitti> jdstrand: and instead the daemon should allow passwordless connections from the root user
[03:03] <pitti> jdstrand: since root can mangle all the db files anyway
[03:03] <pitti> lamont: out of interest, why don't give-backs work?
[03:04] <jdstrand> pitti: re hardy, that is fine by me, assuming it doesn't introduce any other problems, but those can be ironed out
[03:04] <lamont> pitti: no build record.  go launchpad
[03:04] <pitti> jdstrand: I just envision "allow root without password" (with unix socket peer credential checking), drop that system user, don't set a root password; simple and robust IMHO
[03:04] <jdstrand> pitti: my concern for now is dealing with existing and new installations on releases (and possibly gutsy-- haven't looked at it yet)
[03:04] <lamont> OTOH, if we're lucky, we'll get the fix in LP shortly.
[03:05] <pitti> jdstrand: for those, I think we should just appropriately bump the debconf questino priority so that it will actually be seen
[03:05] <lamont> these uploads get us debootstrapability
[03:05] <jdstrand> pitti: it may be more complicated than that in feisty-- I think there may be a timing issue of when mysql is started and the passwordless check is made
[03:06] <jdstrand> pitti: but bottom line is that you think that new installs should be fixed, and existing should not be touched, correct?
[03:06] <pitti> jdstrand: hm; sorry, I never actually used mysql, so I'm not sure about the details
[03:06] <pitti> jdstrand: well, if we can fix existing passwordless installations in a sane way, I'm all for it
[03:06] <jdstrand> pitti: I am only just diving into the issue myself
[03:07] <jdstrand> pitti: alright.  as you know, I have several mysql updates anyway.  so I'll work on it, submit for peer review, and roll it into those updates if appropriate
[03:08] <pitti> jdstrand: thanks; I'm happy to take a look at the patches; keescook will be as well, I figure
[03:08] <pitti> jdstrand: soren also already looked into those packages, he might have some ideas in his head still
[03:08] <jdstrand> pitti: thanks.  yes keescook is always helpful.
[03:10] <pitti> jdstrand: thanks for looking into that long-standing wart
[03:10] <jdstrand> soren: re bug #119075.  I'd like to retroactively fix the passwordless root user issue.  Thoughts?
[03:10] <jdstrand> pitti: np
[03:10] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[03:12] <siretart> pitti: did you mean before that all what's necessary is to fix the 2nd column in /etc/crypttab?
[03:23] <superm1> mvo, you here?
[03:31] <mvo> superm1: yes
[03:31] <superm1> hi mvo, just wanted to touch bases with you regarding our discussion last week
[03:32] <superm1> i checked our old disk (from around 08-30), and it had an older python-apt installed when it was functional
[03:32] <mvo> superm1: nothing new from my side unfortunately. could you please check what version of python-apt was installed so that I can review the debdiff?
[03:32] <superm1> so i upgraded python-apt after it booted and upgraded ubiquity to current, and the stalling problem didn't appear to occur
[03:33] <superm1> so i was leaning towards it indeed being unionfs related
[03:33] <glatzor> ping bryce
[03:34] <superm1> mvo, you were however saying that the cache.open(None) call probably wasn't necessary at that point anyhow though, correct?
[03:35] <mvo> superm1: if it is only used to check for broken packages, then no, that will be detected during the installation and InstallProgress.error() is called
[03:37] <superm1> mvo, well i think i'll just do a ppa build of ubiquity with those disabled, and discuss further with cjwatson before committing it to trunk.  i can at least release the beta disk with the ppa/ubiquity then
[03:38] <StevenK> pitti: So, I'm going to look at getting the -mobile stuff promoted from universe to main - I had a few questions, have you got a few seconds?
[03:40] <soren> pitti, jdstrand: I don't think it's a very good idea to change the priority of the debconf question in dapper->feisty.
[03:41] <soren> pitti, jdstrand: It could potentially automatic install procedures people have set up.
[03:42] <soren> pitti, jdstrand: Er... It potentially *break* ...
[03:43] <jdstrand> soren: right.  IMO this a serious problem though, and a fix needs to be done.  Yur argument, while valid, would really mean we have no way to retroactively fix the problem
[03:43] <jdstrand> soren: because no matter what we do, we will change the process
[03:43] <soren> jdstrand: "the problem" is bug #119075 ?
[03:43] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[03:43] <jdstrand> s/process/install process/
[03:43] <soren> jdstrand: I'm a bit short of context here..
[03:44] <jdstrand> soren: yes.  the 'problem' is that all dapper-feisty (and maybe gutsy) installs default to passwordless mysql root user.  any local user can simply do 'mysql -u root -p', press enter and have full access to the db
[03:45] <jdstrand> soren: remote users could get to that via scripts too
[03:45] <soren> jdstrand: I know, I know.
[03:45] <soren> I have a patch that fixes this differently, though.
[03:45] <jdstrand> soren: do tell
[03:46] <soren> pitti rejected it at first, but given we don't have time for the "right" solution, it might make sense anyhow.
[03:46] <soren> gah.. phone call.
[03:46] <soren> back
[03:47] <soren> It (ab)uses the debian-sys-maint user to implement a "/etc/init.d/mysql reset_passwd" kind of thing.
[03:47] <soren> I don't recall the details.. I'll find it. Hang on.
[03:51] <soren> found it. Hang on, I'll upload it somewhere.
[03:53] <soren> http://people.ubuntu.com/~soren/mysql_rootpw_draft_fix.diff
[03:53] <jdstrand> soren: reading...
[03:57] <jdstrand> soren, pitti: why was it rejected? (I'll admit that it is a little odd that configuration is happening in sysv, but might be worth another look for a retroactive fix)
[04:02] <jdstrand> soren: it seems mysql will not start if /etc/mysql/warn_on_startup exists
[04:03] <dholbach> calc: bug 135086?
[04:03] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
[04:03] <jdstrand> soren: that would need to change
[04:03] <dholbach> Riddell: bug 136425, bug 121872?
[04:03] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
[04:03] <ubotu> Launchpad bug 121872 in qt4-x11 "*-qt4 tools should be present in $QTDIR/bin" [Undecided,In progress]  https://launchpad.net/bugs/121872
[04:03] <soren> jdstrand: True, that seems to be the case now.
[04:03] <jdstrand> soren: but the basic idea of setting a random password and letting the users know about it seems like a good one
[04:03] <Riddell> dholbach: still on my todo
[04:04] <dholbach> it'd be nice if you could at least let the patch author know about that
[04:04] <dholbach> I know that you're busy
[04:04] <soren> jdstrand: Right. I believe pitti rejected it because he wanted to entirely get rid of the debian-sys-maint user.
[04:05] <jdstrand> soren: I can understand that, and like the ideas for moving forward with hardy.
[04:05] <soren> jdstrand: Yeah.
[04:05] <jdstrand> soren: as this user exists in dapper-feisty (and have to check gutsy), then this may be the way to go
[04:05] <soren> jdstrand: We should get someone with strong C++-fu to do it.
[04:06] <soren> jdstrand: I was actively working on this when it was dropped. The patch you see there is a snapshot of what I found lying around in my source directory.
[04:06] <soren> jdstrand: It needs a thorough looking at.
[04:07] <jdstrand> soren: right.  as you know, I am working up several updates
[04:07] <jdong> can anyone comment on the sanity of replacing syslogd with syslog-ng in an Ubuntu install, or otherwise doing filtering on syslog entries?
[04:07] <jdong> some noisy apparmor rulesets are making messages.log grow by like 25MB/day
[04:07] <jdstrand> soren: I'll will go through this and, like I told pitti, submit the work for peer review
[04:08] <jdstrand> soren: thanks *so* much for the patch.  It'll be a great start!
[04:08] <cjwatson> mvo: in superm1's tests, removing cache.open(None) causes ubiquity's broken_packages function immediately following to return incorrect results
[04:08] <cjwatson> mvo: broken_packages is http://paste.ubuntu.com/549/
[04:09] <pitti> siretart: sorry, I didn't have time yet to continue debugging; will do in a bit
[04:09] <siretart> ok
[04:09] <pitti> StevenK: go ahead with the questions about mobile
[04:10] <pitti> soren: raising  debconf prio in stables> I agree; that's why I said if it can be fixed sensibly, I'm all for it
[04:10] <pitti> jdstrand, soren: another possibility is to disable empty root passwords on upgrades
[04:10] <StevenK> pitti: I'm going to file a bunch of bugs about stuff that should be promoted, who should I subscribe, and do I need to put any details in the bug itself apart from "<blah> needs to be checked if it can be promoted" ?
[04:12] <jdstrand> pitti: my initial thoughts were on upgrade, use a variation of soren's patch and just change the password, and be noisy in the logs about it
[04:12] <mvo> cjwatson: I will look in a bit (phonecall)
[04:12] <cjwatson> thanks
[04:12] <jdstrand> pitti: but under no circumstances keep mysql from starting
[04:13] <soren> jdstrand: ..my patch logs the message and outputs it on the console, too. That should make it pretty obvious for most people.
[04:13] <jdstrand> soren: right
[04:13] <jdstrand> soren: I liked that
[04:13] <pitti> jdstrand: yeah, sounds good; I rejected the patch back then since we had loads of time in gutsy to fix it properly
[04:13] <soren> jdstrand: Agreed. That's an artifact of the fact that I dropped it in the middle of development/testing.
[04:13] <soren> pitti: Yeah, those were the days. :(
[04:14] <pitti> StevenK: does the mobile stuff need to go into gutsy main?
[04:14] <StevenK> pitti: Yup
[04:15] <pitti> eww
[04:15] <soren> jdstrand: How's your C++?
[04:15] <pitti> StevenK: so yeah, I think a bug with appropriate tasks will do
[04:16] <StevenK> pitti: Right, one bug, with a whole bunch of tasks.
[04:16] <jdstrand> soren: good enough to read and patch, but probably not good enough to do what you are thinking of asking me.  ;)
[04:16] <soren> jdstrand: Me neither. C++ scares the shit of me.
[04:17] <jdstrand> soren: I wouldn't mind revisiting it if noone steps up, but my plate is pretty full atm
[04:17] <StevenK> Hahah
[04:17] <jdstrand> soren: haha
[04:17] <StevenK> pitti: Subscribe both you and iwj to it?
[04:18] <jdstrand> soren: I assume you are talking about for hardy?
[04:18] <soren> jdstrand: Oh, yes.
[04:18] <pitti> StevenK: that would be good
[04:19] <StevenK> pitti: Okay, cool. I'll look at it tomorrow. Er, later today. :-)
[04:19] <lamont> pitti: any chance of processing bug 144364 today?
[04:19] <ubotu> Launchpad bug 144364 in expect "Please sync expect (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/144364
[04:19] <soren> jdstrand: I'm not even that comfortable getting the patch I wrote into gutsy.. Anything more intrusive than that will keep me awake at night(!).
[04:19] <ubotu> Launchpad bug 137837 in expect "expect ftbfs on ia64" [High,Fix committed]  https://launchpad.net/bugs/137837
[04:19] <jdstrand> soren: well, ping me post-UDS and maybe we look at it more
[04:19] <soren> jdstrand: or during UDS, perhaps.
[04:20] <pitti> lamont: doing
[04:20] <jdstrand> soren: you're not going to make me pack my C++ books are you?
[04:20] <soren> jdstrand: I looked at the mysql code back in the day to figure out how difficult it would be. I think I know what it takes, but... it's c++.
[04:20] <soren> jdstrand: No, please don't.
[04:21] <soren> jdstrand: We need all the good karma we can get .
[04:21] <jdstrand> heh
[04:21] <pitti> lamont: done
[04:22] <lamont> pitti: does the processing auto-close 144364? or should I do that?
[04:24] <pitti> lamont: I closed the bug already
[04:24] <pitti> it's part of the sync ceremony
[04:24] <lamont> doh
[04:24] <bddebian> Heya
[04:27] <jdong> am I being retarded, or is there no way in sshd to disable port forwarding by user?
[04:28] <jdong> some sites reference this AllowTcpForwardingUsers style option but I don't think it exists?
[04:28] <cjwatson> jdong: you can use PermitOpen within a Match block
[04:29] <cjwatson> oh, actually, you can use AllowTcpForwarding within a Match block, which is better
[04:29] <cjwatson> so e.g.:
[04:29] <jdong> cjwatson: what is a match block?
[04:29] <cjwatson> Match user cjwatson
[04:29] <cjwatson> er
[04:29] <cjwatson> Match User cjwatson
[04:29] <cjwatson>         AllowTcpForwarding no
[04:29] <cjwatson> jdong: I trust you know about sshd_config(5) ...
[04:30] <jdong> I'm reading the manpage
[04:30] <jdong> but don't see this Match syntax in there
[04:30] <jdong> OH
[04:30] <jdong> pfft
[04:30] <cjwatson> version of sshd?
[04:30] <jdong> I feel retarded
[04:30] <jdong> was searching halfway down the page :)
[04:30] <cjwatson> hah
[04:31] <iwj> So if I find someone has erroneously marked some bug a duplicate of some other bug and I would like to point it out to them, how should I do this ?  Their LP profile does not appear to show any email addresses.
[04:31] <pochu> you can comment on the bug they marked as a dup, maybe?
[04:32] <iwj> No, because it's all irrelevant and they're not subscribed.
[04:33] <iwj> And anyway that's just noise for the other subscribers.
[04:33] <pochu> True that (though for the first you can subscribe someone else ;) )
[04:35] <jdong> cjwatson: that worked great, thanks. Just to clarify, there is no way to end a match block other than EOF or a second match block right?
[04:37] <cjwatson> jdong: not as far as I know
[04:37] <dobey> how does one get dpkg-buildpkg to create a -dbg package?
[04:38] <lamont> dobey: one adds the necessary steps to debian/rules
[04:38] <iwj> What I want is https://launchpad.net/~spqr1/+filebug :-)
[04:38] <dobey> do you have to also add stuff to debian/control for it?
[04:39] <dholbach> dobey: you can install pkg-create-dbgsym and just run debuild
[04:39] <dholbach> dobey: it will create -dbgsym.ddeb
[04:40] <dobey> rock
[04:40] <lamont> dholbach: cool
[04:42] <pochu> iwj: lol, I knew people had bugs, but I didn't knew they could be fixed
[04:42] <pochu> s/knew/know
[04:59] <dholbach> pitti: is bug 90286 on your list?
[04:59] <ubotu> Launchpad bug 90286 in hal-info "USB flash drive recognized as a music player" [Medium,Confirmed]  https://launchpad.net/bugs/90286
[05:05] <pitti> dholbach: I'll get to it, thanks
[05:13] <asac> ogra: no idea how long i386 in ppa will take ... if you don't have amd64 to test, please get the sources from http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/
[05:13] <dholbach> pitti: thanks
[05:13] <ogra> asac, will do ... i had a weird behavior before where NM was flipping networks all the time
[05:13] <ogra> right after upgrading to the latest oe from the archive
[05:14] <asac> ogra: oe?
[05:14] <ogra> it doesnt do that after a reboot anymore though, but i didnt mover through the house yet
[05:14] <ogra> *one
[05:14] <asac> ogra: ok, please test then asap ;)
[05:15] <ogra> will do, though my machine is currently doing a virtualbox install ... will take a while until i can compile
[05:22] <asac> ogra: virtual box? did you manage to finish normal CD install? Last time i tried I had issues with writing the boot record.
[05:22] <bdmurray> slangasek: No, I'm not certain what the minimum memory is.  My primary testing system has Compiz enabled by default so my results may be skewed.
[05:23] <ogra> asac, i always do my first tests in vbox ... usually that works fine here, but the default CD for edubuntu isnt -desktop so my HW requirements are way lower
[05:30] <asac> pitti: NN has sigaction for SIGSEGV for example. Is a raise(sig) enough to produce proper core-dumps?
[05:30] <pitti> asac: should, yes
[05:31] <pitti> asac: if you reset to SIG_DFL properly, of course :)
[05:31] <asac> pitti: right ... though i am inclined to stop NM to catch those signals at all. It just tries to create a backtrace which is obviously useless for us.
[05:32] <pitti> asac: right, at least without debug symbols
[05:38] <seb128> pitti: do you have some ideas about what's going on there, bug #145866
[05:38] <ubotu> Launchpad bug 145866 in gnome-session "system sounds do not play" [Undecided,Invalid]  https://launchpad.net/bugs/145866
[05:39] <seb128> pitti: bug comment 8
[05:40] <glatzor> ping bryce
[05:51] <pitti> siretart: \o/ I made the cryptsetup initramfs hook work with uuids, I just got hte first working boot
[05:52] <pitti> siretart: not perfect yet, but getting there
[05:52] <siretart> pitti: w00t!
[05:52] <siretart> pitti: so I assume you're going to upload cryptsetup soon?
[05:52] <pitti> siretart: ugh, that cryptroot script is a mess
[05:52] <pitti> I hope so
[05:52] <siretart> indeed
[05:52] <pitti> give me some more time
[05:52] <siretart> no hurry
[05:53] <siretart> ideally, we rethink the cryptsetup hook, and integrate it better with udev
[05:53] <siretart> then we can get rid of the script
[05:53] <pitti> *nod*
[05:55] <pitti> siretart: hm, it doesn't find resumedev yet, I think it should
[05:57] <Nafallo> 16:52  * ^i^ wonders what package to file a bug against if uname -i goes  "unknown" instead of x86_64
[05:58] <ogra> seb128, i'd ask for ~/.asoundrc.asoundconf
[05:58] <seb128> ogra: feel free to comment on the bug ;)
[05:59] <ogra> looks a bit like he ran asoundconf set-pulseaudio
[06:00] <Nafallo> anyone?
[06:00] <Nafallo> should be the kernel?
[06:01] <asac> ogra: ppa has i386 now ;)
[06:01] <ogra> yay
[06:01] <asac> siretart: ^^
[06:01] <ogra> my vbox just crashed :P
[06:01] <pochu> Nafallo: coreutils?
[06:02] <Nafallo> pochu: I have no idea what sets that :-)
[06:02] <Nafallo> pochu: so you're guess is as good as mine ;-)
[06:03] <pochu> Nafallo: emilio@kiko:~$ dpkg-query -S /bin/uname
[06:03] <pochu> coreutils: /bin/uname
[06:03] <Nafallo> already reported apparently.
[06:04] <pochu> Nafallo: uname -p also shows 'unknown'
[06:04] <Nafallo> anyway. I need to get on with more important things :-)
[06:05] <ogra> asac, nice, the first nm upgrade that went just flawless for me ...
[06:05] <asac> ogra: wow :)
[06:05] <asac> ogra: please roam now ... and try to reproduce the issue
[06:05] <ogra> it switched off shortly and came up proper again :)
[06:06] <pitti> seb128: hm, seems that guy configured his system to work with pulse, but doesn't have the packages installed
[06:07] <seb128> pitti: ok, so NOTABUG
[06:10] <ogra> asac, seems to work just fine :)
[06:10] <asac> ogra: please test extensively
[06:10] <asac> ogra: or did it always fail?
[06:10] <ogra> i will, but its way better than before already
[06:10] <ogra> not always but after changing the net several times
[06:11] <ogra> i changed 2 times between the three cells i have in my house (6 changes) ... it didnt choke yet
[06:11] <asac> ok ... please observe ;)
[06:11] <ogra> will do
[06:11] <ogra> but it looks better already
[06:12] <ogra> in any case
[06:13] <stgraber> asac: NM is rock solid here now, suspend/resume works fine, moving from an AP to another too, it only crashed once in a week (its old average being thrice a day :))
[06:13] <asac> stgraber: well one crash too much
[06:13] <asac> stgraber: the average user probably cannot cope with a crashed NM
[06:19] <asac> stgraber: but anyway ... thanks. i would really like to do another session with hidden networks before RC ... you think we can do that?
[06:19] <stgraber> yes, I have a test AP I can use it to test hidden networks a bit
[06:20] <pitti> siretart: hm, I fixed the resumedev thing, too
[06:20] <stgraber> and don't have much to do before RC (waiting for a new server for qa.ubuntu.com (let's hope it's before RC))
[06:21] <pitti> siretart: ATM I'm unsure, though, whether it is necessary at all to supply the "lvm=" option to the initramfs /conf/conf.d/cryptroot; I can fix the script, but I'm not sure why it is necessary at all... after all, the devices are created just fine without it
[06:22] <pitti> can anyone tell me how to get an initramfs prompt? (a magic kernel boot option, I figure?)
[06:23] <ogra> break=top
[06:23] <siretart> pitti: add 'break=top'
[06:23] <pitti> ah, thanks
[06:23] <siretart> or break=bottom
[06:23] <ogra> otr bottom or premount
[06:23] <siretart> depending on where you want it to break ;)
[06:23] <pitti> I need to find out whether 'readlink -f' works in the initramfs environmentt
[06:24] <siretart> pitti: if /etc/crypttab doesn't need to be touched at all, that would be even better. in this case, we need to update README.ubuntu
[06:24] <pitti> siretart: I fixed the hook script for update-initramfs, but i still need to fix the local-top/cryptroot script (maybe; maybe this entire manual stuff isn't necessary in the first place)
[06:24] <pitti> siretart: no, with my current script fixes, both crypttab and fstab are just fine
[06:24] <pitti> siretart: i. e. fully using UUIDs
[06:25] <pitti> siretart: I guess you could back out your recent modifications to udev even
[06:26] <seb128> pitti: http://people.ubuntu.com/~seb128/xdg-user-dirs.changelog http://people.ubuntu.com/~seb128/xdg-user-dirs.debdiff http://people.ubuntu.com/~seb128/xdg-user-dirs.diffstat
[06:26] <seb128> pitti: what do you think about the update?
[06:26] <pitti> slangasek: ^
[06:27] <pitti> seb128: looks bugfixish to me
[06:27] <seb128> pitti: yes, I'm not sure if I should ask for UVFes nowadays or just upload bug fix versions
[06:28] <pitti> UVF has ceased to exist
[06:28] <pitti> seb128: so that's fine
[06:28] <seb128> ok, I'll do the update then
[06:28] <seb128> thanks ;)
[06:29] <mjg59> mvo: What's the compiz situation like?
[06:30] <pitti> siretart: w00t! everything works, including suspend to disk
[06:30] <mvo> mjg59: I'm preparing a mail about it
[06:30] <mjg59> mvo: Ok, thanks
[06:31] <pitti> siretart: seems that this entire messing with lvm= options isn't necessary at all, it's all done dynamically
[06:31] <pitti> siretart: so I'll just remove the lvm=UUID=... madness from the cryptsetup hook to avoid the scary "failed to set up lvm foo" messages, and we should be good
[06:32] <seb128> mjg59, mvo: if you guys look to compiz issue you might want to point that there is still some integration issues (it's still not possible to change the number of workspace under compiz using the GNOME applet, though that should be fixed soon, dnd of windows to the applet don't work correctly, tooltips are not updated correctly, etc)
[06:33] <mjg59> seb128: How much of that do you think will be fixed by release?
[06:33] <stgraber> asac: unabled to connect to WPA protected hidden network (WPA supplicant seems to set the key but can't find the AP), I'm trying with same settings but visible to check that's not a WPA issue
[06:33] <siretart> pitti: sounds excellent!!
[06:33] <asac> stgraber: its known that ipw3945 cannot connect to hidden
[06:33] <asac> stgraber: i need a driver log :)
[06:34] <stgraber> asac: ok
[06:34] <seb128> mjg59: I'm too busy to work on that, mvo and MacSlow are working on some of those bug seeing how they are busy and how fast issues are fixed I would say not a lot
[06:34] <mjg59> seb128: Ok, thanks
[06:34] <stgraber> asac: WPA or open ? any preference ?
[06:34] <asac> stgraber: at best a full driver log ... i am not sure what to look for.
[06:34] <asac> stgraber: i am not sure ... i think both don't work, but i am sure for wpa
[06:34] <siretart> pitti: I need to look at your changes. have you already committed then to our branch?
[06:34] <asac> stgraber: maybe you can test if open fails?
[06:35] <mvo> mjg59, seb128: after the upload that is scheduled for today I do not expect that a lot more will happen, we are too close to release
[06:35] <pitti> siretart: no, I'm still editing it inline in vmware and do a few cleanups
[06:35] <pitti> siretart: ah, cryptsetup is in bzr? I'll keep it in mind
[06:35] <pitti> siretart: I'll give you the diff for eyeballing anyway
[06:35] <asac> pitti: i have a question about dbus :) ... sometimes nm cannot acquire the dbus name service as PRIMARY_OWNER ... on next restart it usually works. Do you think iterating on startup with a sleep might make sense then?
[06:35] <mvo> mjg59: I think that the session management regression will not get fixed, nor the regression with the window focus changes with orca
[06:35] <mvo> mjg59: and glx window of course not as well
[06:35] <pitti> asac: ugh; I think that's above my head
[06:35] <asac> pitti: its the well known bug 85113
[06:35] <ubotu> Launchpad bug 85113 in network-manager "[apport]  NetworkManager crashed with signal 5 in main()" [High,Confirmed]  https://launchpad.net/bugs/85113
[06:36] <mjg59> mvo: Ok
[06:36] <asac> pitti: hmm ... ok i think i will just try and listen to bugs :)
[06:36] <asac> because i never see that bug :(
[06:36] <mvo> mjg59: some integration issues should get nailed down, some keybinding issues, this is the kind of stuff I expect to get fixed in the remaining days. plus a problem with the stack ordering on session-managment that is currently being debugged
[06:37] <mjg59> mvo: And the crashers?
[06:37] <seb128> pitti: can we make translations not being stripped for a package?
[06:37] <siretart> pitti: yes, just 'debcheckout cryptsetup'
[06:37] <pitti> seb128: in general? not advisable, CDs would explode
[06:37] <seb128> pitti: xdg-user-dirs has the list of standards folders (music, pictures, etc)
[06:37] <mvo> mjg59: some yes, some no. upstream is actively working on them, but we will not be able to fix all of them. and it seems like a lot of them happen in custom configurations
[06:38] <seb128> pitti: and that creates issues for intallation without internet connection to download the language packs, the english directory are created
[06:38] <pitti> seb128: ah, just for one package? sure, set NO_PKG_MANGLE=1 in debian/rules
[06:38] <seb128> pitti: ok, thanks
[06:38] <cjwatson> you have to export it too don't you?
[06:39] <pitti> right
[06:39] <pitti> seb128: ^ sorry if that was unclear
[06:40] <seb128> pitti: that was clear, thanks ;)
[06:41] <stgraber> asac: Looks like I can't turn the debug mode on, was it disable in current gutsy module ?
[06:46] <pitti> siretart: http://people.ubuntu.com/~pitti/tmp/cryptroot.diff
[06:46] <pitti> siretart: pretty simple after all, I reduced it to the minimum;
[06:46] <pitti> siretart: I don't dare to do bigger changes now to avoid the warning, but it's just cosmetical
[06:47] <siretart> waah, I didn't think about readlink. this makes things a lot easier :)
[06:48] <siretart> that patch indeed looks pretty nice, let me test it
[06:49] <asac> stgraber: he? no it should still work
[06:49] <ion_> pitti: There arent ""s around all variables inside [ ] . Id be paranoid about that, no matter how unlikely it is the variables would contain spaces.
[06:50] <pitti> ion_: rightly so; patch updated
[06:50] <pitti> siretart: ^ please reload
[06:51] <pitti> siretart: I also noticed another bug, btw: nodes="${nodes#/dev/mapper/}" does not DTRT for multiple nodes, you need to iterate the substitution over the words
[06:53] <siretart> grml, my test machine doesn't have internet. test is going to be hard :/
[06:54] <pitti> siretart: manually do the changes in the patch? It's not quite much
[06:55] <pitti> siretart: if you do that, you could drop the third hunk, it's not essential to make it work; I just fixed it for completeness
[06:55] <siretart> internet restored
[06:55] <pitti> erm, no, that was bogus, it is necessary
[06:55] <siretart> I test the complete patch
[06:55] <pitti> I already dropped the non-necessary bits
[06:56] <pitti> siretart: is that the test machine you installed a few hours ago?
[06:56] <siretart> yes
[06:56] <pitti> siretart: did you use the partman-auto-crypto lvm/encrypted/full disk schema, or manual?
[06:56] <siretart> it is really virgin
[06:56] <siretart> I used partman-auto-crypto
[06:56] <siretart> on a 120gb disk. that's why it took so long ;)
[06:56] <pitti> but well, since you only ever have one root partition, support for multiple nodes is not that essential, I think
[06:56] <pitti> ah
[06:57] <pitti> siretart: I managed to flip the 'erase' switch to off, so it was pretty quick
[06:57] <siretart> I reinstalled it
[06:57] <siretart> pitti: how?
[06:57] <siretart> aborted right after the recipe was running? or by preseeding?
[06:57] <pitti> siretart: say 'no' to the question of whether to apply the changes, then you'll get the manual partitioning dialog with all the setup already done
[06:58] <siretart> aaah, that's nice
[06:58] <pitti> cjwatson: ^ I wonder whether we should make this the default
[06:58] <cjwatson> we don't normally in Ubuntu partman
[06:58] <cjwatson> and I intentionally changed partman-auto-crypto to match
[06:59] <cjwatson> is there a strong reason to revert to the Debian behaviour?
[06:59] <cjwatson> if so, please file a bug with the reasoning - I've only been skimming the discussion above
[06:59] <pitti> the Debian behaviour is to not erase the device before mkfs?
[06:59] <cjwatson> the Debian behaviour is to show the manual partitioning dialog after applying autopartitioning
[06:59] <pitti> cjwatson: oh, then we misunderstood each other
[06:59] <cjwatson> you mean flip the erase flag by default?
[07:00] <pitti> cjwatson: I meant, not erasing the disk by default before mkfsing it
[07:00] <cjwatson> I'm not sure about that, isn't it an appropriate paranoia measure?
[07:00] <pitti> it takes hours on large disks
[07:00] <pitti> yeah, it is
[07:00] <pitti> I see why it is done, but it's quite a pain
[07:01] <pitti> it does not make a difference with protecting the new data, just to erase the data that was on the disk previously
[07:01] <siretart> Isn't it only to make sure old data is overwritten?
[07:01] <pitti> right
[07:02] <cjwatson> I'm not sure. Perhaps bring it up with partman-crypto upstream
[07:02] <pitti> siretart: how long did it take for your 120 GB?
[07:02] <cjwatson> I don't feel confident to judge
[07:03] <pitti> cjwatson: ok; do you think a Debian wishlist bug is an appropriate forum?
[07:03] <siretart> pitti: I think about 2.5 hours
[07:04] <cjwatson> pitti: Debian #381898
[07:04] <ubotu> Debian bug 381898 in partman-crypto "Partition erase should be possible to cancel" [Wishlist,Open]  http://bugs.debian.org/381898
[07:04] <pitti> ah, Debian bug 381898 proposes something even better
[07:04] <pitti> cjwatson: heh, you beat me to it
[07:04] <cjwatson> pitti: cdebconf has support for that (via the progresscancel capability, see e.g. netcfg), so somebody just needs to plumb it into blockdev-wipe
[07:04] <pitti> Debian #400034, too
[07:04] <siretart> pitti: before I'm booting, I'm sneaking into conf/conf.d/cryptroot
[07:04] <ubotu> Debian bug 400034 in partman-crypto "partman-auto-crypto: please allow waiving erase operation during guided partitioning" [Wishlist,Open]  http://bugs.debian.org/400034
[07:05] <siretart> pitti: http://paste.ubuntu.com/557/
[07:05] <siretart> is that intended?
[07:05] <pitti> siretart: looks good
[07:05] <pitti> siretart: one is root, the other is swap
[07:05] <siretart> aah
[07:05] <siretart> ok
[07:05] <pitti> siretart: as I said, it would be sufficient to have one line and skip the lvm= bit
[07:05] <siretart> rebooting now
[07:06] <pitti> siretart: since udev magic dynamically sets up all LVs
[07:06] <pitti> siretart: so you'll see a warning during boot ('could not set up lvm'), but *shrug*
[07:06] <pitti> siretart: if I fix the initramfs top script to set it up itself, then I risk breaking the udev magic, and I'd rather not do that
[07:06] <siretart> cryptsetup: failed to setup lvm device
[07:06] <siretart> that one?
[07:06] <pitti> exactly
[07:07] <pitti> since it doesn't get along with the UUID= bit
[07:07] <pitti> siretart: I think I'll add code to inhibit the warning if it starts with UUID
[07:07] <pitti> siretart: that's a Gross Hack (tm) for Gutsy, just for cosmetics
[07:08] <siretart> pitti: well, your patch works really wonderful for this virgin installation
[07:08] <pitti> but it's much less scary on boot
[07:08] <siretart> pitti: I think we should upload it with README.ubuntu removed, since it is obsolete information in gutsy
[07:08] <siretart> pitti: and I wanted to merge the new debian upload as well, there seem to be a lot of good fixes, which we might want to have in gutsy
[07:08] <pitti> siretart: cryptsetup doesn't have a README.ubuntu
[07:09] <siretart> pitti: the source package has in the branch, which accidentally isn't installed
[07:10] <siretart> right
[07:10] <siretart> but your patch is absolutely necessary
[07:11] <pitti> siretart: right, the Debian changes look good to me
[07:11] <pitti> siretart: do you want to merge this or shall I?
[07:11] <siretart> pitti: the merge is on my todolist anyway. I can do it later today
[07:11] <iwj> iwj@cadmium:~$ grep 'ERROR: No Fallback found for language en-US' adt-play/tmp/_log_raw | wc -l
[07:11] <iwj> 5319835
[07:11] <iwj> and it's still building ...
[07:12] <iwj> -rw-r--r-- 1 iwj warthogs 266M 2007-10-02 18:12 adt-play/tmp/_log_raw
[07:12] <iwj> I'm sure it really needs to generate a 0.25GB build log.
[07:12] <pitti> siretart: ok, thanks
[07:13] <broonie> OO.o is sponsored by Sun to sell their high end hardware as a build systems.
[07:13] <pitti> I'm happy, crypto-lvm by default is great
[07:27] <stgraber> asac: strange, can you recall what was the debug number I had to send it ? it's something like 6152 but I'm not that sure (I tried with 6152 and 65536)
[08:08] <Kmos> bug 148197
[08:09] <ubotu> Launchpad bug 148197 in ubuntu "winscp fails randomly when copying files to ubuntu box" [Low,Incomplete]  https://launchpad.net/bugs/148197
[08:12] <nosrednaekim> how would I diagnose a suspend failure?
[08:14] <Riddell> seb128: do you have an opinion on bug 137701 ?
[08:14] <ubotu> Launchpad bug 137701 in mono "UVF Exception - Mono 1.2.5" [Undecided,New]  https://launchpad.net/bugs/137701
[08:19] <jdong> Keybuk: I just cut my GNOME login time significantly by readahead-watch'ing a login session , then doing a readahead-list during Xsession.d/00readahead... And cut down my login time by nearly half by calling the readahead in rc.local while the system idles at gdm.... I think an optimization like this is worth looking into for the next release :)
[08:23] <Keybuk> err, so which works better
[08:23] <Keybuk> readahead-list in Xsession.d or in rc.local?
[08:25] <jdong> Keybuk: well rc.local works beter provided the user waits for it to complete before logging in....
[08:25] <jdong> Keybuk: Xsession.d works better in the case the user rushes to log in
[08:25] <elmo>  /go thom
[08:25] <jdong> Keybuk: a combination of the two is the most optimal throughout
[08:25] <jdong> (as a redundant readahead has almost no cost)
[08:26] <seb128> Riddell: no real opinion on mono, maybe ask slomo or ajmitch when they are around
[08:27] <slomo> Riddell: well, i want 1.2.5 in gutsy... definitely :) but it's probably far too late now and at the time it wasn't too late i was too busy
[08:27] <Keybuk> jdong: a redundant readahead can have a monumental cost on low-memory systems
[08:27] <slomo> Riddell: and of course monodoc 1.2.5 and libgdiplus 1.2.5 is needed too then, the latter making pitti happy because no longer a private copy of libcairo ;)
[08:27] <jdong> Keybuk: ah, good point..... Can we have Xsession.d have a hook that stalls bootup waiting for the init.d readahead to complete then?
[08:29] <Kmos> bug 148205
[08:29] <ubotu> Launchpad bug 148205 in ubuntu "TouchPad crash when press caps lock " [Undecided,New]  https://launchpad.net/bugs/148205
[08:29] <Kmos> what controls the touchpad ?
[08:29] <Kmos> package?
[08:29] <Kmos> kernel ?
[08:29] <Keybuk> jdong: I was vaguely hoping for the kernel readahead patches that the SoC student did
[08:29] <jdong> Keybuk: hmm never heard of this. what do those patches do?
[08:30] <Keybuk> http://code.google.com/p/prefetch/
[08:31] <jdong> Keybuk: what is the difference between prefetch and the existing preload stuff in userland?
[08:31] <Keybuk> err
[08:32] <Keybuk> it works better :)
[08:32] <nosrednaekim> How would I procede to diagnose wireless-caused suspend failures in gutsy?
[08:34] <slomo> Riddell: and of course it contains many new features, many of them making it a more complete implementation... and also many many bugfixes, some of them rather major *shrug*
[08:34] <jdong> Keybuk: good answer. Better is always good. :)
[08:37] <MacSlow> re
[08:37] <pitti> good night everyone
[08:37] <MacSlow> cu pitti
[08:38] <Chipzz> some thing I've been wondering
[08:38] <Chipzz> the live cd has a pulsating usplash progress bar when booting the kernel, the final system doesn't
[08:38] <Chipzz> any reason?
[08:41] <mjg59> Because otherwise the progress bar wouldn't progress much on the live cd
[08:41] <cjwatson> Chipzz: historically, the live CD's initramfs was less easily predictable than (and certainly very different from) the normal system's, and so it was changed to pulsate as the easiest way not to confuse people
[08:41] <cjwatson> Chipzz: I have a patch from mdz to make it always pulsate in the initramfs
[08:41] <cjwatson> which I think may make more sense these days - there are a couple of long pauses there
[08:42] <Keybuk> err, there are?
[08:42] <cjwatson> but I didn't get round to it before beta and I think now is probably the wrong time to make that change
[08:42] <Keybuk> well, I guess there's the big spinning bit :p
[08:42] <cjwatson> exactly
[08:42] <cjwatson> we don't really know how long some of that is going to take
[08:42] <Keybuk> "less than three minutes" :p
[08:42] <cjwatson> and it would be better to pulsate than to make it look like we've locked up
[08:42] <Keybuk> cjwatson: btw, did I ever mention that I figured out the d-i udev rules bug?
[08:43] <cjwatson> Keybuk: I followed up to the bug
[08:43] <cjwatson> please change udev-udeb kthxbye :)
[08:44] <Keybuk> it seems silly to have a patch just for the udeb
[08:44] <cjwatson> Keybuk: I don't really see why we can't just let udev have a standard path on our system
[08:45] <Keybuk> it does?
[08:45] <cjwatson> busybox is quite entitled to implement [ as an external program
[08:45] <Keybuk> that PATH cannot include /usr though
[08:45] <cjwatson> Keybuk: so why doesn't it work? :)
[08:45] <Keybuk> otherwise seb would get grumpy
[08:45] <cjwatson> oh, is busybox's [ in /usr? odd
[08:45] <Keybuk> yes
[08:45] <Keybuk> /usr/bin/[
[08:45] <cjwatson> wow, freaky
[08:45] <cjwatson> ok, in that case I misunderstood
[08:45] <Keybuk> that's where it is in the real system too
[08:45] <cjwatson> I thought you were saying that it had PATH=/lib/udev
[08:46] <cjwatson> yeah, doesn't matter in the real system though
[08:46] <Keybuk> it's arguably a bug for write_net_rules to use [ at all
[08:46] <Keybuk> since it's inherently relying on it being a built-in
[08:46] <Keybuk> but then test is in /usr too
[08:46] <Keybuk> so that pretty much buggers all shell logic
[08:47] <cjwatson> technically not since you can use case
[08:48] <cjwatson> but I'll move test in busybox-udeb now that I understand the problem
[08:48] <cjwatson> does it need to be moved in the initramfs too?
[08:48] <asac> stgraber: try https://wiki.ubuntu.com/DebuggingNetworkManager
[08:48] <cjwatson> actually, it's not there as a separate program in the initramfs, so that's ok
[08:50] <cjwatson> 17:06 <iwj> It ought to take a list of strings for exec then.
[08:50] <cjwatson> 17:06 <Keybuk> it basically does
[08:50] <cjwatson> 17:06 <iwj> This is hardly rocket science.
[08:50] <cjwatson> 17:06 <Keybuk> with a PATH of /lib/udev only
[08:50] <cjwatson> 17:06 <iwj> Err, why doesn't it use exec[lv] p[e]  then ?
[08:50] <cjwatson> 17:07 <Keybuk> /lib/udev is the only thing you should "by default" guarantee exists
[08:50] <cjwatson> Keybuk: that IRC transcript is why I misunderstood
[08:50] <Keybuk> "basically"
[08:50] <cjwatson> I thought it corresponded to reality :)
[08:50] <Keybuk> it's actually even more insane than that
[08:50] <dobey> hey keybuck
[08:51] <Keybuk> if path[0]  != '/' then it prepends "/usr/lib/" onto it
[08:51] <Keybuk> uh
[08:51] <Keybuk> "/lib/udev/" onto it
[08:51] <Keybuk> which is even more sick
[08:51] <Keybuk> dobey: hi
[08:51] <cjwatson> Keybuk: right, but that's only the actual content of RUN rules
[08:51] <dobey> how's it goin?
[08:52] <cjwatson> not programs called from things listed in RUN rules
[08:52] <Keybuk> yeah
[08:52] <Keybuk> programs called from RUN rules inherit whatever PATH udev has
[08:52] <Keybuk> (which is often none, depending on how featured the calling shell is)
[08:52] <Keybuk> most of the scripts set it to /bin:/sbin
[08:53] <cjwatson> makes sense
[08:54] <cjwatson> Keybuk: uploaded, thanks for correcting my misconception
[08:54] <cjwatson> you can probably close the udev side ...
[08:54] <Keybuk> :)
[08:54] <Keybuk> I'm not completely insane
[08:55] <Keybuk> I wouldn't have forwarded it on to you if I didn't honestly think it was right to fix elsewhere
[08:55] <cjwatson> I did think that setenv("PATH", "/lib/udev") would have been a bit odd
[08:55] <Keybuk> (forwarding on to other people is, of course, a different matter <g>)
[08:55] <cjwatson> but I wouldn't actually have been shocked, only a bit surprised :)
[08:56] <cjwatson> Keybuk: I've taken to reading my bugmail again recently, so I guess I stupidly assumed everyone did :)
[08:56] <cjwatson> (despite the fact that I didn't for months)
[08:57] <Keybuk> I attempted to read it again
[08:57] <Keybuk> and gave up after less than a day
[08:57] <Keybuk> there's just too much ofi t
[08:57] <cjwatson> it wasn't too bad when I resolved to ignore the old stuff
[08:58] <cjwatson> I did only catch up by virtue of an insomniac night waiting for other stuff to happen though
[09:02] <slangasek> siretart: pfff, why do people keep trying to turn normal development activity that needs to be discussed and resolved among a handful of maintainers into "release goals for lenny"?
[09:03] <elmo> slangasek: because it bypasses the discussion
[09:04] <slangasek> if it worked, which I don't think it has yet :)
[09:22] <__mikem> Hey, I heard that the windows ubuntu installer is going to be an official installer in the next release, is this true?
[09:23] <cjwatson> __mikem: we tried, but it looks like it isn't quite going to make it for 7.10; there were just too many problems to fix in time
[09:23] <cjwatson> __mikem: now that we've laid most of the groundwork, though, it should be possible to finish it off for 8.04
[09:23] <__mikem> cjwatson, it worked fine for me
[09:23] <cjwatson> __mikem: the upstream one did, sure, but the internals weren't in a state that we could maintain
[09:23] <__mikem> oh I see
[09:23] <cjwatson> in order to get it merged into Ubuntu we had to rewrite some of that
[09:24] <__mikem> what specifically was going wrong?
[09:24] <cjwatson> the last straw was a mysterious hang when trying to mkfs the loop filesystem that we still haven't really tracked down
[09:25] <cjwatson> up to then it was just a succession of teething troubles; wubi requires an awful lot of weird stuff that was difficult to make work concurrently with Ubuntu's normal boot and install processes
[09:25] <superm1> cjwatson, that mysterious hang, was that similar to the type of hang that we were encountering on the mythbuntu live disks?
[09:25] <cjwatson> superm1: no
[09:25] <cjwatson> (as far as I could tell)
[09:25] <__mikem> cjwatson, in the merged version of the software, does windows get booted up before you start making the fs
[09:26] <cjwatson> __mikem: you launch wubi from Windows, then it reboots into the Ubuntu desktop CD and does an automatic install there, including making the filesystem
[09:26] <cjwatson> switching over to the Ubuntu desktop CD clearly produces a better user experience but unfortunately it had its own problems
[09:27] <__mikem> okay, I did you try running defrag on the machine before you tried the install?
[09:28] <cjwatson> __mikem: no, but it was a fresh install of Windows, and multiple people have encountered the same problem ...
[09:28] <__mikem> okay, did you make sure the FS wasn't compressed
[09:28] <cjwatson> I find it a bit implausible that that would break ntfs-3g, too
[09:29] <__mikem> cjwatson, there is a problem with the upstream version of wubi where if the fs is fragmented, it will cause problems
[09:29] <cjwatson> er, dude, it may not be the best idea to try to debug something you haven't tried yourself yet :-)
[09:29] <cjwatson> Agostino has been spending some time on this
[09:29] <cjwatson> so it's not just me
[09:29] <cjwatson> the upstream version of wubi creates the filesystem in Windows
[09:29] <cjwatson> so I expect it's vulnerable to that sort of thing
[09:30] <__mikem> cjwatson, Okay, I understand, its just that I used the current wubi installer and I figured I might try to help
[09:30] <cjwatson> we just run ntfs-3g and have it treat it as a normal Unix-like filesystem though
[09:30] <cjwatson> __mikem: if you can figure out what's wrong with the current code, that would be great; there are executables on http://wubi-installer.org/devel/minefields/
[09:30] <cjwatson> that you can try to use in conjunction with a current daily build of gutsy
[09:31] <__mikem> I don't currently have a box that I can test that on, but I might be able to see if USF is willing to hand over an old box that they are not using
[09:32] <cjwatson> __mikem: ago suggested that upgrading ntfs-3g may help, so we'll probably try that out ASAP
[09:32] <cjwatson> it hasn't quite bubbled up to the top of my list yet though
[09:33] <__mikem> what is ntfs-3g anyway?
[09:33] <__mikem> I know ntfs is the file system type windows uses
[09:33] <cjwatson> http://www.ntfs-3g.org/
[09:33] <superm1> cjwatson, did you happen to discuss more with mvo earlier today while i was away about why that apt cache wasn't showing broken dependencies?
[09:34] <__mikem> "Most POSIX file system operations are supported, with the exception of full file ownership and access right support." <-- This might cause a problem
[09:34] <cjwatson> superm1: no, he said he was on the phone and would look in a bit, but I think may have forgotten
[09:34] <cjwatson> __mikem: shouldn't be an issue for wubi
[09:34] <cjwatson> it only needs a small number of honking big files :)
[09:35] <superm1> cjwatson, ah okay.
[09:35] <cjwatson> the problems we encountered weren't permissions problems
[09:38] <__mikem> cjwatson, one more question. I had a hell of a time getting ubuntu to run on my HP pavilion. (Now bare in mind that this is a true dual boot setup I am talking about here). Basicly, the nvidia card that it comes with isn't supported by default so I have to instal the binary drivers manually. Now thats something I can live with. What I can't live with is the fact that the HP pavilion is the only machine on which I have seen lin
[09:38] <__mikem> ux hang randomly and intermitantly fail during boot
[09:39] <__mikem> Its quite apparent that that the <sarcasm>fine</sarcasm> people at HP specificly designed their box not to run anything but windows, so I am wondering if any steps have been taken in the next version of ubuntu to get around this
[09:41] <cjwatson> __mikem: I have no idea about that, I'm afraid; you'd need to track it down with the kernel folks
[09:41] <cjwatson> __mikem: it's more likely just a straightforward kernel bug than any kind of conspiracy at HP, though :-)
[09:42] <siretart> slangasek: yeah, you're right, I'm sorry. It was rather meant as a joke
[09:42] <__mikem> cjwatson, well if thats the case then why doesn't it happen on any of my other boxes that run ubuntu
[09:45] <cjwatson> __mikem: kernel bugs are often hardware-specific
[09:46] <slangasek> siretart: ah, that wasn't clear because people really /do/ try to propose release goals like that in Debian. :)
[09:47] <nosrednaekim> speaking of kernels and hardware problem,how would I diagnose a suspend failure related to wifi?
[09:47] <__mikem> Perhapse, but either way, I am not buying any more $h!+ from hp
[09:48] <cjwatson> __mikem: if I boycotted every manufacturer on which I'd experienced some kind of kernel problem at some point, I don't think I'd ever buy a computer again. :)
[09:48] <nosrednaekim> cjwatson: OLPC ;)
[09:49] <__mikem> lol, cjwatson, its not just that. I tried getting tech support once, and it was a nightmare, the potential kernel bug (and I still have my suspicions on the order of a conspiracy theory, and I usually try to avoid those) is just icing on the cake
[09:50] <__mikem> I will say though, I am very happy with the printer I got from them
[09:59] <slangasek> Riddell: libelf is on the list for syncing today still (bug #136986)?
[09:59] <ubotu> Launchpad bug 136986 in libelf "autopkgtest gutsy libelf: erroneous package!" [High,Fix released]  https://launchpad.net/bugs/136986
[10:03] <Riddell> slangasek: no, it already has been
[10:05] <slangasek> ok, cheers
[10:09] <keescook> I know this is crackful, but is there a way to force apt to download the Packages file for a repo that doesn't match the current arch?  (i.e. to see lists of files for i386 when I'm on amd64)  I don't care if they're uninstallable, I just want them to show up in apt-cache madison.  :)
[10:11] <Mithrandir> keescook: you know of rmadison, right?
[10:12] <Mithrandir> keescook: http://chistera.yi.org/~adeodato/blog/106_fakeapt is another alternative.
[10:12] <keescook> Mithrandir: I do, yes, but I need this for bulk automation, which makes it less useful.
[10:13] <Mithrandir> keescook: you know of madison-lite too? :-)
[10:13] <keescook> hm, I saw mention of it while digging in rmadison's CGI but maybe I need to look at it more.  :)
[10:14] <Mithrandir> apt-get install madison-lite
[10:15] <keescook> ah, hm, so I'd need to sync the Packages files manually for madison-lite.  Well, that's what I was trying to avoid with some arcane sources.list syntax, so I'm back to square one.  :)
[10:16] <Mithrandir> well, fakeapt + madison-lite should do what you want, though
[10:16] <Mithrandir> or just something nice-ish in cron
[10:38] <rockets> Out of curiosity, and assuming KDE4 is released on time, is KDE4 going to be included in the Hardy Heron?
[10:40] <__mikem> The kubuntu people really need to make more customizations to kde come kde 4. Their current setup is almost exactly like a default kde setup
[10:40] <ScottK> rockets: Yes, but not as the default.
[10:40] <rockets> ScottK, why not? I thought ubuntu always uses the newest availible stable revision of gnome/kde
[10:41] <ScottK> Because Hardy is an LTS release meant for long term/stable use by people more interested in stability than the latest/greatest.
[10:41] <__mikem> Scott, are they going to at some point actually make an attempt to customize kde by default in kubuntu at some point in the future?
[10:41] <ScottK> It will provide both the latest KDE3 and KDE4, just use KDE3 by default.
[10:41] <rockets> okeydokey :-D
[10:42] <ScottK> __mikem: Not sure what you mean.  It's customized now?
[10:44] <__mikem> No, for one thing, in kubuntu, the icon for the "start menu" is the same as it is in default kde, the general layout of the bar at the bottom looks almost exactly like the origonal kde, (with the exception of a very subtile background) and the colors are blue instead of brown
[10:45] <rockets> __mikem, but you're essentially arguing that they should make customizations just for the sake of customization.
[10:45] <__mikem> rockets, they customized gnome just for the sake of customizations
[10:45] <__mikem> heck they even customized xfce just for the sake of customization
[10:45] <rockets> __mikem, when you say customize are you referring to features or just the appearence?
[10:46] <rockets> __mikem, yes but *they* is not one group of people, you're talking about three different groups here
[10:46] <__mikem> appearence
[10:46] <rockets> oh ok
[10:46] <rockets> thats different
[10:46] <rockets> yeah whatever. . . . who cares though really
[10:46] <cjwatson> the blue in Kubuntu is intentional; it's supposed to have a different look from Kubuntu
[10:46] <cjwatson> er, from Ubuntu
[10:46] <cjwatson> (AIUI; I'm not a Kubuntu developer)
[10:47] <__mikem> okay, I will give that, but why can't you atleast make the menu icon different
[10:49] <ogra> ist Kubuntu lilac ?
[10:49] <ogra> *isnt
[10:50] <Riddell> ogra: it's gone more blue in gutsy
[10:50] <LaserJock> ogra: I think they went back to blue for gutsy
[10:50] <ogra> ah
[10:50] <anthony> Is Gutsy built to work with IPv6 out of the box, or will users need to change something for it?
[10:51] <slangasek> Linux pretty much autoconfigures IPv6 out-of-the-box at the kernel level now
[10:51] <__mikem> It would also be nice if xubuntu could be obtained through shipit
[10:51] <ogra> so kwwii's violet phase is over now eh ? :)
[10:51] <Riddell> __mikem: we make significant customisations to KDE, sometimes to the annoyance of upstream, the default panel quite difference.  obviously if you have specific requests we can look at those
[10:51] <stgraber> anthony: inet6 addr: fe80::219:d2ff:fe26:e216/64 Scope:Link <-- Looks like ipv6 is loaded :)
[10:51] <anthony> slangasek: I've heard some applications would need minor changes.
[10:51] <anthony> stgraber: :)
[10:52] <slangasek> at the application level, most packages have IPv6 support inherited from Debian.  There are some packages I can think of that require tweaks for IPv6.
[10:52] <__mikem> Riddell, if you could atleast customize the menu icon it would be nice since you customize the menu icon in every other ubuntu derivitive
[10:52] <Riddell> why would that be nice, we've very happy to have KDE branding
[10:52] <Riddell> there is a kubuntu logo in the system menu icon
[10:53] <ogra> scatter more of them everywhere :)
[10:53] <__mikem> what ogra said
[10:53] <ogra> yay for overbranding
[10:54] <__mikem> I think I am going to give xubuntu a spin next release
[10:58] <ogra> Riddell, btw, did you ever check if kmix works with virtual devices now ?
[10:58] <ogra> (i.e. in ltsp)
[11:04] <__mikem> heh, it looks like come kde4 time he ubuntu devs are going to have no choice but to make their own custom scheme http://mywheel.net/blog/wp-content/uploads/2006/01/Full_Render_View.png
[11:08] <mdke> ogra: pong
[11:09] <ogra> mdke, i wanted to ask about the TOC in yelp for the edubuntu handbook, but LaserJock already talked to you i think
[11:10] <mdke> ogra: yes, it should be fixed now actually, Seb uploaded the fix today
[11:10] <ogra> yeah, i didnt have time to upgrade yet, i saw a changelog entry that made me want to test :)
[11:11] <ogra> the handbook is over 50 ages now, would be a shame if it were hidden
[11:11] <ogra> *pages
[11:11] <mdke> i tested the patch, it works
[11:11] <__mikem> I will tell you what, with all the cool ways to create the interface for kde4, if they don't put some real thought into how they make kde4 look for kubuntu, me and half the userbase is going to be very p!$$ed off
[11:11] <LaserJock> yep, works here as well
[11:11] <LaserJock> mdke: thanks a lot for that
[11:11] <mdke> np
[11:12] <ogra> mdke, fix confirmed :D
[11:44] <thully> are any devs around who have experience with suspend/power management issues.  I have a few that have been sitting in Launchpad a long time without much response that are annoying to the point of being showstoppers in daily use...
[11:46] <Riddell> ogra: I don't have anything to test it with
[11:48] <Riddell> __mikem: that's not KDE 4
[11:49] <mneptok> siretart: ping
[11:50] <siretart> mneptok: pong?
[11:51] <mneptok> siretart: is dm-crypt+cryptsetup+d-i supposed to work in the 10-02 daily?
[11:51] <siretart> mneptok: not yet, I uploaded a fixed cryptsetup package 2 minutes ago
[11:52] <siretart> mneptok: make sure that cryptsetup_1.0.5-2ubuntu1 is installed on the alternate cd
[11:52] <mneptok> siretart: cool. then the 1s and 0s spewing out of the side of this certification laptop are expected
[11:53] <mneptok> siretart: i told cjwatson i'd use our cert equipment to track it through release. so i'll just wait for tomorrow's daily.
[11:54] <mneptok> thanks for the info. if you have known b0rkeness, i'd appreciate a ping.
[11:54] <siretart> mneptok: the install is already fine with current daily
[11:54] <siretart> mneptok: the installed system will drop out to initramfs during boot
[11:54] <siretart> mneptok: in order to boot the system, you need to do the cryptsetup luksOpen dance by hand. the next cryptsetup package which is currently building will fix that
[11:54] <mneptok> siretart: not here. the 10/02 daily dies when d-i goes to configure the newly encrypted volumes.
[11:55] <siretart> mneptok: thats fisy. I installed successfully on my test machine with the test image from today
[11:55] <siretart> fishy, even
[11:56] <mneptok> it just died on a machine here. i have another machine doing a media ovrwrite that should die in ~60 minutes ;)
[11:57] <siretart> :(
[11:57] <mneptok> same behavior as the beta. after zeroing and passphrase choice, d-i dies and the framebuffer gets wonked (repairs itself with a switch to another console)
[11:59] <siretart> mneptok: that doesn't sound like an issue in dm-crypt nor cryptsetup
[12:00] <siretart> good night!
[12:07] <thully> Anyway, I have a few laptop regressions from Feisty that haven't received much Launchpad love...  Coud mjg59 or some of the other Ubuntu laptop gurus take a look?
[12:08] <thully> The bugs would be 137738 and 137598
[12:11] <elmo> www.ubuntu.com is going down for emergency maintenance, ETD is 5 minutes or less
[12:11] <gnomefreak> ty elmo :)
[12:15] <anthony> Did Xubuntu have a Beta release?
[12:15] <cjwatson> anthony: http://cdimage.ubuntu.com/xubuntu/releases/gutsy/beta/
[12:15] <elmo> (back)
[12:15] <anthony> cjwatson: ty - I was looking on xubuntu.org and releases.u.c
[12:15] <cjwatson> anthony: releases.ubuntu.com has a link to cdimage/xubuntu/releases/
[12:16] <cjwatson> from which you go -> gutsy -> beta
[12:16] <anthony> cjwatson: I was just modifying URLs... :S
[12:16] <cjwatson> nope :)
[12:17] <anthony> on a similar note, has there been any talk yet about Xubuntu being available through ShipIt?
[12:17] <bluefoxicy> Should I file a bug for something failing to protect against man-in-the-middle attacks on ssl/tls implementations
[12:17] <bluefoxicy> or something