[00:13] <directhex> right. should i prepare a debdiff against -3ubuntu2, or -4? i forget which is preferred
[01:12] <slangasek> pitti: ok, looked at the coreutils SRU now; and patched sru-accept to support a -s argument :-)
[01:17] <mathiaz> slangasek: could you promote the -virtual kernel flavor to main?
[01:19] <slangasek> mdke: ubuntu-docs translations> yes; what deadline are you giving translators?
[01:20] <slangasek> mathiaz: it's seeded somewhere, I assume?
[01:20] <directhex> bam. who wants to give bug 282952 a tickle? seeped in double-security-hole goodness!
[01:20] <mathiaz> slangasek: yes - in the server-ship seed
[01:20] <mathiaz> slangasek: It's in the component-mismatch.txt file
[01:26] <slangasek> mathiaz: done
[01:26] <mathiaz> slangasek: thanks you ! :)
[03:43] <TheMuso> RAOF: I have uploaded 0.9.13 of pulseaudio to my PPA if you are interested.
[03:43] <RAOF> TheMuso: I'll play around.
[03:47] <gustavold> I upgraded my ubuntu to intrepid, now sound is not working properly... anyone could help me?
[03:47] <RAOF> gustavold: Support in #ubuntu+1
[03:47] <gustavold> RAOF: thanks
[03:53] <TheMuso> cjwatson: ok that hang I mentioned earlier was a one off.
[04:24] <StevenK> TheMuso: Oh!
[04:24] <StevenK> TheMuso: Can I get you to retry libtunepimp on powerpc, but with an older binutils?
[04:24] <TheMuso> StevenK: If I know where I can get an older binutils, sure.
[04:25] <StevenK> TheMuso: Launchpad? :-)
[04:25] <TheMuso> I thought launchpad didn't keep older binaries.
[04:25]  * TheMuso looks
[04:25] <wgrant> TheMuso: It does.
[04:25] <wgrant> It has all old binaries and sources.
[04:25] <TheMuso> ok great.
[04:25] <wgrant> ANd build logs, unless somebody gave the build back. And everything else on the planet.
[04:26] <wgrant> Librarian must be *huge*.
[04:26] <TheMuso> StevenK: how many versions back do you want?
[04:27] <StevenK> doko didn't say, just an older version :-(
[04:27] <StevenK> I was guessing 2.18.50
[04:27] <TheMuso> ok will try the one before the most current one.
[04:28] <TheMuso> unless you want me to use that version.
[04:28] <StevenK> TheMuso: Try that version, then a few more back. Then we can hit up doko with the results
[04:28] <wgrant> Can I convince somebody to run xinput list-props on Intrepid !(i386|amd64)?
[04:29] <StevenK> If the penultimate versaion works, that's fine.
[04:29] <TheMuso> StevenK: ok.
[04:34] <TheMuso> StevenK: Ok building...
[04:38] <TheMuso> StevenK: ok going back another version of binutils
[04:38] <StevenK> TheMuso: Should be finished? :-)
[04:39] <StevenK> TheMuso: Only it fails the same way?
[04:39] <TheMuso> StevenK: i checked config.log
[04:57] <StevenK> TheMuso: No news is good news?
[04:58] <TheMuso> StevenK: No, still moving back through binutils versions.
[04:58] <TheMuso> back to 2.18.90
[05:03] <TheMuso> ls
[05:03] <TheMuso> oops wrong tab
[05:04] <TheMuso> StevenK: back to 2.18.50
[05:04] <TheMuso> which is what I am trying now.
[05:15] <kees> slangasek, sbeattie: heads up on 230877 -- I'm about to release a dbus security update which will need the current -proposed to get rebuilt
[05:21] <TheMuso> StevenK: Ok just tried binutils_2.18.50.20080610-0ubuntu1_powerpc.deb and still getting the error. Mind you I am only using the binutils package. Should I use any other of its binaries as well?/c
[05:21] <StevenK> TheMuso: At this point, let's bug doko
[05:21] <StevenK> TheMuso: Thank you for your help
[05:23] <TheMuso> StevenK: np
[06:11] <dholbach> good morning
[06:18] <lukehasnoname> good morning
[06:18] <lukehasnoname> 21:18 here in Lubbock
[06:19] <dholbach> lukehasnoname: 7:21 here :)
[06:19] <dholbach> good morning :)
[06:19] <lukehasnoname> er.. 12:18
[06:19] <lukehasnoname> haha
[06:51] <pitti> Good morning
[06:52] <StevenK> Morning pitti
[06:52] <StevenK> pitti: I killed pnetc to go along with your pnet/pnet-assemblies death.
[06:52] <pitti> cjwatson: 176994> indeed, closed
[06:52] <pitti> slangasek: sru-accept -s> nice, thanks
[06:52] <pitti> StevenK: yay killing!
[06:53]  * pitti sings the cruft-busters hymn
[06:54] <pitti> StevenK: ah, http://people.ubuntu.com/~ubuntu-archive/NBS/ has some more to kill; do you want to have the honour?
[06:54] <StevenK> pitti: Yup.
[06:54] <StevenK> pitti: Observe the 13K firefox-2 file ...
[06:55] <StevenK> pitti: I guess libppl-c0 can go. Do we mind if gcc-snapshot is broken on ppc?
[06:55] <pitti> StevenK: right, I forgot to kill mozilla-firefox-locales-all along with the firefox-2 source
[06:55] <pitti> StevenK: don't tell doko, but I don't :)
[06:55] <StevenK> And now that you've said his nick, you've drawn his attention to it :-P
[06:56] <pitti> StevenK: and stuff like adblock-plus already DTRT with alternative dependencies
[06:56] <pitti> ubufox, too
[06:56] <pitti> so it can just go
[06:56] <pitti> along with m-f-l-a
[06:56] <StevenK> Right, I'll just kill it
[06:57] <StevenK> pitti: m-f-l-a source and binaries should die?
[06:57] <pitti> StevenK: yes; for f-3, translations are in the langpacks
[06:57]  * StevenK hits up cocoplum
[06:57]  * pitti holds on something while StevenK makes the earth shatter
[06:59] <doko> pitti: libppl-c0 is obsolete. StevenK: bootstrap on sparc and powerpc is currently broken.
[07:00] <StevenK> 2008-10-14 06:00:50 INFO    337 packages successfully removed.
[07:00] <StevenK> *DAMN*
[07:01] <pitti> *tremble*
[07:01] <ajmitch> that looks promising
[07:01] <ajmitch> great way to clean up bugs :)
[07:05] <viviersf> silly question ? is openofice 3 going into the release ?
[07:05] <StevenK> pitti: NBS flushed
[07:07]  * StevenK kicks octave-gpc a little more
[07:09] <TheMuso> doko: pulseaudio 0.9.13 is in my PA if you are interested.
[07:14] <Hobbsee> ajmitch: the question is...*did* he automatically mark all the bugs as wontfix, with all those removals?
[07:15] <doko> TheMuso: ok, thanks. but probably won't show up in intrepid ...
[07:15] <TheMuso> doko: No it won't.
[07:15] <TheMuso> jaunty most likely
[07:16] <doko> TheMuso: openjdk does need it (as an option) from now on
[07:16] <TheMuso> doko: Thats actually really nice to hear.
[07:17] <StevenK> doko: So, TheMuso and I poked at libtunepimp more. Going back version of binutils didn't help either
[07:18] <Burgundavia> given how many distros seem to release about this time, I am kind of shocked that so many major projects are busy stuffing out major releases right now
[07:21] <Mithrandir> Burgundavia: shouldn't you be surprised the other way around?  The distros should align themselves around releases of their components.
[07:22] <Burgundavia> Mithrandir: no, they are pushing out releases that are missing distros cutoff dates
[07:23] <Mithrandir> Burgundavia: depending on the project, they don't care.  There's always another distro release in six months' time.
[07:23] <Burgundavia> true
[07:23] <TheMuso> Well pulseaudio is a rather fast moving target, so its released when Lennart thinks a new release is worthwhile. 0.9.12 could have probably made it in, however there were some regressions between it and 0.9,10.
[07:23] <TheMuso> Regressions that I think were too much of a problem, since they took away some of pulse's advantages.
[07:24] <TheMuso> Mithrandir: I'd agree with that.
[07:24] <Mithrandir> so getting them into lenny and RHEL is more important than getting them into 8.10.
[07:25] <Mithrandir> (simply because they release more seldomly)
[07:31] <StevenK> checking for Octave version... 3.0.1
[07:31] <StevenK> configure: error: version of octave must be 2.1.57 or later
[07:31] <StevenK> octave-gpc, I'm going to get you.
[07:39] <pitti> slangasek: ah, I fixed s/sys.argv/args/ in sru-accept, it actually works now
[07:54] <mdke> slangasek: I was thinking about something like exporting the translations on Sunday 19 with the translations to be uploaded by Thursday 23
[08:06] <pitti> StevenK: libtunepimp builds fine locally now; cross fingers that it works on ppc now, too :)
[08:15] <tkamppeter> pitti, any chance t fix bug #271288 for intrepid? It is possible that manufacturers also ship PPDs with strange licenses.
[08:16] <pitti> tkamppeter: shouldn't be too hard; I'll target it for intrepid, yes
[08:16] <pitti> tkamppeter: I need to work on jockey anyway, for only offering packaged PPD files by default
[08:17] <pitti> tkamppeter: right now, e. g. splix is broken: it adds the openprinting.org archive, but since that has a smaller version, it installs the ubuntu version anyway (which is probably just fine and working)
[08:17] <pitti> tkamppeter: so I think we should back this out and only install PPD packages for now, until the namespacing is solved (and packages get signed as well, perhaps)
[08:17] <pitti> tkamppeter: what's your feeling about that?
[08:19] <pitti> StevenK: \o/ worked
[08:22] <tkamppeter> pitti, can we do the following: We start only with PPDs, and as soon as there is a naming spec (or better automatizaton in the macro set) we do an SRU of Jockey switching over to binary download support (is probably only a small switch in a config file).
[08:23] <StevenK> pitti: On PPC?
[08:24] <StevenK> pitti: I see that. Woot!
[08:25] <tkamppeter> pitti, will you also fix bug #269454
[08:26] <pitti> tkamppeter: it's a small switch (although not in a config file, but it's fine)
[08:26] <pitti> tkamppeter: if I still have time, yes
[08:26] <pitti> tkamppeter: I have two RC bugs on my lists still, which will probably keep me busy today
[08:26] <pitti> but there's still some time until the release
[08:27] <tkamppeter> pitti, this bug is also very important, as this info is very important for the user to decide about the download.
[08:28] <pitti> right
[08:31] <persia> pitti, Brilliant!  Nice job.
[08:31] <kwwii> pitti: what is the status with the logout stuff? I need to know because of the icons (the little green man is not the desired "look" but I want to make sure that if I replace it with the old red "power button" icon that it will not show up next to another copy of the same icon)
[08:31] <persia> wgrant, Are you still looking for list-props testers?
[08:32] <pitti> kwwii: we don't change it automatically, but on upgrade users get a notification with a "fix it up" button which replaces logout with new fusa and removes old fusa
[08:33] <persia> I still have both Logout and Shutdown in the menu, despite having the new fusa.
[08:33] <pitti> kwwii: so users see it after the first reboot, until they run the upgrade hook (or always if they don't want to get it changed)
[08:33] <pitti> persia: well, it shouldn't be dropped from the menu surely?
[08:34] <pitti> it's my standard way to call the suspend dialog...
[08:34] <persia> pitti, Could be done, but it's tricky.  I suspect it only happens with the consolidated menu.
[08:34]  * persia checks
[08:34] <pitti> well, g-p-m offers it too, but it doesn't offer reboot/shutdown
[08:34] <pitti> persia: what happens?
[08:36] <persia> pitti, I suspect that the "Logout" and "Shutdown" entries only appear in the consolidated menu, rather then the default split menu.  I'm checking in a VM now.
[08:36] <persia> No.  With the split menu, there's still both "Log Out" and "Shut Down" in the System menu.
[08:36] <persia> And it's available from the fusa applet (this is today's liveCD)
[08:37] <persia> (Or, rather, yesterday's : today's seems to have gotten stuck somewhere)
[08:38] <persia> Anyway, the point of bringing this up was to encourage kwwii to still have two icons, for the two menu items.
[08:38] <kwwii> pitti: hrm, that makes things kinda hard then...I guess I should not change the icon or it will confuse some people who upgraded
[08:38] <kwwii> persia: exactly :-)
[08:39] <persia> kwwii, Note that Logout just logs out now, and can't power off, so you might want something different than a power button anyway.
[08:41] <kwwii> persia: yeah, I will probably have to come up with something new and amazingly different :-)
[08:42] <persia> kwwii, Isn't that your superpower anyway?
[08:43] <kwwii> persia: *exactly* (you are really on the ball today!)
[08:57] <wgrant> persia: On obscure archs, yes.
[08:59] <persia> wgrant, Ah.  Does lpia count as obscure?
[08:59] <wgrant> persia: I doubt it... it's too i386.
[09:00] <persia> Well, closer to i686, but yeah.  I don't think I can help then.  Sorry.
[09:10] <pitti> re
[09:10] <pitti> persia: what do you mean with "Still logout and shutdown" in the menu? that's the way it's supposed to be?
[09:11] <pitti> persia: right, but we can't assume that the user has the fusa applet
[09:11] <pitti> I have an upgraded system since, erm, something like woody, and I don't have either applet
[09:12] <pitti> well, for the purposes of GNOME it was really warty, I didn't use GNOME before
[09:13] <persia> pitti, Precisely, so we need visually distinct icons for each function.
[09:14] <persia> And yes, on my continuously upgraded system, I don't have them either (although I don't use that system much anymore : the hardware is aging).
[09:33] <pitti> persia: hm, on my system all functions have a different icon
[09:33] <pitti> not on your's?
[09:34] <persia> pitti, On my system, there are all different icons also.  kwwii wanted to replace the little green man because it didn't match the current look.
[09:35] <persia> He asked you what the plan was for logout, and whether it would go away.  I tried to be helpful, and apparently introduced confusion.  My apologies.
[09:36]  * liw wishes people would stop messing with the logout/shutdown/etc UI
[09:37] <liw> I don't particularly mind what it is like, as long as I don't have keep hunting for it...
[09:37] <Mithrandir> liw: what do you mean, messing with the logout/shutdown UI?  pkill -u $USER and shutdown -h now wfm. :-P
[09:37] <persia> Well, some of the various variations have been unfortunate.  The current one provides way too many ways to do things, but at least it works.
[09:38] <persia> Mithrandir, You do realise that shutdown is just a legacy wrapper now, and may well go away in the future, right?
[09:40] <liw> persia, I've been hearing that for a decade...
[09:40] <persia> liw, Really?  On my system it didn't become a legacy wrapper until just a couple years ago.
[09:40] <persia> (or not that I noticed).  Now it's explicitly provided by a transitional package (upstart-compat-sysv)
[09:41] <persia> Hmm.  Might have only been a year even.  edgy/feistyish I think.
[09:42] <liw> persia, I suspect people have been going back and forth between the various commands for a long time now
[09:44] <persia> liw, Indeed.  I suspect it will be a while before # kill -9 1 breaks, but even that will probably go someday.
[09:46] <Mithrandir> persia: no, given that it's never said anything about being a legacy wrapper, how would I know?
[09:46] <persia> Mithrandir, I guess you'd have to read the changelogs.
[09:46] <Mithrandir> persia: surprise, people don't.
[09:46] <persia> (and as liw points out, fashions may change again)
[09:47] <persia> Mithrandir, I'm not that surprised.  I think it's irresponsible not to read changelogs when installing software, but I'm in the minority.
[09:48] <Mithrandir> persia: my upstart changelog doesn't say anything about shutdown being deprecated.
[09:48] <persia> Mithrandir, Ah.  Hmm.  Maybe I'm mistaken.
[09:48] <Mithrandir> the closest would be:
[09:48] <Mithrandir>     - some upstart-specific options to shutdown and reboot dropped, as
[09:48] <Mithrandir>       these are considered SysV-compat tools.
[09:49] <Mithrandir> that they're a compatibility layer does not mean they'll go away.
[09:50] <Company> dholbach++
[09:51] <dholbach> Company: hm?
[09:51] <Company> swfdec 0.8 finally in intrepid
[09:52] <dholbach> Company: I merely sponsored the upload - it wasn't my work :)
[09:52] <dholbach> but I'm glad you're happy
[09:53] <seb128> dholbach: did didrocks rebase the update on 0.7?
[09:53] <dholbach> seb128: yes
[09:53] <seb128> dholbach: did you sponsor swfdec-gnome too?
[09:53] <dholbach> seb128: no, I didn't know what the verdict on swfdec-mozilla was
[09:54] <emgent`> hello
[09:54] <seb128> dholbach: swfdec-mozilla is yet an another one no?
[09:54] <emgent`> http://www.securityfocus.com/bid/30794/discuss
[09:54] <emgent`> hahah red hat.
[09:54] <seb128> Company: do you really need to version those this way btw? are there really users running several versions?
[09:54] <dholbach> seb128: yes, but still I wanted to keep the options open until I knew what the plan forward is
[09:54] <didrocks> seb128: yes, I did
[09:55] <Company> seb128: i was told it's the best way to handle API instability
[09:55] <didrocks> dholbach: I am working on swfdec-mozilla
[09:55] <dholbach> didrocks: ROCK
[09:55] <didrocks> dholbach: :)
[09:55] <dholbach> emgent`: I'm not sure that gloating is appropriate
[09:56] <directhex> ding dong, this is your early morning merge request. https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
[09:56] <seb128> Company: usually the best way to handle instability is to change the soname
[09:57] <emgent`> dholbach: I'm laughing because redhat long ago said that their archives were damaged but there was no danger to users.
[09:57] <seb128> dholbach: ok, swfdec-gnome is technically GNOME so having 2.24 would be nice ;-)
[09:57] <seb128> dholbach: thanks for the sponsoring
[09:57] <pitti> me, seems I have a real mind blocker here; "sudo pbuilder --create --basetgz /var/cache/pbuilder/hardy.tar.gz --distribution hardy --mirror http://de.archive.ubuntu.com/ubuntu" says "E: File /var/cache/pbuilder/hardy.tar.gz does not exist"; what am I doing wrong her?
[09:57] <pitti> of course it does not exist, I want to create it, you silly pbuilder
[09:58] <liw> pitti, touch the file, pbuilder is happy with that (I don't know if that's considered to be a bug)
[09:58] <dholbach> emgent`: still - I'm not happy about it -- being glad because it didn't happen to us or to you is very different from laughing about mistakes and problems from somebody else
[09:59] <pitti> hm, it's by far not the first pbuilder I created, and I never had to do that
[09:59] <pitti> liw: hm, that helped; thanks
[09:59] <dholbach> emgent`: when we ran into the openssl debacle I didn't see  "haha, look at those Ubuntu/Debian people" - it's just not a response I'd expect from an Ubuntu developer
[09:59] <Company> seb128: i don't really care how i do it (if by soname or libname or whatever), but for me this approach works well, is gnomey and i know what i'm doing
[09:59]  * pitti utters another curse about pbuilder defaulting to cdebootstrap, but is happy now
[10:00] <Company> seb128: plus, every distro seemed happy with it
[10:00] <wgrant> dholbach: While I agree that gloating isn't good, lots of people did you "haha, look at those Ubuntu/Debian people".
[10:00] <directhex> dholbach, i saw plenty of "haha, look at those Ubuntu/Debian people"
[10:00] <wgrant> s/you/go/
[10:00] <dholbach> wgrant, directhex: Redhat developers?
[10:01] <wgrant> And then people gave Red Hat and Fedora hell for their issue.
[10:01] <emgent`> dholbach: yes it`s seems correct, but i dont like redhat devel aggressivity. anyway sorry if you still has problems
[10:01] <seb128> Company: swfdec0.8 is sitting in debian NEW for some weeks now and that's the reason we can't sync it in ubuntu and it's waiting there too
[10:01] <wgrant> dholbach: True. Perhaps not.
[10:01] <dholbach> I'm not talking about uninformed users or trolls
[10:01] <seb128> Company: that requires NEWing new sources, migrating bugs, etc every time
[10:01] <seb128> Company: I would not say distro are happy about it, that's just lot of extra work for no real win, no other GNOME software does that
[10:02] <Company> seb128: the debian stuff is not really my problem, but debian's (or yours)
[10:02] <Company> seb128: yeah, the other gnome software considers itself stable
[10:02] <wgrant> Wait, the upstream source name has the version number in the name? I thought it was just Debian people being strange.
[10:02] <seb128> Company: what is wrong with changing soname when you break abi?
[10:02] <seb128> Company: and that's not really true, having distros shipping your software is somewhat your problem too
[10:02] <Company> seb128: nothing is wrong with it, it's just not how we've done it before
[10:03] <seb128> Company: we could just decide that if you decide you don't care about distro we don't care about your software, which is no-win situation
[10:03] <Company> seb128: btw, there's some debianites running swfdec stable and unstable at the same time
[10:03] <Company> but other than that, noone runs 2 libswfdecs
[10:03] <seb128> Company: people doing that probably know what configure option to use to install in a different directory
[10:04] <pitti> with that argument we could version every package...
[10:04] <Company> although i could imagine that happening when amsn etc start using it for winks (they wanted to)
[10:04] <Company> seb128: debian ships swfdec-mozilla-unstable
[10:04] <Company> (orsomething like that)
[10:05] <emgent`> gh
[10:05] <seb128> Company: which probably conflict with the normal version, mozilla doesn't let you choice the plugin to use at runtime anyway so you need to uninstall the one you don't want by some way
[10:05] <Company> seb128: yeah, i guess so
[10:06] <seb128> Company: anyway no big deal we got 0
[10:06] <seb128> .0.8
[10:06] <seb128> Company: I'm just letting you know that the versionning is really annoying for some distros
[10:06] <Company> seb128: but as i said: currently it doesn't matter for me how it's done, whatever fits distros best
[10:06] <Company> seb128: yeah, ubuntu is special there - but every distro is special somewhere ;)
[10:06] <seb128> the usually way to deal with abi breakage is soname updates
[10:06] <directhex> osc-bigmac:/home/jms# apt-cache search swfdec unstable
[10:06] <directhex> osc-bigmac:/home/jms#
[10:09] <Company> yeah, no swfdec-mozilla-unstable in debian
[10:09] <Company> good thing, i wasn't convinced of the idea anyway ;)
[10:10] <directhex> seems broken in debian anyway
[10:10] <directhex> most arches have 0.6, amd64 has an incomplete uninstallable 0.8
[10:10] <Company> yeah
[10:10] <Company> hanging in the NEW queue
[10:11] <Company> lenny freeze issues people tell me
[10:11] <cjwatson> TheMuso: *user-params* causes update-grub to be called a second time? are you sure?
[10:12] <cjwatson> TheMuso: oh, mediated by grub-installer I suppose
[10:37] <StevenK> pitti: So, octave-gpc is busticated, and I can't make it work with octave3.0
[10:37] <dholbach> somehow accents on my keyboard don't work anymore - ^e for example doesn't give me e with circumflexe
[10:37] <dholbach> anybody had the same issue on intrepid?
[10:37] <dholbach> I just moved away my xorg.conf and configured gnome to use "german nodeadkeys" which worked in the past
[10:38] <RAOF> dholbach: ê seems to work for me, at least as long as you mean <compose>^e
[10:38] <pitti> dholbach: but nodeadkeys is exactly that, it doesn't wait for composition
[10:38] <dholbach> RAOF: I didn't have to use the compose key before
[10:38] <pitti> dholbach: try with dead keys?
[10:39] <pitti> dholbach: so it should give you ^e with nodeadkeys, i. e. the ^ appears immediately
[10:39] <dholbach> yes, it appears immediately in both cases
[10:39] <pitti> sounds like 'nodeadkeys' is working as it should then
[10:40] <dholbach> ok... maybe I should have asked differently ... how do I get the "old behaviour" back? ie: pressing ^ then e gives me ê ?
[10:41] <Keybuk> compose doesn't work for me today?
[10:41] <dholbach> same for ~ ` and '
[10:41] <Keybuk> compose-e-^ just beeps at me
[10:41] <RAOF> Keybuk: How about compose-^-e?
[10:41] <pochu> dholbach: I have the asme issue... but even pressing "^" twice, it doesn't print ^ at all
[10:41] <pitti> dholbach: Deutschland/Germany works
[10:41] <Keybuk> RAOF: that works
[10:41] <pitti> dholbach: i. e. don't choose the deadkeys
[10:42] <RAOF> Is it meant to work the other way 'round?
[10:42] <Keybuk> RAOF: it always has for me
[10:42] <dholbach> pitti: it doesn't work for me - in all cases I always get first ' ` ^ ~, then the other character
[10:43] <dholbach> whatever I pick in the keyboard configuration thingie
[10:43] <pitti> I tested it here, works fine
[10:43] <pitti> dholbach: maybe you have "separate group for each window" or something such?
[10:45] <dholbach> é è ê ẽ ø ï
[10:45] <dholbach> ok, I'm happy again
[10:45] <dholbach> thanks pitti - that was it
[10:45] <dholbach> although I can't remember having checked that box
[10:46] <Keybuk> ooh, you can do “double quotes” with compose :)
[10:46] <Keybuk> I didn't know that!
[10:47] <dholbach> seb128: do you have an opinion about bug 280806?
[10:48] <Keybuk> though, inconsistency of the week: compose = C gives you €  (shouldn't that be - e ?);  compose - L gives you £;  but compose | S doesn't give you $ :p
[10:49] <StevenK> asac_: So, why does gnash ship a .desktop file?
[10:50] <ogra> besauce it can standalone ?
[10:50] <asac_> StevenK: because the viewer is ment to be a viewer. we might hide it from menu
[10:50] <ogra> *because
[10:50] <asac_> but we need the mime-type mapping i guess
[10:50] <ogra> *run ...
[10:50] <StevenK> asac_: Sure, but it just exec's gnash which gives a usage message
[10:50]  * ogra gets more coffee
[10:50] <asac_> StevenK: which is a bug in the gnash viewer from my point
[10:50] <asac_> StevenK: the mime-type associated thing should work though
[10:50] <asac_> e.g. right click on a swf file... select gnash -> done
[10:51] <StevenK> asac_: Well, the reason I bring it up is it appears in Kourou, the MID launcher
[10:51]  * StevenK tries to sort out the rubygems mess
[10:51] <asac_> StevenK: yes. imo we should consider to not show it in menu
[10:51] <asac_> i think that should be fairly easy to do
[10:52] <StevenK> asac_: NoDisplay=true
[10:52] <asac_> StevenK: so is mobile team caring for gnash?
[10:52] <StevenK> asac_: No, we just seed it because we like it.
[10:53] <asac_> StevenK: NoDisplay -> will that also remove the mime-type suggestion?
[10:53] <asac_> or only in the launcher?
[10:53] <StevenK> The mime-type suggestions use .desktop files?
[10:54] <persia> MIME types are registered in .desktop files, but the format for a MIME Entry should be different than an application launcher.
[10:54] <james_w> do we freeze again on Thursday?
[10:55] <persia> Specifically, the Type key shouldn't be an application
[10:55] <StevenK> And the gnash .desktop is a [Desktop Entry]
[10:55] <asac_> persia: err. its an application
[10:55] <persia> RIght, but should be [MIME Type] if it's just MIME registration
[10:55] <asac_> persia: it just doesnt start without argument ;)
[10:55] <ogra> james_w, the schedule doesnt say so
[10:55] <james_w> ogra: yeah, that's what is confusing me
[10:55] <persia> asac, If there's not a way to start with sensible default arguments, it oughtn't be registered in the menu.
[10:55] <asac_> hmm the mimetype isnt even in there
[10:56] <asac_> persia: yes. but thats NoDisplay?
[10:56] <ogra> i think we'll likely freeze for CD builds but monday should suffice
[10:56] <persia> asac, No, that's not having a menu entry .desktop file at all.
[10:56] <ogra> there seems to be no official RC freeze though
[10:57] <persia> asac, I think you want a .desktop file to register your MIME Type, but I think you don't want one that would be a menu entry : just a context entry for MIME-aware file browsers.
[10:57] <asac_> persia: not sure. at some point i want it to be an application. but for now i just want the mime mapping yes.
[10:58] <persia> asac, Something that launches from a menu directly, without any arguments?  In that case, yes, you'd want a menu entry.  In this case, I think you want something smaller.  I'm searching for a good example now.
[10:58] <asac_> persia: no for now gnash only starts with the content file as an argument
[10:59] <davmor2> mvo: just finished an install of Ubuntu for smoke testing would your compiz fix be on this mornings iso or is it in repo?
[10:59] <asac_> (which is the point why the complained about having it in menu is right)
[10:59] <persia> Right, so it needs the other kind of .desktop file
[10:59] <asac_> let me check. i think i have a bug
[11:00] <asac_> persia: http://launchpadlibrarian.net/8613124/gnash.desktop thats the current suggestion
[11:00] <StevenK> pitti: Want to cast your eyes on http://people.ubuntu.com/~ubuntu-archive/NBS/libltdl3 ?
[11:00] <asac_> persia: what opther changes?
[11:00] <asac_> Type=MimeType?
[11:00] <StevenK> pitti: I think we're close enough to kill it
[11:00] <pitti> StevenK: I agree
[11:00] <asac_> anything else? maybe i need to put it in a different location? e.g. not /usr/share/applications
[11:01] <persia> No, /usr/share/applications is correct.
[11:01] <asac_> pitti: could you also remove firefox-2 and the mozilla-firefox-locale-all package? i will include a transition package for firefox-2 in the next upload
[11:01] <StevenK> asac_: I've already killed them both
[11:01] <pitti> asac_: IIRC StevenK already did
[11:01] <asac_> StevenK: brave
[11:01] <StevenK> asac_: mozilla-firefox-locale-all was 337 packages!
[11:01] <asac_> there should be stilla bunch of extensions dangling (like 2 or three never supported firefox 3)
[11:02] <StevenK> asac: If you get a list, make a bug and subscribe -archive
[11:02] <asac> but i have to wait for jazzva who will hopefully return tomorrow or so from holiday
[11:02] <asac> StevenK: yeah. jazzva has prepared that list, but i forgot where he posted it
[11:03] <StevenK> ogra: Can you stop ubuntu-mobile needing gimp-python, and I'll fix the other thing
[11:03] <seb128> dholbach: just don't do the update as the recent comment suggests on the bug
[11:03] <ogra> StevenK, the seeds are fixed already
[11:03] <dholbach> seb128: ok, I'll unsubscribe the sponsors
[11:03]  * StevenK resists the urge to set the comment to "Finally NBS this damn thing out"
[11:04] <seb128> dholbach: danke
[11:04] <dholbach> de rien
[11:04] <StevenK> pitti: libltdl3 killed
[11:04] <pitti> yay!
[11:04] <james_w> StevenK: I've got a fix for nufw, just waiting for Michael to check he hasn't got one waiting for sponsorship. Is that the last of the gnutls transition?
[11:04] <cjwatson> NBS> I don't suppose anyone is planning to deal with the enormous component-mismatches list? :)
[11:04] <persia> asac, I'm not finding the docs I want right now.  For now, just use NoDisplay=true (as is used by vinagre-file.desktop vs. vinagre.desktop).
[11:05] <asac> persia: http://paste.ubuntu.com/57361/
[11:05] <pitti> cjwatson: that looks like a full-week job of all archive admins
[11:05] <asac> persia: hmm
[11:05] <asac> so no Type=MimeType?
[11:05] <persia> asac, Not according to the spec I just read.  I was sure I saw it somewhere.
[11:05]  * persia checks the dh_desktop call to see if that provides a hint
[11:06] <persia> asac, No, that just checks for the MimeType= key.
[11:07] <seb128> persia: what are you looking for exactly?
[11:08] <asac> seb128: applications that shouldnt be in the menu, but are helper for mime-types
[11:08] <asac> seb128: are they supposed to have a Type!=Application ?
[11:08] <asac> in .desktop
[11:08] <persia> seb128, The way to create a .desktop file that registers a MIME Type that can be actioned, but doesn't register a menu entry.  Is it just the absence of Categories?
[11:09] <persia> asac, No, use Type=Application.  That's mandated for that sort of thing in the spec.
[11:10] <seb128> persia: the way it's done usually is just by using NoDisplay=true
[11:11] <asac> persia: StevenK: please check if you are happy with this ;) http://paste.ubuntu.com/57366/
[11:11] <persia> seb128, I thought I remembered seeing a guide on either the Debian wiki or a Debian mailing list with some other advice, but that's what I'm seeing in my current .desktop file selection.
[11:11] <StevenK> asac: Looks great to me
[11:12] <seb128> persia: dunno about debian but GNOME uses NoDisplay=true in a consistant way
[11:12] <persia> asac, s#/usr/bin/gnash#gnash %U#
[11:12] <persia> seb128, RIght.
[11:13] <persia> asac, also, s#/usr/share/pixmaps/gnash.xpm#gnash#
[11:14] <persia> asac, lastly, /^Enco*/d
[11:14] <asac> k
[11:14] <asac> persia: the final artwork -> http://paste.ubuntu.com/57371/
[11:15] <ogra> Koon, heh, your fix for dhcpd looks great apart from the fact that you have  space in the shebang line :)
[11:15] <ogra> *a space
[11:15] <persia> asac, Looks great to me.
[11:15] <Koon> ogra: oops
[11:15] <persia> ogra, The spec calls for a space ...
[11:15] <ogra> Koon, fine to upload if you prepare a debdiff
[11:16] <ogra> persia, ?
[11:16] <persia> "#! ${interpreter}"
[11:16]  * ogra wonders what spec that might be 
[11:16] <persia> Single Unix Specification
[11:16] <Koon> indeed, the space comes from the copy of the openssh-server one.
[11:17] <pitti> cjwatson: for bug 256131, we need to make sure that xml-core is at least at 0.11ubuntu1 before even unpacking rarian-compat (old/new prerm script fail to "upgrade" otherwise); this would work with rarian-compat Pre-Depends: xml-core (>= 0.11ubuntu1); do you see an issue with that? should I use something less intrusive than pre-depends?
[11:17] <persia> Most shells will accept the absence of the space, but the space is technically correct
[11:17] <asac> do we still need dhcpd?
[11:17] <asac> at least NM doesnt use it anymore
[11:17] <pitti> asac: I don't think so, n-m 0.6 was teh only user
[11:18] <ogra> persia, wow, i didnt know .... i always thought it fails to execute with a space :)
[11:18] <pitti> woudl be nice to remove it on upgrades, though
[11:18] <StevenK> pitti: So, I have 7 uploads to clean up this libgems-ruby1.8 or rubygems -> rubygems1.8 mess. Will you hate me if I upload them without test building?
[11:18] <ogra> Koon, fine then
[11:18] <persia> ogra, heh.  No. :)
[11:18] <pitti> StevenK: no, buildds are free ATM, it doesn't cause congestion
[11:18] <StevenK> pitti: Six of them now have Ubuntu changes that they didn't before :-(
[11:18] <asac> pitti: i guess we can remove it then from CD/main? or has that happened?
[11:19] <pitti> asac: that too (shouldn't even be on current CDs), but I meant on upgrade
[11:19] <pitti> asac: i. e. new network-manager coudl conflicts:/replaces: dhcdbd perhaps
[11:19] <asac> pitti: which package should take care of that?
[11:19] <asac> ok
[11:19] <pitti> I'm not sure
[11:19] <pitti> in theory, any package in ubuntu-desktop could
[11:19] <asac> update-manager ? ;)
[11:20] <pitti> well, sure, but apt-get dist-upgrade compatible solutions are always nice :)
[11:20] <pitti> asac: hm, hang on
[11:20] <mvo> asac: hm?
[11:20] <pitti> mvo: if dhcdbd gets demoted to universe, u-m will clean it up, right? but what if the package doesn't exist at all any more?
[11:21] <mvo> pitti: if it gets removed from the archive it gets cleaned up, if it moves to universe the user will be warned about it
[11:21] <cjwatson> pitti: I *think* that's OK but could you raise it on ubuntu-devel@ ?
[11:21] <pitti> cjwatson: ok
[11:21] <asac> yeah. but making NM conflict it isnt nice either
[11:21] <cjwatson> new Pre-Depends should be discussed there really
[11:22] <StevenK> pitti: I'm tempted to bin libhdf5-serial-1.6.5-0 and libopenvrml5c2a anyway. They're both broken, and I can't fix them.
[11:22] <StevenK> pitti: Er. Their rdepends are both broken, I mean
[11:22] <cjwatson> pitti: dhcdbd> my take is that "needs to be removed" should be handled by Conflicts and "would be nice to remove" should be handled by update-manager
[11:22] <asac> i think its the latter
[11:22] <pitti> I agree
[11:22] <asac> i dont see a reason why people cant have NM + dhcdbd installed at the same time
[11:23] <pitti> but mvo just confirmed that it gets cleaned up,so if we remove the package, all shuold be well
[11:23] <pitti> asac: no, it's just cruft; shouldn't break
[11:23] <pitti> ok, I'll remove dhcdbd then
[11:23] <persia> package removal is usually better, unless there's a lack of good alternatives.  We have several other DHCP clients and servers.
[11:23] <asac> pitti: remove completely? or demote/unseed?
[11:24] <pitti> asac: I'd just remove it; nobody is going to look after it, I suppose
[11:24] <pitti> and it has empty checkrdepends
[11:24] <pitti> asac: do you want to keep it?
[11:24] <asac> hmm ... deosnt that come from debian?
[11:24] <pitti> yes, it does
[11:25] <ogra> StevenK, do you want me to do the -meta update as well ? or do you have a new meta change pending anyway?
[11:25] <ogra> (gimp-python)
[11:26] <StevenK> ogra: I don't, so go ahead
[11:26] <asac> pitti: personallyi dont want it. just wonder whats our policy to decide whether we want a debian package in universe or not
[11:26] <ogra> oki
[11:27] <persia> Historically, we've wanted everything from Debian in universe, but old packages with clear replacements don't tend to get a lot of effort by MOTU, so it's likely to just bitrot unless it's actively maintained in Debian.
[11:27] <pitti> removed and blacklisted
[11:28] <pitti> if anyone is missing it, he can ask for it
[11:28] <asac> yeah ;)
[11:28]  * StevenK is plotting uploading gimp-plugin-registry to stop needing gimp-python and python
[11:30] <persia> StevenK, Is there any chance that there will be python bindings for gimp in intrepid?  Also, don't a few other things depend on python?
[11:30] <StevenK> persia: I've not investigated what happened to the Python bindings
[11:31]  * persia looks at Debian
[11:32] <persia> StevenK, There's at least the gimp-gnomevfs fix we want from Debian.
[11:33] <StevenK> persia: gimp 2.6.1-1 is in experimental, and we have 2.6.1-1ubuntu2 ?
[11:33] <persia> Ah.  I missed the version numbers somehow :/
[11:40] <StevenK> persia: Who do I hit up for cra^Wbackports?
[11:41] <ogra> silly firefox
[11:42] <persia> StevenK, Looks like the python bindings are in the "gimp" binary package now.  I suspect ari will eventually split them out, but they aren't meaningful in a package context right now.
[11:43] <ogra> your browser needs to be restarted .... so i reboot the system .... the first thing coming up when i start the browser after a reboot: your browser has been updated and needs to be restarted :P
[11:43] <persia> For backports, I'd recommend jdong or ScottK, but NCommander has been increasingly active there as well.
[11:43] <StevenK> persia: So gimp-python just gets NBS'd out. Sweet.
[11:44] <persia> StevenK, As far as I can tell.  I'm not a gimp-python user, and haven't verified that the python-support hooks are doing the right thing, but that shouldn't affect the old binary package (which wouldn't work anyway due to API changes)
[11:44] <Treenaks> ogra: that's nothing, try 'man gzip'
[11:44] <ogra> heh
[11:45] <persia> Didn't there used to be a manpage for gzip?
[11:45] <persia> (info gzip still works)
[11:45] <Treenaks> persia: https://bugs.edge.launchpad.net/ubuntu/+source/gzip/+bug/281825
[11:45] <james_w> NCommander: hi, are you working on nufw? I have a candidate fix here, do you mind if I upload?
[11:46] <StevenK> james_w: If I didn't answer your question, it's the last thing we fix for libgnutls13.
[11:46] <persia> james_w, There's a trivial patch from Dave Love that would be good to merge with that if you don't mind (check the other nufw bug)
[11:46] <james_w> persia: it's fixed already
[11:46] <persia> Oh, cool.
[11:46] <james_w> as is the bug
[11:52] <pitti> BenC: btw, thanks for getting uvesafb fixed up; usplash now works again even on my external monitor (on dock)
[11:52] <pitti> BenC: do we still actually need v86d in main/anywhere? or can it go back to universe?
[11:52] <pitti> BenC: (it currently wants to go to universe since nothing is depending on it)
[11:53] <pitti> how do I tell git "show me the diff of commit 1234"? "git diff 1234" is something like bzr diff -r 1234, but I want bzr diff -c 1234
[11:53] <pitti> and git diff --help is utterly nonhelpful for that
[11:54] <broonie> pitti: git show
[11:54] <BenC> pitti: uh, I did nothing to fix it
[11:54] <jcristau> git show 1234
[11:54] <TheMuso> cjwatson: Yes it is run by grub-installer. The difference which makes things take a different logic path is that the user_params variable = quiet when using netboot, but doesn't contain anything in a normal CLI CD install. I used CLI mode in netboot also.
[11:55] <pitti> broonie: ah, thanks
[11:55] <BenC> pitti: git-diff-tree -p --pretty 1234
[11:55] <pitti> TIMTOWTDI apparently :)
[11:56] <cjwatson> TheMuso: ah, right. So how come it breaks when update-grub is run again?
[11:56]  * ogra tries to pronounce what pitti wrote there ...
[11:56] <TheMuso> cjwatson: I don't know. That requires looking in update-grub, and I am not sure if its possible to get output of the execution path like it is with sh.
[11:57] <TheMuso> because afaicr update-grub is perl.
[11:57] <pitti> ogra: "there is more than one way to do it", the Perl mantra
[11:57] <ogra> ah :)
[11:57] <StevenK> ogra: Pronounced "Tim-toe-de"
[11:57] <pitti> tim-towdee or so
[11:57] <directhex> jms@osc-bigmac:~$ head -1 `which update-grub`
[11:57] <directhex> #!/bin/bash
[11:57] <directhex> FYI.
[11:58] <cjwatson> what directhex said :)
[11:58] <TheMuso> oh ok. I just remember seeing something to do with perl in the syslog. Will dig again tomorrow morning.
[11:58] <directhex> see, i'm full of useful info. like a really easy way to close a couple of intrepid CVEs!
[12:19] <StevenK> What the?! jpoker failed on i386?
[12:19] <StevenK> And took 41 minutes. Wonderful
[12:20] <StevenK> gem install --include-dependencies --no-rdoc --no-ri --install-dir gems tiddlywiki_cp || \
[12:21] <StevenK> 	gem install --include-dependencies --no-rdoc --no-ri --install-dir gems tiddlywiki_cp
[12:21] <StevenK> Oh, you *have* to be kidding.
[12:21] <ogra> fun
[12:22] <Mithrandir> can we replace gem with a very small shell script?
[12:22] <StevenK> IE: #!/bin/sh\nexit 0\n ?
[12:22] <StevenK> Why not just symlink it to /bin/true? :-)
[12:23] <Mithrandir> StevenK: because /bin/true doesn't output "No, you fool" when you run it?
[12:24] <StevenK> Mithrandir: I think it needs to face-stab people when they run it.
[12:24] <StevenK> That'd fix those pesky rails developers, too
[12:37] <Treenaks> I've attached a patch to debian/rules to the gzip bug (281825) which fixes it
[12:37] <Treenaks> at least, for me
[13:36] <lool> at this point of the cycle, I would be more confortable if someone could confirm the fix in #283200
[13:36] <lool> I couldn't find an already reported bug, which kind of surprized me
[13:37] <Koon> ogra: please see https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/280123/comments/3
[13:46] <Koon> lool: bug confirmed, testing te fix right now
[13:46] <lool> Koon: I pushed the package to my ppa if you like
[13:46] <lool> Koon: it's built
[13:49] <Koon> lool: the patch fixes it for me
[13:50] <lool> Koon: thanks a lot for confirming, will push to intrepid then
[13:51] <Koon> lool: haven't tested from your PPA though, I patched rc directly
[13:53] <lool> Koon: Ok, thanks; I pushed to intrepid now
[14:04] <BenC> cjwatson: new lrm that created nic-restricted-{modules,firmware} is being uploaded
[14:05] <BenC> cjwatson: it includes ipw2[12]00 and iwl{3945,4965,5000} firmware
[14:06] <cjwatson> BenC: is there a non-restricted nic-firmware these days?
[14:07] <cjwatson> BenC: what about scsi-firmware?
[14:07] <BenC> cjwatson: there used to be a restricted one from lrm, and since I'm creating this from lrm, I figured I would be consistent
[14:07] <cjwatson> BenC: but is there nic-firmware *now*?
[14:07] <BenC> cjwatson: no
[14:08] <cjwatson> BenC: many devices certainly used to need scsi-firmware. Does that still exist?
[14:09] <BenC> cjwatson: It doesn't...let me check what we have
[14:09] <directhex> ding dong, this is your early afternoon merge request. complete with security vulnerability healing powers. https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
[14:10] <BenC> cjwatson: I guess aic94xx and qla2x00 should be in one
[14:14] <cjwatson> BenC: have you given any consideration to the upgrade path for users of those modules who did not have l-r-m installed yet?
[14:15] <elmo> (like, say, servers? :-P)
[14:16] <cjwatson> elmo: do you use do-release-upgrade on servers?
[14:16] <elmo> cjwatson: yep
[14:16] <maswan> as a random server admin, so do I
[14:17] <cjwatson> I think the main/restricted split makes it somewhat inevitable that modules will occasionally move the wrong way, so I'm OK with release-noting this and having do-release-upgrade prompt if necessary; but this needs to be implemented
[14:17] <BenC> cjwatson: Well, if they don't have lrm-common installed, then likely they removed it themselves
[14:17] <cjwatson> if we hand-wave until after release we'll just get bad press about it
[14:17] <cjwatson> BenC: yes, they did. that doesn't mean we get to screw them over
[14:17] <mvo> if do-release-upgrade/update-manager should deal with it, I would like to know as early as possible .)
[14:17] <elmo> JOOI, why is this particular firmware being punted to restricted now?
[14:17] <cjwatson> elmo: I have no idea, and have argued against it
[14:17] <BenC> mvo: consider yourself in the know :)
[14:18] <BenC> elmo: because we have no place else to move it?
[14:18] <cjwatson> BenC: it's permitted in main
[14:18] <elmo> BenC: err, what's wrong with leaving it in main?
[14:18] <cjwatson> BenC: the licence policy is quite explicit that we'll consider firmware on a case-by-case basis
[14:18] <BenC> elmo: it was in lum, and lum is gone
[14:18] <BenC> it's not main...it's that I don't want to add it to the linux source
[14:18] <cjwatson> BenC: put it in linux, or create a new linux-firmware source package in main, or *something*
[14:19] <cjwatson> (I think I suggested linux-firmware before)
[14:19] <elmo> cjwatson++
[14:19] <BenC> that still doesn't help the upgrade path
[14:19]  * liw suggests linux-firmwarez
[14:19] <cjwatson> sure it does, if linux-image-* depends on the firmware
[14:19] <cjwatson> which would be totally reasonable
[14:19] <elmo> BenC: sure it does, just make stuff depend on it?
[14:20]  * BenC notes there are underlying issues in making linux-image depend things that gnu would consider non-free
[14:20] <BenC> not technical ones, but "I'm going to hear about it later" ones
[14:21] <cjwatson> BenC: this isn't new; the files were already there
[14:21] <cjwatson> and Ubuntu is very clear on our position here
[14:22] <BenC> cjwatson: So are you prepared to NEW and MIR this new package for me?
[14:22] <BenC> going to require a new kernel upload and everything
[14:22] <cjwatson> if you want to move them in jaunty, I'd be OK with that, but I think it's bad to have to add update-manager UI for this two weeks before release
[14:22] <cjwatson> we should have planned the upgrade path way in advance
[14:22] <BenC> actually, I'll make linux-foo meta depend on it
[14:22] <cjwatson> BenC: certainly
[14:22] <BenC> will be easier
[14:23] <BenC> cjwatson: either way, this is a good bit to do 2 weeks before release :)
[14:23] <cjwatson> linux-meta> OK in the short term but I do think the actual kernel binaries should depend on it
[14:23]  * Hobbsee notes users won't be happy if ipw3945 has been replaced by another "nonfree" driver, which it will be judged to be if it appears in l-r-m - particularly as a lot of users have had trouble with it (such as no LED, for all of hardy).
[14:23] <cjwatson> but I suppose that doesn't matter so much
[14:24] <BenC> Hobbsee: umm, way off on the discussion
[14:24] <cjwatson> BenC: we did bring it up last week when it would have been three weeks before release ;-)
[14:24] <cjwatson> before that, at least I wasn't aware of the problem
[14:25] <Hobbsee> BenC: oh, right, so this is "created based off l-r-m, but would be called something completely different, and also not restricted".  I agree, i'm kinda late.
[14:25] <BenC> cjwatson: Ok, linux-firmware == new package, created nic-firmware/scsi-firmware udeb's, lrm will have firmware removed but still create nic-restricted-modules, linux-meta updated to have linux-image-foo depend on linux-firmware
[14:25] <BenC> s/created/creates/
[14:25] <BenC> cjwatson: sound complete?
[14:28] <pitti> BenC: we don't need to make a lot of MIR fuss about it; if that firmware is in hardy main, we can NEW it straight into intrrepid main
[14:28] <pitti> we traditionally haven't done MIRs for package renames/splits (which is what this amounts to)
[14:29] <BenC> pitti: ok
[14:38] <ogra> tedg, !
[14:38] <tedg> Good morning ogra
[14:38] <ogra> great to see you :)
[14:38] <ogra> IRC is a lot faster than discussing stuff on bugreports :)
[14:40] <tedg> ogra: Heh, yeah.  I'll try to get those fixed.
[14:40] <ogra> i think the two with patches are trivial to do, what do you think about the logout issue ?
[14:42] <tedg> ogra: I don't think that's a big deal.  I'm curious how the command line gnome session works if there's no gnome-session though.
[14:42] <ogra> there is a gnome-session
[14:42] <ogra> Xsession spawns it
[14:43] <tedg> ogra: Can you also try the GNOME Power Manager in my PPA?  It changes the power button behavior, it should use DBus and then fall back to XSMP.
[14:43] <ogra> well, Xsession spawns x-session-manager, which is an alternative linking to gnome-session
[14:43] <cjwatson> BenC: I think that makes sense
[14:43] <tedg> ogra: But the gnome session is running on the server?  So one can't do DBus to gnome-session?
[14:43] <ogra> right
[14:43] <cjwatson> BenC: thanks
[14:44] <ogra> until dbus gets a proper TCP protocol for remote connections
[14:44] <ogra> which we then could tunnel through the ssh tunnel
[14:44] <ogra> but even if that was there now, that would mean massive infrastructural changes to the way ltsp/ldm work atm
[14:45] <ogra> with intrepid we at least have a dbus installed in the client env, i'm happy to discuss session dbusification for jaunty, but in intrepid that wont be possible yet
[14:46] <seb128> ogra: how is your session working at all without dbus?
[14:46] <seb128> ogra: gconf is using dbus to get started in intrepid for example
[14:47] <ogra> it uses the servers system bus
[14:47] <ogra> that works fine until you want hw related things
[14:47] <seb128> gconf is not a system service
[14:47] <ogra> for which we have ltspfs
[14:47] <sebner> cjwatson: maybe you can tell me if the kernel team have plans with jaunty and ext4 or should I ask in #u-kernel
[14:47] <ogra> seb128, well, it works
[14:48] <ogra> seb128, and until now we refrained from dbus and hal installs on clients ... such devices usually have around or less than 64M ... every byte counts ...
[14:49] <ogra> with Xorg forcing that my only chance to still <support such devices was compcache ...
[14:53] <cjwatson> sebner: I don't know why I would know
[14:54] <cjwatson> sebner: -> #ubuntu-kernel
[14:54] <cjwatson> sebner: note that I am not a member of the Ubuntu kernel team
[14:55] <sebner> cjwatson: ah kk, thx
[14:57] <davmor2> mvo: Which compiz fix is meant to resolve the menu issue?
[14:58] <mvo> davmor2: the issue in the apperance capplet? the libcompizconfig -0ubuntu2 and the compiz -0ubuntu3 uploads
[14:58] <mvo> davmor2: I'm not 100% sure if they are enough though, but its definitely a step forward
[15:00] <davmor2> mvo: yeah got them rebooted and checked the menu and it is still happening.  Sorry.
[15:01] <mvo> davmor2: ok, thanks for the test. I will dig deeper
[15:01] <davmor2> mvo: Np's I'll be smoke testing all week so if you find a fix just ping me :)
[15:02] <tedg> ogra: Do you have a setup that you can look at the GPM update?  I wanted to ask for sponsorship on it this morning, but now I'm concerned it'll break LTSP.
[15:03] <ogra> tedg, i have a vbox setup of ltsp, easy for testing
[15:06] <tedg> ogra: Cool, can you attach a thumbs up/down to bug #252795?  Thanks.
[15:06] <tedg> Heh, ubottu is reporting it as a bug in Fedora. ;)
[15:07] <ogra> tedg, oh, thats hard
[15:08] <BenC> cjwatson: Have you heard anything about the installer and disks with host-protected-area in intrepid?
[15:08] <ogra> tedg, i have no clue how to emulate a powerbutton press in vbox :)
[15:08] <ogra> tedg, but it wont affect ltsp at all, the session will never see the button event anyway
[15:08] <tedg> ogra: Not in vbox, but in virt manager if you press the "shutdown" button it behaves like hitting the power button.
[15:08] <tedg> ogra: Will GPM see the powerbutton?  It then calls the session manager.
[15:09] <ogra> no
[15:09] <cjwatson> BenC: I don't think so - why?
[15:09] <ogra> the client HW is totally separated from the session ...
[15:09] <tedg> ogra: Cool, then I'll assume it won't break LTSP :)
[15:09] <ogra> right :)
[15:09] <BenC> cjwatson: I've seen a report in lwn of the installer ignoring HPA when the kernel honors it (like it should) and it tries to use the whole disk when it should only use a partion
[15:10] <BenC> cjwatson: note in hardy and prior, we ignored HPA and caught a lot of static from upstream because of it (was not the default in the kernel)
[15:10] <tedg> ogra: Dave Richards presented at the GUI Hackfest.  They're doing a thin client implementation, not LTSP, but you might find some of the presentation interesting.  http://live.gnome.org/Boston2008/GUIHackfest/CityOfLargoPresentation
[15:10] <ogra> tedg, as long as gpm still hides suspend and hibernate on ltsp clients all will be fine ... btw, the gnome logout from the system menu wors fine
[15:11] <BenC> cjwatson: http://lwn.net/Articles/301862/  last paragraph
[15:12] <alex-weej> can someone tell me why developers keep removing the "regression" tags i add to bugs
[15:12] <alex-weej> and then adding "regression-potential"?
[15:12] <alex-weej> james_w: i'm looking at you now :P
[15:12] <james_w> tedg: hey, did you see my gpm patch?
[15:12] <cjwatson> BenC: I'll look at it after this call but it seems deeply implausible
[15:12] <james_w> alex-weej: because that's the documented tag to state that if we release with something it will be a regression.
[15:13] <alex-weej> where is it documented?
[15:13] <alex-weej> and what is "regression" for, in that case? after the "damage" is done?
[15:13] <ogra> tedg, that looks like he essentially just resembled ltsp, though he uses XDM and XDMCP which i wouldnt ever do
[15:13] <tedg> james_w: Not yet... but I'm still catching up on mail.  (I was in Boston until late last night)
[15:13] <ogra> (you can actively take screenshots from the network traffic under XDMCP)
[15:14] <james_w> tedg: no problem it's on the sponsors list, feel free to roll it up with any updates you are doing, but it's quite a serious bug for amd64 users
[15:14] <tedg> ogra: Yeah, one of the interesting things that he did was set up an entire server for Evolution.  That way he could keep it under support contract and run more modern stuff on his other machines :)
[15:15] <BenC> cjwatson: that's what I thought, since I suspect it would get its geometry from the kernel anyway
[15:15] <ogra> i wonder why he didnt just take ltsp and did his session modifications on that
[15:15] <BenC> cjwatson: if it's getting geometry directly from the drive and ignoring hpa, that would be odd
[15:15] <ogra> looks like a lokt of wasted manpower :)
[15:15] <ogra> ltsp would have given him 80% of that setup out of the box
[15:16] <cjwatson> BenC: I'd be amazed if libparted did that
[15:16] <ogra> the evo server is a cool idea though
[15:17] <cjwatson> BenC: it doesn't explicitly shrink the disk to accommodate HPA, but I'm not entirely sure how it reliably could
[15:17] <ogra> tedg, lol, and he has no answer for dbus either :) i guess i should contact him so we can work together on a dbus over TCP implementation ;)
[15:18] <BenC> cjwatson: if it relied on the kernel geometry, it wouldn't have to do anything special
[15:19] <tedg> ogra: Yeah, I think that he has a big Novell contract -- do they support LTSP?
[15:19] <BenC> cjwatson: the block devices would simply map to the non-hpa portion of the drive
[15:19] <cjwatson> BenC: it calls HDIO_GETGEO, I believe
[15:19] <ogra> tedg, nope, they have a proprietary solution they push instead, but there is a ltsp frok called kiwi-ltsp in opensuse
[15:19] <cjwatson> BenC: but if the partition layout is already outside the HPA then you can end up screwed; that's why the kernel ignored HPA
[15:19] <ogra> *fork
[15:19] <cjwatson> BenC: for reasons that were discussed with lkml at the time
[15:20] <BenC> cjwatson: well, for the first time we have hpa honored by default...would be a simple module-init-tools addition to change that
[15:20] <ogra> tedg, they have a closed system that sits on flashcards on the clients instead of using a diskless ltsp setup
[15:21] <tedg> ogra: Hmm, I wonder if that's what they're using.  He did mention they have flash in all the thin clients.
[15:21] <ogra> i guess so
[15:22] <ogra> its quite annoying to administer compared to ltsp where you only have one chroot for all clients to boot from ...
[15:22] <ogra> i.e. for security kernel updates you need to run around and update the flash
[15:22] <cjwatson> BenC: it's not the first time we've done that. We did it in a previous cycle and it was a last-minute panic to back it out again.
[15:22] <ogra> in ltsp thats one command
[15:22] <cjwatson> BenC: are you *sure* this is a good idea?
[15:22] <BenC> cjwatson: In the long run, it is the right thing to do
[15:23] <cjwatson> it totally breaks existing dikss
[15:23] <cjwatson> disks
[15:26] <BenC> cjwatson: I can add the ability to pass ata_ignore_hpa=1 to the kernel command line and upgrade-note that
[15:26] <nullie> Hello. Is it good to setup ppa and put debian source packages there?
[15:27] <BenC> cjwatson: the alternative is to keep creating bad partitions that cause this sort of problem to begin with
[15:27] <tkamppeter> pitti, I have answered your question in bug #271288
[15:27] <nullie> oh, well
[15:28] <ogra> tedg, ah, i just found you can send an acpi poweroff in vbox, tried that to confirm it does nothing
[15:29] <Riddell> ArneGoetje: how are the new language packs doing?
[15:30] <tedg> ogra: Great, thanks for looking into that.
[15:30] <ogra> tedg, btw, did i mention that the logout item from the system menu works just fine in ltsp  ?
[15:31] <ogra> probably fusa should just resemble that behavior
[15:31] <ogra> instead of calling gnoe-session-save or something in ltsp
[15:37] <cjwatson> BenC: I agree that we should try to avoid creating them, but doesn't that really involve installer work rather than just making bits of the disk invisible in the kernel?
[15:38] <cjwatson> BenC: if ata_ignore_hpa=0 is the default, I think we'll see machines just fail to boot on upgrade, unless update-manager basically just adds ata_ignore_hpa=1 to all upgrading systems (and in that case why not just make it the default?)
[15:38] <BenC> cjwatson: exposing the HPA to userspace can cause more problems (kylem had outlines some really bad ones awhile back)
[15:38] <cjwatson> BenC: I'd like to hear examples
[15:39] <cjwatson> I know Kyle was involved in arranging to ignore the HPA after mjg59 raised it as an issue a while back
[15:40] <cjwatson> has anything significant changed since feisty when we decided to ignore the HPA?
[15:42] <BenC> cjwatson: a lot of upstream pressure is the main reason
[15:42] <BenC> cjwatson: and the fact that HPA was actually designed to be ignored by the OS :)
[15:44] <cjwatson> BenC: I'd rather have a clear plan that actually addresses all the problems rather than just bow directly to upstream pressure
[15:44] <cjwatson> or rather, I'd prefer to bow to upstream pressure by means of a clear plan :)
[15:45] <BenC> cjwatson: upgrades defaulting to ata_ignore_hpa=1 sounds like the right plan
[15:45] <BenC> cjwatson: I can upload a new module-init-tools that adds that on upgrade, but not on new install
[15:46] <cjwatson> but even then new installs on systems where there's a previous install with partitions extending into the HPA will be screwed
[15:47] <cjwatson> I'm uncomfortable with us running different kernel options on a very wide swathe of systems (all upgrades) in general
[15:47] <BenC> then the only alternative is to keep ignoring it, and revisit this at UDS
[15:47] <cjwatson> BenC: we should probably talk about this on ubuntu-devel@
[15:48] <BenC> cjwatson: for intrepid, if we aren't comfortable with the upgrade path, then I suspect there's not much choice other than to revert to what we have been doing all along
[15:49] <BenC> at least it's consistent
[15:49] <cjwatson> mm, I would tend to agree
[15:49] <cjwatson> BenC: I won't be at UDS, but if it's possible I'd like to call into discussions on the subject, e.g. on getting the installer to behave differently going forward
[15:52] <BenC> cjwatson: Ok
[15:52] <cjwatson> seems like we could educate libparted a bit
[15:53] <stgraber> cjwatson: How can you not be at UDS ?
[15:54] <cjwatson> stgraber: we're expecting a baby just around that time; seems a bad time to be on the wrong continent :-)
[15:54] <stgraber> hmm, yes, that makes sense then :)
[15:54] <ArneGoetje> Riddell: building, I guess...
[15:56] <cr3> is there a process that checks that all dependencies are met before building an image?
[15:56] <Riddell> ArneGoetje: you guess?  they don't seem to be in launchpad e.g. https://edge.launchpad.net/ubuntu/intrepid/+source/language-pack-kde-fr/1:8.10+20081013
[15:57] <cjwatson> cr3: for alternate/server CDs, we check (and output report.html) but we don't block building the image on it
[15:57] <cjwatson> cr3: for desktop CDs, we install things with apt so it'll refuse if there are unmet dependencies, which will break the CD build
[15:58] <cjwatson> cr3: it's common enough for optional packages (e.g. language packs) to be uninstallable and we'd rather be able to proceed with testing in the absence of those
[15:58] <cr3> cjwatson: might you happen to know off hand if yesterday's daily had missing packages for smartpm-core and/or update-motd? I can't find them on the image and the installation fails with those unmet dependencies. I'm rsync'ing today's image, just to be sure.
[15:59] <mathiaz> cr3: they're on the -server cd
[15:59] <Riddell> james_w: is bug 267478 likely to be resolved before freeze in two days?
[16:00] <cr3> mathiaz: weird, something in my installation seems to depend on server stuff
[16:00] <cjwatson> cr3: look at report.html, published on cdimage
[16:00] <cjwatson> I don't know offhand, that's where I'd check
[16:00] <mathiaz> cr3: smartpm-core/update-motd: that would point to landscape-client
[16:01] <james_w> Riddell: not sure, I was going to act tomorrow. I'm hoping to get a reply from the author
[16:01] <james_w> Riddell: I'm leaning towards removing at the moment
[16:02] <Keybuk>  * Error: The server must be started under the locale en_GB.UTF-8 which does not exist any more.
[16:02] <Keybuk> cjwatson: any ideas?
[16:02] <Keybuk> my desktop seems to have reset to "C" as well
[16:03] <ArneGoetje> Riddell: 1:8.10+20081011
[16:03] <cr3> mathiaz: I wonder if the problem is that I'm taskselecting both ubuntu-standard and ubuntu-desktop, maybe I should just specify ubuntu-desktop although I thought one encompassed the other
[16:03] <cjwatson> Keybuk: locale -a - does it list en_GB.utf8?
[16:04] <cjwatson> (ignore the slightly different spelling)
[16:04] <Keybuk> cjwatson: no
[16:04] <Keybuk> C and POSIX only
[16:04] <cjwatson> Keybuk: do you have language-pack-en-base installed?
[16:04] <Keybuk> language-pack-en-base	1:8.10+20080920
[16:04] <mathiaz> cr3: which cd are you refering to?
[16:04] <cr3> mathiaz: alternate
[16:04] <Riddell> ArneGoetje: that's the one you said you were going to make yesterday?
[16:05] <tedg> Keybuk: Make sure to add some 'z's to your computer.  WIthout en_GB you'll probably run out otherwise.
[16:05] <Riddell> ArneGoetje: that doesn't contain kdelibs4.mo
[16:05] <cjwatson> Keybuk: meep, no idea. Try 'sudo /usr/share/locales/install-language-pack en ""'?
[16:05] <Keybuk> cjwatson: it's generating locales
[16:05] <cjwatson> cr3: (a) the task is called standard not ubuntu-standard (b) you don't need to select standard explicitly
[16:05] <Keybuk> cjwatson: locale -a lists en_OMGLOTS
[16:06] <ArneGoetje> Riddell: I can't influence that. I'm talking with jtv in the moment. Maybe we can get an intermediate update before Friday.
[16:06] <Riddell> ArneGoetje: we're freezing on thursday!
[16:06] <cjwatson> Keybuk: sorted. wonder why that happened
[16:06] <cjwatson> Riddell: language packs have historically gone later, though
[16:06] <cjwatson> although the sooner the better given the problems
[16:07] <cjwatson> Riddell: unfortunately the export takes a week :(
[16:08] <ArneGoetje> cjwatson: currently we seem to be down to 3 days. However, we will have a full export on Friday with the database contents from the same day. We are pulling plan B for that.
[16:09] <cjwatson> I see we're finally into October on imports
[16:09] <cjwatson> the number is still big but that must be almost entirely updates now
[16:10] <ArneGoetje> cjwatson: yes, hopefully
[16:10] <cjwatson> I've been compulsively reloading the queue ;-)
[16:22] <mvo> davmor2: could you check if the session plugin in loaded for you (via ccsm)
[16:23] <davmor2> mvo: that's the compiz advanced editor thing isn't it?
[16:23] <mvo> davmor2: yes
[16:23] <davmor2> np's
[16:23] <superm1> asac, could you take a look at bug 277302 sooner than the current milestone for it (ubuntu-8.10)?  It's got a fix attached, and is kinda preventing doing wubi testing with mythbuntu.
[16:28] <asac> superm1: hmm. did you do a merge request?
[16:28] <superm1> asac, ah no, I didn't realize I was supposed to
[16:29] <asac> superm1: did you investigate what is run in 28,29 ?
[16:30] <asac> superm1: you use an email for commits that isnt known to launchpad :)
[16:31] <superm1> asac, so on a fairly default install of mine (i've only "added" stuff rather than removing services etc), I don't see anything else at 28 or 29
[16:31] <davmor2> mvo: I got session management
[16:31] <asac> superm1: dont we need to bump the minimum version in the if on top of that?
[16:31] <asac> superm1: did you try if the "migration" works well?
[16:32] <superm1> asac, you mean from the previous runlevel to this one?
[16:32] <asac> yes
[16:32] <mvo> davmor2: cool, thanks
[16:32] <mvo> davmor2: I think I pinpointed it, now I "just" need to fix it :)
[16:32] <superm1> asac, No I haven't.  I wasn't positive what needed to be checked for this type of change, so I wanted to clear with you before anything else was done
[16:33] <asac> superm1: bump the version above to the proposed package version of this upload
[16:33] <asac> superm1: at best merge the latest first
[16:33] <superm1> asac, okay will do
[16:33] <superm1> asac, i'll re-propose it for merging after I can double check it migrates right then
[16:34] <asac> superm1: yeah. proposing for merge would be nice
[16:34] <asac> superm1: try to use the right email :)
[16:34] <asac> superm1: look: https://code.edge.launchpad.net/~superm1/network-manager/ubiquity-fix
[16:35] <superm1> asac, ah yeah, that computer I did on didn't have my bzr info set right.  i'll do it from my main one sand it will work correctly
[16:35] <superm1>  *sand=and
[16:35] <asac> ;)
[16:38] <asac> superm1: oh. it was the wrong branch you asked it to be merged in
[16:38] <asac> superm1: https://code.edge.launchpad.net/~network-manager/network-manager/ubuntu.0.7
[16:38] <superm1> asac, that's what the default had pulled up, what's the proper one then?
[16:38] <asac> thats the right target ;)
[16:38] <superm1> ah okay
[16:38] <superm1> thanks
[16:38] <asac> superm1: that was the upstream branch
[16:39] <superm1> ah
[16:47] <johanbr> evand: I thought I'd try usb-creator with a usb memory, just to see how it works. But it stalls at "102% complete".
[16:47] <Keybuk> clearly it did too much
[16:47] <evand> curious
[16:47] <BenC> cjwatson: module-init-tools with libata ignore_hpa=1 uploaded
[16:48] <Keybuk> BenC: is that a default option?  shouldn't that be a kernel aptch?
[16:48] <evand> johanbr: is there anything relevant in ~/.usb-creator.log
[16:49] <BenC> Keybuk: we have modprobe.d and module options so we don't have to patch the kernel
[16:49] <Keybuk> no we don't
[16:49] <Keybuk> modprobe options are error-prone
[16:49] <Keybuk> they are difficult to apply
[16:49] <Keybuk> a huge number of situations exist in which they could fail to be applied
[16:49] <BenC> Keybuk: then why does /etc/modprobe.d/options even exist?
[16:49] <Keybuk> they are difficult to override
[16:49] <johanbr> evand: actually, it just finished :)
[16:49] <Keybuk> since they are conffiles
[16:49] <johanbr> evand: but I did get "GtkWarning: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed"
[16:49] <Keybuk> and they are *expensive*
[16:50] <Keybuk> BenC: I have been steadily attempting to get rid of it
[16:50] <Keybuk> I had got down to two drivers that needed patching
[16:50] <BenC> Keybuk: I'm not patching the kernel unless you can provide me a solid reason
[16:50] <Keybuk> BenC: because if the kernel default is wrong, the right thing to do is change the kernel default!
[16:50] <BenC> Keybuk: it's not wrong...OUR default is wrong
[16:50] <Keybuk> so we change OUR kernel ;)
[16:51] <BenC> Keybuk: I'd rather our changes to the kernel default options be more visible
[16:51] <Keybuk> I'd rather they be more reliable and cheaper
[16:51] <BenC> changing them in source obfuscates them
[16:51] <Keybuk> hardly
[16:51] <Keybuk> changing them *outside* of course obfuscates them
[16:51] <Keybuk> quest scott% modinfo ipw2200 | grep associate
[16:51] <Keybuk> parm:           associate:auto associate when scanning (default on) (int)
[16:51] <Keybuk> "default on"
[16:52] <BenC> Keybuk: uh, I can grep /etc/modprobe.d/ but if I change the source, there's no way to know unless you check the source code
[16:52] <Keybuk> except if I modprobe "ipw2200" that will be *OFF*
[16:52] <Keybuk> and I have to hunt around the filesystem, to find a strange file that has it set otherwise
[16:52] <Keybuk> *AND*
[16:52] <cjwatson> most options aren't set in /etc/modprobe.d/ at all so the natural place to look is in the source code
[16:52] <Keybuk> if I change that file, and reboot
[16:52] <Keybuk> the default doesn't *GET CHANGED*
[16:52] <evand> johanbr: hrm, do let me know if the resulting image is broken in any way (persistence support will land you in a busybox shell at the moment)
[16:52] <Keybuk> because I forgot to run update-initramfs, or something
[16:52] <BenC> I prefer they be in userspace rather than changes to the kernel source
[16:53] <Keybuk> I prefer kernel defaults be set in kernel source
[16:53] <BenC> The point being that upstream set defaults, and we are changing them using prefered methods
[16:53] <Keybuk> no, it is not the preferred method
[16:53] <BenC> the same methods that users would use
[16:53] <Keybuk> the preferred method is to change the kernel source
[16:53] <Keybuk> exactly
[16:53] <Keybuk> we should not set defaults in the same way that users would use
[16:53] <Keybuk> because it makes it difficult for the user to override that to their value
[16:54] <BenC> Keybuk: if modprobe.d has shortcomings, then users will experience them too...isn't that a bug?
[16:54] <Keybuk> BenC: no
[16:54] <Keybuk> it's a bug that modprobe options are even needed
[16:54] <Keybuk> and it's slowly being deprecated
[16:54] <BenC> Keybuk: vi /etc/modprobe.d/options; sudo update-initramfs -u
[16:54] <Keybuk> at some point in the very near future, we won't *have* a modprobe.d
[16:54] <Keybuk> just like Fedora doesn't already
[16:54] <johanbr> evand: Sure. Is it possible to recover from that, or is persistence just broken atm?
[16:55] <Keybuk> they have a much better way of doing it by taking module options from the kernel command-line
[16:55] <BenC> Keybuk: If I change the source, some users may want to change this default, and they will have to do the same thing that they would do if I change the source instead of a modprobe.d file
[16:55] <Keybuk> so it doesn't matter whether the driver is a module or built-in
[16:55] <Keybuk> the same parameter still gets applied
[16:55] <Keybuk> in fact
[16:55] <Keybuk> that's YET ANOTHER argument for changing the source
[16:55] <BenC> Keybuk: you can't take module options from the kernel command line
[16:55] <Keybuk> if we rely on modprobe options, we utterly break things for users that compile drivers in
[16:55] <BenC> we've had to hardcode that functionality for a few special cases
[16:56] <Keybuk> since modprobe doesn't apply options to built-in drivers
[16:56] <Keybuk> BenC: err, explain "can't" ?
[16:56] <Keybuk> they parse /proc/cmdline
[16:56] <BenC> if users compile their own kernel, they are on their own
[16:56] <Keybuk> they should not be
[16:56] <BenC> Keybuk: Not all of them
[16:56] <BenC> Keybuk: only ones I know is video fb drivers
[16:56] <Keybuk> compiling drivers into the kernel has real performance benefits
[16:56] <Keybuk> it is something we should support
[16:57] <Keybuk> and indeed, is something I'm recommending we *do* by default ourselves
[16:57] <BenC> Keybuk: either way, I'm not hitting source for this one
[16:57] <Keybuk> there are about 10 reasons why you should patch the kernel to fix the defaults
[16:57] <Keybuk> and the only reason you've given for not doing it is "because you don't want to"
[16:57] <BenC> Keybuk: you haven't given me a _good_ reason
[16:57] <Keybuk> what breaks by patching the kernel to fix the kernel default?
[16:58] <BenC> Keybuk: maintaining, merging, rebasing...
[16:58] <evand> johanbr: at the CD boot menu, hit F6 and remove peristence from the kernel command line arguments.  This will disable persistence support, but as mentioned, it's broken.
[16:58] <Keybuk> BenC: I've given you a pile of things that *break*
[16:58] <Keybuk> BenC: surely git makes all that easier?
[16:58] <Keybuk> it's a one line patch, after all
[16:58] <BenC> Keybuk: yeah, if users compile their own kernel
[16:58] <Keybuk> modprobe options are expensive to parse and apply
[16:58] <Keybuk> modprobe options fail to be applied if:
[16:58] <Keybuk> - module loaded in initramfs
[16:58] <Keybuk> - module loaded by insmod
[16:58] <Keybuk> - driver compiled into kernel
[16:58] <BenC> modprobe options work in initramfs, so that's bull
[16:59] <Keybuk> modprobe options involve modifying a conffile, and getting a conffile prompt every upgrade
[16:59] <BenC> insmod isn't used directly, and if it is, by a part of our system, that's broken
[16:59] <BenC> if a user compiles their own kernel, they take on responsibility
[16:59] <Keybuk> BenC: only if you put it in a file that happens to be copied (upgrade pain) and don't remember to run update-initramfs
[16:59] <Keybuk> you're advocating giving users the merging pain
[16:59] <Keybuk> which is bullshit, sorry
[16:59] <BenC> Keybuk: all of /etc/modprobe.d/ is in initramfs
[16:59] <Keybuk> BenC: WRONG
[17:00] <BenC> Then that's fairly broken
[17:00] <Keybuk> in fact
[17:00] <Keybuk> I can't even find the code that copies any of it in anymore :)
[17:00] <Keybuk> oh, yes I can
[17:01] <Keybuk> we copy in various bits of it
[17:01] <Keybuk> but other bits get left out
[17:01] <Keybuk> I'm planning to actively get rid of modprobe.d entirely
[17:01] <BenC> Keybuk: uh, on my system all of /etc/modprobe.d is in initramfs
[17:02] <BenC> Keybuk: Ok, when you get rid of it later, I'll revisit this, but for now, two weeks before release, I'm relying on modprobe.d, since it works, is what we used before, and your corner cases don't seem to be valid for 99.9% of people
[17:03] <johanbr> evand: Alright, thanks. I'll give that a try.
[17:03] <Keybuk> "patch" works even better
[17:03] <Keybuk> I'm told git works too
[17:03] <BenC> Keybuk: patch doesn't work if people compile their own kernel from vanilla sources
[17:03] <BenC> which falls into your same argument
[17:04] <Keybuk> there's a great mailing list you can send patches to
[17:04] <Keybuk> it's called something like "lkml"
[17:04] <BenC> Keybuk: it's called they want the default at =0, and we are forcing it to =1
[17:04] <BenC> they wont change it
[17:04] <Keybuk> where do they want the default at 0?
[17:04] <BenC> Keybuk: ignore_hpa= for libata
[17:04] <Keybuk> I can't see any mails from you to that list in the last several weeks?
[17:04] <Keybuk> you don't seem to have actually asked?
[17:05] <BenC> Keybuk: you seem to be assuming a lot
[17:05] <BenC> Keybuk: this was discussed over a year ago
[17:06] <BenC> Keybuk: OS's are supposed to honor the host-protected-area, we are broken for not doing so by default
[17:06] <BenC> Keybuk: but we must because the upgrade path from previous releases is too complex to worry about right now
[17:06] <Keybuk> fair enough
[17:06] <Keybuk> if we're going to be broken, we should ship with broken defaults
[17:07] <psyke83> asac: I got around to testing nspluginwrapper 1.1.2, and it seems to work well. Should I file a FFe or are you already working on an update?
[17:07] <Keybuk> modinfo libata should show that ignore_hpa's default is 1
[17:07] <Keybuk> since this is us being broken, I assume it's something we plan to fix at some point - so your argument about carrying a burdensome 1 line patch doesn't apply?
[17:09] <Keybuk> in fact, looking at it
[17:10] <Keybuk> most drivers set all their option variables in one block
[17:10] <Keybuk> so the only time one of these option default patches would fail to merge is if the options to the module have changed
[17:10] <Keybuk> or even the defaults
[17:10] <Keybuk> and arguably, those are times we _really_ want to know about it
[17:17] <munckfish> calc: have you guys got a sec to discuss bug 273268. I'm really concerned to do something about this cause it's a big show stopper for the ports.
[17:17] <munckfish> calc: If there's a lot on your plate let me know and I'll try to do as much of the foot work as possible
[17:18]  * munckfish knows that calc is a single person, not many, and should have re-read his text before pressing <return>
[17:23] <asac> psyke83: please use the bzr branches
[17:28] <cjwatson> Riddell,ArneGoetje: is bug 281779 fixed by the langpack-o-matic changes you've been working on?
[17:28] <cjwatson> (nobody is assigned and there's no in-progress indicator or anything)
[17:31] <ArneGoetje> cjwatson: yes, Jonathan updated the files in langpack-o-matic. the current langpacks should have the files at their correct location.
[17:35] <slangasek> mdke: ok
[17:36] <slangasek> pitti: did you see kees' comment about bug #230877?  Requires an updated SRU for dbus, which was one of yours
[17:37] <munckfish> cjwatson: if I were to need to do a test build of OpenOffice.org on powerpc do you still have that machine in your office that could be used for that?
[17:38] <munckfish> I think it would takes days on my PS3
[17:38] <kees> slangasek: I'll make a note on the bug as soon as dbus publishes (should be on the next publisher run)
[17:39] <mathiaz> slangasek: could you have a look at bug 277658?
[17:44] <slangasek> mathiaz: will do so today, yes
[17:56] <calc> munckfish: yes i have the fix for this presumably, need to build it later today, currently i am trying to make 3.0 build for some reason it decides to start OOo in the middle of the build and hangs :-(
[17:57] <cjwatson> munckfish: not easily :-(
[17:57] <cjwatson> munckfish: oh, you mean in the Canonical DC?
[17:57] <munckfish> calc: cool, did you see my last comment on that bug - I'm a bit worried OO won't be compatible with OpenJDK what's your opinion on that?
[17:57] <cjwatson> munckfish: yes, though calc can too
[17:58] <munckfish> cjwatson: ok np, just wondered in case it would allow me to test a fix without bothering calc
[17:58] <Mithrandir> munckfish: if you have .debs I can test build, I can do a test build for you.
[17:58] <munckfish> if he couldn't make time for it
[17:58] <calc> munckfish: looking back at it now
[17:58] <munckfish> Mithrandir: it would be from deb source
[17:59] <calc> munckfish: wrt ppc that isn't an issue as ppc doesn't work with gcj either
[17:59] <munckfish> Mithrandir: thx for the offer
[17:59] <Mithrandir> munckfish: obviously, I meant "source packages".
[17:59] <calc> munckfish: so if it doesn't build with the change for cacao it just needs to be disabled overall
[17:59] <munckfish> calc: ok, so is it a better idea to switch off Java? Less risky?
[17:59] <munckfish> Mithrandir: sorry yes of course
[18:00] <Mithrandir> munckfish: anyway, is it just the current source packages in intrepid or some other packages?
[18:00] <munckfish> calc: well build/run/install worries me based on that debian bug
[18:00] <calc> munckfish: well i will upload with the patch if it still fails i will turn off java for ppc/sparc if that happens
[18:01] <calc> munckfish: hmm maybe it would be best to just disable java entirely for ppc if it is making a problem even for install
[18:01] <munckfish> Mithrandir: it would be current with a patch but I think calc is going to be able to test it this time around
[18:01] <Mithrandir> munckfish: ok.  Tell me if you need anything.
[18:02] <munckfish> calc: My concerns are - your time so close to the end of the cycle, and the fact that powerpc is low priority. Would your schedule allow us to build with Java, test and then upload again with java disabled if need be, all before Interpid goes live?
[18:03] <calc> munckfish: should be able to yes
[18:03] <munckfish> calc: excellent
[18:03] <cjwatson> I strongly recommend just ripping it out if it's in doubt
[18:03] <munckfish> lets go for it then
[18:03] <calc> munckfish: but if ppc needs working java to even install then we probably should just disable it
[18:03] <cjwatson> we know it's been a problem in the past, it's low-priority - why mess around?
[18:03] <munckfish> cjwatson: that would be fine too
[18:03] <cjwatson> and we don't have much time
[18:03] <munckfish> Being able to install from CD is my biggest concern
[18:04] <calc> munckfish: because i'm fairly sure that the cacao java is broken as you mentioned i found the debian bug report about that a while back
[18:04] <munckfish> and currently this stops that altogether
[18:04] <calc> i'll disable java on ppc and use the patch to see if sparc starts working again
[18:04] <munckfish> calc, cjwatson: lets just disable Java then. I can mess around with it in jaunty
[18:04] <calc> sparc usually fails to build due to gcc ICE though so i'm not too sure it will work regardless
[18:05] <munckfish> calc: fantastic!
[18:05] <calc> and i will try to get that uploaded today as soon as I can get 3.0 built properly and uploaded and get my taxes done :\
[18:05] <calc> they have to be mailed by tomorrow, yuck
[18:06] <calc> i can probably do them while the build is running, lol
[18:07] <munckfish> calc: great thx for looking at this :)
[18:08]  * calc is trying older ooo-build checkout hoping it will fix this stupid ftbfs for 3.0.0
[18:11] <nullie> Look. Is it ok to put unmodified debian packages to ppa, if they aren't available in ubuntu?
[18:12] <jdong> you can put anything you want into a PPA as long as it doesn't violate its license.
[18:13] <nullie> well, FAQ says: "We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian"
[18:13] <jdong> well uploading to a PPA will almost certainly require modification of at least the changelog
[18:14] <persia> jdong, Why?  Couldn't one just run genchanges?
[18:14] <cjwatson> you shouldn't
[18:14] <persia> True.
[18:14] <jdong> I've used PPAs for testing backports with just changelog changes before and they worked. whether or not it's a good idea to be doing it extensively is another story
[18:15] <nullie> is there place I can ask, why certain packages not getting included in ubuntu?
[18:15] <jdong> you can probably ask here or #ubuntu-motu
[18:18] <calc> nullie: if it was uploaded to debian after june 26 it would have to have been manually added to Ubuntu (aiui)
[18:19] <nullie> why?
[18:20] <calc> nullie: see https://wiki.ubuntu.com/IntrepidReleaseSchedule
[18:20] <nullie> oh, that
[18:21] <calc> nullie: "DebianImportFreeze"
[18:21] <nullie> thanks
[18:21] <calc> nullie: things can be updated after that but it isn't automatic after that (at least aiui)
[18:21] <cjwatson> correct
[18:28] <nullie> but I guess new packages for beta are not welcome?
[18:31] <ion_> Ooh, the new background image is nice.
[18:37] <cjwatson> nullie: probably not a great idea at this point unless it's critical for Ubuntu as a whole for some reason
[19:01]  * ogra thinks X strike force uses quilt because they want to make sure *you really really want that fix in* ... for trivial fixes i wouldnt go through the pain to use quilt 
[19:03] <pitti> slangasek: dbus SRU> will do
[19:03] <ogra> lool, we could ask jcristau or bryce or tjaalton
[19:04] <lool> ogra: yeah, I had that in mind as well :)
[19:05] <lool> jcristau, bryce_, or tjaalton: the psb driver isn't available in combination with a recent kernel anywhere; we saw that xorg-server has a pci id hinting to use psb
[19:05] <lool> But as psb isn't working, I dropped it from video-all and would like to remove autodetection for it
[19:05] <lool> While still enabling autodetection when support lands, perhaps in some external repos later
[19:06] <bryce_> lool: okay I'd be fine with that
[19:06] <lool> I thought the xorg drivers had external pci ids for this purpose: if the driver is installed, it selects itself, otherwise it doesn't
[19:06] <lool> So is it ok if we make sure this pci id is in psb.ids and drop the xorg-server pci id?
[19:06] <bryce_> yes
[19:06] <lool> thanks!
[19:06] <bryce_> or should it be directed to -vesa?
[19:06] <ogra> looking at debian/patches/142_psb_auto.patch it seems just adding driverList[1] = "vesa"; to the psb line might help
[19:06] <lool> bryce_: it should be directed at vesa
[19:07] <ogra> in xorg-server-1.5.1
[19:07]  * bryce_ nods
[19:07] <ogra> s/to/below/
[19:07] <lool> Now I just need to locate the tree for -psb
[19:07] <ogra> what we both didnt get where the *.ids files come into play here
[19:07] <bryce_> also unless someone has fixed it, the -psb we ship in the regular intrepid archive != what we ship for moblin
[19:07] <lool> to check whether it lists the ids in xorg-server already
[19:07] <slangasek> pitti: do you have some time to look at bug #267875 (the hal part)?
[19:07] <lool> bryce_: You mean ubuntu-mobile ppa versus intrepid?
[19:08] <bryce_> lool, right
[19:08] <persia> bryce_, They should be the same : there's no intrepid at archive.mobile.ubuntu.com
[19:08] <lool> bryce_: i'm not sure we fixed that either, simply because we didn't want to carry over the drm hack in intrepid
[19:08] <lool> persia: So we merged everything in intrepid?
[19:09] <bryce_> persia: nope, the version in intrepid is 0.2.1-* which is an antique
[19:09] <lool> Yeah
[19:09] <bryce_> the correct version is 0.15.* and was last updated for hardy
[19:09] <persia> lool, No, but the current -mobile and -mid images are from the standard repos (and will remain that way)
[19:09] <bryce_> iirc it's not changed during intrepid
[19:09] <ogra> lool, http://paste.ubuntu.com/57531/
[19:09] <lool> It doesn't matter too much to update it I think, because of the drm requirements, bu
[19:10] <ogra> thats the updated patch
[19:10] <persia> bryce_, Even 0.15 doesn't compile in intrepid.
[19:10] <lool> persia: That's fine
[19:10] <persia> RIght.  Just a note.
[19:10] <lool> persia: Exactly bryce's points
[19:10] <lool> 0.15 is the latest version, doesn't compile on intrepid, so intrepid as an older version
[19:10] <bryce_> anyway, just want to make sure no one gets confused by that 0.2.1 version... it's so old it might as well just be purged
[19:10] <lool> we don't want the latest version
[19:11] <lool> Do we care about some changes in the ubuntu-mobile ppa?  perhaps, but we will get a new upstream drop in a distant future and then we'll advise where to do what and whether there's anything to carry over
[19:11] <lool> But trying to merge our 0.15 changes in intrepid doesn't make sense IMO
[19:11] <lool> bryce_: Actually purging is perhaps the best option
[19:13] <ogra> bryce_, does http://paste.ubuntu.com/57531/ look sane to you (line 28 was added)
[19:15] <bryce_> ogra: mmm, won't the break; on line 27 prevent line 28 from executing?
[19:15] <persia> ogra, Shouldn't that be driverList[0] = "psb";  driverList[1] = "vesa"; break; ?
[19:15] <ogra> bryce_, whoops, indeed
[19:16] <ogra> http://paste.ubuntu.com/57534/
[19:16] <ogra> :)
[19:16] <bryce_> ah yes that looks better
[19:16] <persia> tab/space confusion aside.
[19:16] <bryce_> make sure to test the fallback to make sure it gets to vesa correctly
[19:16] <bryce_> if not, we can comment out line 27 until psb is available.
[19:17]  * persia hopes the fallback works in case someone does for -psb what is already done for -nouveau in a PPA
[19:18] <bryce_> I think if a psb.so is present but broken, this code may select that, and fail to fallback properly.  I'm not certain though because we've been doing some improvements that may make this work as expected.
[19:19] <ogra> bryce_, well, the idea was to have the code in a way that we probably can provide a backported psb or PPA psb package laer
[19:19] <persia> As -psb isn't installed by default, that's an unlikely case.  If someone installs it, presumably the error in the log will help encourage them to uninstall it.
[19:19] <ogra> without having to upload xorg-server
[19:19] <ogra> psb isnt in -all so it shouldnt be installed by default
[19:20] <bryce_> alright, sounds like it should be safe then
[19:20] <bryce_> still, definitely worth testing on a couple systems once its uploaded
[19:21] <ogra> lool and persia have such systems
[19:21] <persia> It will certainly be tested on the Jax10 and D4.  I don't know what other -psb HW people have.
[19:21] <ogra> and i should too, though not really mobile :)
[19:22] <persia> If you've different HW, that'd be great.  The more the better.
[19:24] <lool> I have the CB
[19:24] <ogra> me too
[19:25] <persia> OK.  That's three devices.  Anyone have an SC3, or something else with that video card?
[19:25] <lool> the dell mini also has psbN
[19:25] <lool> *psb?
[19:25] <ogra> i could get one if i ever answered steves offer :)
[19:26] <ogra> i think he still has that thing laying around if i want it
[19:27] <superm1> lool, the mini inspiron 910 doesn't have psb.  it has regular ol open source intel 945 graphics?
[19:27] <ogra> well chosen :)
[19:28] <lool> superm1: oh ok
[19:28] <lool> (didn't known hence the "?")
[19:29] <pitti> superm1: btw, is there still a pending regression for wl in hardy-proposed kernel now?
[19:29] <tjaalton> bryce_: the fallback doesn't work if there's a configfile present
[19:29] <superm1> pitti, that's on my TODO today to double check.  i think the last one is fixed now
[19:29] <superm1> pitti, I was out of the office yesterday so I didn't get a chance to look then
[19:30] <pitti> superm1: no problem, just checking
[19:30] <bryce_> tjaalton: ah thanks, I was just looking to see if that's the case when no driver is listed in the xorg.conf?
[19:30] <ogra> bryce_, tjaalton, what i dont understand is why we have the .ids files if everything is hardcoded anyway in xf86AutoConfig.c ... what do they do ?
[19:30] <bryce_> lool: I forget, is the UME xorg.conf we ship still listing "psb" as the video driver?
[19:31] <ogra> i dont think we ship any xorg.conf
[19:31] <lool> We don't do this anymore
[19:31] <tjaalton> ogra: the .ids are used if found
[19:31] <ogra> tjaalton, so the hardcoding is overridden ?
[19:32] <tjaalton> ogra: well, kind of. if no match from .ids is found, it'll use what's in driverList[0]
[19:32] <ogra> ah, cool
[19:32]  * ogra learned a bit again :)
[19:33] <ogra> thanks ! :)
[19:33] <tjaalton> not really, that's why there's the bug about -nv failing to load when the driver doesn't really support the device
[19:33] <bryce_> ogra: I think the xf86AutoConfig.c code is semi-legacy; that's the old way pci id's were mapped to drivers.  The new way places this logic into the drivers themselves.
[19:34] <ogra> yeah, thats what i though
[19:34] <ogra> and thats why i was surprised to see all the ids in xf86AutoConfig.c
[19:34] <tjaalton> bryce_: well, the _latest_ code tries to load the correct driver which should handle it, but if that fails it'll use the fallback. too bad that it doesn't work unless there's no xorg.conf
[19:34] <ogra> but if .ids files override that makes sense
[19:35] <bryce_> tjaalton: do you have more info on why it doesn't work when there's an xorg.conf?  are there plans in place to address that?
[19:35] <tjaalton> ogra: only if there's a match. it doesn't stop there :)
[19:35] <ogra> indeed, understood
[19:37] <tjaalton> bryce_: pretty simple.. it builds an internal conffile if there isn't one. that'll include all the sections for fallback drivers
[19:38] <lool> Ok; will look at uploading xorg-server after dinner
[19:38] <tjaalton> hw/xfree86/common/xf86Init.c
[19:38] <tjaalton>       case CONFIG_NOFILE:
[19:38] <tjaalton>         autoconfig = TRUE;
[19:38] <bryce_> ok so presumably the code that parses the xorg.conf needs to include logic that if no driver is specified, it should use the routines from the internal conffile handling algorithm to determine the driver, rather than what its using currently
[19:38] <lool> unless the nice xorg folks beat me to it
[19:39] <bryce_> tjaalton: do you know if anyone upstream is working to fix that?  If not we could put it on our todo list for jaunty
[19:40] <tjaalton> bryce_: alanc wrote the support for fallback drivers, but I'm not sure if he's working on improving it
[19:40] <jcristau> i don't think anyone's working on it right now. it's somewhere on my todo list, but..
[19:40] <nxvl> pitti: are you waiting for an sru on dbus or it will hit the archive today?
[19:41] <pitti> nxvl: do you mean my re-applied SRU patch? I already uploaded and accepted it
[19:41] <nxvl> ubuntu3.2
[19:41] <nxvl> pitti: so it will hit the archive any minute from now on?
[19:41] <tjaalton> what I had in mind was to just use vesa/fbdev if there's no match from the .ids files. not worthy upstream, but should fix the problem with -nv
[19:42] <pitti> nxvl: rather like 1.5 hours, when the binaries are built and the next publisher is finished
[19:43] <nxvl> awesome, thnx
[19:50] <nullie> humm, how I should decide, to which repo add package?
[19:51] <rainct> nullie: what do you mean by "which repo"?
[19:51] <nullie> main, universe or multiverse
[19:52] <pitti> ("component", BTW)
[19:52] <nullie> "Set the bug title to: Please merge <sourcepackagename><debian-version> (repository) from Debian <repository> (<component>)"
[19:52] <nullie> For instance: Please merge zoph 0.7.0.2-2 (universe) from Debian unstable (main)
[19:52] <ogra> nullie, you can only add it to universe (or multiverse if it has a nonfree license)
[19:53] <rainct> nullie: as ogra says, there's no choice, it just goes into universe or multiverse (depending on the license, not on you)
[19:53] <pitti> nullie: zoph is already in universe ("rmadison zoph" or "apt-cache show")
[19:53] <nullie> well, that was example from wiki
[19:53] <nullie> I want to add python-rope
[19:53] <rainct> nullie: you can fill a MIR (Main Inclusion Report) once it's in universe and has been tested, etc., given that there's a good reason to have it there
[19:54] <pitti> nullie: oh, for a package which is not in Ubuntu yet? that's not a merge then (which is merging the chagnes in debian and ubuntu), but a "sync"
[19:54] <nullie> humm
[19:54] <pitti> nullie: for those you don't need to worry, the archive admins will decide the component
[19:56] <nullie> ok
[19:56] <NCommander> persia, ping
[19:56] <lool> bryce_: heh I think I found how nxvl was able to get the antique psb with current intrepid xorg
[19:57] <lool> bryce_: the provide is in place, but not 'include debian/xsfbs/xsfbs.mk'
[19:57] <nullie> backport requests should be filed too?
[19:57] <lool> bryce_: I think I'll add an explicit conflict with psb to xorg-server and request removal of -psb from archive at this point
[20:00] <james_w> NCommander: hey, are you able to look at nufw? My blind attempt failed to fix it apparently.
[20:00] <NCommander> james_w, I just pined you in -motu about it ;-)
[20:00] <NCommander> james_w, I apperiate you looking at that task since I went AWOL recently this weekend
[20:01] <james_w> NCommander: no problem, I thought I had it, but an upload was my testbuild unfortunately.
[20:02] <NCommander> yeah
[20:02] <NCommander> You should see the changelogs on some of the KDE port bugs
[20:02] <NCommander> "Fix for PPC"
[20:02] <NCommander> "Fix for PPC"
[20:02] <NCommander> "Fix for **** PPC"
[20:02] <james_w> :-)
[20:02] <NCommander> james_w, you inlined your changes?
[20:03] <lool> Riddell: Hey, could you please lp-remove-package.py -u $SUDO_USER -m "Requested by Loïc Minier <loic.minier@ubuntu.com>; obsolete and broken" xserver-xorg-video-psb
[20:03] <james_w> NCommander: yeah, there's no patch system
[20:03] <bryce_> lool, sounds good
[20:03] <lool> Riddell: or would you prefer a bug report?
[20:03]  * NCommander normally adds one in these cases
[20:03] <NCommander> and my pants are singing
[20:04] <infinity> NCommander: Adding patch systems to packages to apply a single path is a much larger delta to maintain than just fixing the bug.
[20:04] <NCommander> Not really
[20:04] <infinity> NCommander: (Assuming we're talking about a package Ubuntu inherited and continues to sync/merge from Debian)
[20:04] <NCommander> If I have to have multiple patches
[20:05] <NCommander> A patch system is perferred
[20:05] <NCommander> And inlining ins pure evil when something breaks
[20:05] <NCommander> james_w, we really need porting boxs
[20:06] <james_w> NCommander: I can get access to one if you don't have time to fix it
[20:06] <NCommander> I'm building it now on my PPC
[20:06] <james_w> and I don't think a one-line inline change is "pure-evil"
[20:07] <lool> hmm wont watch Riddell today
[20:07] <lool> I'll drop an email to StevenK for the removal
[20:07] <lool> or rather, file a bug and mail StevenK
[20:08] <infinity> lool: I can do it.
[20:10] <infinity> lool: Done.
[20:10] <lool> infinity: would be pleased if you do
[20:10] <lool> infinity: thanks!
[20:11] <lool> infinity: I'm afraid I forgot about US holiday yesterday, did you see my poke about Xvfb?
[20:11] <lool> infinity: It looks like pygtk is failing to build on buildds with a real chroot (rather than xenish stuff)
[20:11] <lool> infinity: The error message from xvfb-run -e is completely useless, so it's be nice if you could see what went wrong
[20:12] <superm1> pitti, yeah I can confirm it works properly now.
[20:12] <superm1> pitti, do you have a particular bug you'd like that on?
[20:12] <lool> infinity: see e.g. https://edge.launchpad.net/ubuntu/+source/pygtk/2.13.0-0ubuntu7/+build/738828 or https://edge.launchpad.net/ubuntu/+source/pygtk/2.13.0-0ubuntu7/+build/738827
[20:13] <pitti> superm1: not really, maybe the one you last commented on, where you said it was broken?
[20:13] <superm1> pitti, ah yeah okay.
[20:13] <infinity> lool: Canadian holiday yesterday actually.
[20:14] <pitti> superm1: also, on bug 263097 you said "not yet", so another "yes, it fully works now" would be appreciated for SRU purposes
[20:14] <infinity> lool: And yeah, I can poke it in a sec.  Xvfb needs massaging several times per release, it seems.  I wish we had a better way to run these testsuites. :/
[20:14] <lool> infinity: We actually discussed this with jcristau
[20:15] <lool> infinity: Everybody hates xvfb-run, and we need to make the whole thing much more robust
[20:15] <lool> it's hard to get build-deps right, and they change with Xvfb features, it's very hard to launch xvfb-run in an useful way for testsuites, and even harder to get output
[20:15] <ogra> just run real X servers :)
[20:15] <lool> error output
[20:16] <infinity> Same problem.
[20:16] <infinity> xvfb's inheriting its moving-target CLI switches and other issues from X itself.
[20:16] <infinity> (Plus the part where people use xvfb to avoid asploding machines that just plain can't run a real X server, but that's beside the point)
[20:17] <lool> Well perhaps we should run xvfb-run in the xvfb's package testsuite muahahaha
[20:17] <lool> hmm sorry
[20:17] <infinity> lool: I wouldn't be against that.
[20:17] <infinity> lool: If we have a known target for expected CLI switches it should accept, and expected output from some basic scripts thrown at it, then we can stop blowing up every OTHER package's testsuite at the source.
[20:17] <infinity> lool: I don't actually see a problem with that.
[20:18] <lool> i'm adding that to the long list of things to fix in xvfb then!
[20:30] <infinity> lool: Ugh, it only failed on big-endian architectures?  I don't like the looks of that.
[20:30] <lool> infinity: There was a new snapshot taken recently
[20:31] <infinity> Well, good thing my house is filled with BE arches.  Doing some local testing to see if we can get more verbosity...
[20:33] <lool> thanks
[20:33] <lool> infinity: There's also the option of git bisecting the regression
[20:33] <infinity> lool: I'll leave that back in your hands once I give you a failure to look for.
[20:34] <lool> Sure
[20:34] <infinity> lool: "LOL, DOESN'T START, SUX2BU!!!111" isn't a great failure mode.
[20:34] <lool> I might bounce it on tjaalton    O:-)
[20:36] <slangasek> I read that and wondered if infinity was starting a new distro flavor called "sux2buntu"
[20:36]  * infinity coughs.
[20:37] <infinity> slangasek: Yeah, it's just like regular Ubuntu, except the entire system runs in xvfb, on top of qemu.
[20:37] <lool> Not very useful when HOME isn't writable
[20:39] <cjwatson> infinity: wishlist bug report: please implement sux2buntu from vnc in a browser window
[20:40] <ogra> with virtual input devices ?
[20:41] <infinity> cjwatson: Should I introduce artificial intercontinental latency, even when running on a local network?
[20:42] <slangasek> no, you should introduce /real/ intercontinental latency, even when running on a local network ;)
[20:43] <infinity> slangasek: Ahh, so the mouse emulation should be hosted in the DC.  Check.
[20:43] <slangasek> using geoip to helpfully locate the server farthest from you
[20:43] <cjwatson> virtual input devices> you can do wonderful things with mouseemu
[20:43] <infinity> slangasek: I'm sure I can get buy-in from elmo for that!
[20:43] <cjwatson> err, uinput
[20:43] <cjwatson> redirect all keyboard events via your antipodes
[20:43] <Mithrandir> or just use userspace device drivers and advanced sleep(3) technology.
[20:44] <infinity> We're getting dangerously close to speccing yet another way to stab people in the face over the internet.
[20:44] <cjwatson> you could use the whole thing as a test of the comment in linux/net/ipv4/tcp_timer.c:tcp_retransmit_timer
[20:44] <cjwatson> infinity: no, you've got it all wrong. This is a way to stab YOURSELF in the face over the Internet.
[20:45] <slangasek> the great thing about stabbing people in the face over the internet is that there are so many specs to choose from
[21:00] <slangasek> ArneGoetje: I understand Riddell is still in a holding pattern for proper KDE langpacks; is that being worked on?
[21:03] <cjwatson> hmm, 39 undecided-priority bugs targeted for intrepid
[21:04] <cjwatson> Riddell: the kde-i18n-es task on bug 259180 should be rejected, shouldn't it? we don't need both it and the kde-l10n-es task
[21:04] <cjwatson> (just trying to minimise task count on the RC page ...)
[21:05] <Riddell> cjwatson: so long as it's on something in intrepid that's fine
[21:05] <Riddell> it's really a bug in rosetta not kde-l10n-xx
[21:06] <cjwatson> Riddell: yeah
[21:06] <cjwatson> TheMuso: did you get a UI freeze exception for bug 279288? that needs to move ahead RSN
[21:09] <Riddell> lool: "ERROR   Could not find source 'xserver-xorg-video-psb/None'" I guess someone else removed it?
[21:09] <lool> Riddell: Yup, infinity did; sorry for the bother and thanks!
[21:10] <NCommander> ajmitch, is rezound still broken?
[21:15] <ajmitch> NCommander: depends if someone else had time to look at it, since I didn't
[21:16] <NCommander> given the version number still screwy as hell, I'm going to say no
[21:18] <infinity> lool: Still around?
[21:24] <lool> infinity: yup
[21:25] <infinity> lool: Do you recall how to coax xvfb-run into writing out an X.log somewhere?
[21:26] <lool> infinity: It's what pygtk does in the build
[21:26] <lool> infinity: -e
[21:26] <infinity> lool: That doesn't seem to be getting a log to disk.
[21:27] <lool> -e debian/xvfb-2.5.log
[21:27] <lool> infinity: It doesn't?
[21:27] <infinity> lool: (I see error stuff in strace, I'll just bump the string size and yank it from there)
[21:27] <lool> infinity: If you open xvfb-run, -e sets ERRFILE which is used as the target of the >"$ERRFILE" 2>&1 redirs after Xvfb and other commends
[21:28] <lool> commands
[21:28] <lool> fuck.
[21:28] <infinity> [pid  3703] write(2, "\nFatal server error:\n", 21) = 21
[21:28] <infinity> [pid  3703] write(2, "Cannot establish any listening sockets - Make sure an X server isn\'t already running", 84) = 84
[21:28] <lool>         XAUTHORITY=$AUTHFILE xauth remove ":$SERVERNUM" >"$ERRORFILE" 2>&1
[21:28] <infinity> Hrm.
[21:28] <lool> It's cloberring the ERRFILE in cleanup
[21:29] <jcristau> i fixed that :)
[21:29] <lool> infinity: Can you remove the redirs in a local copy of xvfb-run
[21:29] <lool> jcristau: Eh
[21:29] <calc> OOo 1:3.0.0-2ubuntu1 should be in the ppa in a couple hours
[21:29] <calc> i was about to upload when i noticed there was another update, heh
[21:30] <lool> infinity: This should fix the issue with logigng
[21:30] <jcristau> lool: so if you rebase on 2:1.5.2-1 you get the fix!
[21:30] <jcristau> ;)
[21:30] <lool> I will
[21:31] <lool> I'm doing it already :)
[21:31] <lool> Hmm xserver 1.5.2
[21:32] <lool> bryce_, tjaalton: do we want xserver 1.2 for itnrepid?  looks like bug fixes mostly
[21:32] <infinity> Hrm, I call BS:
[21:32] <infinity> _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[21:32] <infinity> _XSERVTransMakeAllCOTSServerListeners: server already running
[21:32] <infinity> Fatal server error:
[21:32] <infinity> Cannot establish any listening sockets - Make sure an X server isn't already running
[21:32] <bryce_> do you mean 1.5.2?  yes we already have all the changes from 1.5.1->1.5.2
[21:33]  * rainct notes that the "busy" status on the new user/status/logout-thingie doesn't work for him with Pidgin
[21:33] <infinity> lool: Given that it fails only on sparc/hppa/powerpc, I'd be willing to bet there's an endian-cleanliness issue in the routine that checks for a current listener.
[21:34] <tjaalton> bryce_: in fact one commit is missing
[21:34] <cjwatson_> ogra: could you check up on the status of bug 258110 in intrepid, please?
[21:34] <infinity> lool: (This is on a headless server with no X, no other Xvfb, and in a chroot with a clean (just deleted and recreated, no less) /tmp
[21:35] <cjwatson_> ogra: it looks like both are backports and so might already be in intrepid if we have a new enough version, but I'd appreciate you checking
[21:35] <infinity> lool: So, no xauth breakage, no other users messing with me, and it still seems to think it's clashing with another server.
[21:35] <lool> bryce_: Hmm are the changes pushed to git.d.o?
[21:35] <ogra> cjwatson, erm, so i need to buld an intrepid image ?
[21:35] <lool> infinity: aha
[21:35] <cjwatson> ogra: no, I'm just looking through the bugs currently targeted to intrepid
[21:35] <infinity> lool: Is that enough for you to go on?
[21:36] <cjwatson> ogra: and I would like to know if the intrepid tasks on that bug can correctly be closed
[21:36] <ogra> cjwatson, i'll check the code
[21:36] <lool> infinity: Perhaps it's enough for tjaalton or bryce_
[21:36] <cjwatson> ogra: thanks
[21:36] <lool> tjaalton: What do you think?
[21:36] <jcristau> infinity: but /tmp/.X11-unix/ exists?
[21:36] <cjwatson> jdstrand: sync bug 281456 was processed; can the intrepid task on bug 257122 be closed now?
[21:36] <jdstrand> cjwatson: yes
[21:37] <jdstrand> cjwatson: removed
[21:37] <cjwatson> BenC: do we still need the initramfs-tools task on bug 246269?
[21:37] <cjwatson> jdstrand: thanks
[21:37] <tjaalton> lool: sigh, the changelog was not finalized, but it's in the archive
[21:38] <infinity> jcristau: Indeed.
[21:38] <lool> tjaalton: Ok, cause I see a lot of diff between origin/debian-experimental and origin/ubuntu; I guess it's because the changes are as patches perhaps?
[21:38] <infinity> jcristau: chowned back to root:root after I deleted it and had it recreated as a regular user (which caused a different complaint :P)
[21:38] <lool> Looks like it
[21:39] <tjaalton> lool: duh, maybe I didn't push at all
[21:39] <tjaalton> lool: done
[21:39] <lool> thanks
[21:40] <infinity> jcristau: Hrm.  Get a different error when I whack the X99 socket and let it get recreated, my bad.
[21:40] <infinity> jcristau: The real error is:
[21:40] <infinity> (EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/base
[21:40] <infinity> (EE) XKB: No components provided for device Virtual core keyboard
[21:40] <infinity> No core keyboard
[21:40] <infinity> Fatal server error:
[21:40] <infinity> failed to initialize core devices
[21:40] <infinity> That seems much more easily resolved.
[21:40] <cjwatson> jdstrand: hmm, the bug still seems to be open ...?
[21:41] <jdstrand> cjwatson: it shows here as 'Fix Released' with no milestone...
[21:41] <lool> tjaalton, bryce_: so do we care to rebase on 1.5.2 (upstream or debian)?  IOW, should I merge debian-experimental or should I cherry-pick xvfb-run?
[21:41] <infinity> jcristau: (Sorry, had one failure as root, so the socket stuck around... Entirely different bug there, that really should be cleaned up)
[21:41] <cjwatson> jdstrand: the ruby1.9 task
[21:41] <cjwatson> jdstrand: it doesn't have a milestone, but it does have an intrepid target
[21:41] <cjwatson> which is "In Progress" and assigned to you
[21:42] <jdstrand> cjwatson: oh heh, yeah-- I removed the milestone for the closed bug
[21:42] <jdstrand> cjwatson: sorry
[21:42] <lool> infinity: Does installing xkb-data workaround the bug?
[21:42] <bryce_> lool, I'd asked tjaalton that question a few weeks back, and it wasn't felt necessary to rebase to it
[21:42] <tjaalton> lool: rebase sounds fine by me
[21:42] <tjaalton> :P
[21:42] <jcristau> infinity: thanks
[21:42] <lool> you say rebase, but we actually git merge, right?
[21:43] <tjaalton> lool: you can also just cherry-pick the only missing commit that was added to 1.5.2
[21:43] <jdstrand> cjwatson: done
[21:44] <jdstrand> (for real this time :)
[21:44] <lool> tjaalton: TBH I'm a bit lost in mixing cherry picks with real patches
[21:44] <cjwatson> jdstrand: thanks, much better :)
[21:44] <lool> I'm cherrypicking debian/ commits, but stuff from upstream in the .diff along with patches from upstream in debian/patches?  hmm
[21:45] <lool> +fine
[21:45] <tjaalton> there aren't patches from upstream in d/p
[21:45] <tjaalton> at least not from the 1.5-branch
[21:45] <tjaalton> master is different
[21:47] <infinity> lool: I assume I'm still missing a package:
[21:47] <infinity> sh: /usr/bin/xkbcomp: not found
[21:47] <infinity> (EE) Error compiling keymap (server-99)
[21:47] <infinity> (EE) XKB: Couldn't compile keymap
[21:47] <infinity> No core keyboard
[21:47] <infinity> Fatal server error:
[21:47] <infinity> failed to initialize core devices
[21:48] <lool> x11-xkb-utils
[21:48] <lool> I don't quite get why it works in my chroots though
[21:48] <lool> or on other arches
[21:49] <lool> tjaalton: ok, understood
[21:49] <infinity> lool: Nah, still fails:
[21:49] <infinity> No core keyboard
[21:49] <infinity> Fatal server error:
[21:49] <infinity> failed to initialize core devices
[21:49] <cjwatson> ogra: yay, thanks
[21:49] <jcristau> xkb failure shouldn't be fatal..
[21:49] <infinity> jcristau: Shouldn't be, sure.  My machine disagrees.
[21:50] <lool> infinity: At least that's consistent
[21:50] <lool> You don't have a core keyboard for some reason; the xkb issues are probably on all arches
[21:51] <cjwatson> slangasek: do you know what's going on with bug 251683? nobody's tried to get any more information
[21:52] <cjwatson> vorian: what filesystem type were you using for your / (and /boot if separate) partitions in that test?
[21:52] <cjwatson> vorian: and is this problem still present for you?
[21:53] <slangasek> cjwatson: mmm, no I don't
[21:54] <lool> tjaalton: Hmm I see you drop the last ubuntu changelog entries when merging with debian, but I don't understand why other changelog entries were kept
[21:54] <cjwatson> is anyone working on bug 260235? does it actually make sense for it to be targeted to intrepid?
[21:54] <infinity> lool: So, can I leave it to you and the X guys to sort out why sparc/hppa/powerpc have no core keyboard?
[21:55]  * slangasek pattern matches on php.*gtk and foams at the mouth
[21:55] <vorian> cjwatson: it is not, i'll mark it invalid
[21:55] <lool> infinity: I guess we'll come back to you if we need more info; thanks a lot!
[21:55] <infinity> slangasek: It's the Way and the Light.  We're moving launchpad to PHP with a PHP-GTK frontend, too!
[21:56] <lool> *needs-packaging*  needsnot!
[21:56] <infinity> lool: Sure.  I won't destroy my test environment, so you can come back to me.
[21:56] <cjwatson> vorian: fantastic, thanks
[21:56] <vorian> no problemo
[21:56] <cjwatson> vorian: I guess we're just so hot we fixed it without noticing ;-)
[21:56] <vorian> hell yeah!
[21:56] <calc> slangasek: i am going to attempt to get the last 2.4.1 build in tonight or by early tomorrow
[21:56] <cjwatson> TheMuso: what's the state of bug 191027? should it be targeted to intrepid?
[21:56] <vorian> thanks :)
[21:57] <calc> slangasek: currently getting the 3.0.0 build done so that forum users will be happy ;-)
[21:57] <slangasek> calc: ok, thanks :)
 the release is lower priority than keeping forum users happy?
