[00:28] <cjwatson> lool: that redirect is in place and seems to be working now; I guess the mirror just hadn't synced properly earlier
[00:28] <cjwatson> (ubuntu-mobile.* -> ubuntu-cmpc.*)
[00:28] <cjwatson> err umpc
[02:12] <ytoox> I know this is not a support channel but I am trying to figure out why my vaio can't use the built-in microphone
[02:12] <ytoox> can someone help me
[02:12] <ytoox> ?
[02:14] <ytoox> I am using intrepid
[02:16] <persia> ytoox, You'll have much better luck in #ubuntu or #ubuntu+1
[02:18] <ytoox> ok
[04:31] <calc> ugh the new hp netbook has a 1024x600 screen :\
[04:32]  * calc was hoping it would be like their old model
[04:35] <persia> Was that 1024x768?
[04:35] <persia> From what I understand, 1024x600 glass became really cheap recently, which is why so much has that resolution at 7" and 9".
[04:41] <calc> persia: it used to be 1280x768
[04:44] <persia> That's an unexpected resolution.  I've seen lots of 1280x800 in the shops, but the last time I saw 1280x768 was on smoe Sony subnotebooks 5 years ago.
[04:45] <calc> yea it is a bit odd for res most 1280 widescreen are 1280x800
[04:50] <Burgundavia> calc: wow.thatis worse than my laptop and it is bad
[04:50] <Burgundavia> why do they think that tradingverticl for horizontal is a good idea?
[04:53] <bryce> I heard something about that the aspect ratios are an outcome of the manufacturing process
[04:54] <persia> Burgundavia, It's good for watching movies : it's the attempt to demolish the haldheld DVD player segment.
[04:55] <Burgundavia> persia: yes,and not much else
[04:55] <Burgundavia> my screen isnot tall enough for inkscape
[04:56] <persia> Burgundavia, Well, that's partly an issue with window management, and toolkit DPI-independence, but yes.
[04:56] <persia> Personally, I've gotten quite used to using 640x480 for all sorts of things over the past several years, and for me 1024x600 is a big improvement, but that's for 4-5" screens, so a different use case.
[04:58]  * calc thinks persia has all the cool toys :-)
[04:59] <persia> calc, Come visit.  I'll take you to a shop.  It's all retail, and most of it is subsidised if you get a 3G contract.  You can get an Eee for 100 yen at some shops.
[04:59] <calc> wow
[05:00] <calc> hmm i don't think getting a contract in a country i don't live would work too well :)
[05:01] <persia> Then you get the low-price contract : 1000 yen a month for two years.  I suppose that's less good if you live in a country with inflation though.
[05:01] <calc> yea
[05:02] <calc> maybe eventually the US will catch up to Japan (maybe 50 years ;-)
[05:02] <superm1> calc, see what you should have done is jumped on a Sprint SERO plan while they were still easy to get on
[05:03] <superm1> if you haven't heard of them, i'd recommend you google and read a little bit about what you missed out on.  probably a better discussion for #ubuntu-offtopic though
[05:05] <calc> superm1: i meant more about getting cheap netbooks (etc) with a plan
[05:05] <superm1> calc, ah :)
[05:05] <calc> or bandwidth in general, i can't get more than 3mbps from my telco :\
[05:05] <calc> the US is just behind all around :(
[05:06] <superm1> agreed
[05:07]  * Chipzz doesn't get why laptop manufactures think widescreen is a good idea in the first place
[05:09] <Chipzz> browsing for example is a horrible experience on widescreens imo
[05:10] <Chipzz> (having your eyes make horizontal movements all the time is not very convenient)
[05:10] <persia> Chipzz, I find it much more pleasant to browse on widescreens in landscape mode.  Just tell xrandr to rotate your screen to e.g. 600x1024, and you can read sensibly.
[05:11] <Chipzz> (which is why both A4 and American paper both are taller than wide - which makes perfect sense)
[05:11] <Chipzz> persia: that only works on a netbook though ;)
[05:11] <Chipzz> laptop I'm currently working on is too big for that
[05:11] <persia> Chipzz, Well, actually it works better on tablets, convertibles, MIDs, PDAs, etc.  netbooks tend to be awkward in landscape mode.
[05:12] <Chipzz> I was thinking about the OLPC ;)
[05:13] <persia> That's a convertible, right?
[05:13] <Chipzz> not sure what you mean by convertible?
[05:14] <persia> You can spin the screen, so use it in either laptop or tablet mode.
[05:14] <Chipzz> right. it is, afaik
[05:15] <calc> works for good desktops too, just rotate your monitor
[05:15] <persia> Depends on the desktop.  Given a high-enough resolution, I'd rather look at two pages side-by-side.
[05:16] <Chipzz> calc: depends on if you can physically rotate your monitor I guess :)
[05:16] <persia> Chipzz, What monitor can't be rotated?
[05:16] <calc> Chipzz: yea
[05:16] <calc> persia: cheap ones
[05:16]  * persia expects that a bit of electrical tape would fix that
[05:16] <Chipzz> persia: like physically rotating, ie putting on their side :P
[05:16] <calc> persia: heh
[05:16] <calc> if you physically rotate a crt bad things can happen
[05:17] <persia> Chipzz, Right.  The only reason I can imagine why it wouldn't work was for a CRT with a loose flyback cable.
[05:17] <calc> it throws off the gun it seems (tried it once)
[05:17] <calc> it worked fine when i put it back to normal
[05:17] <Chipzz> calc: lol :)
[05:17] <persia> calc, That's a *very* cheap housing for the gun
[05:18] <calc> persia: probably so it was a computer from 1994 that i tried it on
[05:18] <Chipzz> if you think about it, widescreens make very little sense. you loose vertical screen estate with title bars, menus, toolbars, status bars and panels
[05:18] <calc> even some crt's were rotatable back in the day
[05:18] <calc> Radius brand monitors in the US iirc
[05:18] <Chipzz> if /anything/, they should be making /tall/-screens
[05:18] <calc> er i mean were able to be rotated by design
[05:19] <Chipzz> calc: I've seen a crt that was rotatable by design once
[05:19] <Chipzz> err
[05:19] <Chipzz> s/crt/lcd
[05:19] <persia> calc, heh.  That's different.  I once completely furnished a house using mostly working VT100s at all angles.  They still worked, but I'm sure that wasn't a design feature.
[05:19] <Chipzz> but they
[05:19] <Chipzz> but they're hardly common
[05:20] <calc> http://cgi.ebay.com/Radius-15-Full-Page-Pivot-Monitor-Model-0320-RAD0320_W0QQitemZ350115394192QQcmdZViewItem?_trksid=p3286.m20.l1116
[05:20] <persia> Chipzz, HP makes a number of good tall flatscreens.
[05:20] <persia> I've at least played with their 1600x1024.
[05:21] <persia> Err, 1024x1600
[05:21] <calc> i have a hp 23" 1920x1200 that can rotate
[05:21] <persia> That's a lot of head bending.
[05:23] <Chipzz> anyway, I run firefox in fullscreen all the time. I gain about 25% to 35% vertical screen real estate that way
[05:23] <Chipzz> pretty sad actually that I have to do that
[05:23] <Chipzz> hrrrrm ok, little less maybe. but still
[05:28] <calc> wow it does look like now its harder to find lcd's that can rotate
[05:28] <calc> it used to be just about any high end one could rotate
[05:28] <calc> the monitor i have original msrp was ~ $1500
[05:29] <Chipzz> that's a lot of money for a monitor
[05:29] <persia> I think most of the rotating demand is shifting to the mounted sort, with the emergence of the common backmount standard.  The local monitor shops all have lots of mounts and stands on display.
[05:30] <calc> Chipzz: i waited until LCDs got 'cheap' i was looking at them when they were > $5000 for 20" but couldn't afford them
[05:30] <calc> Chipzz: i bought it refurb for $750
[05:30] <calc> persia: ah
[05:31] <calc> the new HPs can still rotate though
[05:31] <calc> hmm actually they can adjust all sorts of ways it seems
[05:35]  * TheMuso uses a monitor with a VESA mount stand on his desk. Gives a lot of movement, rotation, etc.
[05:35] <persia> VESA mount.  That's what it's called.  Thank you.
[05:36] <TheMuso> Very good for work environments, allows me to move the monitor closer when I need it, and push it back when I don't, prevents me from leaning too far forward/back etc, and keep a good typing position.
[05:39] <persia> Yeah.  One of my recent customers was a bank, and they would give each new hire 9 VESA mounts and one screen : earning the other screens was part of the incentive program.
[06:09] <kees> what a surprise, fedora's s-b-t/liboobs doesn't freak out with sha512
[06:10] <StevenK> kees: Ours does?
[06:11] <kees> StevenK: yup -- it creates new users with 3DES since it doesn't see "md5" in the PAM configs any more.
[06:11] <kees> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/system-tools-backends/+bug/287134
[06:12] <wgrant> Um, only High?
[06:12]  * slangasek grabs the s-t-b authors by the ear and holds a perfectly good spinny wheel in front of their eyes
[06:13] <kees> and I can't figure out wtf liboobs is named in fedora
[06:13] <slangasek> but then, there's nothing in s-t-b that doesn't make me weep
[06:13] <slangasek> is the bug fixed that will let it race-condition your users out of existence? :P
[06:17] <kees> well, that's easy -- Fedora just doesn't use that library.
[06:18] <slangasek> good choice
[06:18] <slangasek> why are *we* using it? :)
[06:24] <pitti> Good morning
[06:25] <pitti> slangasek: s-t-b race> yes, ages ago
[06:25] <pitti> kees: argh, I just tested it half an hour before I told you...
[06:25] <slangasek> pitti: that's good; this is a good reason for it to have fallen off my radar, as opposed to it still lingering somewhere
[06:26] <StevenK> Morning pitti
[06:28] <pitti> slangasek: was fixed in Nov 2007 (23_users_update_model.patch)
[06:28] <pitti> hey StevenK
[06:28] <pitti> kees: oh, I get "conflicting distribution" now; apparently the cronjob does something different than my manual building
[06:29] <pitti> kees: argh, silly me; forgot to pull my changes to macaroni
[06:31] <slangasek> pitti: hmm, I think the bug I'm thinking of was later than that...
[06:47] <dholbach> good morning
[06:47] <slangasek> ribbit
[06:49]  * dholbach hugs slangasek
[06:49]  * slangasek hugs dholbach froggily
[06:50] <dholbach> :)
[06:52] <wgrant> A frog for an RM. How unfortunate.
[06:53] <Hobbsee> depends.  can it drink beer?
[06:53] <Hobbsee> because if it can't, what do you pay it in?
[06:54] <StevenK> The hearts of French chefs that like serving frogs legs
[06:54] <slangasek> Hobbsee: greenbacks, duh
[06:54] <Hobbsee> ah
[06:59] <slangasek> persia, TheMuso: will there be a release announcement url on ubuntustudio.org that I can link to in the ubuntu-announce mail?
[06:59] <slangasek> persia, TheMuso: hopefully something more detailed than the "it's out" blurb I see on http://ubuntustudio.org/news :-)
[07:00] <slangasek> superm1: same question for you wrt mythbuntu
[07:00] <superm1> slangasek, yeah there will be
[07:01] <slangasek> superm1: do you have a target url that I can prepopulate in the draft here?
[07:01] <superm1> slangasek, expect it at http://mythbuntu.org/8.10/release
[07:02] <slangasek> ok, thanks
[07:02] <slangasek> and will that page be live such that I can confirm it prior to pushing the button on the announce mail?
[07:04] <pitti> pgraner: oh, "pong"
[07:05] <superm1> slangasek, that depends on when that button is pushed.. we don't put the page live until all our mirrors catch up
[07:05] <slangasek> hmm
[07:05] <slangasek> how long does that take?
[07:05] <superm1> er well at least the big ones catch up
[07:06] <superm1> well we have to reroll our live disks in the morning, umenu broke on us
[07:06] <superm1> alternates are fine but we won't announce until the lives are ready
[07:07] <superm1> so maybe better to just leave us out of announce then for now if you are sending it out later today
[07:13] <superm1> slangasek, I think i might have come across something fairly bad in testing latest standard ubuntu DVD.  would you be able to make a call on it with what should be done? (bug 290580)
[07:14] <slangasek> superm1: it's not going out later today, it's going out Thursday... :)
[07:14] <slangasek> looking at the bug
[07:14] <slangasek> hrm
[07:15] <superm1> oh yeah its wed not thur right now
[07:15] <pitti> kirkland: argh, my ~/Private dir broke
[07:18] <pitti> kirkland: apparently I changed my password yesterday, and then reset /etc/shadow to the old value (same password, but different encryption, I think sha256->md5); apparently that broke ecryptfs
[07:18] <pitti> kirkland: "keyctl_search: Required key not available"
[07:25] <lool> morning
[07:38] <dholbach> hi thekorn, lool, ara
[07:38] <ara> hey dholbach, morning
[07:41] <thekorn> hello dholbach
[07:47]  * NCommander is doing something insane
[07:47] <StevenK> Oh?
[07:47] <NCommander> Yes
[07:47] <NCommander> insane
[07:47] <StevenK> Going to UDS?
[07:47] <NCommander> Beside that
[07:47]  * NCommander is debating if the kernel team will lynch or deepfry me ...
[07:47] <NCommander> oh well
[07:47] <liw> NCommander, oh! you're rewriting the kernel in Python too?
[07:48] <liw> NCommander, should we collaborate?
[07:48] <NCommander> liw, no, not python
[07:57] <wgrant> PHP, with added backslashes?
[07:57] <mdke> calc: pong
[08:15] <rootard> Hi, is there any way to get a list of udeb packages in a repository? Packages[.gz|.bz2] does not seem to contain the info normally.
[08:16] <slangasek> there's a separate Packages file under the debian-installer subdirectory
[08:18] <rootard> oof, but only if you use dak I imagine :-/
[08:19] <rootard> how about a way to tell if a source only produces udeb packages?
[08:22] <rootard> let me rephrase: if the source is in section: debian-installer, is it gauranteed to only produce udebs?
[08:23] <slangasek> that's should be a valid assumption for the Debian and Ubuntu archives
[08:24] <rootard> slangasek: thank you :)
[09:02] <TheMuso> slangasek: I don't have access to the site and am not involved with release notes.
[09:02] <slangasek> TheMuso: ok; is there someone else you can point me to who does/is?
[09:09] <TheMuso> slangasek: luisbg is doing English and a spanish translation, but that is all I know about who is doing what release notes wise.
[09:10] <slangasek> luisbg: around?
[09:33] <slangasek> superm1: still around?
[09:33] <slangasek> superm1: evand and cjwatson are up now and looking at 290580
[09:56] <MacSlow> how do I get around a bzr-error like: "Cannot lock LockDir(http://.../.bzr/branch/lock) : Transport operation not possible http does not support mkdir()"?
[09:56] <MacSlow> got that for "bzr commit somefile.txt"
[09:56] <pitti> MacSlow: you can't commit to http://
[09:56] <pitti> MacSlow: if it's on launchpad, use bzr+ssh://
[09:57] <pitti> if it's somebody else's branch, put your own branch on people.ubuntu.com or launchpad or so
[09:58] <MacSlow> pitti, well ok... but I just want to commit not push.
[09:58] <MacSlow> pitti, I thought a commit always works on my local branch
[09:58] <pitti> MacSlow: then apparently you used "checkout" instead of "branch"
[09:58] <pitti> MacSlow: use "bzr unbind", that should do
[09:58] <pitti> if bzr allows "checkout" on a http:// branch, I'd call that a bug, though
[09:58] <MacSlow> *sigh*
[10:05] <pitti> MacSlow: unbind worked?
[10:11] <pitti> bah, LP seems to be utterly slow today; I get lots of timeouts
[10:12] <\sh> pitti: it's the weather ;) the fibers are depressed ,-)
[10:16] <seb128> pitti: use non-edge
[10:16] <geser> \sh: it's not *that* cold yet in Germany that the data packets freeze inside the internet tubes and cause clogging :)
[10:16] <\sh> geser: it's raining ;) that's enough to feel depressed;)
[10:17] <Treenaks> it's the fog!
[10:17] <Treenaks> packets can't see where they're going
[10:17] <geser> \sh: can't confirm, clear sky here
[10:18] <arj> hi, does anyone know about the status of the backports of php5.2. for dapper?
[10:18] <arj> as can be seen here? https://bugs.launchpad.net/dapper-backports/+bug/78771
[10:19] <arj> i could read THAT
[10:19] <arj> ubottu: so, do you know wether this will be done in the next weeks?
[10:19] <arj> grml
[10:19] <arj> ah ok
[10:20] <ScottK> arj: Until someone does testing and says so in the bug, nothing will happen
[10:20] <ScottK> !backports | arj
[10:20] <arj> how do i test?
[10:20] <arj> can I download and test the package somewhere?
[10:20] <ScottK> If you read the link, it should give you some guidance on building packages to test.
[10:20] <arj> ok thanks for your advice
[10:21] <pitti> seb128: works much better, yes; apparenlty packets fell off the edge
[10:21] <seb128> pitti: yeah, I was getting the same issue
[10:22] <seb128> non-edge works correctly
[10:28] <wgrant> pitti: bzr checkout on an HTTP URL makes sense if you're using it readonly.
[10:29] <pitti> wgrant: hm; using "update" or "pull" isn't any difference in terms of efforts, but it's a bit more consistent for people who are used to checkouts, yes
[10:31] <\sh> geser: karlsruhe, Rain, <10 Degrees C
[10:32] <james_w> and http isn't always readonly
[10:32] <wgrant> james_w: True... but that's rare.
[10:37] <munckfish> Hi folks - who is in charge of writing up the final release notes? I need to find out how best to include (or not) notes on the PS3 version.
[10:38] <cjwatson> munckfish: ubuntu-release collaboratively; you've already done the right thing by opening tasks on ubuntu-release-notes, but if you want to help further then propose text in those bug reports too
[10:38] <cjwatson> munckfish: we're going through the list today
[10:41] <slangasek> I've gotten some feedback to the effect that many of the PS3 notes are not regressions over hardy, so it may not make sense to release note all the issues
[10:41] <munckfish> cjwatson: I've drafted quite comprehensive PS3 specific notes on psubuntu.com's wiki http://psubuntu.com/wiki/IntrepidReleaseNotes
[10:41] <munckfish> cjwatson: so may only need to refer to that doc from our official notes to save space - if you prefer?
[10:41] <slangasek> perhaps it makes sense to hit the highlights and refer to that doc, yes
[10:42] <slangasek> not to save space, but to not information-overload the users we're trying to get to read the release notes
[10:42] <munckfish> slangasek: ye exactly
[10:42] <munckfish> s/ye/yep/
[10:43] <cjwatson> robbiew: ^- (since I was just mentioning this in person)
[10:43] <munckfish> I'll try to get the notes the tidied up asap today and leave it to you guys to cherry pick the more important issues as you like
[10:43] <slangasek> munckfish: that would be wonderful
[10:44] <cjwatson> munckfish: the installation stuck at 6% thing may be basically the same issue as bug 290234
[10:44] <cjwatson> perhaps, anyway
[10:44] <cjwatson> I certainly think we could phrase that as "may seem to get stuck around this point depending on the installation mode"
[10:44] <munckfish> cjwatson: ok noted
[11:07] <munckfish> doko_: I've added a note on Cell development to the PS3 release notes: http://psubuntu.com/wiki/IntrepidReleaseNotes
[11:08] <munckfish> I remember when I installed gcc-4.3-spu
[11:08] <munckfish> It gave me the gcc-4.3-spu binary command
[11:08] <munckfish> I had to install another package from universe
[11:08] <munckfish> to get the symbolic link spu-gcc installed
[11:08] <munckfish> I don't have my PS3 here
[11:09] <munckfish> what's the name of that package in universe? gcc-spu? spu-gcc is the old Cell one right (aah confusing)
[11:10] <directhex> spu-gcc: /usr/bin/spu-gcc
[11:11] <pitti> Keybuk: do you see anything wrong with renaming /etc/rc0.d/S31umountnfs.sh to K31, and likewise S40umountfs to K40?
[11:12] <pitti> kees: the scripts only do stuff on "stop", so this looks like a packaging bug at first sight
[11:12] <pitti> but there might be something more delicate
[11:12] <pitti> Keybuk: (this is bug 42121, recently reopened)
[11:13] <pitti> kees: sorry, that was for Keybuk
[11:14] <directhex> pitti, so THAT'S to blame for my 3 minute shutdown time?
[11:14] <pitti> shmaybe
[11:14] <slangasek> pitti: rc0 and rc6 are special, S scripts are called with "stop" always in those runlevels and the difference between S and K is solely one of ordering
[11:14] <pitti> slangasek: oh, ok; so it's not that then
[11:15] <slangasek> pitti: and the ordering is very important for these scripts, though I don't think the current ordering is right either (c.f. bug reports against samba, about timeouts on reboot because the network goes away before umountnfs is called
[11:15] <slangasek> )
[11:16] <Koon> yes, bug 211631
[11:16] <directhex> slangasek, yeah, that's the bunny. quite annoying
[11:16] <slangasek> yes
[11:16] <pitti> hm, but then it should be correct; it first calls umountnfs, then networking, then umountfs
[11:16] <slangasek> it's also a bug on the samba side; by that point the routing table should be down and it shouldn't take a timeout to tell that the server is gone
[11:16] <slangasek> pitti: NetworkManager :P
[11:16] <munckfish> directhex: thx I think it's more confusing than that actually, I just checked the gcc-defaults package and found my answer - the spu-gcc package is from the old Cell SDK, but gcc-spu package is a meta package which depends on gcc-4.3-spu and provides the /usr/bin/spu-gcc symlinks .... umm I think ;)
[11:16] <pitti> slangasek: oh, right
[11:17] <directhex> handy
[11:17] <slangasek> pitti: previously, dhcdbd, though this part is obsolete now; but I think we're still getting the ordering wrong with NM in the shutdown case
[11:19] <pitti> slangasek: thanks muchly for the heads-up
[11:20] <slangasek> sure
[11:23] <directhex> when does networkmanager drop connections?
[11:24] <slangasek> possibly as soon as the desktop goes away
[11:24] <directhex> urgh
[11:24] <slangasek> I'm not sure, though
[11:24] <slangasek> hrm, ufw's shutdown script seems to be a bit earlier in the sequence than it ought
[11:25] <slangasek> directhex: if it doesn't die earlier, I'm pretty sure S20sendsigs kills it...
[11:26] <slangasek> which is before S31umountnfs.sh
[11:26] <directhex> slangasek, s' not ideal.
[11:34] <directhex> slangasek, perhaps the "easy" solution is fixing cifsmount et al so they can unmount immediately, even if connection is lost? at least make it a -o flag?
[11:34] <directhex> saves worrying about "what is killed when"
[11:34] <slangasek> directhex: it's the kernel driver that needs to be fixed
[11:35] <doko_> munckfish: gcc-spu
[11:35] <slangasek> and yes, this is a bug
[11:35] <directhex> sigh. kerneltastic
[11:35] <slangasek> but having the network die before umountnfs is also a bug, it could cause data loss
[11:36] <directhex> well, yeah
[11:36] <munckfish> doko_: thx
[11:36] <directhex> and depending on what's mounted where, it may be impossible to fix unless we can guarantee the network will be up when umount is called
[11:37] <ogra> if we'd default to sync mount nfs that wouldnt be a prob :)
[11:38] <slangasek> ogra: a) there are other network filesystems, b) <bleurgh>
[11:38] <ogra> heh
[11:40] <slangasek> directhex: it's not possible to completely eliminate the risk of losing uncommitted data when the network goes unaway unexpectedly, just like it's not possible to eliminate the same risk of losing data that hasn't been flushed to disk yet when the power is cut; but issues that cause such data to be lost *as a matter of course* on shutdown are a bug :)
[11:40] <directhex> hm, no lustre support in umountnfs.sh? bah!
[12:05] <elkbuntu> shani, could you please join me in #ubuntu-ops
[12:06] <shani> sure elkbuntu
[12:18] <jdstrand> slangasek: hi. saw your comment on ufw and shutdown order. I remember initially I had it not do anything on shutdown, but apparently for 0.12 I was talked into having it run a shutdown script. K39 seemed reasonable for hardy, but now there appears to have been some initscript shuffling :/
[12:19] <slangasek> jdstrand: K39 has always been earlier than the network itself is shut down
[12:19] <jdstrand> slangasek: yes, that wasn't the part I was thinking of
[12:20] <jdstrand> slangasek: I've never wanted to run 'stop'-- can you think of a reason why I should run 'stop' at all?
[12:20] <pitti> jdstrand: what does it actually need a shutdown script for?
[12:20] <pitti> jdstrand: heh
[12:20] <jdstrand> my notes are not illuminating
[12:20] <jdstrand> postinst: update-rc.d to stop the firewall in runlevels 0, 1 and 6
[12:20] <slangasek> jdstrand: I can think of reasons that an admin would want to run it by hand
[12:21] <jdstrand> ok, dude, but *why*?
[12:21] <slangasek> er
[12:21] <slangasek> debugging?
[12:21] <jdstrand> slangasek: that 'dude' was a 'dude' to me :P
[12:21] <slangasek> oh
[12:21] <slangasek> ok. :)
[12:22] <jdstrand> slangasek: I want 'stop' as part of the initscript, I just don't want in the shutdown process
[12:22] <slangasek> that makes sense to me
[12:22] <jdstrand> slangasek: do you think that removing the link in an SRU is appropriate?
[12:22] <slangasek> at the very least, if it's in the shutdown process it needs to be later
[12:23] <slangasek> I think it would be; I'll take a second opinion from pitti on that
[12:24] <pitti> jdstrand: yes, having a shutdown script in rc1.d makes sense, but not in 0 or 6
[12:24] <pitti> jdstrand: SRU> only if it can be shown to actually break stuff
[12:24] <jdstrand> yeah, I was just thinking 1 was good
[12:24] <pitti> jdstrand: SRU'ing it "just because", or for getting an 0.1 second shutdown speed improvement is not enough
[12:24] <jdstrand> heh, I think you mean s/break/not break/ :P
[12:24] <pitti> jdstrand: no, I did mean "break"
[12:25] <slangasek> pitti: it's not to get a speed improvement, it's to avoid dropping the firewall before the network services have terminated
[12:25] <jdstrand> right
[12:25] <pitti> jdstrand: if shutting it down early causes bugs like hanging network connections, an SRU is okay (since the preinst code isn't particularly difficulat, and has lots of prior art)
[12:25] <pitti> oh, I see, K39ufw
[12:26] <pitti> jdstrand: shutting down ufw will go to an all-REJECT state then, not to an all-ACCEPT? (as is the default in Linux)
[12:26] <jdstrand> pitti: all-ACCEPT
[12:26] <jdstrand> so it should never have broken network connections
[12:27] <pitti> jdstrand: ah, so it's not about cutting connections, it's for providing full firewall coverage even during shutdown
[12:27] <jdstrand> well, it does flush...
[12:27] <jdstrand> pitti: exeactly
[12:27] <jdstrand> exactly
[12:28] <pitti> oh, it -F/-X'es, thus potentially breaking masquerading or so, but that shouldn't be an issue during shutdown either
[12:28] <pitti> since 2 seconds later the machine is down anywa
[12:35] <jdstrand> pitti: have you revised your opinion based on the 'full firewall coverage even during shutdown' or is this strictly jaunty material?
[12:36] <pitti> jdstrand: it's a corner case, but it'd be enough to convince me to accept it
[12:36] <slangasek> pitti, jdstrand: eh, -F -X -- it doesn't do that on the nat table, does it?
[12:36] <pitti> jdstrand: nat> oh, right
[12:37] <pitti> jdstrand: but if we fix it, we shuold also move rc1.d/K39ufw to something like S80ufw (or drop rc1.d, too)
[12:38] <pitti> in practice it makes little difference, I think, since in single mode there aren't any network services running
[12:38] <jdstrand> slangasek: -F with no args, so all the chains
[12:38] <Keybuk> pitti: err, it would not be a change I would make in intrepid ;)
[12:38] <slangasek> ah
[12:38] <slangasek> jdstrand: that sounds like something that ufw shouldn't be doing :P
[12:38] <pitti> Keybuk: you mean killing the ufw rc.d links?
[12:38] <Keybuk> pitti: the umountnfs thing
[12:39] <pitti> Keybuk: ah, no, we settled that already (it's not a bug in the rc symlinks, but rather NetworkManager-ish
[12:39] <Keybuk> when in doubt, blame NM
[12:40] <slangasek> jdstrand: i.e., I don't think ufw init scripts should ever be touching any chains other than its own; I would probably be quite upset if I had run into this by accident on a live system instead of finding out from you in conversation...
[12:41] <jdstrand> slangasek: right-- actually I mispoke
[12:41] <slangasek> oh
[12:41] <slangasek> phew :-)
[12:41] <jdstrand> slangasek: it does do -F without args, but -F does not clear the nat table
[12:42] <pitti> bryce, tjaalton: random question; intrepid-created xorg.conf looks purely boilerplate, just identifiers and no options; why do we still create one in the first place?
[12:42] <jdstrand> slangasek: we had the conversation before, and are in agreement
[12:43] <jdstrand> slangasek: I just forgot about -F without args for a moment
[12:43] <slangasek> jdstrand: ok, so you agree it's a bug?  Need a bug report?
[12:44] <jdstrand> slangasek: no, I agree with your philosophy on ufw touching things it shouldn't. it doesn't as implemented
[12:44] <slangasek> jdstrand: if -F clears all chains in the default table, that means it clears any user-defined chains as well, though?
[12:45] <jdstrand> slangasek: ok, that would be a bug, if you have you're own chains. I was speaking of -t nat
[12:45] <slangasek> right, I was speaking more generally - though I'm glad that the nat table is safe
[12:45] <jdstrand> slangasek: though, I'm not sure it is sane to clear some stuff from the default table, and not others, so maybe we are not in complete agreement here
[12:46] <jdstrand> I can envision some chains that it'd be fine, but others, perhaps not
[12:48] <slangasek> I think clearing any chains that weren't created by ufw itself is the wrong model
[12:48] <slangasek> it doesn't matter what's in those chains - they should be off-limits
[12:50] <jdstrand> slangasek: well, part of my TODO list in jaunty is reworking the initscript stuff, so I've added this to my todo list. we can talk about it another time
[12:50] <sistpoty|work> pitti: iirc there are some corner cases (e.g. running inside kvm) that get optoins set, but I'd need to look at dexconf to be certain though
[12:50] <slangasek> jdstrand: ok
[12:50] <tjaalton> pitti: might be dropped for jaunty. it wasn't really considered for intrepid yet
[12:51] <pitti> tjaalton, sistpoty|work: ah, so it's just dexconf always writing out a skeleton, even if it doesn't have anything to configure?
[12:51] <tjaalton> pitti: yes, those corner-cases should be dealt also in the postinst if there would be no xorg.conf by default
[12:52] <kagou> Hi
[12:52] <kagou> who is in charge of building iso ?
[12:53] <ogra> pitti, for me the resolution applet still adds the virtual option if i run in two display mode with a merged screen
[12:53] <pitti> ogra: yes, that's fine; but python-xkit should cope and just create one if there isn't one
[12:53] <ogra> pitti, and i think that virtual thing is still needed ... which means you need an xorg,.conf
[12:53] <ogra> right
[12:53] <slangasek> kagou: I am; is something wrong?
[12:54] <kagou> no non slangasek,
[13:14] <asac> mvo: didnt we fix 240736 ?
[13:21] <robbiew> bryce:  working on release notes and was wondering if you could write one for bug #290156: ""Display out of range" after upgrade to Intrepid"
[13:22] <kirkland> pitti: hmm, let me grab a coffee and debug this
[13:22] <jdong> Are the final images spun yet? I've got three systems here with 100mbit connections that I can enslave towards seeding.
[13:23] <joaopinto> can someone explain me the latest change on the kernel related to the atheros driver ? I am using the current build cd, the live cd properly configured my ath0 device, the installed system does not
[13:23] <joaopinto> is the livecd kernel/modules expected to be different from the target install ?
[13:29] <kirkland> pitti: oh, way, you manually munged /etc/shadow?  if so, that would definitely break matters
[13:30] <kirkland> pitti: the pam_ecryptfs.so module should be in the common-password stack, and when called as part of running "passwd", should handle matters for you
[13:30] <kirkland> pitti: you can manually recover by running ecryptfs-rewrap-passphrase
[13:30] <kirkland> pitti: or individually running ecryptfs-unwrap-passphrase and ecryptfs-wrap-passphrase
[13:34] <mdz> anyone suffering from Launchpad slowness and timeouts on bug pages, visit https://bugs.edge.launchpad.net/malone/+bug/290668 and disable edge redirection as a workaround
[13:35] <seb128> mdz: edge timeout a lot today
[13:35] <mdz> joaopinto: they are identical
[13:35] <seb128> mdz: non-edge works correctly
[13:36] <mdz> seb128: right, that's what I've put in the bug now
[13:36] <seb128> mdz: I misread what you wrote as a question but that was a suggestion so ignore my comment ;-)
[13:37] <cjwatson> jdong: you should know by now that we don't answer that kind of question :-) Feel free to seed if you have capacity but it is always possible that we'll have to respin
[13:38] <joaopinto> mdz, any idea why I am getting an working ath0 device on the livecd, and no device in an installed system ?
[13:38] <mdz> joaopinto: check that the module is getting loaded, read dmesg
[13:38] <joaopinto> I have also experienced bug 287747, but I did a kernel reinstall
[13:40] <joaopinto> I am going to remove the module backports, and check the livecd lsmod vs the install lsmod
[13:41] <cjwatson> joaopinto: we'd like to get your installer logs
[13:41] <cjwatson> joaopinto: /var/log/installer/syslog and /var/log/installer/debug
[13:41] <cjwatson> (after installation)
[13:41] <mdz> joaopinto: also ls -l /boot
[13:41] <mdz> joaopinto: (regarding 287747)
[13:42] <joaopinto> hum, so far I did an chroot, apt-get remove/install to the kernel, and installed the backport-modules
[13:47] <joaopinto> cjwatson, mdz: Done
[13:49] <tvakah> right so, cross compiling in ubuntu, how: need to compile a package for an amd64 server on my intel workstation
[13:49] <joaopinto> I also had this issue with the atheros during the latest kernel upgrade in hardy, but I would prefer to go for ndiswrapper this time, since I had a working configuration without it for a couple of months
[13:49] <joaopinto> I mean, not to go
[13:51] <directhex> tvakah, define "intel workstation"
[13:52] <tvakah> directhex, core duo... I know full well that I need to cross compile, I just need to discover what the mystical "ubuntu way" of doing so is ;)
[13:53] <directhex> tvakah, core or core 2?
[13:53] <ogra> sudo debootstrap --arch amd64 intrepid ./chroot-amd64 && sudo chroot ./chroot-amd64
[13:54] <tvakah> grep model.name /proc/cpuinfo
[13:54] <tvakah> model name      : Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
[13:54] <tvakah> model name      : Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
[13:54] <tvakah> happy directhex
[13:54] <tvakah> ogra, ahha thanks
[13:54] <directhex> tvakah, but you're running a 32-bit kernel? why?
[13:54] <tvakah> directhex, read my openning question thoroughly then get back to me
[13:54] <ogra> note that you need to install all the compiler stuff, pbuilder or whatever you want to use ...
[13:55] <tvakah> ogra, righto, should I mess with apt-cross or dpkg-cross? or just use the chroot?
[13:55] <ogra> just the chroot
[13:55] <directhex> ogra, and he's not going to have trouble chrooting into a 64-bit chroot on a 32-bit kernel?
[13:55] <cjwatson> joaopinto: I also need /boot/grub/menu.lst and /var/run/grub/menu.lst, please - if possible before upgrade although I realise that this may be tricky and after upgrade might be good enough
[13:55] <ogra> directhex, i wouldnt think so ...
[13:56] <mdz> Oct 29 12:21:59 ubuntu ubiquity: Internal Error: Could not find image (/boot/vmlinuz-2.6.27-7-generic)
[13:56] <directhex> tvakah, nothing about your initial question adequately answers the question i just asked. fr'example, lots of people don't know that core2 and amd64 are the same arch and run the same apps, so there's no need to cross-compile anything. unless you're running a 32-bit os on a 64-bit intel chip for some reason
[13:57] <tvakah> directhex, so core2 is a 64 bit architecture? interesting, but even if I did end up relading a 64 bit system on my workstation, I'd still like to know how to cross compile for another arch so that I can build a package for say a server running sparc or anything else ;)
[13:58] <tvakah> reloading*
[13:58] <ogra> well, sparc is different :)
[13:58] <directhex> tvakah, well, that's the thing. i think ogra is wrong about being able to run a 64-bit chroot with a 32-bit kernel (unless things have changed a lot recently), but the reverse is very easy
[13:58] <ogra> amd64 and lpia should easily be doable in a chroot
[13:58] <joaopinto> cjwatson, it doesn't worth much now, I have manually removed the older kernel entries after reinstalling the proper kernel package
[13:58] <ogra> unless you want to play with kernel stuff
[13:59] <tvakah> all I want to do is recopmile openssh-server with the hpn patch so that people don't notice a huge slowdown now that this server isn't running freebsd ;)
[13:59] <ogra> directhex, for package building and compiling a chroot is totally fine
[13:59] <directhex> tvakah, core 2, i7, pentium-d, pentium dual core, some pentium 4, and all modern xeon and celeron chips, are amd64
[13:59] <joaopinto> the version part of the description was changed on the menu.lst, but not the target kernel
[13:59] <directhex> ogra, how is 64-bit gcc gonna get a 64-bit memory address on a 32-bit kernel?
[14:00] <ogra> directhex, no idea, but i never had probs with amd64 package builds in chroots on 32bit hosts
[14:01] <james_w> does apport do something obvious when it retraces something that has a stacktrace that is the same as the one on a bug marked Fix-Released?
[14:01] <james_w> i.e. if the bug wasn't fixed, or it regressed?
[14:01] <ogra> i also know the kernel we use in 32 and 64bit is identical just wont use the 64bit stuff on a 32bit system
[14:02] <ogra> both arches use the same -generic kernel since some releases
[14:02] <directhex> the name is the same
[14:02] <directhex> the source is the same
[14:02] <ogra> right
[14:02] <directhex> the binary is not.
[14:02] <ogra> binary isnt indeed
[14:03] <joaopinto> mdz, what info should I attach for the atheros card issue, a full dmesg and lsmod should be sufficient ?
[14:03] <mdz> joaopinto: for that one, run "ubuntu-bug linux" on the affected system
[14:04] <mdz> joaopinto: in general, you should always try to report bugs using "ubuntu-bug <package>" as this will attach much of the necessary information
[14:04] <directhex> 64-bit kernels can run 32-bit code thanks to CONFIG_IA32_EMULATION=y
[14:04] <directhex> there's no reverse equiv
[14:06] <ogra> well, feel free to test it and prove me wrong :)
[14:06]  * ogra has to go back to image testing
[14:06] <joaopinto> hum, the live cd is using ath_pci
[14:07] <ogra> then the installed system should do the same unless you install linux-backports-modules
[14:07] <directhex> ogra, i don't have any systems with 64-bit processors and 32-bit kernels.
[14:08] <ogra> directhex, well, i wasnt talking about 64bit processors :)
[14:08] <ogra> just about a 64bit chroot on a 32bit host
[14:09] <directhex> 100% not happening
[14:14] <directhex> "W: Failure trying to run: chroot /tmp/blart mount -t proc proc /proc"
[14:14] <directhex> oh look, a 32-bit chip doesn't understand 64-bit mount. shocked be i!
[14:14] <joaopinto> ogra, it's not, ath_pci is not loaded in the installed system
[14:15] <ogra> joaopinto, hmm, does linux-restricted-modules get installed ?
[14:15] <joaopinto> yes
[14:16] <ogra> weird, then ath_pci should be used
[14:16] <joaopinto> I have some ath5k related messages on the log
[14:16] <ogra> joaopinto, which iso is that (what day did you pull it)
[14:17] <joaopinto> Oct 28
[14:17] <ogra> hmm, bad
[14:17] <ogra> that shouldnt use ath5k at all afaik
[14:18] <joaopinto> but I don't get any wifi device available, unlike when I install the backports module
[14:18] <joaopinto> which gives me a non working device :P
[14:19] <ogra> well, ath5k interferes with ath_pci
[14:19] <joaopinto> I am most confused about the different behavior between the livecd session and the installed system
[14:20] <ogra> yes, that shouldnt happen
[14:20] <ogra> i'm n the middle of a umpc image test on a atheros device here
[14:20] <ogra> lets see how that behaves after install
[14:22] <joaopinto> hum, I am getting a linux-backports-modules warning
[14:23] <ogra> directhex, so i was apparently wrong :)
[14:24] <joaopinto> is ath_pci provided by the -restricted package ?
[14:24] <ogra> yes
[14:24] <ogra> its part of madwifi
[14:25] <joaopinto> I am getting module not found on modprobe -v
[14:25] <ogra> on the installed system i guess
[14:25] <joaopinto> right
[14:25] <joaopinto> hum, maybe it's related to my initial kernel issue, and I need to reinstall the -restricted also
[14:25] <ogra> how did you install your kernel ? using the linux metapackage ?
[14:26] <ogra> or linux-generic
[14:26] <joaopinto> linux-image-blah-generic
[14:26] <ogra> ah
[14:26] <ogra> you shoudl use linux-generic ;)
[14:26] <joaopinto> I had to reinstall it, because of 287747
[14:26] <cjwatson> joaopinto: it should only be the actual vmlinuz image itself that's missing
[14:26] <cjwatson> joaopinto: thanks for this, I think you win the dubious honour of triggering a last-minute respin ;-)
[14:27] <ogra> heh
[14:27] <joaopinto> cjwatson, well, uname -a states I am using 2.6.27-7
[14:27] <joaopinto> cjwatson, well I have reported this on on RC-1 :P
[14:27] <cjwatson> (it's not RC-1, it's just RC)
[14:28] <cjwatson> I know, it's unfortunate that we didn't manage to reproduce it then
[14:28] <joaopinto> RC-1 = RC - 1 day :P
[14:28] <cjwatson> ah
[14:28] <cjwatson> and you did say you couldn't help with any further information in your initial report which made it a bit less appealing to diagnose once we had failed to reproduce it ourselves :)
[14:29] <cjwatson> anyway, I have a fix in progress
[14:29] <joaopinto> it would be great to have it fixed on final, I would like to suggest some people to upgrade without formatting ;)
[14:29] <cjwatson> yes
[14:30] <joaopinto> but not distupgrade :P
[14:30] <cjwatson> of course update-manager is our recommended approach
[14:31] <joaopinto> It's my "not recommended", not based on self experience, but on reports from previous upgrades
[14:31] <ogra> ugh
[14:32] <cjwatson> joaopinto: you can tell that the approach you're planning on recommending people is not as reliable and less well-tested by the fact that it has been broken since mid-July without us noticing
[14:32] <cjwatson> joaopinto: so, even though we plan to fix this, I strongly suggest that you reconsider
[14:35] <joaopinto> cjwatson, there are too many untested conditions on the upgrade path, despite your best effort, at least for power users, which play too much with their configs and are capable of the most unlikely scenarios :P
[14:35] <ogra> thats like in #ubuntu-de it seems to be the standard procedure to tell people to purge network-manager right after install because they heard it would be bad
[14:35] <ogra> thats one of the standard advises there
[14:35] <cjwatson> joaopinto: you are recommending people a *totally* untested path; and update-manager is in fact increasingly well-tested over time
[14:35] <cjwatson> joaopinto: so obviously you can do what you like, but don't expect the Ubuntu team to stand behind you
[14:36] <joaopinto> cjwatson, well based on this problems I am not going to recommended the /home preservation for this release yet
[14:37] <cjwatson> joaopinto: it would be much more productive if you worked with us to help improve the upgrade path, which is generally perfectly achievable by high-quality packaging
[14:37] <cjwatson> it harms us all when people stick their heads in the sand and say it can't be done
[14:37] <cjwatson> because, in fact, it can
[14:38] <ogra> ... and is done by a major amount of people since mutiple releases
[14:38] <davmor2> superm1: Ping
[14:38] <mvo> joaopinto: given that update-manager will not touch your /home but will preserve your package selections and config in /etc you may well recommend people using it, if it fails, you can still go the install with preserving home without losing any (but time of course). however if the update works (which is what we expect) then its usually quicker and less wokr
[14:38] <joaopinto> also I have some other concerns to not recommend dist-upgrade, users which are lazy to proceed as instructed and keep packages which may be problematic
[14:38] <cjwatson> dist-upgrade != update-manager
[14:39] <joaopinto> I understand that, update-manager has a more complex upgrade logic, I like to call it dist-upgrade ;)
[14:40] <cjwatson> please don't, it's confusing
[14:40] <cjwatson> both for us and for users who know what apt-get dist-upgrade is
[14:40] <joaopinto>  atheros fixed, the -restrcited modules were not properly installed, to the initial install problem
[14:40] <joaopinto> due to
[14:41] <cjwatson> perhaps the initramfs wasn't properly generated
[14:41] <cjwatson> or something else due to the linux-image-* postinst failing
[14:43] <cjwatson> the actual files look like they should have been copied, from your logs and from the code bug
[14:55] <pitti> kirkland: right, I figured as much; I just wondered why ecryptfs-rewrap-passphrase needs the passwords on the command line; that's eww (.bash_history and all that)
[14:55] <seb128> pitti: could you look at #276745?
[14:58] <kirkland> pitti: yeah, i fixed that upstream
[14:58] <kirkland> pitti: they take them in on stdin
[14:58] <kirkland> pitti: we can sru that if you like, at some point
[14:59] <kirkland> pitti: actually, ecryptfs-add-passphrase and ecryptfs-wrap-passphrase can take that pwd in on stdin, in Intrepid
[14:59] <kirkland> pitti: write a 3 line bash script
[15:00] <kirkland> pitti: i plan to make those interactive, too, at some point
[15:05] <joaopinto> I am unable to login into my gnome session, with a clean home dir I have no problems, where should I look into, besides .xsession-errors ?
[15:06] <joaopinto> I see some strange artifacts which hints to the graphic driver/screen resolution config
[15:07] <seb128> joaopinto: could you describe what happens when you try to log in your session?
[15:08] <mvo> could someone with a intel i945 video card please try some video playback with compiz? (bug #264368)
[15:08] <joaopinto> seb128, I get some seconds of balck with green, like attempting to use the wrong driver/resolution, then it returns to gdm
[15:09] <joaopinto> meanwhile I decided to remove compiz, which did not help
[15:09] <seb128> mvo: I've a intel 965 which works correctly
[15:09] <lhoersten> I'm having issues with x not getting x events from my mouse after a certain amount of activity. what package should I report this to?
[15:09] <mvo> seb128: yeah, me too
[15:10] <joaopinto> also, after a login attempt, using CTRL-ALT-F1 will drop me into what looks a broken graphical session
[15:10] <joaopinto> with a clean boot, no login attempts, it behaves correctly
[15:10] <seb128> joaopinto: do you have a monitors.xml in .local?
[15:10] <seb128> joaopinto: .config rather
[15:10] <joaopinto> seb128, is that the screen resolution config file ?
[15:10] <seb128> correct
[15:11] <seb128> could be that your driver doesn't like the xrandr settings applied or something
[15:11] <joaopinto> ok, rebooting and checking
[15:11] <joaopinto> CTRL-ALT-F1 hanged the system
[15:13] <joaopinto> seb128, I do not  :\
[15:14] <seb128> joaopinto: you looked in the .config directory right?
[15:14] <joaopinto> I did a find $HOME -name "monitors*"
[15:16] <joaopinto> manually moving my data/settings to a new home dir will be painfull
[15:18] <seb128> there is no need to move your datas, etc just figure what is broken
[15:19] <joaopinto> well, I don't have much experience on this kind of problem, I would need to dig up all the scripts from gdm until gnome starts
[15:20] <joaopinto> that is my primary workstation, I will not have the enough time :\
[15:21] <seb128> joaopinto: try starting a failsafe session
[15:21] <joaopinto> seb128, tried it already, no improvement
[15:21] <seb128> joaopinto: look to .xsession-errors after getting the issue
[15:21] <joaopinto> it reports some warnings about compiz and xgl
[15:22] <seb128> that's not likely the issue
[15:22] <sistpoty|work> lhoersten: I assume xserver-xorg-input-mouse would be best
[15:22] <seb128> is compiz working for your other user?
[15:22] <joaopinto> apart from the screen resolution, are there any driver specific options that can be set by users ?
[15:22] <seb128> no
[15:23] <joaopinto> hum, didn't tried, but meanwhile I have removed the compiz package
[15:26] <joaopinto> rescue mode, dbus start, hal start, su - user; startx, works fine
[15:27] <lhoersten> sistpoty|work: thanks
[15:28] <lhoersten> sistpoty|work: bugs can't be added to virtual packages
[15:28] <pitti> kirkland: hm, bug 276745 might be for you
[15:28] <unimatrix9> hello there you all
[15:28] <belendax> when will intrebid ibex be released?
[15:28] <unimatrix9> i know you are very busy
[15:29] <unimatrix9> is it known that synaptic has an bug, it cannot search as it should do...is this an known bug?
[15:29] <unimatrix9> just found out now, so there is little time for fix,,,
[15:30] <kirkland> pitti: thanks for the heads up...  unfortunately, i don't have a fingerprint reader, so i cannot test this usecase
[15:30] <unimatrix9> aptitude does work when searching for packages, but a search for the same package with synaptic show nothing
[15:30] <sistpoty|work> lhoersten: hm... xserver-xorg-input-mouse is no virtual package though *shrug*
[15:30] <pitti> kirkland: the log has some ecryptfs errors (I don't think it's related to the fprint reader)
[15:31] <lhoersten> sistpoty|work: ah your right. my bad
[15:31]  * kirkland looking
[15:31] <mvo> unimatrix9: could you please try to open a termianl and run "sudo update-apt-xapian-index" and see if that fixes it?
[15:31] <lhoersten> sistpoty|work: it just had no previous bugs submitted against it
[15:31] <sistpoty|work> heh
[15:31] <unimatrix9> i am on 8.04 right now, so i cant test
[15:32] <joaopinto> seb128, somehow it's related to gdm: rescude mode, dbus start, hal start, gdm start, and I am experiencing the problem
[15:32] <seb128> weird
[15:32] <sistpoty|work> lhoersten: not too sure if you're using the right package then, as it does have some bugs against it: https://launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bugs
[15:32] <lhoersten> sistpoty|work: this is 8.10
[15:33] <unimatrix9> mvo, but from your reaction i assume its known?
[15:33] <lhoersten> sistpoty|work: i was looking at 8.10->xserver-xorg-input-mouse
[15:34] <mvo> unimatrix9: it sounds faimilar, however I currently don't know what is causing it
[15:34] <ogra> gah, console setup failing and then clicking "go on with install anyway" results in a messy python traceback error at the end of install
[15:35] <belendax> dingdangdong: boro biroon
[15:35] <kirkland> pitti: might be a duplicate of #255799
[15:35] <kirkland> pitti: i posed a couple of questions to the reporter
[15:35] <dingdangdong> belendax: what?
[15:35] <dingdangdong> :P
[15:35] <pitti> kirkland: thanks
[15:35] <kirkland> pitti: no prob ;-)
[15:36] <belendax> yeki ino bendaze biroon
[15:36] <joaopinto> I see a pulseaudio warning on dmesg, I don't get that warning on my desktop system, does gdm interface with pulseaudio to setup the user's pulseaudio services ?
[15:38] <belendax> ey baba!
[15:38] <joaopinto> not that I see a relation between pulseaudio and the graphical settings :P
[15:39] <unimatrix9> mvo
[15:39] <unimatrix9> sorry i was away from computer for a moment
[15:39] <unimatrix9> i am downloading daily build of 28 oktober right now
[15:40] <unimatrix9> and will test your command when i got the build , see if it helps
[15:40] <unimatrix9> of not i will report back in to see if any one can work at it
[15:41] <unimatrix9> its an bug in synaptic, search does not show up good results of packages
[15:41] <unimatrix9> i tested it yesterday on an other machine, same result
[15:41] <unimatrix9> any one running the daily build right now?
[15:42] <pgquiles> has anyone tried to to videochat with Empathy in Intrepid RC? I've tried in 4 different machines, both in LAN and through Internet, and it does not work (at least if using Jabber accounts)
[15:42] <belendax> teste farsi!
[15:42] <belendax> teste farsi nevisi 2!
[15:43] <cjwatson> belendax: please take this elsewhere
[15:43] <belendax> cjwatson: ok
[15:44] <unimatrix9> cjwatson, do you run the daily build? 8.10 ?
[15:44] <cjwatson> unimatrix9: this isn't a chat channel
[15:44] <cjwatson> I am running a fully updated 8.10 but I am also extremely busy right now
[15:44] <unimatrix9> chat, i am trying to track down a bug
[15:45] <cjwatson> ok, but please don't just ask whoever happens to say something
[15:45] <unimatrix9> ok  | np
[15:57] <ogra> cjwatson, does ubiquity rely on /etc/default/console-setup to be in the livefs before starting the install ?
[15:58] <cjwatson> I just posted on the bug asking for more information
[15:58] <ogra> i just hit bug 290760 and syslog looks like /etc/default/console-setup is required beforehand
[15:58] <ogra> ah, k
[15:58] <cjwatson> no, it doesn't
[15:58]  * ogra re-runs
[15:59] <cjwatson> in fact, ubiquity actually moves /etc/default/console-setup aside before it starts up
[15:59] <ogra> Oct 29 15:33:39 ubuntu ubiquity: cp:
[15:59] <ogra> Oct 29 15:33:39 ubuntu ubiquity: cannot stat `/etc/default/console-setup'
[15:59] <ogra> that made me wonder
[15:59] <cjwatson> the log message you're referring to is because the first run of console-setup (much earlier) fails, and therefore doesn't *generate* /etc/default/console-setup for use by the later run
[15:59] <ogra> ah
[15:59] <cjwatson> sort of unfortunate it doesn't fail the install earlier
[15:59] <ogra> well, thats likely the point where i get the popup message
[16:00] <ogra> anyway, restarting install
[16:01] <ogra> cjwatson, do i need --automatic as well ? i see the .desktop file execs it like that
[16:02] <ogra> --automatic --desktop %k gtk_ui to be precise
[16:03] <persia> ogra, If you're testing MID, you want --automatic
[16:04] <ogra> persia, yes, calling it with all options plus --desbug now
[16:04] <ogra> i hipe it doesnt work now because i had a wireless kbd attached inbetween (removed again now)
[16:04] <ogra> ah, same error pops up ... good
[16:05] <ogra> oh, wow
[16:05] <ogra> new error this time from partman
[16:05] <ogra> this seems messed up
[16:05] <ogra> cant get to partitioning
[16:06] <ogra> same with "Try again"
[16:07] <persia> ogra, Reboot.
[16:07] <ogra> persia, hmm
[16:07] <ogra> i wanted to keep the same state
[16:07] <ogra> but well
[16:07]  * ogra reboots
[16:08] <persia> You're still running the last partman-server.  If you can't reproduce with the same procedure, it's hard to understand anyway.
[16:08] <ogra> ah, right
[16:08] <persia> (especially with --automatic, because it won't ask the questions this time)
[16:08] <ogra> makes sense
[16:27] <robbiew> bryce: ping
[16:28] <cjwatson> mvo: does your fix for bug 277285 address bug 289611, as suggested?
[16:28] <cjwatson> (I don't have a problem with adding a release notes item as well)
[16:29] <unimatrix9> mvo are you there?
[16:31] <unimatrix9> bug of synaptic , when you search for an package is does not give the proper results , in quick search as well as normal search
[16:31] <unimatrix9> mvo pointed out to use sudo update-apt-xapian-index
[16:32] <unimatrix9> wich does fix the bug !
[16:32] <bryce> hi robbiew
[16:32] <robbiew> hi
[16:32] <ogra> unimatrix9, he's taking a break, but will surely read the backlog
[16:32] <unimatrix9> thank you very much
[16:32] <robbiew> did you get my email about the release notes?
[16:33] <robbiew> bryce: ?^
[16:35] <bryce> robbiew: yep I'll take a look
[16:35] <robbiew> thanks!
[16:41] <unimatrix9> mvo : i tested on daily build 8.10 28 october version.
[17:04] <ogra> cjwatson, --debug output attached to 290760
[17:06] <bryce> robbiew: hmm, looking at the other issues listed in the release notes, I'm not sure that 290156 qualifies for inclusion - as far as we know at this point, that bug affects only a single monitor model-number, and the workaround is kind of complicated to explain
[17:07] <bryce> robbiew: I can add it in, but am just concerned it might be too minor of an issue
[17:07] <ogra> debconf (developer): --> 10 debian-installer/keymap doesn't exist
[17:07] <ogra> hmm
[17:07] <robbiew> bryce:
[17:07] <robbiew> right
[17:07] <robbiew> good point
[17:07] <bryce> robbiew: but what I could do is add it to our general Xorg troubleshooting page
[17:08] <robbiew> ok...let me confer with cjwatson, but I think that is acceptable
[17:08] <robbiew> cjwatson: ?^
[17:10] <cjwatson> ogra: will look later
[17:11] <cjwatson> robbiew: I'm OK with it being a general troubleshooting item if bryce thinks that makes sense, although possibly bryce and ScottK should duke it out directly
[17:11] <robbiew> cjwatson: right
[17:11] <robbiew> ScottK: ping
[17:13] <ScottK> robbiew: I'm OK either way.  It was extremely painful for me to get through it the first time and I want to make sure it's documented somewhere that people will find it.
[17:13] <ScottK> Up to bryce where that is, since he'll get stuck with the questions.
[17:13] <robbiew> heh...ok
[17:13] <robbiew> thanks
[17:14] <mvo> cjwatson: I think the latest update-manager changes should deal with this situation, it will make sure kubuntu-desktop is installed and transition kubuntu-kde4-desktop to kubuntu-desktop. there might be corner cases, but a broad note should not be necessary (unless I missi something, but nothing in the bugreport indicates it)
[17:15] <bryce> ScottK, ok, I'm going to draft up X/Troubleshooting/Resolution and include this workaround there.
[17:15] <mvo> apachelogger: re bug #289961 - do you have a upgrade log avaialble were the dection failed?
[17:15] <robbiew> thanks bryce
[17:20] <cjwatson> mvo: ok, perhaps you could take ownership of that bug and sort it out
[17:20] <apachelogger> mvo: are you sure you mean that bug?
[17:20] <mvo> https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/289611
[17:22] <mvo> cjwatson: will do
[17:22] <apachelogger> mvo: I didn't try to reproduce since the cause is pretty obvious, maybe the report still has one around
[17:22] <apachelogger> otherwise I can try to trigger the issue
[17:23] <mvo> apachelogger: its not obvious for me :) (but I'm not too familiar with kde4) - so any help/advice/information is helpful for me to figure out more
[17:28] <apachelogger> mvo: well, since you uploaded a possible fix, I would just assume that the bug actually appeared some days before it was reported
[17:28]  * mvo nods
[17:28] <apachelogger> if this was not the case update-manager did screw up :P
[17:30] <cjwatson> mvo: I think a release note mightn't hurt in case people upgrade manually, of course (if that wasn't clear)
[17:30] <mvo> cjwatson: good point, I add it
[17:33] <moquist> kees: I've lost track. Is there still work needed on moodle? testing, maybe?
[17:34] <asomething> Hey all, I've got an upload sitting in intrepid-proposed waiting (bug 274844) but now a new bug has been filed for the same package with an easy but important fix (bug 290769). what's the process for something like this? are uploads in intrepid-proposed published yet or just in a queue? show i prepared a new upload with the same revision number or take care of it with a separate upload?
[17:34] <cjwatson> asomething: they're just in a queue
[17:34] <kees> moquist: I managed to find some Proofs-of-Concept and was able to test the update already.
[17:35] <cjwatson> asomething: upload with an incremented version number, please
[17:35] <kees> moquist: additional testing would be great too, of course.  :)
[17:35] <moquist> kees: OK; thx.
[17:35] <asomething> cjwatson: thanks
[17:39] <asomething> cjwatson: is the queue publicly available? my sponsor mentioned (pitti) he made a few modifications to my upload and i don't want to accidentally drop them
[17:40] <pitti> asomething: I'd actually prefer if I'd reject that upload, and we do another upload wit that additional fix
[17:40] <pitti> asomething: https://launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=
[17:40] <asomething> pitti: didn't see you were around, thanks
[17:41] <asomething> pitti: should i prepare something or do you want to take care of it?
[17:45] <kagou> i can't build a french iso for intrepid. I use last daily-live 8.10, I uncompress it and re-compress it (without doing any changes/chroot). The resulting iso failed to launch gnome session. Any idea ?
[17:50] <bryce> scottk, robbiew: https://wiki.ubuntu.com/X/Troubleshooting/Resolution
[17:51] <kees> james_w: hi! any progress on 287134?
[17:52] <james_w> kees: refresh :-)
[17:52] <pitti> asomething: if you could subscribe ubuntu-sru to the new bug, and maybe prepare a new debdiff, I'd appreciate; I'll take care of the sponsoring
[17:52] <james_w> I was too tired to post the patch when I got back last night, sorry
[17:52] <asomething> pitti: will do, thanks
[17:52] <kees> james_w: hah, I refreshed that bug *just* before you added that info.  :P
[17:53] <kees> james_w: yeah, that looks fine to me.
[17:53] <ScottK> bryce: Looks good.  You might want to bug cody-sommeriville or some Xubuntu person for their version.
[17:53] <james_w> kees: I'm just going to, you know, test it, now
[17:53] <kees> james_w: for the record, I look at Fedora 10 (they're using sha512 as well), and they don't use system-tools-backends or liboobs at all.
[17:53] <robbiew> bryce: looks fine
[17:53] <kees> heh
[17:53] <kees> *looked
[17:53] <james_w> kees: yeah, I think us and Debian are the only users, and so we're the only ones affected.
[17:53]  * robbiew thinks ScottK has a good point
[17:54] <kees> whee
[17:54] <kees> james_w: what does SuSE use (and if not s-t-b, why do we use it?)
[17:54] <james_w> kees: yast
[17:54] <kees> erg
[17:55] <james_w> kees: for the Jaunty fix I can't see any way to make it nicer, without pretty much re-writing everything, so we may just have to implement every password hash supported by pam in liboobs.
[17:55] <james_w> kees: I did spend some time trying to work out how to remove gnome-system-tools instead, but it doesn't look promising
[17:55] <kees> james_w: that's fine -- I'd prefer liboobs _used_ pam, though.
[17:56] <kees> and technically, it's glibc that supports it (since it implements the crypt() call)
[17:56] <james_w> kees: I can't find a way to ask pam to hash a password for you and return the result, do you know of one?
[17:56] <james_w> kees: ah, it does use crypt, I looked at the crypt manpage, and it gave no hint as to how to specify the has you wanted.
[17:58] <kees> james_w: yeah, the crypt manpage _sucks_
[17:58] <kees> basically, you select the hash based on the "N" in $N$salt
[17:58] <kees> james_w: what about just calling "chpasswd" directly?
[17:59] <kees> james_w: that's what the installer uses
[18:00] <james_w> kees: are you sure you want to go there? :-)
[18:01] <kees> james_w: hrm? why?
[18:01] <james_w> kees: it's because liboobs doesn't set the passwords, s-t-b does. s-t-b calls out to usermod to do so, which requires a crypted password.
[18:02] <james_w> kees: so liboobs crypts a plaintext password if you give it one, before passing it on to s-t-b.
[18:02]  * kees cries
[18:02]  * fabbione offers kees a shoulder to cry
[18:02] <pitti> fabbione: hey dude! how's life?
[18:02] <kees> omfg!
[18:02] <kees>     $command = "$cmd_usermod " .
[18:02] <kees>         " -p '" . $password . "' " . $login;
[18:02] <kees>     &Utils::File::run ($command);
[18:02] <kees> KILL
[18:02] <fabbione> pitti: not so bad.. you?
[18:03] <pitti> kees: kwality
[18:03] <pitti> fabbione: pretty good, thanks
[18:03] <james_w> kees: so to make this use pam we either need libpam-perl, to rewrite s-t-b in python or C, or to rip it all apart and re-architect it.
[18:03] <kees> james_w: okay, I think I see how this should be done
[18:04] <kees> james_w: liboobs should use "!" as the "encrypted password"
[18:04] <kees> james_w: and s-t-b should grow a _proper_ password-changing routine
[18:04] <xerosis> vorian: are you the right person to talk to about the release notes?
[18:04]  * ogra thought there was general agreement at last UDS to drop s-t-b completely and to port the fedora equivalent
[18:04] <kees> james_w: passwords are already sent in the clear on dbus for things like policykit, yes?
[18:05] <kees> ogra: I would be in favor of that after seeing this mess.
[18:05] <james_w> kees: not policykit I don't think
[18:05] <ogra> kees, i think pitti reviewed the tool right after UDS but then nothing further happened
[18:05] <ogra> james_w, that woud surprise me
[18:05] <ogra> fedora is PK all over
[18:05] <james_w> kees: polkit has a sane architecture :-)
[18:05] <pitti> ogra: no, the fedora tool is equally insane
[18:05] <kees> james_w: oh, how does the password get verified for polkit?
[18:06] <ogra> pitti, ah
[18:06] <ogra> i knew there had to be a reason we didnt switch
[18:06] <pitti> it uses it's very own crazy "get passwordless root through being at local console" thingy
[18:06] <james_w> kees: when polkit needs a password you ask for something to get it for you, polkit-gnome for a GNOME environment.
[18:06] <ogra> yeah, that breaks it for all ltp users
[18:06] <ogra> ltsp#
[18:07] <kees> james_w: ah, a local help does all the pam stuff and sends a root-originated dbus message?
[18:07] <kees> *helper
[18:07] <james_w> kees: this then pops up in a separate process, asks for the password, and then uses set{uid,gid} helpers to create the authentication in the database.
[18:07] <kees> okay, hm
[18:07] <james_w> kees: when that dbus call returns you then make the original call again, which finds the authentication in the database and proceeds.
[18:08] <james_w> seems much more sensible to me, but not directly applicable.
[18:08] <kees> james_w: how about a patch to chpasswd so that it spits out encrypted passwords to stdout instead of updating /etc/shadow?
[18:08] <kees> james_w: I'm just trying to isolate the encryption-selection code into one place if possible.
[18:08] <kees> chpasswd already has all the logic built in to check for the right methods, etc.
[18:09] <james_w> kees: that sounds reasonable to me, if we're not going to rip it apart
[18:10] <ogra> kees, would that work with ldap as backend ?
[18:10]  * ogra has the longstanding dream that the user and groups tool can just attach to ldap as well
[18:10] <james_w> ogra: it wouldn't change the capabilities of this at all.
[18:10] <kees> ogra: I have no idea
[18:11] <james_w> ogra: just reduce the number of implementations of the password hashes by 1
[18:11] <james_w> assuming kees just meant to make it spit out hashed passwords without looking at existing passwords etc.
[18:12] <kees> james_w: right, exactly.
[18:32] <philsf> cjwatson: ping?
[18:33] <cjwatson> philsf: yes?
[18:33] <philsf> cjwatson: can I ask you for some clarification on your resolution for Bug 289284?
[18:33] <cjwatson> philsf: sure
[18:33] <cjwatson> philsf: are you the reporter?
[18:34] <philsf> I am
[18:34] <philsf> I didn't understand what you meant by "set up email, if the user doesn't have one"
[18:34] <cjwatson> ubiquity is intended to be a small and simple installer UI (at least insofar as possible), and I do not believe this is an appropriate feature for it
[18:34] <cjwatson> that was really not a very relevant comment, I guess
[18:35] <cjwatson> but I meant that the installer offers the user no guidance on setting up an e-mail account, which would be necessary for many users in order to subscribe to mailing lists
[18:35] <cjwatson> many users don't have e-mail set up
[18:35] <cjwatson> anyway, that was not my primary justification for closing the bug wontfix
[18:35] <philsf> cjwatson: do you agree that users should be in some way (strongly) recommended to subscribe to at least those two MLs (-security-announce and -announce)?
[18:35] <cjwatson> no, I don't
[18:36] <cjwatson> well, I certainly don't believe it should be in the installer
[18:36] <philsf> oh, then maybe this is where we disagree
[18:36] <cjwatson> users get security updates automatically
[18:36] <cjwatson> get told about them automatically anyway - that's what the little icon thing in the notification area is for
[18:36] <cjwatson> and they get informed of new versions of the distribution via update-manager
[18:37] <cjwatson> the announcement lists are very useful for people who prefer to receive information that way; however I would tend to say that -security-announce is more useful for administrators of multiple machines
[18:37] <kees> hrm, is there a general fix for the weird libtool errors involving "X--tag=CC: command not found"
[18:37] <joaopinto> most users do not care about MLs at all
[18:37] <cjwatson> and anything on -announce that everyone has to know about, I think we often need to address by means of distribution updates anyway
[18:38] <cjwatson> I don't think my dad needs to read -announce or -security-announce
[18:38] <philsf> cjwatson: I see your point. but I think the announcement lists are the only fast enough channel where the user might get official information on big issues, say, if a big regression is discovered (and before it gets fixed, obviously)
[18:38] <cjwatson> (as the closest-to-home example I have of an Ubuntu user)
[18:39] <cjwatson> philsf: we don't usually publish announcements about that to end users before fixing them
[18:39] <cjwatson> it usually simply causes more confusion
[18:39] <cjwatson> sometimes we would notify development lists
[18:39] <philsf> cjwatson: maybe it could *prevent* confusion
[18:40] <philsf> the type of confusion that people get into by following $random tutorials on the interblag
[18:40] <cjwatson> we are not going to help that by flooding them with more information
[18:41] <philsf> ok, I agree -security-announce is overkill for your dad, my mom and my girlfriend, but the -announce is underutilized, and has more explicative potential
[18:41] <cjwatson> honestly, I'm sorry but I said no
[18:41] <philsf> *explanatory
[18:41] <philsf> cjwatson: pity, just thought I'd give a last try, to make sure we were understanding each other
[18:41] <philsf> thanks anyway
[18:42] <cjwatson> experimental evidence suggests that users who care about it do not generally have a problem finding -announce
[18:42] <cjwatson> we link to this sort of information from the start page in the browser
[18:42] <cjwatson> the installer, I've found, is not a suitable venue for presenting documentation
[18:42] <cjwatson> people want to get through it ASAP and start actually using their computer
[18:42] <cjwatson> if you put information there, or links to it, it gets skipped
[18:43] <philsf> makes sense
[18:43] <Chipzz> joaopinto: I'm going to repeat what cjwatson, mvo and possibly a bunch of other people have already told you: please DO NOT instruct people to upgrade using the CD
[18:43] <ScottK> kees: IIRC NCommander helped me fix one of those.
[18:44] <kees> ScottK: any idea what the solution was, or which package?
[18:44] <ScottK> IIRC it involved reliboolization and I don't remember
[18:44] <joaopinto> Chipzz, uh ? who mentioned about upgrades using the CD ? We were talking about doing a fresh install into an existing /
[18:44] <kees> ScottK: what's weird is that "libtool" is being generated during the build.
[18:44] <joaopinto> and the conclusion was, not recommended at this time because it was not properly tested
[18:45] <ScottK> kees: I really don't recall.
[18:45] <Chipzz> I would say: not recommended *ever*, even if properly tested
[18:46] <joaopinto> Chipzz, uh ? So there is am approved blue print, and the feature was implemented, and now it should not be used ?
[18:46] <cjwatson> it was implemented because the alternative was worse
[18:47] <cjwatson> the alternative was everyone telling users to create a separate partition for /home, which involved them making a decision for which they typically had insufficient information (relative sizes of / and /home) which was then very difficult and painful to change later
[18:47] <joaopinto> so, what is wrong with the current implementation, apart from the lack of testing ?
[18:48] <kees> NCommander: ping (libtool magic)
[18:49] <Chipzz> there are 2 possible ways such an upgrade could work; I see problems with both of these
[18:49] <Chipzz> cjwatson: do files in /etc get overwritten by a live-cd install without format, or do the originals get kept?
[18:50] <Chipzz> joaopinto: either the files in /etc get overwritten, which means users loose all their existing config, or it doesn't in which case you may get a broken install
[18:50] <Chipzz> both cases suck
[18:51] <cjwatson> Chipzz: overwritten
[18:51] <cjwatson> preserve-home is about keeping data, not settings
[18:51] <Chipzz> right, that's what I guessed
[18:52] <Chipzz> cjwatson: btw, that's not a critique pointed at ubuntu; just pointing out to joaopinto why that is not a good way of upgrading
[18:52] <cjwatson> indeed
[18:52] <joaopinto> regular desktop apps do not have any relevant data on /etc, nothing that you can't afford to lose
[18:52] <Chipzz> brb, gotta run for a bit
[18:52] <Chipzz> joaopinto: things you may have had to do to get say, wireless, or X working?
[18:53] <joaopinto> Chipzz, uh, how is that different from a regular reinstall ?
[18:53] <cjwatson> it's different from an upgrade
[18:53] <joaopinto> those are expected to be set by the installer, not something you need to preserve across instals
[18:53] <cjwatson> we do not recommend that people reinstall either to get from one version of Ubuntu to another
[18:54] <cjwatson> we recommend that they upgrade, which preserves both data and settings
[18:54] <joaopinto> preserve-home is not about upgrading, is about, reinstalling
[18:54] <cjwatson> yes. but you're recommending it to people upgrading, by your own statement
[18:54] <cjwatson> it is not intended for this purpose.
[18:54] <joaopinto> also, reinstalling is a good way to cleanup your system from software that you no longer need, a lot of people reinstall just for the sake of cleaning up
[18:55] <cjwatson> sure, which is fine (ish), but that's *different* from upgrading
[18:55] <cjwatson> please do not recommend reinstalling to people who should be upgrading
[18:55] <joaopinto> no, I am recommending people to do a fresh install :)
[18:55] <cjwatson> well, that's at variance with what we recommend so we will continue to disagree
[18:55] <cjwatson> we> Ubuntu development team
[18:56] <joaopinto> cjwatson, I have seen a lot of reports, on forums and irc, about problems with upgrades, is the upgrade process more reliable now ?
[18:56] <joaopinto> I mean, problems which were not experienced with a fresh install
[18:56] <azeem> I've seen many reports about aliens on the web
[18:56] <cjwatson> we are constantly improving the upgrade process in light of reports we receive
[18:57] <cjwatson> it is better for people to upgrade and for us to fix that than for everyone to be told to reinstall and lose all their settings every time
[18:57] <cjwatson> upgrading is a core strength of Debian-based systems
[18:57] <joaopinto> azeem, that is funny, because some people does classify linux users as aliens...
[18:57] <elmo> azeem: I've seen many reports that _you're_ an alien on the web
[18:58] <azeem> at least I'm not Ben Affleck anymore
[19:01] <joaopinto> cjwatson, I understand your point, the issue is that, you don't have massive testing for upgrades, "production" users will upgrade after the release, which is too late
[19:01] <Chipzz> 19:57 < cjwatson> upgrading is a core strength of Debian-based systems >> exactly
[19:02] <cjwatson> joaopinto: (a) we have more than you might think (b) that's why we continue to fix update-manager after release as necessary
[19:02] <Chipzz> joaopinto: like already stated, the upgrade path is way more tested than the reinstall path
[19:02] <cjwatson> joaopinto: sorry, I'm busy and not interested in discussing this further
[19:02] <joaopinto> cjwatson, no problems, thanks for your time
[19:03] <Chipzz> joaopinto: I am not part of the ubuntu development team, but have lots of experience with both debian and ubuntu (forgive the arrogance, but you could call me an expert)
[19:03] <Chipzz> joaopinto: nevertheless, 2 prominent people of the ubuntu development team have contradicted you
[19:03] <joaopinto> Chipzz, like I said, my position is not based on my own experience, is based on my frequent participation in both forums and irc support
[19:04] <Chipzz> now I don't want to sound threatening, but I suggest you follow their advice against your own "knowlegde", and do not go around spreading poor "advice" to people
[19:04] <joaopinto> Chipzz, I am talking from users perspective, not from a developers perspective
[19:05] <Chipzz> yes, and you are doing the users a DISSERVICE with it
[19:05] <azeem> and the Ubuntu project
[19:05] <Chipzz> so let me, once again, strongly suggest you do NOT give that advice to users
[19:07] <joaopinto> Chipzz, you sound threatening, but I don't care, I will follow the recommendations that I found reasonable and having in consideration the input that I got from the respectable members of the Ubuntu devs community
[19:08] <ogra> joaopinto, which members of the dev community did suggest reinstalling ?
[19:08] <joaopinto> ogra, none
[19:08] <Chipzz> it's not a threat. It's very strong advice
[19:08] <Chipzz> because you are ill-informed
[19:08] <ogra> right
[19:08] <Chipzz> and are spreading that bad advice to other users
[19:09] <joaopinto> ogra, I am not going to suggest reinstalls anymore
[19:09]  * ogra would consider Chipzz a "quasi ubuntu dev btw" ... a typical lazy chap that doesnt do the paperwork but does a lot of helpful work ;)
[19:10] <ogra> and surely someone knowledgeable about ubuntu and its processes
[19:10] <Chipzz> ogra: thx :)
[19:10] <joaopinto> Chipzz, well, that why I am here, learning, and please be aware that you see a lot more people recommending reinstalls after failed upgrades, eventually also ill-informed
[19:10] <ogra> joaopinto, cool, thats great
[19:11] <Chipzz> joaopinto: if the upgrade fails, and there is no easy way of fixing things, you can still consider a reinstall (which may, or may not work)
[19:11] <ogra> and notify us about the failure so it will not occur in the next release
[19:12] <joaopinto> that will be my approach for the next release
[19:12] <ogra> if people reinstall first place, very important info for us as devs is lost
[19:16] <joaopinto> I will be mailing about 20k ubuntu users today, I will be forwarding them to the official upgrade instructions, based on your input
[19:17] <ogra> great :)
[19:17] <\sh> 20k ubuntu users?
[19:17] <\sh> I'll by the list with emails ,-)
[19:17] <\sh> s/by/buy/
[19:17] <joaopinto> \sh, getdeb registered users
[19:18] <joaopinto> not for sale :P
[19:21] <\sh> joaopinto: you can make a dime, if you do something like "opendownload.de" ;;) sell ubuntu debian packages for money ,-) with a weekly renewal fee ,->
[19:21] <NCommander> kees, pong
[19:22] <kees> NCommander: I'm trying to fix a problem with libtool.  ScottK said you may have helped him with a similar issue.
[19:22] <kees> ../libtool: line 824: X--tag=CC: command not found
[19:22] <NCommander> kees, oh, that issue. What package?
[19:23] <kees> NCommander: shadow
[19:23] <NCommander> on intrepid, hardy, gutsy, or dapper?
[19:23] <mvo> joaopinto: please tell the users to file bugs if a upgrade fails, there is also some new test tool called "sandbox-upgrader" that can sort of simulate the upgrade on modern hardware.
[19:23] <kees> intrepid -- I'm just testing something for when jaunty opens
[19:23] <NCommander> kees, where is your patch so I can replicate the build failure
[19:24] <kees> NCommander: no patch -- it FTBFS with no changes.
[19:24] <ajmitch> that sounds familiar
[19:24] <joaopinto> \sh, that would required fulltime dedication, I need a job to pay my bills :P
[19:24] <kees> ajmitch: yeah, though google is unhelpful
[19:24] <mvo> joaopinto: its ok to talk to me about failure on irc too (well, not by all the 20k users at the same time :) - I think its ok to tell them aobut the install with preserving /home as a way to restore the system if a upgrade fails. its nice that this way no user data is lost
[19:25] <\sh> joaopinto: this company which did this, made a lot of money in less then a couple of months :) more money you need to pay your bills ;) but now they have a problem ;)
[19:26] <joaopinto> mvo, on the past on my instructions I have advised to keep /home on a different partition and doing a fresh install, because on my perception that was the most reliable method
[19:26] <NCommander> kees, ok, I kinda see the issue, some of your patches are doing something to trigger a libtool regeneration
[19:27] <mvo> joaopinto: right, its a valid approach, but as cjwatson pointed out already its difficult to get right for a user to figure how much space to give the system and how much home and its a pain to change it after the install. but certainly valid for experienced users
[19:28] <jspiro> hi all.  could you please ship glipper (gnome equivalent of klipper) with ubuntu?  it prevents accidental clipboard clobbering.
[19:28] <sebner> mvo: for a normal guy 15gb / are great and the rest /home :P
[19:29] <joaopinto> \sh, that would required some money oriented mind, we are all community oriented ppl
[19:29] <kees> NCommander: really?
[19:29] <ion_> For a normal guy, a plain / is great.
[19:29]  * pitti usually uses 5 GB /
[19:29] <kees> NCommander: I touched some manpage xml
[19:29]  * sebner wonders why his / is 12GB big
[19:29] <NCommander> kees, weird things can do it :-/
[19:29] <kees> NCommander: but so do other patches
[19:29] <NCommander> kees, however, it hasn't died here yet
[19:30] <kees> NCommander: yeah, I may have misspoke -- I thought I retested it
[19:30] <pitti> but since ubiquity supports preserving /home on reinstall, the only reason why you'd want a separate home is multiple linux installations
[19:30] <kees> but I started a new build without patches
[19:30] <NCommander> THere we go
[19:30] <jspiro> ion_: it's harder to dual-boot 2 linux distros without a separate /home.
[19:31] <kees> NCommander: ah, yeah, boom
[19:31] <NCommander> For CDBS packages, the easiest way to fix this is to properly regenerate the libtool to the right version with the DEB_AUTO_UPDATE_LIBTOOL macro
[19:31] <sebner> pitti: but it's still a bad idea to use a /home with multiple distributions?
[19:31] <\sh> sebner: why?
[19:31] <pitti> sebner: works fine for me
[19:32] <mrooney> sebner: do you mean to share a /home with multiple distros?
[19:32] <sebner> mrooney:
[19:32] <pitti> I share my /home amongst dapper, hardy, and sid
[19:32] <sebner> pitti: hmm ok ubuntu and debian but what about suse or fedora? I think I read somewhere that that might break something
[19:32] <mrooney> pitti: I had trouble with that between hardy and gutsy, when hardy rhythmbox updated its db to a new version and gutsy couldn't read it anymore
[19:32] <pitti> sebner: maybe
[19:33] <ion_> jspiro: I thought we were talking about the normal guy.
[19:33] <\sh> mrooney: you can prevent this with adding a separate user for each distro...
[19:33] <jspiro> ion_: sorry, i jumped into the middle of the conversation.  I shouldn't've.
[19:34] <sebner> \sh: ah you read the same as me? ^^
[19:34] <sebner> \sh: that was one solution I think ^^
[19:34] <NCommander> kees, test building the fix
[19:34] <\sh> sebner: well, I'll do the same as pitti, but I can recreate my rhythmbox db all the time ;) just delete the .<dir> ,-)
[19:35] <pitti> and I don't actually use RB in dapper, I just have that for testing some stuff
[19:35]  * sebner uses amarok2 so no matter if it's b0rken with intrepid or anything else :D
[19:35] <mrooney> \sh: yeah, I didn't think of that
[19:35] <\sh> sebner: but yes, someone can really create additional users for testing..most of the time you have your default user for allday work and other accounts for testing other stuff
[19:35] <kees> NCommander: what's the patch look like?
[19:36] <mrooney> but then you aren't sharing application settings and it isn't as neat
[19:36] <NCommander> kees, one line change to rules
[19:37] <sebner> \sh: someone != sebner. /me only has 1 laptop with 1 distro (ubuntu unstable) and 1 user :D
[19:37] <\sh> mrooney: but this can be pita even on upgrades...or reinstalls...:) I just did that at home, and fall into some pits with it...(even if some magic upgrade hooks are trying to come over this problem...but KDE is sometimes a b*tch)
[19:38] <NCommander> kees, and success
[19:38] <kees> NCommander: pastebin the patch?
[19:39] <jspiro> all : semi-repeat :  How do I request that a package be included in ubuntu?  I would like you folks to please ship glipper (gnome equivalent of klipper) with ubuntu.  It prevents accidental clipboard clobbering.
[19:39] <NCommander> !packages jscinoz
[19:39] <NCommander> argh
[19:39]  * NCommander has a bot failure
[19:39] <james_w> jspiro: it's in the archives, do you mean by default?
[19:40] <jspiro> james_w: yes, i mean by default
[19:40] <james_w> jspiro: I'm not sure that's a good idea. glipper is unmaintained upstream, and has a couple of pretty bad bugs.
[19:40] <NCommander> kees, I'm having trouble generating a clean debdiff (your clean rule doesn't actually clean :-P!
[19:40] <\sh> sebner: ok :) I have at least 4 desktop machines, 2 production ones (who are staying on hardy) and two play desktops which are running intrepid for some time now...
[19:41] <jspiro> james_w: are the bugs worse than the data loss caused by accidental clipboard clobbering? :)
[19:41]  * kees doesn't claim to be the maintainer of "shadow"  :P
[19:41] <sebner> \sh: hrhr, nice. but /me only needs 1 machine for playing,testing and working :P
[19:41] <james_w> jspiro: heh :-)
[19:41] <NCommander> Unrelated but awesome news: I got AppArmour available on PowerPC!
[19:41] <NCommander> wooo
[19:42] <\sh> NCommander: AWESOME!
[19:42] <NCommander> kees, http://pastebin.ca/1239916
[19:42] <NCommander> \sh, and a 2.6.27 based kernel :-)
[19:43] <jspiro> james_w: :-) what do you think?
[19:43] <kees> NCommander: cool, thanks
[19:46] <kirkland> NCommander: very nice!
[19:46] <jdong> NCommander: it's AppArmor :)
[19:46] <jdong> sheesh you people europeanizing American words.
[19:46] <NCommander> jdong, this is why I want to backport the kernel
[19:46] <NCommander> jdong, I am American
[19:46] <\sh> AppAmore? ,-)
[19:47] <jdong> NCommander: then stop wasting bits with superfluous u's!
[19:47] <jspiro> uuuuuuuuuuuuuuu
[19:47] <NCommander> No, the flavour and colour of British spelling of American words like Armour!
[19:48] <james_w> jspiro: if someone were to care for it, and start by fixing the critical bugs then I wouldn't be against it, but I think it would need more discussion
[19:48] <NCommander> kees, I also ported it to IA64
[19:48]  * NCommander has been extremely busy
[19:48] <jspiro> james_w: how does one convince someone at Gnome to take maintainership and fix the critical bugs?
[19:49] <james_w> jspiro: no idea.
[19:49] <james_w> is it even a GNOME project?
[19:49] <james_w> i.e. on GNOME infrastructure?
[19:49] <kees> NCommander: wow, nice.  have you sent the patches to the AppArmor upstream folks?
[19:51] <NCommander> kees, it built withotu changes from their SVN head
[19:51] <kees> ah, cool
[19:51] <NCommander> None of the code is in any platform specific places, and at least on powerpc, the userland tools appear to work
[19:52] <kees> NCommander: is it not enabled on ubuntu ppc?
[19:52] <NCommander> kees, it was never added to our git tree
[19:52] <NCommander> <- *has seemingly become the defacto linux-ports maintainer*
[19:53] <sebner> cruft-remover is strange. That installed some applications (I had some installed that are not in the archive)
[19:53] <NCommander> I have no idea how to install profiles however to confirm its actually working, I just know things like apparmor_status work
[19:53] <kees> NCommander: ah, cool.
[19:54] <jspiro> james_w: looks like it isn't.
[19:55] <james_w> jspiro: have you looked at any of the alternatives?
[19:55] <jspiro> james_w: no
[19:55] <jspiro> is there an alternative which is maintained and which you would consider shipping with ubuntu?
[19:56] <james_w> I'm not sure.
[19:56] <james_w> I have seen something called something-packer or something mentioned a couple of times
[19:57] <james_w> parcellite
[19:58]  * NCommander works on the HPPA kernel
[19:58] <jspiro> james_w:  ah, http://parcellite.sourceforge.net/.  it looks still maintained.  But I've never tried it.
[19:58] <Chipzz> NCommander: the more exotic, the better? :)
[19:58] <NCommander> Chipzz, I'm aiming to improve all port architectures
[19:59] <NCommander> Anyway, the major w/ HPPA is NPTL support
[19:59] <james_w> jspiro: if you would like to discuss this more I suggest mailing<EMAIL_ADDRESS>[19:59] <NCommander> THe kernel chunks are badly out of date, but having a more modern kernel available should get that beast going aagain
[20:05] <\sh> sebner: what is cruft-remover?
[20:06] <sebner> \sh: the new name for "system-cleaner" <-- our new hot utily in intrepid
[20:06] <jspiro> sebner: did you know there's already a cleanup tool in Debian called cruft(1)?
[20:06] <pitti> it's still a mystery to me how a functional description like "system cleaner" can get a trademark..
[20:06] <\sh> sebner: ah..well...I just reinstall my ubuntu install when I need to remove cruft *lol*
[20:07] <jspiro> sebner: sudo aptitude install cruft -yq
[20:07] <sebner> jscinoz: apt apt apt :P
[20:07] <\sh> pitti: what? it has a trademark? (system-cleaner)?
[20:07] <sebner> pitti: is it the intention so remove also non-archive stuff?
[20:07] <sebner> \sh: yes, because of that -> new name
[20:08] <sebner> *so = to
[20:08] <\sh> sebner: that sounds like the "webspace" name patent during the 90ties in germany...
[20:08] <liw> existing trademark: correct, hence name change; cruft(1) already exists: correct, but it's somewhat limited in scope and has no GUI
[20:08] <sebner> \sh: O_o /me was a little little child that time :P
[20:09] <sebner> cruft-remover is a new thing and not only a cruft gui I suppose!?
[20:10] <liw> sebner, correct, a completely new thing
[20:10] <sebner> that removed my software xD
[20:11] <\sh> sebner: it was cruft, you didn't need it ;)
[20:11] <liw> all those .deb packages just take up space on your hard drive, so you're better off removing them and using the space for something important
[20:11] <liw> (I'm joking :)
[20:12] <sebner> \sh: hmm maybe that app is some kind of mental doctor. /me should play games :P
[20:12] <\sh> mkfs.xfs /dev/sda1 (NTFS Partition) -> Removing Cruft
[20:13] <sebner> \sh: hrhr. bah ext4 ftw :P
[20:13] <\sh> sebner: na...ext4 needs some more testing from my side...before I rely on it ;)
[20:14] <cjwatson> jspiro: cruft-remover is in the same spirit as cruft, IMO
[20:14] <sebner> \sh: that's why I don't like server stuff and so on. Unstable ftw! :D
[20:14] <cjwatson> so I think the similar name is fine
[20:14] <sebner> cjwatson: /me wonders if it's installed by default now!?
[20:14] <jspiro> cjwatson: i think it's a bit confusing.  how about junk-remover or some other name?
[20:15] <cjwatson> sebner: no, we took it out
[20:15] <cjwatson> jspiro: enough with renamings :) we've already renamed it once
[20:15] <jspiro> cjwatson: you picked an imperfect name :)
[20:15] <sebner> cjwatson: but it was? /me hasn't reinstalled intrepid yet
[20:15] <liw> cjwatson, hey, I'm fine with renaming it for every release, and keeping the version number constant ;)
[20:15] <\sh> liw: lol
[20:16] <jspiro> witness phoenix (trademark of BIOS manufacturer) -> firebird (name of database software) -> firefox
[20:16] <Treenaks> cjwatson: Phoenix -> Firebird -> Firefox
[20:16] <liw> sebner, correct, it was part of the default install, but not anymore (hopefully will be again)
[20:16] <sebner> liw: hopefully not. it removed cruft that I wanted to keep xD
[20:16] <liw> sebner, that'll get fixed before it gets installed by default again, of course
[20:17] <\sh> I wonder when "Lenovo" will come to me and complain about "Leonov"
[20:17] <sebner> liw: ok then it's nice. removing all the kernel cruft was nice but not my games xD
[20:17] <cjwatson> jspiro: whatever
[20:17] <cjwatson> sebner: it was, yes
[20:17] <sebner> \me wonders when \sh will have time again for it
[20:17] <sebner> cjwatson: right decision, too buggy
[20:18] <cjwatson> jspiro: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers
[20:18] <\sh> sebner: from the 10th again...then I have my time back...and not running around in DCs all the time and doing other "not so important stuff" like real life work ;)
[20:18] <Treenaks> cjwatson: http://bikeshed.com/
[20:19] <Treenaks> cjwatson: (now in full colour!)
[20:19] <sebner> \sh: that's my /me likes to be unemployed  ^^
[20:19] <\sh> sebner: without my job I couldn't afford all the fun ubuntu / leonov stuff...
[20:19] <slangasek> Treenaks: that's a terrible <hr /> they're using on that page; it needs to be at least 15% shorter
[20:19] <ajmitch> \sh: how's leonov going?
[20:20] <sebner> \sh: don't you know the "olliver geissen show" with all the hartz4 people enjoying their lifes? ^^ xD
[20:20] <\sh> ajmitch: when everything is fine, I'll get rid of most parts of py-lp-bugs and switch over to lp-api completly
[20:21] <\sh> ajmitch: there  are still some things missing..but it will make our life much easier when speaking of "changing real stuff on LP"...
[20:21] <james_w> kees: are sha512 passwords created by something other than glibc's crypt()?
[20:21] <\sh> ajmitch: it's just my job which is in the way right now (since the last two months somehow)
[20:21] <jspiro> cjwatson: you're right.  I should stop complaining about cruft-remover's name and just enjoy the tool. :)  thank you for pointing that out.
[20:22] <ajmitch> \sh: nice, hopefully it can see some more use for jaunty
[20:22] <kees> james_w: shouldn't be, no.
[20:22] <kees> james_w: afaik, pam calls into glibc's crypt()
[20:23] <\sh> ajmitch: I think just in time before UVF we can include leonov into jaunty...
[20:23] <directhex> okay, how's this: explicitly don't mount network mounts during boot on systems that use n-m. handle it in a n-m way (e.g. whatever the equiv of if.post-up et al are)
[20:23] <james_w> kees: the crypt.texi in glibc is better than the crypt manpage, but it only describes 3DES and md5. I'm trying to follow the twisty paths to the implementation
[20:23] <kees> james_w: don't re-implement, go the call-chpasswd route (I've got a patch ready for shadow)
[20:24] <james_w> kees: ah, nice, thanks.
[20:24] <RainCT> kees: btw, did you find the problem about ubiquity encripting the password in /etc/shadow using the wrong method?
[20:24] <kees> RainCT: yeah, 51551
[20:25] <RainCT> wow, old bug
[20:25] <\sh> ajmitch: but a good idea would be to find a sponsor who is sponsoring me and one gtk dev for leonov for at least one year ,-) so I can leave work for one year for an unpaid leave and do real work ;)
[20:26] <ajmitch> \sh: heh, yes, I'd love to have the same :)
[20:26] <kees> james_w: http://people.ubuntu.com/~kees/shadow_4.1.1-1ubuntu2.debdiff
[20:27] <RainCT> kees: anyway, thanks for looking into it :)
[20:27] <\sh> ajmitch: how is NZ these days? more linux approaching or still on the MS travelling course?
[20:27] <james_w> kees: nice.
[20:27] <kees> RainCT: yeah, it's turning into an ever-growing problem.  :)
[20:27] <kees> james_w: http://pastebin.osuosl.org/22450
[20:27] <kees> (though you'll need "ENCRYPT_METHOD SHA512
[20:27] <kees> in your /etc/login.defs
[20:28] <ajmitch> \sh: hard to say, MS stuff still seems to dominate
[20:28] <james_w> kees: that's not default though right?
[20:28] <kees> james_w: not in intrepid, but it will be in jaunty
[20:28] <james_w> kees: cool
[20:28] <kees> james_w: oversight on my part -- I thought only pam needed it
[20:29] <kees> fixing /etc/login.defs will mostly fix 51551
[20:29] <ajmitch> \sh: to avoid being too OT here, let's take over #leonov instead :)
[20:29] <\sh> ajmitch: crap...I hope I can immigrate just before I'm too fat for NZs immigration rules ;)
[20:29] <james_w> kees: I'm not sure how to call an external program and capture the output in C.
[20:29] <james_w> kees: or do you propose to pass the password unencrypted over dbus?
[20:29] <kees> james_w: no, call it locally.
[20:29] <ogra> fork() ... pipe() ?
[20:29] <james_w> ok, I'll research how to do it.
[20:30] <kees> james_w: there are (probably too many) things documenting how to do it.  I would recommend popen
[20:30] <james_w> kees: have you read the rest of the s-t-b file in question?
[20:30] <james_w> kees: cool, thanks.
[20:30] <kees> james_w: yeah
[20:30] <james_w> not pretty, is it?
[20:30] <ogra> if its a glib capable app, use g_spawn_sync/async
[20:31] <james_w> kees: anything else in there needs to be fixed urgently, or is it just a little unpleasant?
[20:32] <kees> james_w: your sha\d+ is sufficient for intrepid.  the chpasswd+oobs patches should be for jaunty.
[20:32] <kees> james_w: (so, no, nothing urgent beyond the sha\d+ fix)
[20:33] <james_w> kees: yeah, sorry, I meant urgently as in jaunty.
[20:33] <kees> james_w: all the packages attached to bug 51551 need fixing too
[20:34] <kees> I'll handle shadow, and I think I can convince evand to do the d-i stuff.
[20:34] <james_w> cool, I'll take a look at the others.
[20:34] <james_w> I think we can make s-t-b respect login.defs as well as parse pam.d
[20:35] <kees> james_w: there's no reason to involve s-t-b at all if oobs ignores the use_md5 stuff and DTRT by calling chpasswd
[20:35] <james_w> ah, ok
[20:35] <james_w> got it now
[20:35] <james_w> # modifies /etc/shadow directly, not good practice,
[20:35] <james_w> # but better than passing clean passwords around
[20:36] <james_w> that's not nice, but is solaris only, so we don't have to fix it
[20:36] <kees> james_w: right, s-t-b uses "usermod" on linux, which is fine, if a bit crazy
[20:36] <james_w> kees: thanks for your help. When you forward the shadow patch can you drop me a link so I can point to it when forwarding the oobs one?
[20:37] <kees> the primary issue is killing a duplicate password-crypting implementation.
[20:37] <kees> james_w: yeah, totally.  I need to clean up the shadow patch a little anyway -- this is just an initial PoC
[20:38] <evand> kees: will do
[20:38]  * kees hugs evand
[21:44] <pregier> Are questions about live usb image construction best asked here or in the support channel?  The image made by usb-creator has some elements I don't recognize which is making customization a bit tricky; I'm trying to customize an image which doesn't require constant access to the boot device but I can't locate the mechanism that accesses the squashfs file in /casper...
[21:45] <cjwatson> evand: ^-
[21:50] <evand> pregier: the image created by usb-creator is the same as a live CD plus a casper-rw file and a few options changed in the syslinux configuration (additional kernel command line options)
[21:56] <ptx0> why does the default kernel in Intrepid have XEN_CONFIG=y :/
[21:57] <pregier> evand: That helps, but even then I'm still not sure which component is responsible for the squashfs file handling; is that ubuntu-specific in any way?
[21:58] <pregier> if it's a feature of the kernel or of syslinux which I've never seen,  then I'm probably in the wrong place altogether
[21:59] <cjwatson> the squashfs is mounted by casper's initramfs scripts
[21:59] <cjwatson> apt-get source casper
[21:59] <pregier> perfect; thanks!
[22:22] <pitti> Riddell: hm, so I am confused now; is http://launchpadlibrarian.net/19039704/kdebase-workspace_4.1.2-0ubuntu13_source.changes for bug 281950 or for bug 287488? AFAICS, one bug should be prepared for SRU (task, etc.); can you please give me a quick heads-up there?
[22:23] <Riddell> pitti: https://launchpad.net/bugs/287488 is the one I'm using now, I was using 281950 for the issue but the reporter insists he has a different issue so I went back to 287488
[22:25] <pitti> Riddell: right, so 281950 is the driver issue which doesn't have an SRU right now
[22:26] <Riddell> pitti: right (which I've not looked in to)
[22:35] <ptx0> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/290888
[22:38] <jdong> ptx0: I think we need a patch similar to debian bug 500175
[22:38] <jdong> i.e. nvidia is incorrectly detecting Xen
[22:38] <ptx0> correctly*
[22:38] <ptx0> hm
[22:40] <jdong> *in* correctly from what I can see
[22:40] <jdong> -        #ifdef CONFIG_XEN
[22:40] <jdong> +        #if defined(CONFIG_XEN) && !defined(CONFIG_PARAVIRT)
[22:41] <jdong> something like that.
[22:43] <ptx0> http://pastebin.com/m52f7dd1b
[22:49] <slangasek> kirkland: the release notes text in bug #290445 is also not yet accurate, right, because the package fixing this is not available?
[22:50] <kirkland> slangasek: would you care to sponsor?
[22:50] <kirkland> slangasek: the patch is in that bug
[22:50] <kirkland> slangasek: jdstrand was waiting for the -updates repo to open
[22:51] <jdstrand> kirkland: I can push it out
[22:51] <slangasek> kirkland: it's already open; but even so it needs to go through the SRU process which involves a waiting period, it would be good to have release notes that are accurate at release time
[22:51] <kirkland> slangasek: okay
[22:51] <jdstrand> that was my thinking
[22:51] <jdstrand> kirkland: I'll upload it soon
[22:53] <kirkland> slangasek: i'm good with whatever test you want to go with, in that case
[22:57] <slangasek> darn
[22:57] <slangasek> I don't have any text for it yet :)
[23:00] <kirkland> slangasek: shall i rework it again?
[23:00] <slangasek> if you could, that would be lovely
[23:00] <slangasek> if not it goes on my stack
[23:01] <kirkland> slangasek: i've got my kubuntu iso install going, so i'll do it
[23:01]  * Riddell hugs kirkland
[23:03] <kirkland> Riddell: ;-)
[23:04] <kirkland> slangasek: i could hardcode the version, that the user should upgrade to >= 53-1ubuntu12 (or wait until that is available) ?
[23:05] <slangasek> kirkland: hard-coding the version number seems reasonable to me; probably with some brief explanation that it's not available at day-one
[23:05] <kirkland> slangasek: cool, uno momento
[23:07] <kirkland> slangasek: robbiew: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/290445 updated text there
[23:15]  * calc bought a new dect phone with bluetooth support :)
[23:15] <calc> no more interference in phone calls from my wifi
[23:22] <pwnguin> http://twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject =(
[23:25] <jdong> pwnguin: ugh I have enough of a grudge against them that the project can burn in hell.
[23:25] <jdong> pwnguin: I created a website back then off twiki 3.x.x and lived through all the hell
[23:25] <jdong> pwnguin: multiple quote mark shell escapes, attachment execution vulnerabilities, search infinite loop DoS, the entirely incompatible 4.x.x upgrade....
[23:25]  * jdong shudders
[23:25] <NCommander> jdong, I perfer MediaWiki or MoinMoin over TWiki :-/
[23:26]  * NCommander grumbles
[23:26] <jdong> NCommander: as do I. I've learned my lesson.
[23:26] <jdong> NCommander: I was a young one back then
[23:26] <jdong> even before backports was conceived :)
[23:30] <calc> yipee my evil bug got fixed :)
[23:30] <calc> well one of my evil bugs
[23:50] <luisbg> slangasek: ping! you around_
[23:50] <luisbg> ?
[23:50] <slangasek> luisbg: hi
[23:51] <luisbg> slangasek: http://ubuntustudio.org/release_note
[23:51] <pwnguin> jdong: apparently the lead developer appointed himself bdfl, because that's how ubuntu did it.
[23:51] <pwnguin> and then locked everyone out?
[23:51] <luisbg> slangasek, should the formating be improved or maybe the url to something like ubuntustudio_8-10
[23:51] <luisbg> ?
[23:52] <slangasek> luisbg: I think moving the url is a good idea.  You also say "See the Ubuntu release notes for other non Ubuntu Studio specific changes.", but the Ubuntu release notes document errata, not changes in general
[23:53] <slangasek> so that might benefit from clarification
[23:54] <luisbg> slangasek: http://ubuntustudio.org/8-10_release_note
[23:54] <ogra-Q1> moop
[23:54] <luisbg> its there now, which looks much better
[23:54] <luisbg> slangasek: I dont understand what you say about the "See the Ubuntu release notes..." :S
[23:55] <slangasek> luisbg: you tell people "See the Ubuntu release notes for other non Ubuntu Studio specific changes."  If people go to the Ubuntu release notes, what they get is not what I think they'll expect based on that sentence
[23:55] <luisbg> how would you phrase it?
[23:57] <slangasek> luisbg: are the release notes what you want to point users at?  i.e., https://wiki.ubuntu.com/IntrepidReleaseNotes ?
[23:58] <luisbg> no
[23:58] <slangasek> then I don't think it's a question of phrasing :)
[23:58] <luisbg> the press release anouncing the new version and a quick summary of what it has
[23:58] <slangasek> press release is at http://www.ubuntu.com/news/ubuntu-8.10-desktop
[23:59] <slangasek> and should probably be referred to as "the Ubuntu press release"
[23:59] <luisbg> ok
[23:59] <luisbg> changing that
[23:59] <slangasek> anyway - I've included the link to this page in the mail draft, so thank you
[23:59] <luisbg> no problem :)
[23:59] <luisbg> thanks to you