[02:49] <tfheen> there's this, there's the crack about using stdin/stdout and other things.
[02:50] <seb128> vim-tiny built without multibyte support (bug #361378), would it been considered as something to fix for edgy? A bug triager pointed it on #ubuntu-bugs, it seems to be the cause for some bugs already reported
[02:51] <tfheen> seb128: not edgy.  IMO.
[02:51] <Kamion> tfheen: the signal handling is just a bug, but I'd like to get unixsocket in for edgy+1, yes
[02:51] <pips1> bug 66726
[02:51] <Ubugtu> Malone bug 66726 in usplash "edubuntu artw ork has funny colors on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66726
[02:51] <seb128> bug #66733 I mean
[02:51] <Ubugtu> Malone bug 66733 in vim "Edgy's vim-tiny doesn't have multibyte support" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66733
[02:51] <seb128> tfheen: ok
[02:52] <seb128> tfheen: I'm asking because that's the default vim, and it doesn't allow to edit utf-8 files correctly apparently
[02:53] <Kamion> hmm, that is rather nasty
[02:53] <heno> janimo: does it work in gnome as well?
[02:53] <tfheen> oh, I thought vim was desktop
[02:53] <janimo> heno: I only tested in gnome :)
[02:53] <tfheen> but it's just -ship.
[02:53] <tfheen> seb128: I think we should fix it, then.  Post-RC.
[02:53] <heno> janimo: it would be nice if that could ship yes
[02:53] <Kamion> vim-tiny is minimal
[02:53] <Kamion> I'm happy to take responsibility for fixing that post-RC
[02:53] <janimo> heno: I'll attach the patch to the same bug in LP
[02:53] <tfheen> Kamion: yeah, I knew that, but I thought vim proper was -desktop.
[02:54] <seb128> Kamion: thank you
[02:54] <heno> ok, thanks
[02:54] <seb128> tfheen: the issue is vim-tiny
[02:54] <Kamion> milestoned and assigned to me
[02:54] <tfheen> seb128: yes, but it would have been less of an issue if vim (proper) was -desktop.
[02:55] <seb128> tfheen: right
[03:02] <tfheen> Kamion: http://err.no/patches/cdrom_checker_workaround_cdebconf_exit_status_propagation.diff works for me.  Post-RC?
[03:02] <infinity> pitti: chinstrap:~adconrad/ffox/
[03:03] <infinity> Kamion: Did you get my above message and re-spin the other desktop/live ISOs?
[03:04] <pitti> infinity: yay
[03:04] <infinity> pitti: Do you want a matching i386+all build to go with that?
[03:04] <infinity> pitti: I didn't build arch-indep in that build...
[03:05] <pitti> infinity: would be nice for a call for testing
[03:05] <infinity> pitti: Oh, true, I'll do i386+all and powerpc then, so you can get broad testing.
[03:05] <mdz> Riddell: what's the story with bug 63325?
[03:05] <Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  http://launchpad.net/bugs/63325
[03:07] <Riddell> mdz: I've been working on a fix but not got it totally sorted yet, if it doesn't get fixed it's not the biggest of problems
[03:07] <Kamion> infinity: yes, done
[03:07] <infinity> Kamion: Cool.
[03:07] <infinity> Just checking. :)
[03:07] <Kamion> tfheen: fine by me if it's tested
[03:09] <Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
[03:10] <cbx33> is there a known problem with printing?
[03:10] <cbx33> or was there?
[03:11] <seb128> cbx33: printing is wide
[03:12] <cbx33> um....gnome printing
[03:12] <seb128> some extra details on what sort of issue would probably make easier for you to get a reply
[03:12] <seb128> still wide
[03:12] <seb128> I was thinking to something like
[03:12] <seb128> "printing from gedit generates only blank pages"
[03:12] <seb128> or something like that :)
[03:12] <seb128> (the example is a random example, not a real one)
[03:13] <cbx33> well....I have to confirm but since my update to edgy...printing seems totally broken
[03:13] <seb128> "totally broken" still not good
[03:13] <seb128> how broken?
[03:13] <seb128> do you get any message?
[03:13] <cbx33> I'm getting more info
[03:13] <cbx33> hang on
[03:13] <seb128> pages are not going out of the printer?
[03:13] <seb128> content is not correct?
[03:13] <cbx33> pages seem to go into the queue
[03:14] <Keybuk> tfheen: jamesh reported bug #66360, it's a trivial fix (sync from Debian -- which just brings in a translation update)
[03:14] <Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Unknown,Unknown]  http://launchpad.net/bugs/66360
[03:14] <cbx33> lemme just check the machine it's connecting to
[03:14] <Keybuk> tfheen: basically a package missed that still uses daniels X paths, rather than real ones
[03:14] <cbx33> seb128 ignore that
[03:14] <seb128> cbx33: ?
[03:14] <cbx33> it's working now...must have just been having a slow day
[03:14] <seb128> k
[03:24] <tfheen> Keybuk: I wonder why I have /usr/share/X11/fonts still.
[03:25] <Keybuk> tfheen: upgrade?
[03:25] <tfheen> Keybuk: it should have been nuked then
[03:25] <Keybuk> mine is empty and just contains fontconfig crap
[03:26] <tfheen> yes, it's just fonts.* and encodings.dir here too.
[03:26] <mdz> Riddell: medium or low?
[03:27] <pitti> mdz: ah, the m-firefox-locale-all question more or less resolved itself -- we need to ship the matching xpis unless we want to ship with a broken hel0p
[03:27] <pitti> s/0//
[03:27] <mdz> pitti: oh, I missed that question
[03:27] <mdz> pitti: does that involve a round trip to rosetta?
[03:27] <pitti> mdz: no
[03:27] <mdz> ok
[03:27] <pitti> mdz: we don't have langpack support for Firefox yet
[03:27] <mdz> right
[03:27] <mdz> and we don't export XPIs either
[03:27] <pitti> mdz: of course I'll test all languages that we ship
[03:28] <mdz> pitti: how many of those do you speak? ;-)
[03:28] <pitti> s/ship/support/
[03:28] <pitti> mdz: well, I can't check the translations obviously, but I can check for XML failures and if the help works :)
[03:29] <pitti> I can check German, en-GB, and Russian, and I can recognize some Spanish, Czech, Polish, and French words
[03:29] <pitti> the rest is 'ah, looks nice and looks like Chinese' :)
[03:29] <mdz> pitti,sfllaw: I think the manual partitioning and auto resize test cases should be reversed in order, since it seems that usually manual partitioning is necessary to get a layout which can be auto-resized
[03:30] <mdz> the page should probably have a note about how to get there as well
[03:30] <pitti> mdz: yesterday I thought I had figured out how to get there, but I still cannot reproduce it consistently
[03:30] <mdz> erase disk -> auto-resize used to work
[03:30] <mdz> but no longer
[03:30] <mdz> (used to work in dapperish times)
[03:30] <pitti> mdz: apparently it does for Kamion
[03:31] <pitti> but not for me
[03:31] <mdz> nor me
[03:31] <mdz> (in vmware)
[03:31] <pitti> I usually do a manual install with a single large partition
[03:31] <mdz> and no swap?
[03:31] <pitti> putting swap as a first partition works, too
[03:39] <leonel> hello  where can I find or ask about  SUN JDK  in ubuntu ?
[03:39] <leonel> hello  where can I find information about updates for the    SUN JDK  in ubuntu ?
[03:40] <Mirv> leonel: ask in channel #ubuntu
[03:41] <bddebian> Howdy folks
[03:42] <leonel> ok  Mirv thanks
[03:42] <Riddell> mdz: low I guess, it just means some translations will be unused
[03:43] <doko_> tfheen: please consider http://people.ubuntu.com/~doko/edgy/python-central.debdiff for the RC, reviewed by mvo; it makes the upgrade more robust and allows people with broken installations to recover.
[03:53] <pitti> hi sbalneav
[03:53] <sbalneav> Hey pitti!
[03:54] <sbalneav> I'll be buying you those beers I owe you soon!
[03:54] <sbalneav> :)
[03:54] <pitti> sbalneav: you'll come to UMV?
[03:54] <sbalneav> I will!
[03:54] <sbalneav> Like a bad penny, I keep turning up :)
[03:55] <pitti> sbalneav: great! I'm looking forward to seeing you again
[03:55] <sbalneav> Likewise!
[03:55] <tfheen> doko_: no, for RC it's not appropriate.
[03:57] <sladen> hope so
[03:58] <mdz> Riddell: jane pointed out that the kubuntu upgrade instructions need a bit more detail; please see the FIXME
[04:07] <mvo> fabbione: I drafted some notes about the upgrade
[04:10] <pitti> mvo, infinity: on dapper->edgy upgrade I get a conffile question about /etc/initramfs-tools/initramfs.conf (##RESUME= -> #RESUME=); is that known?
[04:11] <thom> pitti: mdz was fixing that earlier
[04:12] <mdz> pitti: fix is uploaded and queued for post-RC
[04:12] <pitti> ah
[04:12] <Riddell> mdz: done
[04:13] <mdz> Riddell: thanks
[04:14] <mdz> sfllaw: ping
[04:14] <mvo> pitti: yes, see the Testing/Current page
[04:14] <pitti> mvo: ok, thanks
[04:15] <mvo> np
[04:37] <infinity> pitti: Okay, concrete proof I need sleep sometime; I just made the same CurrenlyBuilding mistake on the other two builds.  Re-building for you. :/
[04:37] <pitti> infinity: you rock
[04:38] <infinity> pitti: Not today, I don't. :)
[04:38] <pitti> maybe today a little less than usual :)
[04:39] <mdz> pitti: so it appears that it works OK on the buildds but not in the chroots you tried?
[04:39] <pitti> mdz: right
[04:40] <infinity> mdz: Yeah, I'll have to work with pitti a bit later to see why it's not working on his box.  Could be a sleeper bug somewhere.
[04:40] <pitti> mdz: I can live with that for the moment, although it doesn't feel right
[04:40] <pitti> aah, I finally found the culprit that's breaking half of firefox translations
[04:41] <mdz> infinity: not his box or the porting box
[04:41] <mdz> pitti: oh?
[04:41] <infinity> mdz: Yeah, that's even worse.
[04:41] <pitti> mdz: yeah, installing one faulty XPI ruins a random subset of other translations :)
[04:42] <mdz> pitti: this was only on amd64 in both cases, right?  did it build for you on i386?
[04:43] <pitti> mdz: right, I didn't try i386, since I don't have an i386 edgy here ATM
[04:44] <keescook> (joining in the middle of the conversation) what wasn't building?  Can I help test?  (i've got both amd64 and i386 edgy chroots)
[04:44] <pitti> keescook: firefox isn't building for me on amd64/edgy
[04:44] <mdz> keescook: a very strange firefox build failure which happened for pitti locally, and on another manual build as well, but doesn't happen on the autobuilders
[04:44] <infinity> keescook: firefox doesn't build on ronne or on pitti's machine, but works fine on my buildds and my laptop.
[04:44] <mdz> infinity: i386 laptop?
[04:44] <pitti> mdz: ... and does happen on ronne, too
[04:45] <infinity> mdz: Yeah.
[04:45] <mdz> pitti: do you have a full build log?
[04:45] <pitti> mdz: ronne should be quite similar to the buildds, with running dapper kernel and all that
[04:45] <infinity> pitti: Will you be around tomorrow for me to walk you through recreating a buildd-alike on your machine to narrow down some variables?
[04:45] <infinity> The buildds don't run dapper kernels, they run a home-brew <IP_ADDRESS>.
[04:45] <pitti> mdz: http://people.ubuntu.com/~pitti/tmp/firefox_1.99+2.0rc3+dfsg-0ubuntu1_amd64.build
[04:46] <pitti> infinity: can do
[04:46] <elmo> infinity: it's dapper kernel source, just custom config
[04:46] <infinity> elmo: Ahh, kay.
[04:46] <elmo> and ronne == buildds, for kernels.  for most arches.  the less well supported arches (powerpc, sparc, hppa) all run dapper kernels
[04:46] <infinity> I expect ronne's is more or less the same anyway.
[04:47] <keescook> hmm. where's the .dsc?  I can stuff it through my sbuild/schroot setup and see what happens.
[04:47] <infinity> pitti: How's your bandwidth?
[04:47] <pitti> infinity: poor
[04:47] <infinity> keescook: The .dsc is there.
[04:48] <pitti> infinity: well, 300 kB/s, but only 300 MB quota left for the next couple of days
[04:48] <keescook> infinity: ah, gotcha
[04:48] <infinity> pitti: Ow... Kay.
[04:48] <dholbach> did we get oopses like that already (installation on usb disk):  http://daniel.holba.ch/temp/oops ?
[04:48] <pitti> infinity: well, should be a little more actually
[04:48] <pitti> infinity: I have 3 GB in any seven days
[04:48] <pitti> and I'm at 80%
[04:48] <elmo> let me dist-upgrade edgy on ronne
[04:48] <elmo> it's bound to be out-of-date
[04:49] <infinity> pitti: Alright, well, the chroot tarballs are small anyway, so if you have a hot apt cache you can steal the build-deps from, it won't be too bad. :)
[04:49] <mdz> pitti: your local chroot is up-to-date, right?
[04:49] <pitti> infinity: I do have all build deps for firefox here
[04:49] <mdz> infinity: do we still wrap gcc on the buildds?
[04:49] <pitti> mdz: right, I just freshly created it and installed build-deps from CD
[04:50] <pitti> s/CD/archive/
[04:50] <infinity> pitti: Kay, tomorrow we'll play with "making it just like crested", then.
[04:50] <pitti> my main system is up to date, too
[04:50] <pitti> infinity: heh, let's :)
[04:50] <infinity> mdz: No more gcc-opt or ccache.  It's just bare g++
[04:50] <Kamion> dholbach: that's usually squashfs reacting REALLY BADLY to a badly burned CD or a dirty CD drive lens
[04:50] <mdz> pitti: can we compare the nsCOMPtr.o from a good build and a failed build?
[04:51] <dholbach> Kamion: oh good to know, I'll give it another try then - thanks.
[04:51] <infinity> mdz: We could if I hadn't blown away the chroot I used to build.  I can always re-do the amd64 build, though.
[04:51] <elmo> (no ccache?!)
[04:51] <pitti> mdz: should be fine to compare against ronne:~pitti/firefox/firefox-1.99+2.0rc3+dfsg (against infinity's build tree)
[04:52] <infinity> elmo: It was on my todo to get ccache back in one way or another after removing gcc-opt from the equation, but it wasn't a high priority, as the package that always seemed to benefit the most (12 xorg uploads in a day, yay!) was a non-issue now.
[04:53] <infinity> elmo: And taking it out of the equation does prevent some quirkier FTBFS issues with some sketchy build systems *cough*scons*cough*
[04:53] <elmo> fair enough
[04:53] <pitti> okay, powerpc/alternate and dist-upgrade is happy
[04:53] <mdz> http://www.google.co.uk/search?q=nsCOMPtr.o%3A+relocation+R_X86_64_PC32&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:unofficial&client=firefox-a
[04:54] <pitti> tfheen: so you rolled 17.2 for all architectures again? I thought only for ppc?
[04:54] <infinity> pitti: Re-rolling powerpc will re-publish everythin else under the same name/directory.
[04:54] <mdz> also bug 63814
[04:54] <Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
[04:54] <mdz> apparently dholbach saw this before as well
[04:55] <mdz> bug 61104 seems relevant
[04:55] <Ubugtu> Malone bug 61104 in gcc-4.1 "Build process of firefox trunk is broken with both gcc 4.1.1 and gcc 4.0 !" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61104
[04:55] <mdz> doko_: ^^
[04:55] <pitti> infinity: ah, so for i386 and amd64, 17.1 and .2 are identical?
[04:55] <infinity> pitti: Should be, yes.
[04:55] <infinity> pitti: Timestamps should give that way.
[04:55] <pitti> well, given that the desktop testing matrix is empty anyway, I can as well bump the version
[04:56] <pitti> infinity: s/17.2/18; s/17.1/17.2/ of course
[04:57] <infinity> pitti: Yeah, note the timestamps at http://cdimage.ubuntu.com/daily-live/20061018/ and how only the powerpc ISO is "new", the rest are a bit stale.
[04:57] <infinity> (But the torrents get re-done on each re-publish)
[04:57] <pitti> ah, sweet
[04:57] <Kamion> pitti: correct, as I said a while back
[04:57] <Kamion> 14:09 < Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
[04:58] <pitti> ah, didn't catch that
[04:59] <elmo> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... test: 1: ==: unexpected operator
[04:59] <Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
[04:59] <mdz> there are quite a lot of reports of this same build failure with firefox/thunderbird on the web
[04:59] <elmo> no
[04:59] <elmo> are those relevant?
[04:59] <elmo> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... test: 1: ==: unexpected operator
[04:59] <Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
[04:59] <elmo> no
[04:59] <elmo> I saw that flash past in a build log
[04:59] <sfllaw> Kamion: Thanks.
[04:59] <mdz> elmo: oooh
[05:00] <elmo> god, I would kill for buildd.d.o/pkgname type shortcuts in launchpad
[05:00] <pitti> mdz: for testing I entirely disabled the visibility=hidden check in configure, didn't help
[05:00] <mdz> pitti: what does it do if the test succeeds?
[05:01] <pitti> mdz: I'll fix the == and check if it works with the bug test
[05:01] <infinity> elmo: I'm to the point of doing javascript bookmark popups in firefox to bounce me places.
[05:01] <mdz> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes
[05:01] <mdz> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no
[05:01] <Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
[05:01] <Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
[05:01] <mdz> pitti: that test passes on the buildds
[05:01] <elmo> mdz: the amd64 buildd doesn't have that unexpected operator gumph
[05:01] <mdz> infinity: what's /bin/sh on the buildds
[05:01] <infinity> Ah-ha.
[05:02] <pitti> right, == is a bashism
[05:02] <infinity> mdz: /bin/sh on the buildds is bash, because I didn't want to break the world 3 weeks ago when I noticed it hadn't been switched.
[05:02] <infinity> So, we have a winner here.
[05:02] <mdz> ok
[05:02] <mdz> so it's a gcc bug
[05:02] <mdz> but firefox works around it
[05:02] <infinity> mdz: (It's going to dash first thing in feisty)
[05:02] <mdz> but the workaround has a bashism
[05:02] <pitti> mdz: ok, I'll fix the firefox source accordingly
[05:02] <mdz> wheels within wheels
[05:02] <infinity> pitti: If you fix the bashisms, does the world work for you?
[05:02] <elmo> within wheels within wheels
[05:03] <mdz> infinity: I bet a dollar
[05:03] <infinity> I'm not taking that bet.
[05:03] <elmo> I'm test building on ronne now, will let you know
[05:03] <pitti> elmo: heh, me too; /me cancels
[05:03] <mdz> doko: is gcc 20297 the same as bug 63814?
[05:03] <Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
[05:03] <elmo> = is the non-bash version, right?
[05:03] <infinity> elmo: yes.
[05:04] <Kamion> @bugtracker add gcc bugzilla http://gcc.gnu.org/bugzilla/
[05:04] <Kamion> wonder if I have leet Ubugtu privileges somehow
[05:04] <Kamion> gcc bug 26905
[05:04] <Ubugtu> gcc bug 26905 in c++ "default-visibility class symbol improperly resolved as hidden-visibility" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
[05:04] <infinity> Apparently.
[05:04] <Kamion> bingo
[05:04] <Kamion> GCC bug 20297
[05:04] <Ubugtu> gcc bug 20297 in middle-end "#pragma GCC visibility isn't properly handled for builtin functions" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[05:05] <mdz> doko: I meant 61104
[05:05] <sladen> elmo: = is posix  == is bash
[05:05] <infinity> I've never understood why that Cism crept into bash anyway, but whatever.
[05:05] <infinity> Yay for confusion.
[05:05] <mdz> pitti: is that an upstream bug?
[05:06] <pitti> mdz: the bashism? no, that's a Debian specific patch to work around the gcc problem
[05:06] <mdz> yes, the bashism. ah
[05:06] <infinity> Oo, go us.
[05:06] <mdz> pitti: what does it do to work around the bug?
[05:07] <sladen> infinity: mentally I prefer '==' since '=' is something else, namely assignment.  Languages like basic are confusing to beginners because two different operators share one representation
[05:07] <elmo> the build seems to be going further, I suspect that fixes it
[05:07] <infinity> sladen: Yeah, but you can't assing in shell with $var = foo, so...
[05:07] <mdz> sladen: = is equality, == is very very equality
[05:08] <infinity> sladen: I understand why C (and perl and PHP, and many languages) need to make the distinction, but shell just plain doesn't let you do that anyway, so adding a == operator to make others more comfy with bash just ends up confusing (and making us write bad patches, apparently)
[05:09] <Ng> hey folks, apologies for being slightly offtopic, but if any of you have a SIP client, could you call<EMAIL_ADDRESS>now to give us a hand with some testing please?
[05:09] <sivang> Ng: don't forget those hubackup bugs :)
[05:09] <sivang> re all
[05:09] <Ng> sivang: yeah I have them in tomboy. I noticed most of them are reported already
[05:11] <sivang> Ng: cool
[05:12] <sladen> Ng: so, who's in there?
[05:16] <pitti> mdz: it does this: VISIBILITY_FLAGS='-I$(DIST)/include/system_wrappers -include $(topsrcdir)/config/gcc_hidden.h'
[05:16] <pitti> mdz: and the latter does '#pragma GCC visibility push(hidden)'
[05:19] <elmo> ok, this isn't actually offtopic, it's for UDS
[05:19] <elmo> if you have a machine with any kind of soundcard, regardless of whether or not you have headphones or a mic, please help us stress test the conf call facility by dialing<EMAIL_ADDRESS>[05:20] <Spads> also, it helps if you try the echo test out first at<EMAIL_ADDRESS>[05:20] <pitti> does that work with ekiga?
[05:20] <elmo> pitti: yes
[05:20] <Spads> pitti: most of us are using ekiga
[05:20] <elmo> it works with any SIP capable phone
[05:20] <elmo> or client
[05:27] <Nafallo> hmm
[05:27] <Nafallo> low volume :-/
[05:27] <Ng> turning off echo cancellation is a good plan
[05:27] <pitti> Spads: if I dial 6701, I get two 'free' tones, and then a 'busy' tone; is that correct?
[05:28] <Spads> pitti: hmmm, it should stay connected, and repeat everything you say back to you
[05:28] <pitti> argh, I see, login has failed
[05:28] <pitti> I do remember seeing 'logged in' (freely translated), now it's failed'
[05:28] <Nafallo> Ng: I finally found the option, thanks :-)
[05:29] <elmo> pitti: you shouldn't need to login
[05:29] <elmo> not to get to the conf call at least
[05:29] <pitti> hmm
[05:29] <elmo> I doubt the echo test either
[05:29] <pitti> elmo: I get the same 2x free, 1x busy, hangup for 5501
[05:29] <elmo> pitti: hmm, maybe it's your firewall of death
[05:30] <pitti> sure, I disabled STUN as advised in the wiki
[05:30] <pitti> but that's only for incoming calls anyway, isn't it?
[05:30] <Nafallo> oh? supposed to disable that?
[05:31] <keescook> it seemed to me that if you're behind a NAT, and you can get registered, you don't need STUN.
[05:31] <keescook> but I've only tried sip once before.
[05:31] <pitti> hm, it says 'security check failed' in the status bar, does that mean anything?
[05:32] <keescook> not sure.  :(  wrong password?
[05:33] <pitti> it's the one I was given by mail
[05:33] <mdz> tfheen: is the current candidate still without showstoppers?
[05:33] <mdz> tfheen: and have you heard from sfllaw at all?
[05:34] <tfheen> mdz: I haven't heard of any showstoppers with them, at least.
[05:34] <tfheen> mdz: no, I haven't heard from Simon.
[05:35] <mdz> he mentioned something the other day about not feeling well I think
[05:35] <pitti> no, still 'login failed: not allowed'
[05:35] <sfllaw> Uhm, I am here.
[05:38] <pitti> mdz: ffox build is now going well for me, too
[05:38] <pitti> \o/
[05:38] <dholbach> congratulations pitti!
[05:39] <pitti> dholbach: well, the credit is due to elmo, he spotted the bashism
[05:39] <dholbach> ahhh great!
[05:39] <mdz> sfllaw: I take it you didn't see either of my messages in channel earlier?
[05:40] <doko_> mdz: 61104, tried a backport from the redhat/gcc-4_1-branch, which works for ff, but breaks the OOo build ... it's definitely fixed in 4.2
[05:40] <mdz> doko_: and we're going with 4.2 after edgy?
[05:43] <sfllaw> mdz: I saw the one about new PPC images.
[05:43] <mdz> sfllaw: I didn't say anything about new PPC images
[05:44] <doko_> mdz: not before it's released. it will branch this week
[05:44] <sfllaw> mdz: Ah, sorry.  That was Kamion.
[05:45] <sfllaw> I suppose swapping those auto-resize and manual does make sense.
[05:46] <mdz> fabbione: why are all of the sparc CD test cases marked N/A?
[05:47] <mdz> oh, the server ones aren't
[05:48] <mdz> sfllaw: there are no known showstoppers in the current candidate, but very few test cases are filled in
[05:48] <mdz> sfllaw: all of the most important ones are assigned to cr3, but he isn't in here
[05:49] <sfllaw> I'll invite him.
[05:49] <lool> seb128: around?
[05:51] <lool> seb128: I'd like to discuss the spec on easy codecs installation
[05:52] <lool> seb128: I wonder if it would make sense to extend its scope slightly to cover more problems; instead of focusing in mime type => gstreamer element mappings, we might want to provide some general feature => package mapping with a common UI to search and install packages or popup web pages
[05:53] <lool> seb128: this would at least cover the KDE use case
[05:54] <lool> seb128: concerning the storage of the mappings, I thing Xb- headers would permit some sort of simple implementation which we could automatically provision with gst-inspect at build-time, but it has some limitations because of the packages that would be in repositories not visible to apt; of course, it doesn't cover codecs which are not in packages
[05:55] <lool> seb128: finally, the specs shortly mentions that non-admin users can't install codecs, but on the other hand gstreamer perfectly permits installing plugins in ~/, so perhaps it makes sense to support this?
[05:55] <lool> (I've added most of the above on the wiki page of course, but thought it would be interesting to discuss implementation live a little)
[05:56] <mdz> Kamion: selecting 'use largest continuous free space' with only ~200M of free space seems to allow me to continue although it is doomed to fail
[05:57] <mdz> and I can't seem to convince it to offer me the resize option
[05:57] <mdz> cr3: how goes it?
[05:58] <cr3> mdz: it's going more or less, that installation bug I logged is worrying me
[05:59] <tfheen> cr3: which bug is that?
[06:00] <cr3> tfheen: 66632
[06:00] <tfheen> bug 66632
[06:00] <Ubugtu> Malone bug 66632 in linux-source-2.6.17 "Ubuntu 6.10 Desktop for i386 installation crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66632
[06:02] <cr3> sorry for the crappy bug subject, I have no clue what's going on so I preferred to log the bug early instead of waiting a day while trying to gather more information
[06:03] <tfheen> yes, I'm reading the bug now, judging how critical it is.
[06:04] <wasabi> ajmitch: ping
[06:05] <tfheen> cr3: had any chance to test the media, etc on the machine?
[06:06] <cr3> tfheen: I had tested the media before, as stated in my bug report. I have been running memtest86 all morning, still not finished
[06:07] <cr3> tfheen: I will update the bug report as soon as I have new information
[06:07] <tfheen> cr3: I'm worried about your "On the other hand, I am also getting installation failures on other systems."
[06:07] <cr3> tfheen: I'm trying to get some relevant information from that system as well, and I will probably log another bug report as soon as I have some sort of substance.
[06:07] <tfheen> cr3: thanks.
[06:08] <cr3> fuck, crashed again, this time at 22% and last time at 46% :(
[06:08] <pitti> infinity: are the i386/ppc firefox builds finished?
[06:09] <mdz> cr3: have you been able to successfully install on any machines?
[06:14] <cr3> mdz: yes: t1000, t2000, Precision 380, Dimension 9150 and a couple netinstalls on gigabyte boards
[06:15] <mdz> cr3: great news; could you update Testing/Current with those results?
[06:16] <cr3> mdz: sure, but I have a few reports to generate beforehand
[06:18] <mdz> cr3: reports?
[06:21] <elmo> Kamion: ping?
[06:21] <Kamion> elmo: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
[06:21] <elmo> har har
[06:21] <cr3> mdz: certification reports, that is ultimately my responsibility so I need to generate them quickly. it shouldn't take long though, probably an hour or so
[06:23] <pitti> does anyone else apart from infinity have access to the buildds? infinity did i386 and ppc builds of firefox 2.0rc3, and I'd like to put the binaries on rookery for testing
[06:25] <tfheen> pitti: the sysadmin team has
[06:26] <pitti> elmo: ^ if you have a minute, can you please copy these binaries to chinstrap or rookery?
[06:26] <elmo> what?  soyuz builds?
[06:26] <elmo> they're not stored on the buildd
[06:28] <cr3> mdz: I have another installation crash on a Dimension 5150, any files you'd like other than /var/log/dmesg?
[06:29] <cr3> kern.log seems to contain interesting information as well
[06:30] <pitti> elmo: I guess so, infinity wanted to manually build them; he did amd64 on a buildd (crested), so I guess he used a buildd for the other arches
[06:30] <pitti> elmo: right, he spoke about an invalid CurrentlyBuilding, so this must have been a buildd
[06:32] <mdz> cr3: wiki.ubuntu.com/DebuggingSystemCrash
[06:33] <mdz> cr3: since it's reproducible, just switch to a text console while the installer goes, and you should either see the panic or at least be able to do sysrq commands to get more info
[06:33] <elmo> pitti: yeah, sorry, I don't think I can help - you really want a team soyuz person or similar
[06:33] <elmo> if he built it on crested, that's a soyuz buildd and the binaries are sent back to drescher over XMLRPC and I can't retrieve them from the buildd
[06:34] <elmo> they really should be available from the librarian, if you can find them in the web UI
[06:42] <Kamion> mdz: continuous> yes, I don't think we ever filled in that particular bit of intelligence in partman. Bug report on partman-auto please?
[06:42] <pitti> elmo: ah, thank you anyway
[06:42] <Kamion> mdz: resize> as usual, I can debug given /var/log/partman (and time to stare at it)
[06:42] <Kamion> elmo: yes?
[06:45] <Kamion> right, now that two sets of parents have left I can get some work done ;-)
[06:46] <Kamion> (though they have been very helpful otherwise ...)
[07:00] <cbx33> hi guys, inlight of future ubuntu development
[07:00] <cbx33> what language is most needed by ubuntu?
[07:00] <cbx33> c/C++/python/mono/Java...?
[07:02] <pradeep_> cbx33, i think c and python
[07:03] <thom> c/python/shell
[07:03] <thom> and you'll be pretty much laughing to start with
[07:05] <Keybuk> lua!
[07:05] <pitti> elmo: cprov does not have an accound on adare/vernadsky any more, so he cannot fetch the debs for me; those were manual builds, thus they weren't uploaded anywhere
[07:06] <mdz> Kamion: ok, it's trivially reproducible for me, so I'll do so now
[07:14] <Kamion> any chance we could get bug 60071 fixed for final?
[07:14] <Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60071
[07:14] <tfheen> Kamion: I thought I fixed that?
[07:14] <tfheen> or rather, worked around it.
[07:15] <Kamion> tfheen: it now fails on /filesystem.squashfs/usr/bin/yelp, but same difference ...
[07:15] <Kamion> (rather than /casper/filesystem.squashfs/...)
[07:15] <tfheen> Kamion: is the cdrom mounted?
[07:16] <Kamion> tfheen: er, it's on a live CD ...
[07:17] <Kamion> (so yes)
[07:19] <mdz> Kamion: sounds awfully like a kernel issue
[07:19] <mdz> presumably /proc/pid/exe has that path
[07:20] <tfheen> mdz: yes, that's the problem.
[07:20] <mdz> we could hack around it in l-i for final
[07:21] <Kamion> tfheen: /proc/pid/cmdline doesn't always have the full path, so that doesn't work
[07:21] <mdz> but probably not fix the underlying issue
[07:21] <Kamion> $ cat /proc/7344/cmdline; echo
[07:21] <Kamion> gnome-terminal
[07:21] <elmo> Kamion: getting debconf prompts on avril's laptop in the office - 100% sure that's only ever been Ubuntu
[07:21] <Kamion> elmo: echo GET debian-installer/keymap | sudo debconf-communicate
[07:21] <tfheen> Kamion: sorry, are the squashfs-es bind-mounted inside the root?
[07:22] <Kamion> tfheen: not AFAICS
[07:22] <Kamion> certainly no /filesystem.squashfs directory
[07:22] <Kamion> no /casper either
[07:22] <Kamion>   * Don't move-mount all the squashfs-es into / since that confuses mono
[07:22] <Kamion>     (and some other apps too).  Malone: #62756
[07:22] <tfheen> Kamion: gnnr. :-/
[07:23] <tfheen> yes, that's what I hoped fixed it, but apparently not well enough
[07:23] <Kamion> I think we should be very careful about messing about with the bind/move-mounts at this point
[07:23] <mdz> Kamion: I am dead serious about hacking around it in l-i
[07:23] <Kamion> mdz: I entirely agree with you
[07:23] <tfheen> that sounds like a safer approach, yes.
[07:23] <Kamion> not much else appears to care
[07:23] <elmo> Kamion: locked 'cos the config question is still up - is it safe from a diagnosis to just go forward in the upgrade?
[07:24] <tfheen> I wonder why l-i breaks it, while mono is now happy.
[07:24] <mdz> why does mono care?
[07:24] <Kamion> elmo: less /var/cache/debconf/config.dat and see
[07:24] <Kamion> elmo: also, what default answer did it present? U.S. English?
[07:25] <tfheen> mdz: ask ajmitch or one of the other Mono guys.
[07:25] <Kamion> elmo: please don't go forward *quite* yet - shouldn't take long
[07:25] <elmo> Kamion: noting in config.dat about debian-installer
[07:25] <bhale> f-spot was looking for a config file in the squashfs
[07:25] <elmo> /var/log/installer/syslog makes it look like a ubiquity install of some sort
[07:25] <bhale> not the unionfs
[07:25] <infinity> pitti: I passed out, sorry, do you still need those builds? (they're done)
[07:26] <pitti> infinity: would be great
[07:26] <Kamion> elmo: is there a /var/log/installer/version, or a version number at the top of /var/log/installer/syslog?
[07:26] <pitti> infinity: as soon as I have them, I call for testing
[07:27] <mdz> bhale: but why?
[07:27] <mdz> was it trying to look up the location based on the path to an executable for the running process via /proc?
[07:27] <avril> Kamion: "Configuring console-setup" is the title, "The origin of the keyboard:" is the question, default answer is "United Kingdom"
[07:27] <pitti> infinity: (and, no reason to apologize for sleeping in the middle of the night) :)
[07:27] <bhale> mdz: no idea, tfheen said "hey that looks like l-i, I have a lead on a fix"
[07:27] <mdz> I don't know where else that's exposed
[07:27] <bhale> mdz: not sure on what that fix was
[07:27] <Kamion> interesting that that's the default
[07:27] <infinity> pitti: Well yeah, it's 3:30am now, but still, I wasn't planning on passing out. :)
[07:27] <avril> Kamion: no version either in separate file or at top
[07:27] <bhale> mdz: and yes at /proc
[07:28] <Kamion> avril: I'm betting it was a pre-release of espresso/ubiquity then
[07:28] <Kamion> dapper's version copied debian-installer/keymap into the installed system
[07:28] <Kamion> ubiquity (1.0.10) dapper; urgency=low
[07:28] <Kamion>   * Copy debian-installer/keymap to the installed system (closes: Malone
[07:28] <Kamion>     #40627).
[07:28] <Kamion>  -- Colin Watson<EMAIL_ADDRESS>Sun, 28 May 2006 15:46:48 +0100
[07:28] <avril> hmm, ok
[07:28] <avril> that's possible, I think I reinstalled this laptop from scratch when it passed from Pregnant Claire to Avril
[07:29] <Kamion> avril: go ahead with the upgrade - think we just have to suck this up as an annoyance
[07:29] <avril> Kamion: ok, cool, thanks sorry for the false positive
[07:29] <bluefoxicy> Nautilus is suddenly misbehaving, it hangs when I access a usb drive
[07:29] <infinity> pitti: chinstrap:~adconrad/ffox/
[07:29] <Kamion> it's not necessarily a false positive - ideally we'd upgrade from dapper beta without questions
[07:29] <bluefoxicy> ls sees the drive fine and I've umounted/mounted/removed/inserted it a bunch of times
[07:29] <pitti> infinity: thanks! and continue to sleep well
[07:29] <Kamion> the keymap's just damned hard to parse without the value being recorded
[07:30] <Kamion> we tried grokking it out of xorg.conf, but console-setup upstream mailed me with some convincing reasons why that was a thorny approach, and I was seeing bugs in it anyway
[07:31] <Kamion> (convincing reasons> lots of users fix broken autodetected X keymaps using GNOME - the console keymap was probably right because they managed to use it to install, but the X keymap might well not have been)
[07:31] <avril> Kamion, what about parsing /var/log/installer/syslog? ;-)
[07:31] <Kamion> avril: ewwwww. is it actually in there?
[07:31] <avril> Kamion, yep
[07:31] <avril> ubiquity: apply_keyboard: uk
[07:31] <avril> ubiquity: apply_keyboard: layout gb
[07:31] <avril> I was kidding tho
[07:31] <Kamion> avril: I know how you love parsing non-machine-readable files
[07:32] <tfheen> avril: don't give Colin ideas, please. :-P
[07:32] <avril> haha
[07:32] <Kamion> # What kind of genius logs 3.5 years of removal data in
[07:32] <Kamion> # semi-human-parseable text and nothing else?  Hmm.  That would be me. :(
[07:32] <Kamion> # MAAAAAAAAAAAAAADNESSSSSSSSSSSSSSSSS
[07:32] <avril> thank you for sharing my shame
[07:32] <Kamion> :-)
[07:32] <zul> uh..ok
[07:33] <mdz> Kamion: do we save that stuff somewhere machine-readable on current installs?
[07:33] <Kamion> mdz: yes, and in dapper too
[07:33] <Kamion>     for q in ('^console-setup/',):
[07:33] <Kamion>         misc.ex('debconf-copydb', 'configdb', 'targetdb', '-p', q,
[07:33] <Kamion>                 '--config=Name:targetdb', '--config=Driver:File',
[07:33] <Kamion>                 '--config=Filename:%s' % targetdb)
[07:33] <tfheen> removals.txt is fairly parseable, though.  I wrote something generating RSS out of it some time ago.
[07:34] <Kamion> aside from debconf-copydb having possibly the craziest command-line syntax evah
[07:34] <dholbach> hm, it seems that usbdisks get mounted during a desktop install (during/before) the partitioning step
[07:35] <jonh_wendell> Kamion: are you the person who take care of keyboard setup in edgy install?
[07:35] <Kamion> jonh_wendell: yes
[07:35] <jonh_wendell> Kamion: can you take a look at bug 66774?
[07:35] <Ubugtu> Malone bug 66774 in ubiquity "Wrong configuration for Brazilian keyboard" [Undecided,Confirmed]  http://launchpad.net/bugs/66774
[07:36] <mdz> Kamion: alternate install in vmware prompts for the X mode?!
[07:36] <mdz> is that normal?
[07:37] <Kamion> mdz: yes - vmware doesn't expose that information
[07:37] <tfheen> Kamion: didn't your xorg upload fix https://launchpad.net/distros/ubuntu/+source/xutils-dev/+bug/65264 ?
[07:37] <Ubugtu> Malone bug 65264 in xutils-dev "Dapper-Edgy upgrade: three packages are still from dapper" [Undecided,Confirmed]
[07:37] <Kamion> AFAIcouldT last I looked
[07:37] <infinity> mdz: It did in dapper as well.
[07:37] <Kamion> jonh_wendell: ok, shame I found out about this so late
[07:38] <infinity> mdz: (I know, since I just did a few dapper test installs in vmware for upgrade testing)
[07:38] <Kamion> jonh_wendell: may be fixable for edgy, possibly. thanks
[07:38] <mdz> I don't remember dapper doing that for me, weird
[07:39] <Kamion> tfheen: yes, I'll close it, thanks
[07:39] <jonh_wendell> Kamion: thank you
[07:47] <bluefoxicy> Keybuk:  hey check this bootchart out.
[07:47] <Keybuk> ...?
[07:48] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061018-1_desktop.png
[07:49] <Keybuk> does that thing have an ATI/ALi sound card chip, by any chance?
[07:49] <bluefoxicy> 00:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
[07:49] <bluefoxicy> nope
[07:49] <Keybuk> what about the onboard?
[07:49] <bluefoxicy> it's disabled in bios.
[07:50] <Keybuk> just wondering what that long modprobe is
[07:50] <bluefoxicy> no clue.
[07:50] <Keybuk> got a copy of /var/log/udev available?
[07:51] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/udev
[07:52] <bluefoxicy> Keybuk: can you get udev up earlier, by any chance?
[07:52] <bluefoxicy> or well, it starts pretty early heh.
[07:53] <Keybuk> bluefoxicy: nothing much happens before udev
[07:53] <bluefoxicy> Better question:  What's about the best you can do to get modules loaded as early as technically possible
[07:53] <Keybuk>       8.710907  add@/devices/pci0000:00/0000:00:09.0/0-0:TR28602
[07:53] <Keybuk> what's that one?
[07:54] <bluefoxicy> Keybuk:  Windows XP does its 'preload' (readahead) at boot "while loading drivers" because "drivers take time to initialize and we can capitalize on that time spent doing nothing" or something.  That's what sparked my whole readahead thing. :)
[07:54] <Keybuk> oh, your sound card
[07:54] <bluefoxicy> yeah, it is.  Hm.
[07:54] <Keybuk> bluefoxicy: that's what we tried to do ... except that we don't just load drivers, we do lots of other bits, that also need readahead
[07:54] <Keybuk> the other one is your usb hub
[07:54] <bluefoxicy> hmm
[07:54] <Kamion> and also some of the drivers that take longest to initialise are things like SCSI disk drivers and RAID controllers
[07:55] <bluefoxicy> Kamion:  nods.
[07:55] <bluefoxicy> Kamion:  for everything else, there's Vesa?
[07:56] <bluefoxicy> Keybuk:  will that go away when udevsettle is killed off?
[07:57] <mdz> pitti: great, thank you
[07:57] <bluefoxicy> boot time is a bunch of little CPU and IO spikes :/  I'm actually pretty amazed at how difficult it is to turn it into one giant massive spike of IO and CPU
[07:57] <mdz> sfllaw: how is i386?
[07:57] <pitti> mdz: I can't get ubiquity to offer resizing to me, but it worked fine in d-i
[07:58] <mdz> pitti: I got it to work
[07:58] <mdz> my virtual disk needed to be bigger
[07:58] <Keybuk> bluefoxicy: the fact that the rest of the boot waits for your sound card to faff will go away, yes
[07:58] <infinity> sfllaw: I noticed you put me on the testing matrix for powerpc.  My powerpc machine can't boot from CDs. :)
[07:59] <pitti> mdz: hm, I tried with bootstrap/256MB swap/35GB root, bootstrap/35GB root/256 MB swap, and boostrap/36GB root; no dice :(
[07:59] <mdz> pitti: dunno about powerpc
[07:59] <Nafallo> lol
[08:00] <pitti> Kamion: yay
[08:01] <pitti> mdz: for the record, firefox 2.0rc3 is prepared and ready for testing on people, locales updated, fixed, and tested, reverse dependencies tested; looks pretty good
[08:01] <tfheen> "ready for testing on people" sounds like a new drug or biochem weapon or something.
[08:02] <Nafallo> tfheen: maybe it is :-)
[08:02] <thom> most mozilla products could be reclassified as pyschological warfare
[08:03] <mdz> pitti: is there a mail about it?  I'll give it some testing here
[08:03] <mdz> ah, there it is, on -devel
[08:07] <Kamion> pitti: first time since breezy that powerpc has gone vaguely smoothly
[08:07] <Kamion> this is good news
[08:10] <Kamion> mdz: I always just use vmware's default "8GB, split into 2GB chunks"
[08:10] <Kamion> which is more than adequate
[08:10] <mdz> I usually keep them small because I preallocate them
[08:11] <mdz> usually 4G
[08:11] <mdz> 6G is enough to get the resize option so I'm using that now
[08:11] <Kamion> seb128: I've just done two consecutive amd64 desktop CD boots both of which failed to start gnome-settings-daemon
[08:11] <mdz> I learned this lesson during the dapper release but forgot it
[08:11] <Kamion> seb128: what do you need me to do?
[08:11] <mdz> I thought that was fixed
[08:12] <Kamion> except this time at least it managed to start a usable desktop; last time it seemed to just hang
[08:13] <Kamion> starting it by hand appears to work fine
[08:13] <Kamion> classic, strace it and it goes away :(
[08:14] <pitti> mdz: yup, I mailed u-devel
[08:14] <pitti> Kamion: indeed, after the recent ubiquity fixes it went surprisingly smooth today
[08:14] <tfheen> Kamion: it fails during boot because too much other stuff is going on.  It's a timeout.
[08:14] <tfheen> Kamion: the fix is to increase the dbus activation timeout.
[08:15] <pitti> Kamion: we increased the timeout from 25 to 40 seconds lately
[08:15] <pitti> Kamion: if that's still not enough, we have to increase it further, maybe 60 seconds
[08:15] <pitti> slomo: ^ FYI
[08:15] <Kamion> where does it need to be fixed? g-s-d or dbus?
[08:16] <slomo> dbus
[08:16] <tfheen> at least that has been the problem in the past.
[08:16] <Kamion> it gives a pretty poor impression of the desktop CD, and this is not that slow a machine - increasing that for final sounds relatively safe to me
[08:16] <infinity> Is this timeout a compiled-in thing?
[08:16] <tfheen> infinity: yes.
[08:16] <infinity> Cause it seems one would want a ridiculously long one for the live session, but a shorter one for an installed system.
[08:17] <infinity> Shame.  So casper can't fiddle with it. :/
[08:17] <tfheen> we could binpatch it..
[08:17] <tfheen> we should just not use dbus activation for this, IMO.
[08:17] <slomo> infinity, tfheen: nope, it's set in the session bus configuration in /etc
[08:17] <infinity> slomo: Ahh, so there's hope.
[08:18] <Kamion> there's /etc/dbus-1/session-local.conf which casper could write
[08:18] <shawarma> Where can I find a list of the packages installed on the Ubuntu Live CD and the Kubuntu Live CD? (I'm here assuming that it's not just equivalent to [k] ubuntu-desktop and all their dependencies)
[08:18] <slomo> Kamion: "<limit name="service_start_timeout">40000</limit>" in /etc/dbus-1/session.conf
[08:19] <Kamion> shawarma: *.manifest files alongside each of them on cdimage
[08:19] <Kamion> slomo: not here
[08:19] <shawarma> Kamion: Of course. thanks.
[08:19] <slomo> Kamion: oh damn, the patch for it is wrongly applied in the package... i'll add this correctly after RC or now if you want
[08:19] <mdz> tfheen,Kamion: I've created a 'later' milestone for the 'ooh, really should fix that after the release' bugs
[08:19] <tfheen> mdz: thanks,
[08:19] <Kamion> slomo: after RC, please
[08:20] <mdz> it's a milestone on edgy and might look a little weird but it's something
[08:20] <slomo> pitti: i wonder what fixed it for you then... :/
[08:20] <infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
[08:20] <Kamion> yeah, I've just been uploading my post-RC fixes so that they can sit in the queue
[08:20] <slomo> infinity: it's just a one-line addition to another file, i forgot that we don't use upstream's session.conf but have our own in debian/
[08:20] <mc44> pitti: not that this is a regression from rc2, but firefox rc3 still breaks on rss feeds re: bug 61182 - this is not broken in vanilla upstream firefox. I don't know if any who cares for firefox has actually looked at this bug...
[08:20] <Ubugtu> Malone bug 61182 in firefox "Mozilla Firefox Bon Echo Beta 2 Doesn't show RSS Feed preview" [Unknown,Rejected]  http://launchpad.net/bugs/61182
[08:21] <mdz> Kamion: this was more for immediately after final
[08:21] <shawarma> Kamion: Is the manifest by any chance generated from the ubuntu-desktop with some additions? I suppose what I'm actually looking for is what packages are installed on the Live CD, but are not part of ubuntu-desktop (and the same for Kubuntu).
[08:21] <mdz> ubuntu-6.10 is appropriate for post-RC
[08:22] <Kamion> mdz: yeah, my comment was unrelated to your comment about milestones; I was replying to 19:20 < infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
[08:22] <Kamion> shawarma: ubuntu-minimal + ubuntu-standard + ubuntu-desktop + ubuntu-live [+ make sure the right kernel is there]
[08:22] <infinity> shawarma: There's an "ubuntu-live" task. (apt-get install ubuntu-live^)
[08:22] <shawarma> infinity, Kamion: aha! Excellent. Thanks!
[08:22] <infinity> shawarma: And the one Kamion missed was casper, which isn't in any task. :)
[08:22] <mdz> Kamion: gotcha
[08:23] <Kamion> shawarma: easier to see in the seeds (http://people.ubuntu.com/~cjwatson/seeds/edgy/ for a read-only mirror of the Ubuntu edgy seeds)
[08:24] <Kamion> casper isn't in live because we also build a "livecd-base" that doesn't include the desktop or live seedss
[08:24] <Kamion> seeds
[08:24] <Kamion> but maybe casper should be in live anyway, for clarity
[08:24] <slomo> Kamion: ok, finished... http://slomosnail.de/~slomo/temp/dbus_0.93-0ubuntu3.debdiff if you already want to look at it now...
[08:24] <infinity> mdz: Do we have any intention of even pretending to care about the nvidia-glx root hole, or is "upgrade to a random beta driver to fix it" just not a good enough answer for us?
[08:25] <mjg59> infinity: Wouldn't help the legacy ones anyway
[08:25] <mdz> infinity: we'll wait until there's a proper update
[08:25] <shawarma> Kamion: Are those seeds the input for germinate?
[08:25] <Kamion> shawarma: yes
[08:25] <infinity> Kamion: I vaguely recall we had some reason or other (other than livefs-base) for not having it in the live seeds, but danged if I can remember what that reason was.
[08:25] <shawarma> Kamion: I see.
[08:25] <Kamion> c.f. SeedManagement
[08:26] <mdz> infinity: and -legacy will need to go to universe
[08:26] <mdz> we can't pretend to support it
[08:26] <Kamion> multiverse
[08:26] <mdz> right
[08:26] <Kamion> mdz: if so, we should make that overrides change nowish
[08:26] <infinity> mdz: Yeah, like we pretend to support any of it anyway. :/
[08:26] <Kamion> I don't want to be changing overrides post-release
[08:27] <mdz> Kamion: still debating whether to change it for edgy
[08:27] <infinity> It probably should have been in multiverse from its introduction anyway.
[08:27] <mdz> yes
[08:27] <mc44> mdz: how about an option for nvidia-beta a la nvidia-legacy, obivoulsy in multiverse as well
[08:27] <mjg59> mc44: Adds another lump to linux-restricted-modules
[08:27] <mdz> mc44: far too frozen for that sort of thing
[08:27] <infinity> A large lump.
[08:27] <infinity> The nvidia kernel module is huge.
[08:27] <mjg59> Is it going to be releases-noted?
[08:28] <mdz> Kamion: ok, let's do it before final
[08:28] <mdz> mjg59: which? legacy or the bug?
[08:28] <mjg59> "If you install this, arbitrary websites may 0wn you"
[08:28] <mc44> fair enough. Just dont like thee idea of random strings on webpages crashing my computer :-/
[08:28] <pygi> hello all
[08:28] <mjg59> mdz: The bug
[08:28] <Kamion> still trying to figure out why nvidia-glx-dev isn't on the demotion list in the first place
[08:28] <mdz> mjg59: probably a good idea
[08:29] <mdz> mjg59: though we don't do that for, say, the kernel
[08:29] <Kamion> s/nvidia-glx-dev/nvidia-glx/
[08:29] <mdz> I don't think it's necessary
[08:29] <mdz> Kamion: I think restricted is...weird
[08:29] <Kamion> mdz: anastacia is supposed to look at both main and restricted
[08:29] <mjg59> mdz: We don't generally release kernels with known security issues
[08:29] <Kamion> migration between main<->restricted is entirely manual, yes, but it should notice stuff in restricted that's not seeded
[08:30] <mdz> mjg59: sure we do; if they become known too close to release there's little point in delaying
[08:30] <mdz> the difference between releasing with very-recently-known vulnerabilities and unknown vulnerabilities is minimal
[08:30] <infinity> Kamion: nvidia-glx is in ship.
[08:30] <Kamion> OH, sigh
[08:30] <mc44> mdz: but then you expect to update the kernel in a reaobale timeframe
[08:30] <mc44> *reasonable
[08:30] <Kamion> infinity: I meant nvidia-glx-legacy, I just can't think/type/whatever
[08:30] <Kamion> but I worked it out - it's because of Extra-Include: *-dev
[08:30] <mdz> mc44: and we do. what is your point exactly?
[08:30] <infinity> Kamion: Fair enough, I can;t do any of those three either. :)
[08:31] <Kamion> which pulls in nvidia-glx-legacy-dev which pulls in nvidia-glx-legacy
[08:31] <Kamion> infinity: you can't whatever?
[08:31] <infinity> Kamion: Indeed.  I'm terrible at it.
[08:31] <Kamion> mdz: so, Extra-Exclude: nvidia-glx-legacy-dev and demote that pair?
[08:31] <mc44> mdz: that an update to the kernel would be quick after release so risk is smaller not warrenting a realse note, however it may be a long time before nvvidia fix it in a stable driver, and that may be too dangerous to -update
[08:31] <mdz> Kamion: yes
[08:31] <Kamion> mdz: before or after RC?
[08:32] <mdz> Kamion: after
[08:32] <shawarma> Kamion: Do you happen to know the Kubuntu equivalents of -minimal and -standard?  Do "they" have such equivalents at all?
[08:32] <infinity> Makes little difference, since it doesn't ship anyway.
[08:32] <Kamion> right, I'll do the seed change locally
[08:32] <mdz> Kamion: unless it's seriously negligible in the risk department
[08:32] <Kamion> shawarma: all derivatives use the same minimal and standard tasks
[08:32] <infinity> shawarma: The "minimal" and "standard" tasks are the same for all derivatives.
[08:32] <Kamion> shawarma: same minimal is a technical requirement (debootstrap); same standard is merely policy
[08:32] <infinity> shawarma: Again, "apt-get install taskname^"
[08:33] <shawarma> Kamion, infinity: ah. makes sense.
[08:33] <shawarma> infinity: apt-get install ubuntu-live^  does not install everything 'apt-get ubuntu-desktop ubuntu-minimal ubuntu-standard' does.
[08:33] <Kamion> shawarma: it's not meant to.
[08:34] <infinity> shawarma: No, you need to do all the above-mentioned tasks to get a livefs.
[08:34] <Kamion> we tried making those inherit at one point and it had complicated undesirable consequences whose specifics I forget exactly (sorry)
[08:34] <infinity> shawarma: minimal, standard, ubuntu-desktop, ubuntu-live, casper, kernelstuff.
[08:34] <infinity> Kamion: If nothing else, it makes debugging uninstallable tasks pure hell.
[08:34] <mdz> Kamion: I believe it was that removing something low on the stack removed all metapackages going upward
[08:34] <infinity> And that too.
[08:34] <Kamion> yeah, either of those could've been it
[08:35] <shawarma> infinity: So 'apt-get install ubuntu-live^ ubuntu-desktop ubuntu-standard ubuntu-minimal linux-generic casper' for ubuntu and 'apt-get install kubuntu-live^ kubuntu-desktop ubuntu-minimal ubuntu-standard casper linux-generic' for Kubuntu?
[08:35] <Kamion> shawarma: you don't install ubuntu-minimal from scratch - you debootstrap to get that
[08:35] <shawarma> Kamion: Yes, I was wondering why they didn't just depend downwards.
[08:35] <infinity> shawarma: More or less, yes, but you start with a debootstrap.
[08:36] <shawarma> Kamion: Of course, but that's not exactly what I'm trying to do. :-)
[08:36] <Kamion> and the linux-* are different for different architectures
[08:36] <shawarma> infinity: Yes, I *would* if I was doing an actual install :-)
[08:36] <infinity> Kamion: I still install minimal^ anyway, for sheer paranoia's sake.  Not sure why. :)
[08:36] <shawarma> Kamion: Of course.
[08:36] <shawarma> infinity: Ah, minimal is a taskk, too?
[08:36] <Nafallo> pitti: nice changelog on the firefox-build :-)
[08:37] <Kamion> minimal's only really a task because I'm a completist
[08:37] <infinity> Kamion: Was there a point when minimal wasn't part of debootstrap?  That could be why it's in livecd.sh
[08:37] <infinity> (It clearly doesn't need to be anymore)
[08:37] <shawarma> Kamion: -desktop and -standard are not tasks, right?
[08:38] <Kamion> infinity: no
[08:38] <infinity> shawarma: They are.
[08:38] <Kamion> infinity: before minimal existed, there was base, but that was part of debootstrap then
[08:38] <shawarma> infinity: Ok.
[08:38] <Kamion> one of the main reasons for splitting base into minimal and standard was to speed up debootstrap :)
[08:38] <infinity> Kamion: Right, then, I guess it's just lamont paranoia that I never stripped.
[08:39] <shawarma> infinity: minimal and standard are not. At least that's why my apt-get tells me.
[08:39] <infinity> shawarma: minimal^ and standard^
[08:39] <infinity> shawarma: No derivative stem.
[08:39] <shawarma> infinity: Garh... I'm so stupid.
[08:39] <shawarma> infinity: feel free to quote me on that.
[08:40] <infinity> Only when drunk, and you're paying.
[08:40] <shawarma> infinity: indeed.
[08:41] <Nafallo> pitti: firefox looks good in Swedish anyway, nothing jumps at me.
[08:42] <infinity> pitti: Can we s/BonEcho/Firefox/ on the user agent string?  There are some painfully retarded websites that refuse to work with "unknown" user agents.
[08:47] <seb128> Kamion: do you have anything to ~/.xsession-errors or any clear message about the issue on boot?
[08:48] <seb128> that's weird we didn't get some bug reports about that, the package didn't change for weeks now
[08:48] <seb128> there was an issue some time ago, I fixed it and people who replied on the bug confirmed it's fixed
[08:48] <seb128> Kamion: does it happen every time?
[08:56] <slomo> pitti: ping?
[08:58] <Kamion> seb128: no, not every time - and as I say it's on the live CD so it could well be the dbus activation timeout thing that people were talking about above
[08:58] <pitti> Nafallo: cheers
[08:58] <pitti> slomo: pong
[08:59] <Kamion> seb128: http://people.ubuntu.com/~cjwatson/tmp/xsession-errors - nothing obvious
[08:59] <pitti> Nafallo: changelog> well, I got sick of tracking all these CVEs in the manual db :)
[08:59] <pitti> infinity: I'll look into it
[08:59] <Kamion> (I've already started g-s-d by hand and started ubiquity)
[08:59] <Nafallo> pitti: hehe, yea. thought so :-)
[08:59] <slomo> pitti: saw that i managed to not change the dbus timeout? ;) any idea what else has fixed it for you? (and does the bcm43xx driver work for you with latest kernel? i always loose the connection to APs after some time...)
[09:00] <Lure> mjg59: I cannot reproduce bug 60442, but I have prepared a test package - so if you can test it would be great
[09:00] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
[09:00] <pitti> slomo: dbus timeout> no idea, it just works now
[09:00] <Kamion> seb128: also bug 66124 was filed just four days ago about this and you replied to it ...
[09:00] <Ubugtu> Malone bug 66124 in control-center "gnome-settings-daemon crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66124
[09:00] <Kamion> so it's obviously not fixed for everyone
[09:00] <pitti> slomo: bcm43xx> works fine for me, but I didn't test it for longer than an hour or so
[09:00] <pitti> slomo: but it's completely broken with network-manager
[09:00] <elmo> my fonts consistently get mangled on upgrade
[09:00] <seb128> Kamion: that one is clearly a different issue
[09:00] <pygi> sivang: ping?
[09:00] <Kamion> seb128: oh?
[09:00] <elmo> from subpixel -> best shape
[09:00] <elmo> who would that be a bug on?
[09:00] <Kamion> seb128: oh, sorry, you're quite right
[09:00] <seb128> Kamion: the previous crasher people have had "gstreamer init failed" message
[09:00] <pitti> slomo: From what I have heard, wpasupplicant wrecks up the settings, and I don't even get an IP
[09:01] <pitti> slomo: so I'm back at good ol' sudo ifup eth1
[09:01] <seb128> s/have/had
[09:01] <slomo> pitti: i loose the connection after < 5 minutes already but don't use NM at all
[09:01] <pitti> slomo: anything helpful in dmesg?
[09:01] <slomo> pitti: no... jsut the usual spamming by the bcm43xx module
[09:01] <seb128> Kamion: would be nice to try with the extra delay for dbus first
[09:01] <Kamion> mm, I'll see if I can try that out hand-hacked later
[09:01] <seb128> Kamion: and debug it if the isssue is still there
[09:01] <pitti> slomo: how come that the timeout isn't changed? I still remember the changelog
[09:02] <pitti> Kamion: it's nontrivial to hack
[09:02] <Nafallo> pitti: network-manager bailed out on my rt2500, wifi-radar works though :-). if you want something GUIsch that is :-).
[09:02] <slomo> pitti: i patched upstream's session.conf but we have our own in debian/ and forgot about it
[09:02] <pitti> Kamion: in my experiments I never managed to get the effect after logging out and back in - that was just too fast
[09:02] <Kamion> pitti: I can hack it at boot
[09:02] <Kamion> break=casper-bottom, mess around with ed
[09:02] <pitti> ah, nice trick
[09:03] <Kamion> you have to provide a script that edits the file, but shrug
[09:04] <seb128> is apport running on the desktop CD?
[09:04] <seb128> like a g-s-d crash would generate a crash log?
[09:11] <Kamion> doesn't seem to
[09:16] <Riddell> mjg59: has usplash changed on amd64?
[09:16] <tfheen> Riddell: yes.
[09:16] <tfheen> Riddell: it now works, unlike what it used to.
[09:16] <Riddell> well that would be handy to know
[09:16] <Riddell> what do I have to do to make it work in kubuntu?
[09:17] <tfheen> provide proper (640x400 and 640x480) artwork.
[09:17] <tfheen> 16 colours
[09:26] <pitti> sfllaw: do you need help with amd64 testing? I can do some testing tomorrow morning
[09:27] <Kamion> I'm slowly cranking my way through the amd64 DVD still
[09:36] <ogra> hmm, gaim is funny as IRC client
[09:37] <sivang> ogra: I couldn't never get used to it as an IRC client
[09:43] <Riddell> Gloubiboulga: someone will have to add a 640 xubuntu usplash too, else it won't work on amd64
[09:44] <seb128> lool: hi, yeah, you have some nice ideas. I think we will discuss that again at next summit. I'm busy with edgy at the moment but I would be happy to discuss that after edgy if you are interested. I think mvo is interested to the topic too
[09:58] <mvo> seb128: what topic was that?
[09:58] <seb128> mvo: easy-codec-install
[09:59] <mdz> sfllaw: how goes the testing?
[09:59] <lamont> infinity: what did I do now??
[10:00] <mvo> seb128: yeah, that is a nice one
[10:08] <pitti> mdz: btw, I did the whole range of amd64/alternate tests with yesterday's images; the big bugs I noticed have been fixed
[10:08] <mdz> pitti: thank you
[10:08] <pitti> my machine is still busy with firefox, but I'll do some more amd64 tests tomorrow
[10:13] <mvo> how can I get the installer to present me the auto-resize option :/
[10:14] <mvo> do we need more ubuntu testing? it would be a welcome break from edubuntu testing :)
[10:14] <tfheen> mvo: the disk needs to be bigger than 6G
[10:14] <tfheen> mvo: ubuntu i386 testing == good
[10:14] <pygi> get mvo
[10:15] <pygi> hey*
[10:15] <pygi> o joy, what a typo
[10:15] <gnomefreak> seb128: you mean like amaroks easy install codecs?
[10:15] <seb128> gnomefreak: what?
[10:15] <gnomefreak> amarok installs codecs for you now :)
[10:15] <seb128> gnomefreak: and?
[10:15] <mvo> tfheen: my disk is 160G and I don't see it in ubiquity
[10:15] <seb128> gnomefreak: I don't use amarok and don't care about what it does
[10:15] <mvo> hey pygi!
[10:15] <gnomefreak> seb128: is that the same as what you mean?
[10:16] <seb128> gnomefreak: no
[10:16] <gnomefreak> oh ok
[10:16] <seb128> gnomefreak: I mean you try to play a mp3 with totem and it open a dialog "you need to install gstreamer0.10-plugins-ugly"
[10:16] <seb128> gnomefreak: with an "install" button
[10:16] <gnomefreak> seb128: yeah thats what amarok does atm
[10:17] <gnomefreak> it would be nice if it can be done with totem
[10:17] <seb128> gnomefreak: how do they do the mapping package to install codec?
[10:17] <seb128> gnomefreak: and is amarok running as admin or is there a daemon to install the package?
[10:17] <gnomefreak> seb128: that i dont know thats a riddell question
[10:17] <gnomefreak> seb128: daemon
[10:18] <seb128> gnomefreak: that's stupid to have an app specific daemon
[10:18] <seb128> gnomefreak: we should have something you can speak to over dbus or something like that
[10:18] <gnomefreak> agreed
[10:19] <seb128> gnomefreak: does amarok install the codec for the user or the package required or the codec out of the package systm?
[10:20] <gnomefreak> out of package system iirc. the last time i played with it it kept running in a loop
[10:20] <seb128> gnomefreak: ah, k, that's not what the spec is about, the spec is about determining what package is required and install it
[10:20] <gnomefreak> ah
[10:21] <seb128> we are not really interested to install codecs out of the packaging system :)
[10:21] <gnomefreak> ah
[10:25] <sfllaw> Kamion: You're looking at bug 59983.  EtienneG was wondering if this will make it for edgy.
[10:25] <Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
[10:25] <sfllaw> According to the report, it looks like the kernel interface changed.
[10:25] <sfllaw> And he's already had a call about it.
[10:26] <mdz> Kamion: I think we had the same idea: https://features.launchpad.net/distros/ubuntu/+spec/install-with-third-party-drivers and https://features.launchpad.net/distros/ubuntu/+spec/ubiquity-driver-updates
[10:26] <Riddell> gnomefreak: hmm?
[10:26] <gnomefreak> Riddell: we were talking about how amarok installs the codecs
[10:27] <Riddell> gnomefreak, seb128: it runs /usr/lib/amarok/install-mp3
[10:27] <Riddell> which installs libmad
[10:27] <Riddell> there's no daemon
[10:28] <seb128> Riddell: is that mp3 specific or does it do that with any codec?
[10:28] <Riddell> seb128: it's mp3 only, amarok just reads this .desktop file for the script to run which is supplied by the packager /usr/share/services/amarok_xine-mp3_install.desktop
[10:29] <seb128> Riddell: and does it install the package or a codec it downloads from somewhere?
[10:29] <dieman> suck, wont be working with ubuntu a ton in my new job it sounds -- the emc software for the SAN requires SLES or RHEL.
[10:29] <Riddell> seb128: our install-mp3 runs kdesu adept to enable muliverse if needed and do apt-get install libmad0
[10:30] <seb128> Riddell: ok, I see. gnomefreak said that amarok was already doing what the easy-codec-install specs wants to do, looks like it's a "light version" :) We want a mapping for any codec
[10:30] <pygi> dieman: why is that?!
[10:30] <dieman> pygi: its not 'certified' for ubuntu, etc.
[10:30] <lool> seb128: fine
[10:30] <seb128> Riddell: thank you for the details about it :)
[10:30] <dieman> the SAN people here dislike not using certified platforms, etc.
[10:31] <pygi> dieman: ok, help us get in contact with the providers of software, we'll certify
[10:31] <dieman> i can't blame them, because its a support issue for them.
[10:31] <tfheen> dieman: where you moving to?
[10:31] <dieman> sticking here at umn in minneapolis
[10:31] <dieman> moving to oit security and assurance
[10:31] <dieman> doing network security work
[10:31] <tfheen> oh, nice.
[10:31] <dieman> yah
[10:34] <Kamion> 01:31 < Kamion> mdz: I registered ubiquity-driver-updates before seeing install-with-third-party-drivers. Which should we keep?
[10:34] <Kamion> 01:36 < Kamion> mdz: do I need to repropose ubiquity-advanced-partitioner for uds-mtv, or can we just carry it over? (I don't think it desperately needs further discussion)
[10:34] <Kamion> 01:37 < Kamion> I suppose that means I'll have to actually think of other stuff I want to do for edgy+1 then, otherwise my slate is going to look artificially empty in MTV
[10:35] <Kamion> mdz: yep, I'd noticed that too, shortly after registering u-d-u
[10:35] <infinity> Kamion: If you already have a large amount of work (and thus no need to spec more for yourself), register a mess of LP specs, and sit in with the soyuz guys and I for distro/soyuz requirements.
[10:36] <infinity> Kamion: Or register other random specs for cool stuff you hope you can pawn off on other assignees. :)
[10:36] <Kamion> sfllaw: some total random assigned that bug to me without my consent; I know nothing about it
[10:36] <sfllaw> Kamion: Ah.
[10:37] <ajmitch> morning
[10:37] <sfllaw> When people do that, can you toss it back to Nobody?
[10:37] <ajmitch> wasabi_: pong (what was it about?)
[10:37] <Kamion> sfllaw: yeah, I just did
[10:37] <Kamion> it was only yesterday
[10:38] <sfllaw> mdz: Bug 59983 looks like it could cause pain for our users.  The regression seems to be a bad one, but the fix involves a UVF exception.
[10:38] <Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
[10:38] <sfllaw> mdz: EtienneG just pointed out that he had a call about it.
[10:39] <mdz> sfllaw: I have read that entire bug and I don't understand what the problem is
[10:40] <tfheen> ajmitch: http://err.no/src/contentless_ping.pl
[10:40] <Riddell> mdz, tfheen: I'm uploading a new kubuntu-default-settings to allow booting on amd64
[10:40] <mdz> Riddell: bug#?
[10:40] <pitti> there, firefox User-Agent string fixed
[10:41] <Riddell> mdz: been to busy making the changes to report a bug yet :) hang on
[10:41] <mdz> Riddell: so kubuntu/amd64 is completely broken?
[10:41] <Riddell> mdz: you need to turn off usplash
[10:42] <pitti> mdz: I fixed firefox' UserAgent: to be 'Firefox' instead of 'BonEcho' (to restore compatibility with some websites which check the string); I hope that's conformant with the branding agreement?
[10:42] <mdz> pitti: please make it compatible with whatever dapper did
[10:42] <Ubugtu> Malone bug 66815 in kubuntu-default-settings "amd64 usplash boot broken" [Undecided,Unconfirmed]
[10:42] <pitti> mdz: alright
[10:43] <ogra> Riddell: woah, thats evil ...
[10:43] <mdz> Riddell: was this a regression caused by the most recent usplash changes?
[10:43] <sfllaw> mdz: The bug is that you can't use ndiswrapper-utils to confiugre a proprietary network card.
[10:43] <sfllaw> That makes it rough for users who don't have free cards in their computers.
[10:43] <ogra> in edubuntu the splash is completely broken on amd64, but still boots fine
[10:43] <mdz> sfllaw: that's the symptom. what's the problem?
[10:43] <sfllaw> mdz: ndiswrapper.ko changed its interface.
[10:43] <Riddell> mdz: yes, since nobody told me about the usplash changes I never knew to update it
[10:44] <ogra> Riddell: it was mentioned loosely on teh last dev meeting
[10:44] <sfllaw> Our ndiswrapper (1.1) doesn't know how to use the new module.
[10:44] <sfllaw> Upstream's 1.8 reportedly does.
[10:44] <sfllaw> EtienneG says he's going to verify that.
[10:44] <tfheen> sfllaw: so we can just change the seeds to point to 1.8 for release, then.
[10:44] <mdz> Riddell: why does that cause it to fail to boot?
[10:45] <tfheen> fwiw, not having proper artwork doesn't make it blow up for me.  It just gives a garbled image.
[10:45] <Riddell> mdz: it seems to freeze the computer shortly after X starts (presumably when usplash stops)
[10:45] <Kamion> ugh, cdebconf-keystep doesn't line-wrap one of its questions - that's incredibly ugly
[10:45] <ajmitch> tfheen: ta for the script
[10:45] <EtienneG> sfllaw, I will confirm and post a comment in #12016 somewhen before midnight EST
[10:46] <sfllaw> EtienneG: 12016?
[10:47] <EtienneG> sfllaw, Sorry !  I am mixing bug/ticket number here ... :)
[10:47] <sfllaw> tfheen: I'm confused but I presume you're not.  Are you saying you'll point the seeds to 1.8, which is living in?
[10:47] <sfllaw> EtienneG: Please comment in Malone.
[10:47] <EtienneG> that's really #59983
[10:47] <EtienneG> sfllaw, yep, I guess that's better ! :)
[10:48] <EtienneG> tfheen, my understanding is that ndiswrapper-utils bring in ndiswrapper-utils-1.1
[10:48] <EtienneG> so just changing ndiswrapper-utils to bring in -1.8 should worked, if confirmed
[10:48] <doko_> sfllaw: can we swap Ubuntu/Kubuntu testing for amd64 (already have the CD here)?
[10:49] <sfllaw> doko_: Yes.
[10:49] <doko_> sfllaw: ok, changing the wiki
[10:49] <sfllaw> doko_: Thanks.
[10:50] <mdz> Kamion: I replaced my spec with yours
[10:51] <doko_> sfllaw: hrm, no, Kamion is testing amd64 Ubuntu, not me, so please keep it ;-) starting with the kubuntu CD's :)
[10:51] <sfllaw> OK.
[10:51] <tfheen> EtienneG: no, not changing the package.  Changing the seeds.
[10:51] <Kamion> doko_: only DVDs
[10:51] <sfllaw> kozz: Right.
[10:51] <sfllaw> Desktop CD and Alternates.
[10:52] <doko_> Kamion: seen
[10:53] <mdz> sfllaw: I have version 1.8-0ubuntu2 installed
[10:53] <mdz> but the source package in the archive is 1.1-5
[10:54] <mdz> oh, it's gone weird
[10:54] <mdz> the package names changed around
[10:54] <Kamion> oh, I see - we need to build cdebconf-keystep with libtextwrap
[10:55] <mdz> there's an ndiswrapper-utils in the archive, built from ndiswrapper-1.1
[10:55] <mdz> then a bunch of newer stuff built from 'ndiswrapper'
[10:55] <tfheen> mdz: that's an empty transitional package depending on ndiswrapper-utils-1.1
[10:56] <mdz> tfheen: 'ndiswrapper' also builds an ndiswrapper-utils though
[10:56] <mdz> which is not empty
[10:56] <tfheen> mdz: yes, ndiswrapper-utils is the package I talked about.  It should be empty or just containing symlinks, I'd imagine.
[10:56] <Riddell> doko_: if you're testing amd64 kubuntu keep in mind the usplash needs disabled
[10:56] <ogra> Riddell: how does kdm stop usplash ? i dont see the initscript running DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start
[10:56] <tfheen> the reason for this is to prevent upgrades to break people's networking because the ndiswrapper ABI changed and they didn't get a new kernel at the same time
[10:57] <tfheen> (and now they can't because they have an old kernel and new ndiswrapper or the other way around)
[10:57] <Riddell> ogra: there's nothing in kdm to stop usplash as far as I remember
[10:57] <mdz> tfheen: what I don't understand is that I have two 'ndiswrapper-utils' packages in my apt cache
[10:57] <ogra> Riddell: aha ... that might be your prob then
[10:57] <mdz> tfheen: which contains only edgy
[10:58] <tfheen> mdz: and you don't have it locally installed?
[10:58] <sfllaw> There's a 1.8 in dapper.
[10:58] <mdz> tfheen: I have it installed, but I wouldn't have manually installed it
[10:58] <Riddell> ogra: so that'll be yet another usplash change I've not been told about, grump
[10:58] <ogra> Riddell: look at gdm in debian/patches/15_usplash.patch
[10:58] <mdz> it's as if the version number got smaller between dapper and edgy
[10:58] <sfllaw> It did.
[10:58] <doko_> Riddell: will do
[10:58] <mdz> that's not supposed to happen
[10:58] <sfllaw> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ndiswrapper-utils
[10:58] <mdz> ndiswrapper-utils |     0.10-1 |         warty | i386
[10:58] <mdz> ndiswrapper-utils | 0.12+1.0rc2-1 |         hoary | i386
[10:58] <mdz> ndiswrapper-utils | 1.1-4ubuntu2 |        breezy | amd64, i386
[10:58] <mdz> ndiswrapper-utils |      1.1-5 |          edgy | all
[10:58] <mdz> ndiswrapper-utils | 1.8-0ubuntu2 |        dapper | amd64, i386
[10:59] <mdz> cprov,malcc: ^^^
[10:59] <tfheen> that's.. special.
[10:59] <mdz> so we just need to fix ndiswrapper-utils to depend on -1.8 rather than -1.1 it sounds like
[10:59] <Nafallo> where are the manpages? :-P
[11:00] <sfllaw> And up the version number.
[11:00] <mdz> for good measure
[11:00] <cprov> mdz: I'm checking
[11:00] <sfllaw> I'll update the description for 59983.
[11:01] <sfllaw> Done.
[11:04] <infinity> cprov: Could it be that version constraints are only checked on source uploads, but not on binary uploads?
[11:05] <infinity> cprov: Oh, or something more sinister at work...
[11:05] <malcc> We seem to have two source packages (ndiswrapper vs ndiswrapper-1.1) both publishing ndiswrapper-utils binaries...?
[11:05] <infinity> mdz: At a glance, I'd say that 'ndiswrapper-utils' was removed from edgy as NBS, then ndiswrapper-1.1 started building it with a lower version.
[11:06] <malcc> Hmm, the version of ndiswrapper in edgy builds ndiswrapper-utils-1.8
[11:06] <sfllaw> doko_: What did you decide to do?
[11:06] <cprov> infinity: have you ran archive-cruft-check recently ?
[11:07] <infinity> (Which still is no excuse for it not failing version constraints when it was cleared from the new queue)
[11:07] <mdz> malcc: yes, we had some discussion about it before you /joined
[11:07] <mdz> malcc: cprov should have a copy
[11:07] <doko_> sfllaw: just testing the Kubuntu CDs/DVD
[11:07] <sfllaw> OK.
[11:07] <sfllaw> Thanks.
[11:07] <sfllaw> I'll continue with AMD64 on Ubuntu.
[11:08] <mdz> sfllaw: someone needs to confirm Riddell's bug
[11:08] <mdz> if it breaks the boot everywhere, it's a problem for RC
[11:09] <Kamion> cprov: I run a-c-c frequently, and its output was empty yesterday
[11:09] <Kamion> in fact this morning too, I think
[11:09] <Kamion> mdz: I checked for versions in edgy << dapper-updates, but looks like I need to check dapper too ...
[11:10] <cprov> Kamion: good, was just curious about it, thanks
[11:10] <mdz> Kamion: where do you check that?
[11:10] <Kamion> cjwatson@drescher:~$ for component in main restricted universe multiverse; do for arch in amd64 i386 ia64 powerpc sparc; do echo "$component/$arch:"; ./suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/dapper/$component/binary-$arch/Packages.gz /srv/launchpad.net/ubuntu-archive/ubuntu/dists/edgy/$component/binary-$arch/Packages.gz gt; echo; done; done | less
[11:10] <Kamion> ndiswrapper-utils is the only offender for edgy << dapper
[11:11] <Kamion> suite-diff.py is something I wrote way back shortly after I started working for Canonical; I no longer remember why ...
[11:11] <Kamion> oh, I think it was to check for newer versions of packages in unstable than warty after UVF
[11:12] <Kamion> there's also one instance of edgy << dapper-security at present
[11:12] <mdz> sfllaw: ubuntu/i386 is still lacking confirmed tests as well
[11:12] <Kamion> mvo: could you (get somebody to) update vmware-player-kernel-2.6.15 for our current kernel, please?
[11:12] <sfllaw> I'm going to import some of cr3's results from Salesforce.
[11:12] <Kamion> assuming we're allowed to
[11:12] <sfllaw> mdz: Is there a DevelTeamMeeting this week?
[11:12] <mdz> sfllaw: no, as posted to ubuntu-devel-announce
[11:12] <tfheen> Kamion: should we even have vmware-player-kernel-2.6.15 in edgy?
[11:12] <Kamion> vmware-player-kernel-modules: <IP_ADDRESS>-10 > <IP_ADDRESS>-6
[11:12] <Kamion> vmware-player-kernel-source: <IP_ADDRESS>-10 > <IP_ADDRESS>-6
[11:12] <sfllaw> OK.
[11:13] <Kamion> tfheen: no, should be 2.6.17
[11:13] <Kamion> but regardless, the versions of those binaries need to be higher
[11:13] <sfllaw> Ah.  I see, it's cancelled on fridge, not disappeared like normal.
[11:13] <tfheen> oh, the binaries doesn't have versioned package names.
[11:14] <Kamion> which is correct for -source; less sure about -modules
[11:16] <mdz> sfllaw: I see cr3 is also assigned all i386 DVD cases, but there supposedly isn't enough bandwidth to montreal for CDs, much less DVDs
[11:16] <tfheen> I can do DVD ubuntu tests in the morning
[11:35] <Kamion> tfheen: vmware-player-kernel-modules: <IP_ADDRESS>-10 > <IP_ADDRESS>-6
[11:35] <Kamion> vmware-player-kernel-source: <IP_ADDRESS>-10 > <IP_ADDRESS>-6
[11:35] <Kamion> oops
[11:35] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/cdebconf-keystep.libtextwrap.diff
[11:35] <Kamion> how does that look to you?
[11:35] <Kamion> need to figure out how to test it
[11:37] <tfheen> Kamion: it doesn't need to do anything to use libtextwrap?  Just make sure it's present?
[11:38] <Kamion> it already has that code, AFAICT
[11:39] <Kamion> which is why I didn't notice the problem earlier - it's all inside #define HAVE_LIBTEXTWRAP
[11:39] <tfheen> oh, ok.
[11:39] <Kamion> which is always defined in cdebconf so I assumed it would be in cdebconf-keystep too
[11:39] <tfheen> I probably got that when I C&P-ed the code out of cdebconf.
[11:39] <tfheen> yeah, looks good to me otherwise.
[11:39] <Kamion> it's only 9 lines of #defined-out code in total
[11:40] <tfheen> yeah, I'm not worried about that bit.
[11:46] <malcc> Looks like ndiswrapper-utils-1.8 is left behind in universe where ndiswrapper-utils and ndiswrapper-utils-1.1 are in main
[11:46] <sfllaw> tfheen: Thanks.
[11:52] <Kamion> malcc: due to not being seeded
[11:54] <malcc> So, I can't find anything wrong in Soyuz here, unless its whole approach to packages with chunks of version numbers in their names is on crack
[11:55] <Kamion> malcc: we're talking solely about the ndiswrapper-utils binary package here, not the others
[11:55] <cr3> mdz: do answer your concer about testing DVDs in the Montreal office, sfllaw has sneakered much of the DVD downloads into the office from home, so we should be able to rsync minor changes in the office
[11:55] <sabdfl> malcc: evenin'
[11:55] <malcc> sabdfl: Hi
[11:55] <Kamion> malcc: the bug is that the ndiswrapper-utils binary package should not have been accepted into edgy when its version was << that in dapper
[11:56] <tfheen> malcc: you need to never forget about a binary package that has existed in some distro you derive from and also disallow version number downgrades.
[11:57] <Kamion> well, yes, there are weak and strong versions of this constraint
[11:57] <tfheen> Kamion: I suspect dak is vulnerable to a similar problem as soyuz is, but I haven't verified it.
[11:57] <Kamion> the weak version is to check just versions of binaries in other existing distroreleases, with an awareness of the order of distroreleases
[11:57] <tfheen> I've just pondered with it as an (evil!) way to get rid of epochs.
[11:57] <Kamion> the strong version is to remember all versions and never allow going backwards, as tfheen says
[11:58] <Kamion> tfheen: what about epochs?
[11:58] <tfheen> Kamion: if you're allowed to downgrade, you can get rid of epochs.
[11:59] <Kamion> you have to arrange for an ftpmaster to remove the binary temporarily
[11:59] <Kamion> I think eventually ftpmaster would notice :)
[11:59] <tfheen> so if edgy-2 had a package, you got rid of it in edgy-1, you can reintroduce it in edgy without the epoch and close any bugs as "this was a package that wasn't in edgy-1".
[11:59] <tfheen> yes, evil, wrong and all.
[12:01] <Kamion> from the sounds of things, I think I need to get a version of my suite-diff hack into Soyuz sooner rather than later. :)
[12:01] <Kamion> in case anyone gets any ideas
[12:01] <Chipzz> I don't see how this can work
[12:02] <Chipzz> if I have a package installed with an epoch
[12:02] <Chipzz> I do not update
[12:02] <Chipzz> you guys remove it
[12:02] <Kamion> Chipzz: it wouldn't. that's the point
[12:02] <Chipzz> you guys add it again
[12:02] <Kamion> Chipzz: that's why it's evil
[12:02] <Chipzz> I update
[12:02] <Chipzz> it still wouldn't work
[12:02] <tfheen> Chipzz: it wouldn't, but I could blame it as user error since you should have removed it when it wasn't supported.
[12:02] <tfheen> well, 'night.
[12:02] <Kamion> Chipzz: tfheen's pointing out a failing in the archive's current integrity checks. of course it has negative consequences on users ...
[12:02] <Chipzz> tfheen: no, I just didn't update while it wasn't supported
[12:03] <Chipzz> I never noticed that there was a period when it wasn't supporte
[12:03] <Chipzz> d
[12:03] <tfheen> Chipzz: you should have.
[12:03] <Kamion> don't analyse it too hard
[12:03] <tfheen> what Colin says.
[12:03] <tfheen> anyway, I need sleep; there's an RC tomorrow.
[12:03] <Chipzz> uhu :)
[12:03] <malcc> Ok, I'm feeling a bit better that I didn't understand this now :)
[12:03] <Chipzz> good night :)
[12:03] <tfheen> need to be dapper, no, edgy tomorrow.
[12:03] <Kamion> CAFFEINE
[12:04] <Kamion> Chipzz: the above is why, by policy, version numbers never, ever go backwards
[12:05] <Kamion> Chipzz: mostly, this is enforced technically; occasionally it still needs to be enforced socially; sometimes things slip through
[12:05] <Kamion> malcc: it's actually much more important in some ways that version numbers never go backwards for binary packages than for source packages, because the reason why they mustn't go backwards is that if they do they won't get upgraded on users' systems, as Chipzz describes
[12:06] <Chipzz> Kamion: uhu
[12:06] <elmo> tfheen: dak is so not vulnerable to that - it does cross-suite version checking
[12:06] <Kamion> for source packages we could theoretically get away with only uniqueness (although decreasing version numbers might break things like apt-src; I'm not sure about that) - but in practice it's much less confusing just to have the same constraint, especially considering that you have to go to some lengths to get source and binary versions to differ
[12:07] <Kamion> elmo: it's vulnerable to it across removals within the same suite, surely?
[12:07] <elmo> the only thing it's vulnerable to is the temporary removal trick, but if I ever saw anyone do that deliberately I would kick them out of the keyring faster than they could say banana hammock
[12:08] <elmo> Kamion: not sure how you mean?  dak would have rejected an edgy upload of a package, even if it was new to edgy, if the version was << dapper


[01:44] <teward> arraybolt: no you cant alter fix released bug stauses.  but bug control members like myself (and devs) can. why does a fix released bug need altered th
[01:50] <arraybolt3> teward: It doesn't, I thought it did, but was mistaken.
[01:55] <teward> ok
[03:56] <Psil0[m]> Nice


[02:05]  * Linden940 is away: I'm away
[09:59] <stjohnmedrano> Happy New Year Linux Users!
[19:51]  * Linden940 is back (gone 17:45:23)