[21:57] <lool> It's not clear to me how I should sort changelog entries when the Ubuntu version was started from an UNRELEASED entry which got its version bumped in Debian later on
[21:58] <calc> slangasek: well i thought it wouldn't take long but i ran into a small issue, its now fixed so shouldn't take much longer
[21:58]  * slangasek extrapolates that all forum users are cannibals
[21:58] <calc> somehow when code doesn't change the build still manages to break (rc4 and 3.0.0 are the same code)
[21:59]  * calc mutters something about rene flipping a switch that blew up the build :-\
[22:00] <tjaalton> lool: you are free to sort them using the version numbers.. I don't think it's that important
[22:01] <lool> tjaalton: If I sort them using version numbers, we'll see the first changes from Debian appear higher in the changelog than your "merged from Debian"
[22:02] <tjaalton> lool: ok then, your call :)
[22:02] <lool> If I don't sort them, they will be after your "merged with debian" instead of being between the merges
[22:02] <seb128_> kees: hello
[22:02]  * lool thinks debian/changelog merging doesn't work so well
[22:03] <tjaalton> lool: you can skip the merge, just cherry-pick what you need
[22:03] <jcristau> tjaalton: the cherry-pick would conflict in the changelog ;)
[22:03] <cjwatson> lool: you could always move the old changelog entries around if they've never been uploaded
[22:03] <tjaalton> jcristau: argh
[22:03] <cjwatson> lool: you don't have to religiously keep old changelog entries that don't correspond to an upload
[22:04] <lool> cjwatson: It's a) ubuntu changelog entry about merging changes from Debian b) unreleased changes from Debian
[22:04] <Riddell> evand: what's planned for bug 270423 ?
[22:05] <lool> and now my real history is A) merge from debian B) some debian changes C) merge from debian (a)) D) unreleased changes from debian (b))
[22:05] <lfaraone> Hey, how can https://bugs.launchpad.net/bugs/277302 (patch inlcuded) get shipped?
[22:05] <evand> Riddell: I'm working on it, I hope to have it resolved tonight.
[22:05] <lool> I can't possibly describe the real history AND preserve the real uploads
[22:06] <lool> It's funny cause I faced the same issue in bzr branches recently, when merging debian/changelog changes from Nokia into Ubuntu
[22:06] <lool> it gets fun when Debian does the same thing
[22:07] <lool> I guess we shouldn't ever rely on the changelog entries from the merge party staying where they are, but mention explicitely up to which point they were pulled and list them in a separate place
[22:14] <superm1> pitti, ah just make sure LBM was copied at the same time at jockey to hardy-updates, I might have missed it if it already was
[22:15] <pitti> superm1: currently at it
[22:15] <superm1> pitti, alright, sorry for stepping on your toes, just saw an email about jockey :)
[22:15] <pitti> superm1: when did you "step on my toes"? :)
[22:16] <kees> seb128_: hi!
[22:17] <lool> jcristau: FYI rmdir --ignore-fail-on-non-empty
[22:17] <seb128_> kees: I just got upstream complains about the vte patch you added, which is to list their concern: adding ubuntu specific api which is not ubuntu namespaced, incorrect and for which one you didn't follow up upstream to say ubuntu is using the change etc
[22:18] <seb128_> kees: they will fix it properly in svn soon, can you try to backport the change before intrepid?
[22:18] <Riddell> evand: good luck!
[22:19] <evand> thanks
[22:19] <kees> seb128_: "ubuntu-specific api" ??
[22:19] <seb128_> kees: http://launchpadlibrarian.net/17143914/vte_1%3A0.17.2-0ubuntu1_1%3A0.17.2-0ubuntu2.diff.gz
[22:19] <seb128_> kees: it adds a libvte function no?
[22:20] <kees> seb128_: ah, that.  if they've actually fixed it, I have no problems.  They were incorrectly stating it wasn't a vte problem.
[22:20] <seb128_> kees: the change is ubuntu specific since the patch has not been accept upstream so it should be namespaced to avoid issues
[22:20] <seb128_> kees: they are fixing it now but complaining about ubuntu again
[22:20] <seb128_> kees: would be nice to stop giving them reason to rant against ubuntu ;-)
[22:21] <kees> seb128_: how about they commit the other VTE bug-fixes instead of complaining about stuff we've actually fixed?
[22:21] <seb128_> kees: looks like the bug has been discussed upstream but nobody bother to look there after the change had been uploaded to intrepid
[22:22] <jcristau> lool: for /etc/X11/xserver? yeah, i thought of that, and then decided I didn't care why rmdir would fail :)
[22:22] <kees> seb128_: well that's not my fault fault -- they chronically ignore important bugs to VTE, even when patches have been put into their bug tracker.
[22:22] <seb128_> kees: they say the fix is not correct, anyway I told them we will try to namespace the functions which are ubuntu specific and we will backport what they consider the correct change
[22:23] <kees> seb128_: like I said, if they've _actually_ fixed it, I have no problem merging their fix.
[22:24] <kees> seb128_: I don't see any solution for the bug still (http://bugzilla.gnome.org/show_bug.cgi?id=518405)
[22:24] <seb128_> kees: behdad said he's working on a fix now so it'll probably be fixed soon in svn
[22:24] <kees> seb128_: okay.
[22:24] <seb128_> kees:
 seb128_: two things: 1) would help immensely if ubuntu-added API is clearly marked so (by appending _ubuntu for example), 2) would be helpful if existence of such patchs be reported to upstream.
 in this specific case, the solution really is something different.  and I'm working on a fix right now.
[22:25] <seb128_> just for the record there
[22:25] <kees> seb128_: I hadn't heard the suggestion of adding _ubuntu namespaces, which I'm happy to do.  The patch I used was already in their tracker.
[22:25] <seb128_> right I pointed there to him too
 seb128_: the patch was indeed sent upstream, but the fact that ubuntu is actually shipping it was not pointed that.  that's the information I can use when prioritizing and making decisions.
[22:26] <kees> can they please commit http://bugzilla.gnome.org/show_bug.cgi?id=54926 too then?
[22:26] <seb128_> kees: anyway let's try to namespace ubuntu specific api next time and backport this svn change when it's available
[22:26] <kees> seb128_: okay, if that makes a difference to them, sure.
[22:26] <seb128_> kees: not blaming you, just forwarding upstream concerns
[22:27] <lool> bryce_, tjaalton: I've pushed the Debian merge and psb changes; Debian re-adds xserver-common, is that fine with you?  If in doubt, please take a look before I upload
[22:28] <kees> seb128_: okay, sure.  I'm just really sensitive about vte bugs because I spent an entire weekend of my own time fixing bug 54926 and it's been virtually ignored even though the bug has been open for 7 years.
[22:28] <bryce_> lool: I don't have an opinion; tjaalton might but I think he may be in bed
[22:29] <lool> Rationale:
[22:29] <lool>   * Re-introduce the xserver-common package, containing
[22:29] <lool>     /usr/lib/xorg/protocol.txt and the Xserver(1) manpage for now.
[22:29] <lool> The changes look safe, it's just going to NEW, but I don't think that's a big issue
[22:29] <bryce_> ahh, that looks familiar, yes I think those things are safe
[22:30] <bryce_> xserver-common was dropped, but then it was found certain packages were expecting to see the protocol.txt file
[22:30] <lukehasnoname> who is allowed to edit community documentation?
[22:30] <lool> bryce_: Ok, will push it then, thanks
[22:33] <stgraber> oh oh, a new fglrx !!!
[22:33] <RAOF> stgraber: What?  One that might possibly work in Intrepid?  Surely not!
[22:33] <bryce_> stgraber: yep, just uploaded it
[22:33] <wgrant> I'm afraid so.
[22:33] <stgraber> bryce_: thanks !!! I'll test that tonight
[22:33] <ogra> oh, sigh
[22:34] <bryce_> stgraber: great thanks :-)
[22:34] <stgraber> (not that I don't like the free driver but some 3D and compiz would be great)
[22:34]  * ogra just notices that the rest of linux-lpia can only be uploaded if the kernel has built
[22:34] <ogra> stgraber, intel FTW :)
[22:34] <wgrant> RAOF: Are you on your amd64 machine with xinput issues right now?
[22:34] <RAOF> wgrant: Yes.
[22:35] <stgraber> ogra: yeah ... that's the only non-intel component in that laptop ...
[22:35] <RAOF> (That's my only machine)
[22:35] <wgrant> RAOF: Can you grab https://edge.launchpad.net/%7Ewgrant/+archive/+files/libxi6_1.1.3-1ubuntu5~wgrant1_amd64.deb and try it?
[22:35] <stgraber> wgrant: should I too ?
[22:35] <wgrant> stgraber: If you're on amd64, sure.
[22:35] <stgraber> yes
[22:36] <ogra> lool, i guess i dont have to care if linux-lpia is ftbfs on i386, right ?
[22:36] <lool> ogra: Well actually I asked OEM and they could find the tree useful
[22:36] <jcristau> lool: some packages from the xorg source package Conflict with xserver-common. i changed the conflict to (<< 7) recently, but i'm not sure if that's in ubuntu yet
[22:36] <lool> ogra: But right now, it's not used
[22:36] <ogra> ok
[22:37] <stgraber> wgrant: works
[22:37] <ogra> though i dont really get why there is an attempt to build it at all
[22:37] <ogra> Architecture: lpia
[22:37] <stgraber> wgrant: no more error when doing: xinput --list-props <id>
[22:37] <wgrant> stgraber: You can see the properties? Can you set them to?
[22:37] <wgrant> +o
[22:37] <ogra> shoudnt that prevent it from building on i386 anyway ?
[22:38] <wgrant> ogra: That will just make it fail. P-a-s stops it from building at all.
[22:38] <ogra> ah
[22:38] <ogra> k, thenk i'll just wait for the lpia build
[22:38] <ogra> oh, sigh
[22:38] <ogra> Package: linux-image-2.6.27-4-virtual
[22:38] <ogra> Architecture: i386 amd64
[22:38] <RAOF> wgrant: So, Sys->Pref->Mouse->Touchpad now shows up, but doesn't do anything.
[22:38] <ogra> i bet that will get us probs
[22:39] <lool> jcristau: grep-aptavail -F Conflicts xserver-common -s Package tells me x11-common, xserver-xorg, xserver-xorg-core; i guess I need to push x11-common as well
[22:39] <cathyal> anyoen running dell hardware?
[22:39] <wgrant> RAOF: Restart gnome-settings-daemon.
[22:39] <cathyal> are they alright with linux?
[22:39] <wgrant> cathyal: Yes.
[22:39] <ogra> .oO(why did amit leave -virtual in)
[22:39] <wgrant> In general, yes.
[22:39] <cathyal> specially the integrated graphics chips
[22:39] <cathyal> no issues whatsoever?
[22:39] <wgrant> cathyal: They vary significantly, and this isn't the channel.
[22:39] <cathyal> ok pvt then?
[22:40] <wgrant> I don't think so.
[22:40] <stgraber> wgrant: Mouse preferences now work here too
[22:40] <cathyal> ..k
[22:40] <RAOF> wgrant: Works.  You rock.
[22:40] <wgrant> stgraber: As in the touchpad tab?
[22:40] <stgraber> yeah
[22:40] <wgrant> RAOF: This is jcristau's doing. He rocks.
[22:40] <wgrant> stgraber: Excellent.
[22:40] <wgrant> Thanks for testing, both of you.
[22:41] <stgraber> wgrant: I just played with vertical/horizontal scrolling and could turn them on/off correctly
[22:41] <stgraber> wgrant: thanks for the fix :)
[22:41] <wgrant> I'm glad that's fixed...
[22:41] <lool> ogra: I didn't see virtual last time; I suspect he pulled it when he rebased
[22:41] <stgraber> so now I have perfectly working touchpad and soon video driver, quite a good day it seems :)
[22:42] <ogra> lool, do we want for a failure or should i act right now and fix the control file in suspicion ?
[22:44] <lool> ogra: Sorry, don't understand what you're referring to: virtual or i386?
[22:44] <ogra> lpia
[22:44] <ogra> lool, look at the control file on -changes
[22:44] <lool> We want it to build on lpia  :)
[22:44] <ogra> lool,
[22:44] <ogra> Package: linux-image-2.6.27-4-virtual
[22:44] <ogra> Architecture: i386 amd64
[22:45] <ogra> thats in debian/control
[22:45] <ogra> assuming that binary exists already we wil likely produce some kind of errors
[22:45] <lool> Well it wont generate them
[22:45] <lool> because it ftbfs on these arches
[22:45] <ogra> oh, indeed :)
[22:45] <lamont> wth does ekiga keep its config?
[22:45]  * ogra is to tired
[22:46] <lool> lamont: /apps/ekiga, in gconf?
[22:46] <lamont> lool: rsync of .gconf/apps/ekiga between two machines, and ekiga still wants to be configured
[22:47] <lool> lamont: Did you restart gconfd?
[22:47] <stgraber> superm1: Who did you say I should contact about the Mythbuntu ISO testing testcases ?
[22:47] <lamont> meh
[22:47] <lamont> lool: SIGHUP will do?
[22:47] <lool> I think any signal will do :)
[22:48] <lool> yeah HUP is fine
[22:48] <lool> kill -s HUP `pidof gconfd-2`
[22:48] <superm1> stgraber, tgm4883 or tgm4883_laptop
[22:48] <lool> (gconfd supposedly writes the list of dbus listeners to some on disk file and reloads it on startup)
[22:48]  * lamont liked the system better when it wasn't all bolted into stupid daemons
[22:48]  * lool finds it odd from the maintainer of postfix :)
[22:49] <BenC> cjwatson: no
[22:49] <BenC> cjwatson: (re: initramfs-tools and uvesafb)
[22:49] <lamont> well... still no address book or acct info... sigh
[22:50]  * ogra guesses thats saved in some gnome-keyring protected area
[22:50] <lamont> registered accounts: 0
[22:50] <ogra> or some such
[22:51]  * lamont declares total fail on rational configuration, and will do the manual clone between ekiga configs once he can sit with the stupid widgits up on both machines
[22:51] <lamont> still, what would be wrong with  putting it all in one directory, I wonder
[22:52] <cjwatson> BenC: marked invalid then, thanks
[22:53] <pitti> bryce_, tseliot: oh, just saw the fglrx-installer upload; two questions, (1) I thought we'd ship the driver in xorg-driver-fglrx? (2) if it actually works with intrepid now, can we update xorg-driver-fglrx, too? then I'd re-enable it in jockey
[22:53] <pitti> bryce_, tseliot: oh, nevermind me; fglrx-installer is the source for xorg-driver-fglrx
[22:53] <slangasek> xorg-driver-fglrx is built from ...yeha
[22:54] <slangasek> bryce_: so should the comments on fglrx be dropped from the release notes completely at this point?
[22:54] <bryce_> slangasek: yes
[22:54] <jdong> so fglrx is gonna be really really good on Intrepid right? :)
[22:54] <slangasek> w00t
[22:54] <bryce_> pitti: righto
[22:54]  * jdong digs out his dungeon laptop
[22:54] <slangasek> jdong: no, it's going to be non-free binary crap like always ;-)
[22:54] <bryce_> jdong: I sure hope so!
[22:55] <jdong> slangasek: lol I have a big collection of {free, non-free} {binary, source} crap right now :D
[22:55] <jdong> I think I'll survive
[22:55] <bryce_> jdong: actually I'll be satisfied with "sort of works almost as good as it did in hardy"
[22:55] <pitti> bryce_: so I guess https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/262819 can actually be closed now, too?
[22:55] <jdong> speaking of that, bryce_ while you're here, what will it take for concurrent AIGLX sessions?
[22:55] <pitti> that also means we need to revert the update-manager transition to ati
[22:56] <jdong> i.e. two VTs running Compiz with Intel
[22:56] <cjwatson> yay, under 100 targeted bugs
[22:56] <tseliot> pitti: yes, and we will also have to make jockey depend on the modalias package
[22:56] <jdong> pitti: while I have you here, can I get your opinion on bug 281835?
[22:56] <slangasek> cjwatson: also-w00t
[22:57] <jdong> pitti: I can't see the trivial workaround causing any problems
[22:57] <bryce_> pitti: I figured this was a prereq for that, so didn't list the upload as closing the bug, but yeah once jockey is suitably poked, can be closed.
[22:57] <slangasek> now give me a second to pile some more on from the other end ;)
[22:57] <pitti> bryce_: yes, I just closed the fglrx-installer task.
[22:57] <bryce_> jdong: concurrent AIGLX - not sure maybe ask upstream
[22:57] <cjwatson> slangasek: yeah, I've been slightly futilely trying to sort wheat from chaff in +nominations too
[22:57] <jdong> bryce_: ok so it's not supposed to work right now on -intel right?
[22:58] <jdong> bryce_: the 2nd display started up lacks any DRI
[22:58] <bryce_> pitti: re reverting the update-manager transition, yes I was about to mention that to mvo, but if you know what needs reverted, please proceed
[22:58] <cjwatson> but the list is horrific
[22:58] <cjwatson> (ally long)
[22:59] <wgrant> cjwatson: I often wonder if Launchpad needs some defense to prevent Joe Random from nominating for every release...
[22:59] <tseliot> bryce_: I worked with mvo on that (with xkit). I'll talk to him
[22:59] <pitti> bryce_, slangasek: I added release-notes and update-manager tasks to bug 247376
[23:00] <bryce_> jdong: it's not something I've tested, but it would not surprise me to see it not working; again, upstream is probably the best to talk to to see what work needs done.
[23:00] <seb128> slangasek: I just read your freeze email, GNOME has a standing exception right? ;-)
[23:00] <jdong> bryce_: ok, gotcha
[23:00] <slangasek> pitti: uh, didn't we already /have/ a release-notes task on 247376?
[23:00] <pitti> yeah, "reopened"
[23:01] <pitti> jdong: thanks for the pointer, will fix tomorrwo
[23:01] <slangasek> pitti: oh meh, I already reverted the release notes before you did that :)
[23:01] <pitti> ok, sorry, closing again then
[23:01] <jdong> pitti: sweet, thanks! btw I love the guest session feature :)
[23:01] <slangasek> seb128: as long as you don't upload anything that depends on webkit...
[23:01] <TheMuso> cjwatson: re 279288? I haven't received an exception yet. I've subscribed ubuntu-release, but no movement on the bug as yet.
[23:02] <slangasek> (or otherwise bump us oversized)
[23:02] <bryce_> cjwatson: yeah...  It took me a full day just to get through all the Xorg nominations.  It occurred to me that maybe a launchpadlib script could be written to just bulk-close all bugs not meeting certain criteria.  E.g. bugs with no attachments, without a priority assigned, and state undecided, probably are probably safe to decline without looking at them, and that might chop the list down considerably
[23:02] <seb128> slangasek: that was not GNOME but gimp, GNOME 2.24.1 update will only bug fix updates for desktop applications
[23:02] <pitti> slangasek: I did the corresponding change (fglrx) to https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview
[23:02] <seb128> slangasek: but right the new webkit requirement was not nice, good that pitti fixed this one ;-)
[23:03]  * seb128 hugs pitti
[23:03]  * pitti hugs seb128, no problem
[23:03] <pitti> seb128: nothing against webkit in general, but a bit too late for intrepid, I'm afraid
[23:03] <slangasek> pitti: ok :)
[23:03] <TheMuso> cjwatson: re 191027?, that was a hardy bug, but users using intrepid decided to comment on that bug as they were having problems, which appear to be resolved now.
[23:03] <pitti> seb128: epy-webkit by default in jaunty, right? *duck*
[23:03] <slangasek> heh
[23:04]  * slangasek weeps at all the SRU bugmail from the linux SRU
[23:04] <cjwatson> slangasek: can you look at 279288? I didn't want to do it myself since I was involved in suggesting the changes
[23:04] <seb128> pitti: I didn't want to advocate for webkit, we had just quite some user pressure to update gimp and I didn't notice the webkit requirement before doing the update
[23:04] <slangasek> cjwatson: looking
[23:04] <cjwatson> oh, never mind, pitti already did
[23:04] <cjwatson> :-)
[23:04] <bryce_> pitti: let me know when you've updated jockey, and I'll notify the fglrx-installer bug reporters to re-test
[23:04] <cjwatson> TheMuso: reload 279288 ;-)
[23:04] <slangasek> er, yes, I have that bug open in a window in fact
[23:04] <slangasek> :)
[23:04] <seb128> pitti: doubt of that ;-) but it's not impossible that GNOME applications using gtkhtml or gecko for rendering will switch next cycle
[23:05] <slangasek> seb128: s/GNOME applications/all &/ ? please?
[23:05] <seb128> slangasek: all those we have on the CD will likely switch
[23:06] <slangasek> woohoo
[23:06] <calc> had a doh moment about why his phone is not working well, not sure why it stopped recently though
[23:06] <seb128> slangasek: we still need to have xulrunner for firefox though so it doesn't really help CD space
[23:06] <calc> his phone is 2.4ghz and next to a wireless router at 2.4ghz, heh
[23:06] <cjwatson> TheMuso: I've seen 191027 myself in intrepid, but it was a couple of weeks ago
[23:06] <TheMuso> cjwatson: Right, how do things stand now?
[23:06] <cjwatson> TheMuso: I haven't seen it for a while, but it was intermittent to start with
[23:06] <slangasek> seb128: getting rid of gtkhtml would help more than not getting rid of it :)
[23:06] <cjwatson> TheMuso: did you consciously fix it or did it just go away?
[23:07] <seb128> slangasek: right agreed on this one
[23:07] <TheMuso> cjwatson: I conciously made an effort to fix it.
[23:07] <seb128> anyway that's for next cycle
[23:07] <cjwatson> TheMuso: ah, right
[23:07] <cjwatson> TheMuso: it wasn't clear to me from the bug log that anything had been uploaded to intrepid to fix it; could you add details where appropriate?
[23:07] <slangasek> hmm, I wonder if branch merge proposals are at all effective for Ubuntu at present
[23:08] <TheMuso> cjwatson: Sure, when I get to my bug mail, I'll do so.
[23:08] <cjwatson> thanks
[23:13] <lukehasnoname> who is allowed to edit community documentation?
[23:14] <mdke> anyone with a Launchpad account
[23:14] <lukehasnoname> I was told I was not authorized to edit the nagios community page.
[23:15] <mdke> lukehasnoname: link?
[23:15] <Hix-2> hey guys, just wanted to say thanks for a linux OS that 'just works'
[23:15] <Hix-2> see ya
[23:15] <mdke> :)
[23:15] <lukehasnoname> Well, not it works. I feel foolish. It didn't work earlier, even though I was clearly logged in.
[23:15] <cjwatson> Hix-2: you're welcome :-)
[23:15] <cjwatson> Riddell: does lp:~ubuntu-core-dev/language-selector/ubuntu r193 look right to you?
[23:16] <mdke> lukehasnoname: no worries
[23:18] <Riddell> let mw look
[23:19] <cjwatson> Riddell: review of bug 266971 looks like it'd be good as well
[23:19] <calc> yipee 3.0 build finished successfully
[23:23] <cjwatson> slangasek: I'm feeling as if the hit rate on +nominations is about the same as that from going through a random sample of bugs. Does your experience match this?
[23:23] <Riddell> cjwatson: revision 193 seems fine.  I also fixed the bug in revision 192, but both fixes seem good to have
[23:23] <slangasek> cjwatson: I'm not sure I've ever gone through a random sample of bugs to compare it with :)
[23:23] <slangasek> cjwatson: but it's certainly lower than I would like, yes
[23:24] <cjwatson> Riddell: does that also cover bug 266971, then?
[23:24] <cjwatson> hmm, doesn't look like it
[23:25] <Riddell> cjwatson: no, I think we want that patch too
[23:26] <cjwatson> Riddell: could you please use UNRELEASED in changelogs when you haven't uploaded them? I just realised it was incorrect for me to start a new changelog entry for that
[23:26] <Riddell> hmm, I wonder why I didn't upload
[23:26] <cjwatson> I'll merge the changes back
[23:27] <cjwatson> I always use UNRELEASED even if I'm going to upload immediately; I find it a useful habit
[23:27] <ogra> cjwatson, what do you think how many years will it take until you converted us all :)
[23:28]  * ogra totally agrees with cjwatson but still constantly forgets about it
[23:28] <cjwatson> echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts
[23:29] <lool> Yeah, it rocks
[23:29] <cjwatson> much more sensible for anything maintained in revision control
[23:29]  * ogra copy pastes
[23:29]  * TheMuso uses UNRELEASED also. Very handy.
[23:30] <stgraber> bryce_: bug !!!
[23:30] <ogra> i refrain from setting DEBEMAIL to force me to look over the changelog again
[23:30] <ogra> but i think my changelog typos show it doesnt really help much
[23:30] <stgraber> bryce_: http://ubuntu.pastebin.com/f6529441d http://ubuntu.pastebin.com/f34a0d549
[23:30] <cjwatson> Riddell: I've committed but testing involves:
[23:31] <cjwatson> Need to get 49.1MB of archives.
[23:31] <cjwatson> After this operation, 149MB of additional disk space will be used.
[23:31] <ogra> stgraber, all your fault :P
[23:31] <cjwatson> Riddell: don't suppose I can con somebody into testing it before upload? :-)
[23:31] <stgraber> ogra: why ? :) (except from choosing ATI)
[23:31] <Riddell> cjwatson: I can try it
[23:31] <ogra> stgraber, no exceptions allowed :P
[23:31] <cjwatson> ta, r196
[23:31] <stgraber> ogra: :(
[23:32] <bryce_> stgraber: hmmm... come to #ubuntu-x plz
[23:37] <directhex> ding dong, this is your tuesday night merge request, required to make sure intrepid doesn't ship with CVE-2008-3422 and CVE-2008-3906 haunting it: https://bugs.launchpad.net/ubuntu/+source/mono/+bug/282952
[23:37]  * ogra cries
[23:37] <ogra> lool, http://launchpadlibrarian.net/18545026/buildlog_ubuntu-intrepid-lpia.linux-lpia_2.6.27-4.5_FAILEDTOBUILD.txt.gz
[23:37] <ogra> :(
[23:37] <ogra> i thought we dont have the abi check anymore in lpia
[23:38]  * ogra thought that was the whole purpose of having separate source packages
[23:39]  * ogra mumbles something that should better be not understood by anyone and adds the abi overrides
[23:41] <lool> ogra: grah :-(
[23:57] <calc> uploading openoffice.org_3.0.0-2ubuntu1 now
[23:57] <calc> er to PPA of course ;)
[23:58] <directhex> aw, scaredycat
[23:59] <ogra> calc, phew