[00:12] <chrisccoulson> slangasek - i've uploaded gnome-screensaver to karmic-proposed now
[00:14] <TheMuso> ~s/c~s
[00:16] <silas428> is floodbot an actual bot?
[00:19] <genii> silas428: Yes
[00:19] <silas428> genil: k, thought I was getting flooded out of #ubuntu for a second
[00:19] <genii> Well, no physical incarnation
[00:20] <silas428> is #ubuntu down or something?
[00:20] <Pici> no?
[00:20] <ari-tczew> [01:20] [Uwaga] -ChanServ- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there - This channel is officially logged at
[00:20] <silas428> I get an error message saying something is wrong with my router
[00:20] <silas428> Every other chat room works just fine
[00:20] <Pici> silas428: Then you should read the topic of the channel you were forwarded to
[00:21] <Pici> silas428: If you have any further questions you can ask in #ubuntu-ops
[00:21] <silas428> Pici: I did, I just didn't bother updating yet
[01:44] <ScottK> chrisccoulson: In the event of an SRU related regression, the Tech Board is to be notified.  If you didn't, I recommend writing them with the details of the issue and the resolution.
[01:44] <chrisccoulson> ScottK - thanks, I'll do that
[01:44] <ScottK> Good.
[02:10] <eboyjr> I'm thinking about cleaning up jockey-gtk a little bit.. Where should I start?
[02:15] <ScottK> eboyjr: Probably by talking to pitti.
[02:34] <Plagman_> why is libGLU.so in /usr/lib/mesa now?
[02:34] <Plagman_> shouldn't there by a symlink from /usr/lib/libGLU.so to /usr/lib/mesa/libGLU.so.1 if you're going to do that?
[02:35] <Plagman_> s/by/be/
[02:51] <ScottK> Plagman_: It should be OK in the most recent upload.  If you want to discuss it, #ubuntu-x is probably the best place.
[03:03] <Plagman_> ScottK : alright, thanks
[03:03] <Plagman_> I'll be sure to check the most recent packages
[03:38] <Kurlon> Evening all.
[03:40] <Kurlon> Is the nvidia driver conflict with xorg-server resolved at this point in the lucid repositories, or is it still glitching?
[03:41] <ScottK> Kurlon: #ubuntu-x is a better channel to ask.
[03:42] <Kurlon> Ah, ok, figured given I was mucking with an alpha #dev would be the safer start.  I'll ping in there instead, danke!
[05:18] <jelmer> ScottK, hi
[05:18] <ScottK> Hello jelmer
[05:18] <jelmer> ScottK: So, I'm trying to get bzr-svn to understand the KDE svn repository a bit better. Is there a description of the structure of the repository somewhere?
[05:19] <ScottK> jelmer: Not particularly, but with the exception of the kdebase split, it follows the Debian packages pretty closely.
[05:19] <ScottK> The getting started page I linked to explained it a little bit.
[05:20] <ScottK> The other thing you need to know is that there are roughly four catagories of software there:
[05:20] <ScottK> 1.  KDE core
[05:21] <ScottK> 2. KDE support (stuff needed to build KDE core, but not KDE specific (akonadi is an example))
[05:21] <ScottK> 2.  Extragear - Applications that aren't part of KDE core, but have a certain quality, stability, etc.  May or may not follow the KDE release schedule
[05:22] <ScottK> 4.  Playground - could be anythings.
[05:22] <ScottK> 2/3 on extragear
[05:22] <jelmer> ScottK: I'm basically trying to come up with patterns for things that should be considered branches in bzr
[05:22] <ScottK> For KDE core it's pretty easy
[05:23] <ScottK> Everything in the branches directory is a branch off of trunk
[06:33] <dholbach> good morning
[06:34] <hyperair> how does one get bug triaging powers?
[06:35] <hyperair> like the power to set the bug status to triaged
[06:36] <maco> hyperair: join bug control
[06:36] <hyperair> ah okay
[06:36] <dholbach> https://wiki.ubuntu.com/UbuntuBugControl
[06:36] <hyperair> thanks
[06:36] <hyperair> That you promise to be polite to bug reporters, even if they don't deserve it, by signing the Ubuntu Code of Conduct.
[06:37] <hyperair> ..oh hey i've violated that already
[06:37] <hyperair> more than once.
[06:37]  * hyperair repents
[07:57] <pitti_> bonjour
[07:57] <slangasek> b'jou
[07:58] <ttx> pitti: bonjour
[07:59] <ttx> pitti: about the new work item reports -- how do you determine someone is in a given team ?
[07:59] <ttx> pitti: soren is currently on loan in the QA team, and his work items clutter our alpha2 report :P
[08:00] <pitti_> ttx: it reads the members from LP
[08:00] <pitti_> ttx: hang on, rickspencer3 doing his opening speech
[08:00] <ttx> sure
[08:00] <ttx> He is doing it in French, I hope.
[08:13] <ttx> mvo: hey, about bug 494499, do you plan to release it for alpha2 ?
[08:13] <mvo> ttx: yes, I upload today, sorry for the delay
[08:14] <ttx> mvo: no pb, just making sure it will land, since it's still in the current dailies :)
[08:30] <ttx> pitti, cjwatson, slangasek: same issue as yesterday, please trigger a server CD respin, newest eucalyptus landed too late
[08:31] <ttx> slangasek: we now have on servers (hardware permitting) a graphical KSM-flicker-free Ubuntu logo. However it's not replaced by a login prompt at the end. The logo stays there until you swap VTs. I'd say that's a bug, but what should I file it against ?
[08:32] <slangasek> ttx: as a starting point, 'plymouth'
[08:32] <slangasek> server respin triggered
[08:32] <ttx> slangasek: thx
[08:38] <ttx> slangasek: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/506297
[08:40] <ttx> slangasek: I milestoned it to alpha2, I think we should at least try to fix it.
[08:42] <slangasek> ttx: nack; this behavior change was prompted by serious incompatibilities with plymouth's VT handling prior to this point, and Keybuk has limited availability this week - I'm afraid this is errata territory
[08:43] <ttx> slangasek: ok, alpha3 it is, then ;)
[08:43] <slangasek> yep - sorry :)
[08:44] <ttx> slangasek: anything I should do to make it appear on the errata ?
[08:44] <slangasek> ttx: add it to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview directly? :)
[08:44] <ttx> slangasek: right :)
[09:04] <seb128> hello
[09:04] <seb128> so today's upgrades are a fail in lucid there
[09:04] <seb128> the mini10 displays what seems to be plymonth and then no screen
[09:04] <seb128> no way to vt switch and I don't manage to open the grub2 menu
[09:04] <seb128> and my laptop has no x cursor displayed
[09:04] <seb128> it works since I can click on things but I don't see it
[09:04] <seb128> and compiz is broken
[09:05] <seb128> did plymouth broke xorg or something?
[09:05] <seb128> where is Keybuk? ;-)
[09:05] <slangasek> "don't manage to open the grub2 menu"?
[09:05] <slangasek> holding down shift?
[09:05] <seb128> oh, shift
[09:05] <seb128> I tried esc and tab
[09:06] <seb128> thanks
[09:06] <seb128> what was wrong with the good old esc? ;-)
[09:07] <seb128> hum, booting without splash doesn't fix the issue
[09:07] <seb128> did the x guy broke the intel driver or something?
[09:08] <slangasek> there've been mesa changes in the past couple of days
[09:08] <slangasek> the X driver itself hasn't been touched, and isn't that the kernel's job now anyway? :)
[09:08] <seb128> it's weird that I don't get vts either
[09:09] <seb128> can I turn kms off from grub?
[09:10] <slangasek> yes, i915.modeset=0
[09:10] <slangasek> (IIRC)
[09:10]  * alkisg is also interested in this, as he has an intel based thin client which broke with today's updates...
[09:10] <seb128> Xorg.0.log says that "glx doesn't exist"
[09:10] <seb128> wth?
[09:10] <seb128> tjaalton, bryyce: ^
[09:11] <slangasek> seb128: ls -l /etc/alternatives/gl_conf?
[09:11] <slangasek> (this is the mesa stuff I mentioned)
[09:11] <seb128> $ ls -l /etc/alternatives/gl_conf
[09:11] <seb128> lrwxrwxrwx 1 root root 24 2010-01-12 02:46 /etc/alternatives/gl_conf -> /usr/lib/mesa/ld.so.conf
[09:11] <slangasek> and that file is present?
[09:11] <seb128> yes and contains "/usr/lib/mesa"
[09:12] <alkisg> slangasek: thanks, i915.modeset=0 did the trick for me.
[09:12] <slangasek> seb128: ldconfig -p | grep libGL?
[09:12] <MacSlow> bryyce, still/already up?
[09:12] <slangasek> alkisg: sure thing
[09:12] <seb128> trying to turn kms off on the mini now
[09:12] <seb128> $ ldconfig -p | grep libGL
[09:12] <seb128> 	libGLU.so.1 (libc6) => /usr/lib/mesa/libGLU.so.1
[09:12] <seb128> ...
[09:12] <MacSlow> hm... guess I join the right conversation here
[09:12] <bryyce> MacSlow, are you pinging me?
[09:12] <seb128> anything special you want there?
[09:13] <seb128> bryyce, I did
[09:13] <MacSlow> bryyce, just see all folks here are talking about the GLX-issue
[09:13] <seb128> bryyce, the mini10 doesn't boot since this night update
[09:13] <seb128> blank screen
[09:13] <seb128> and glx is broken on my laptop
[09:13] <seb128> cf running discussion
[09:13] <seb128> all intel cards
[09:13] <seb128> i965 on the laptop
[09:14] <MacSlow> seb128, here too... what I see/know... apps using dlopen("libGL") work (e.g. chromium with WebGL enabled, doom3) but apps using normal GLX (glxinfo, glxgears, compiz) don't
[09:14] <MacSlow> seb128, on nvidia-glx-195 here
[09:14] <bryyce> MacSlow, it is the mesa alternatives system rework probably
[09:14] <bryyce> https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/258038
[09:15] <seb128> good timing with alpha2 freeze today ;-)
[09:15] <seb128> bryyce, what would be useful in a bug report?
[09:15] <seb128> I'm not sure what info to provide there...
[09:15] <slangasek> bryyce: what's supposed to provide the actual GLX /extension/ for X?
[09:16] <slangasek> is that built into the core server?
[09:16] <bryyce> slangasek, for open source drivers, mesa provides it; for closed source it is the closed source drivers providing it
[09:16] <slangasek> bryyce: yah, mesa isn't providing it now
[09:16] <slangasek> er, no
[09:16] <slangasek> $ dpkg -S /usr/lib/xorg/modules/extensions/libglx.so
[09:16] <slangasek> xserver-xorg-core: /usr/lib/xorg/modules/extensions/libglx.so
[09:16] <slangasek> $ ls -l /usr/lib/xorg/modules/extensions/libglx.so
[09:16] <slangasek> ls: cannot access /usr/lib/xorg/modules/extensions/libglx.so: No such file or directory
[09:16] <slangasek> so something deleted my libglx.so \o/
[09:18] <bryyce> that's weird
[09:18] <slangasek> by "something" I'm pretty sure I mean "mesa"
[09:19] <superm1> MacSlow, if you are using a binary package nvidia-glx-195, that means that it wasn't one of the packages that was enabled for that alternatives system yet
[09:19] <superm1> MacSlow, you should switch to nvidia-current (which is complete in the archive currently)
[09:19] <MacSlow> slangasek, fyi I'm you example-case for someone using nvidia-glx-195 and being affected by this
[09:19] <seb128> superm1, and for those who use intel?
[09:19] <bryyce> xserver-xorg-core.postinst.in:    --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/standard-x11/libglx.so \
[09:19] <slangasek> MacSlow: ah, ack
[09:20] <seb128> bryyce, the actual file has been deleted, did it move between binaries recently?
[09:20] <MacSlow> superm1, oh nvidia-current... didn't know about that new package-name
[09:20] <seb128> bryyce, hum or not
[09:20] <superm1> MacSlow, the official packages should have transitioned you over, but -195 was never in the archive (and neither was -190)
[09:21] <superm1> seb128, for -intel, things should be working ;)
[09:21] <seb128> bryyce, that code is not in the postinst
[09:21] <seb128> $ grep glx /var/lib/dpkg/info/xserver-xorg-core.postinst
[09:21] <seb128> $
[09:21] <slangasek> seb128: version?
[09:21] <seb128> ii  xserver-xorg-core                     2:1.7.3.902-1ubuntu4                       Xorg X server - core server
[09:22] <slangasek> ok
[09:22] <slangasek> bryyce: are you around to follow that up, or do we need tjaalton ?
[09:22] <seb128> did somebody forget to update the postinst from the .in?
[09:23] <slangasek> seb128: well, /usr/lib/standard-x11/libglx.so also doesn't exist here
[09:23] <seb128> hum
[09:23] <seb128> xorg-server (2:1.7.3.902-1ubuntu4) lucid; urgency=low
[09:23] <bryyce> slangasek, following up with tseliot would be best
[09:23] <seb128> "- Do not install an alternative any more. Mesa will deal with this.
[09:23] <seb128> "
[09:23] <seb128> bryyce, slangasek: ^
[09:23] <bryyce> seb128, what I pasted was from prior to this latest change
[09:23] <seb128> ok
[09:24] <bryyce> yeah probably follow up with tseliot when he wakes
[09:24] <superm1> slangasek, could you see why the mythbuntu live disk job didn't run yesterday? I don't even see a log at http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/lucid/
[09:25] <seb128> tseliot, !!!
[09:25] <seb128> hey ;-)
[09:25] <slangasek> tseliot: which package is supposed to be shipping extensions/libglx.so in the new world order?  Because it isn't
[09:26] <tseliot> slangasek: xserver-xorg-core
[09:26] <slangasek> superm1: the CD build job won't run if the livefs build failed; have you looked there?
[09:26] <tseliot> what happened?
[09:26] <seb128> tseliot, it doesn't
[09:26] <seb128> tseliot, libglx.so vanished
[09:26] <tseliot> let me check
[09:26] <seb128> tseliot, in yesterday's updates
[09:27] <superm1> slangasek, ah that's what's up.  i didn't realize that behavior changed. thanks :)
[09:27] <slangasek> superm1: ah yes, last cycle :)
[09:29]  * seb128 hates grub2
[09:30] <seb128> you would think it takes less that 15 tries to get the menu to open on boot
[09:30] <mr_pouit> superm1: I think I saw some testers write that hal wasn't started automatically in our iso for lucid, so xfce4-session, thunar & xfce4-power-manager were somewhat useless/broken. Did you have a chance to test?
[09:30] <slangasek> seb128: holding the shift key down?
[09:31] <slangasek> seb128: (more effective than trying to hit it at the right moment; part of why we the shift key was chosen)
[09:31] <superm1> mr_pouit, i've been poking at little installer snippets of troubles, so not yet any hal integration tests
[09:31] <seb128> slangasek, I will try on next boot, I was hitting shit a zillion time there
[09:31] <superm1> mr_pouit, you might run into a problem that xubuntu-default-settings needs to be reconfigured before you boot for the first time
[09:32] <superm1> mr_pouit, perhaps a ubiquity post install hook needs to be added
[09:32] <seb128> bryyce, tseliot: yesterday's update made the mini10v boot with screen off too
[09:32] <seb128> bryyce, tseliot: it works when turning off kms
[09:32] <seb128> bryyce, tseliot: which component would be right to bug?
[09:33] <tseliot> seb128: is it plain ubuntu or the netbook remix?
[09:35] <tseliot> slangasek: the extensions are definitely there. Can I see an X log, please?
[09:35] <seb128__> re
[09:36] <tseliot> I think it's because X looks for them in a different directory first
[09:36] <slangasek> tseliot: no, the file is physically *not there* on our systems
[09:36] <seb128__> grrr
[09:36] <slangasek> I don't have an X log for this, I haven't restarted X yet
[09:36] <slangasek> tseliot: so something deleted it on upgrade
[09:36] <seb128__> bryyce, tseliot: did you get my mini question?
[09:36] <seb128__> today's update make that on have screen off on boot
[09:36] <seb128__> it works without kms though
[09:36] <tseliot> seb128__: is it plain ubuntu or the netbook remix?
[09:37] <seb128__> lucid stock
[09:37] <slangasek> tseliot: it's still registered with dpkg (dpkg -S knows what package owns it), but something removed it
[09:37] <seb128__> I use it as a bootchart box
[09:37] <tseliot> slangasek: I extracted the package and the files are there.
[09:37] <slangasek> yes
[09:37] <tseliot> aah
[09:37] <seb128__> is there an another package Replacing it?
[09:37] <tseliot> no, I don't think so
[09:37] <seb128__> could be a replaces, update race
[09:37] <seb128__> ok...
[09:37] <tseliot> let me check on my testing box
[09:38] <seb128__> tseliot, which component is the right one to bug for the mini bug?
[09:38] <seb128__> tseliot, it's not linux, boot an old version doesn't work
[09:38] <seb128__> and booting without splash doesn't work
[09:38] <seb128__> turning off kms does work though
[09:39] <pitti> (removed the locale-gen stuff)
[09:39] <tseliot> seb128__: what do you mean by "the screen is off"?
[09:39] <seb128__> tseliot, nothing is displayed
[09:39] <tseliot> just to be clear
[09:39] <seb128__> no VT, no xorg
[09:40] <tseliot> aah
[09:40] <seb128__> I just see plymonth and then nothing
[09:40] <seb128__> plymouth
[09:40] <slangasek> oh, you do see plymouth?
[09:40] <seb128__> booting without splash I see nothing
[09:40] <seb128__> slangasek, yes
[09:40] <seb128__> if I remove the "splash" boot option I see nothing though
[09:40] <seb128__> no text, no xorg
[09:41] <persia> (mention alpha 2 freeze)
[09:41] <slangasek> seb128__: "no text" - have you checked your other VTs?
[09:41] <slangasek> persia: ta
[09:41] <seb128__> slangasek, yes, as said
 no VT, no xorg
[09:41] <seb128__> slangasek, there are all blank
[09:41] <slangasek> ok
[09:47] <tseliot> seb128__: I think it's the same problem that slangasek reported
[09:48] <lool> tseliot: Hey, got a warning during nvidia-common upgrade yesterday due to some quoting issue in the .config script; I don't know which way to fix it
[09:48] <lool> Oh great timing
[09:48] <bryyce> lool, I think that bug was fixed now
[09:48] <slangasek> tseliot: seb128__ does have the same problem I mentioned, he was the one who brought it to my attention; but that doesn't explain lack of text consoles AFAICS
[09:48] <lool> tseliot: On line 11 of /var/lib/dpkg/info/nvidia-common.config
[09:49] <seb128__> tseliot, the glx issue lead to have no compiz on my laptop
[09:49] <lool> tseliot: It was indeed; thanks
[09:49] <tseliot> np
[09:49] <seb128__> tseliot, but the mini get no screen content at all, either xorg or vt
[09:49] <seb128__> tseliot, and without kms it works...
[09:49] <lool> bryyce: Uh thank you too
[09:49] <bryyce> heh
[09:50] <tseliot> seb128__: I can reproduce it here with -ati
[09:51] <seb128__> tseliot, the boxes I'm using at all intel
[09:51] <seb128__> but good
[09:51] <seb128__> I will let you sort if it you have the issue locally ;-)
[09:51] <tseliot> I'll let you know when it's fixed
[09:51] <seb128__> thanks
[09:55] <tseliot> seb128, slangasek: does reinstalling xserver-xorg-core solve the problem?
[09:55] <slangasek> tseliot: I'm sure it will; but first I'm trying to see if I can reproduce the upgrade failure path
[09:55] <slangasek> (so I can understand what happened, which currently I don't)
[09:56] <tseliot> neither do I :-/
[09:58] <slangasek> the old prerm should have triggered before unpack of the new package, so there shouldn't have been any weird interaction between update-alternatives and dpkg
[09:58] <seb128> slangasek, well they moved the alternative handling to a different binary now
[09:59] <seb128> could that create some races between alternative and xorg upgrade?
[09:59] <slangasek> seb128: I don't see any alternative handling at all for libglx.so on my system
[09:59] <seb128> like the alternative is registered first
[09:59] <seb128> then xorg is update
[09:59] <slangasek> unless it was in an earlier version of mesa and removed again?
[09:59] <seb128> and the binary get cleaned?
[09:59] <tseliot> the alternatives were handled by X while they there are handled by mesa
[10:00] <slangasek> tseliot: is there still an alternative for libglx.so?
[10:00] <tseliot> slangasek: no, there isn't.
[10:01] <tseliot> now what happens is that X looks for extensions in /usr/lib/xorg/extra-modules first and then in /usr/lib/xorg/modules/extensions/
[10:01] <tseliot> so that when /usr/lib/xorg/extra-modules (which is a link created by alternatives) points to, say, /usr/lib/nvidia-current
[10:02] <tseliot> the modules in that directory will have a higher priority
[10:02] <tseliot> while the standard modules remain in their old directory
[10:03] <tseliot> if the link doesn't exist and/or the modules aren't in /usr/lib/xorg/extra-modules, it falls back to /usr/lib/xorg/modules/extensions/
[10:03] <tseliot> this, however, doesn't explain why those modules were removed in the first place :-/
[10:03] <alkisg> apt-get install --reinstall xserver-xorg-core fixed the problems for me.
[10:06] <tseliot> right
[10:08] <seb128> pitti, could you run "grep libglx /var/lib/dpkg/info/*" since you didn't upgrade yet?
[10:09] <tseliot> slangasek: hopefully the apt, dpkg, etc. logs will give us some clues
[10:09] <pitti> /var/lib/dpkg/info/xserver-xorg-core.list:/usr/lib/standard-x11/libglx.so
[10:09] <pitti> /var/lib/dpkg/info/xserver-xorg-core.md5sums:465cb23fcebef8712baf1b9c70453d3b  usr/lib/standard-x11/libglx.so
[10:09] <pitti> /var/lib/dpkg/info/xserver-xorg-core.postinst:    --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/standard-x11/libglx.so \
[10:09] <pitti> seb128: ^
[10:09] <slangasek> so far I know that I had xserver-xorg-core 2:1.7.3.902-1ubuntu1 installed when I last restarted X, upgraded to 2:1.7.3.902-1ubuntu4 directly, and the file is now gone; and that mesa and X were upgraded in the same run
[10:09] <pitti> I have 2:1.7.3.902-1ubuntu2
[10:09] <slangasek> and that an upgrade of just the X server from 1ubuntu1 to 1ubuntu4 doesn't reproduce the failure
[10:09] <slangasek> examining my unpack order now
[10:10] <seb128> pitti, thanks, so maintainer script playing with that on upgrade...
[10:10] <slangasek> seb128: that's the postinst of the old version
[10:10] <seb128> slangasek, right, I was try to check if some prerm or something played with that
[10:10] <slangasek> the relevant script there is actually the prerm of the old version, which doesn't pattern-match because it calls update-alternatives --remove with only the master name (gl_conf)
[10:11] <seb128> oh right
[10:11] <seb128> pitti, grep gl_conf /var/lib/dpkg/info/*
[10:11] <seb128> pitti, can you try that one too?
[10:11] <tseliot> libglx.so and libdri.so were previously installed in /usr/lib/standard-x11/
[10:12] <seb128> slangasek,
[10:12] <seb128> /var/lib/dpkg/info/libgl1-mesa-glx.prerm:  update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
[10:12] <seb128> slangasek, would that delete the file if called after the xorg unpack?
[10:12] <tseliot> seb128: does reinstalling xserver-xorg-core solve the problem for you?
[10:12] <seb128> tseliot, let met try on the mini, I want to keep my laptop in broken state to try the official solution
[10:13] <slangasek> seb128: I don't know yet - I think it /should/ not, because X's own prerm should have already removed it
[10:13] <slangasek> oh
[10:13] <slangasek>   if [ ! -f /usr/lib/standard-x11/standard.conf ]; then
[10:13] <slangasek>     update-alternatives --remove gl_conf /usr/lib/standard-x11/standard.conf
[10:13] <slangasek>   fi
[10:14] <slangasek> well that check is going to fail, because it's in the *pre*rm, so the files is still there
[10:14] <pitti> /var/lib/dpkg/info/xserver-xorg-core.postinst:    --install /etc/ld.so.conf.d/GL.conf gl_conf /usr/lib/standard-x11/ld.so.conf 500 \
[10:14] <pitti> /var/lib/dpkg/info/xserver-xorg-core.prerm:    update-alternatives --remove gl_conf /usr/lib/standard-x11/standard.conf
[10:14] <pitti> seb128: ^
[10:14] <seb128> pitti, thanks
[10:14] <slangasek> so the xserver-xorg-core old prerm does *not* remove the alternative; instead it gets removed by something else, later
[10:15] <slangasek> tseliot: this needs to be fixed by adding an update-alternatives --remove call to the xserver-xorg-core preinst
[10:15] <tseliot> slangasek: ouch, right
[10:15] <tseliot> ok, I can do that
[10:15] <slangasek> tseliot: thanks - how soon do you think you'll have it ready?  (I'd like to confirm the result before nodding off :)
[10:16] <tseliot> slangasek: minutes?
[10:16] <pitti> StevenK: just to be sure, you didn't rename lp:~ubuntu-core-dev/ubuntu-seeds/unr.lucid/ right? still the same seed
[10:16] <slangasek> tseliot: cheers :)
[10:17] <seb128> tseliot, the xserver-xorg-core reinstall solves the issue yes
[10:17] <pitti> StevenK: nevermind me, found it
[10:17] <seb128> tseliot, the mini10 no screen issue too
[10:18] <tseliot> seb128: aah, the joys of KMS... :-P
[10:18] <seb128> ;-)
[10:20] <tseliot> slangasek: do you want me to test a particular condition before passing that command?
[10:20] <slangasek> tseliot: a version check on $2
[10:20] <slangasek> tseliot: if dpkg --check-versions "$2" lt-nl 2:1.7.3.902-1ubuntu5; then
[10:21] <slangasek> superm1: what did you learn regarding mythbuntu livefs failures?
[10:22] <tseliot> dpkg: unknown option --check-versions
[10:22] <persia> Is it "check-versions"?  I thought it was "compare-versions"
[10:22] <tseliot> yes, if that's what he meant
[10:22] <tseliot> to check
[10:23] <tseliot> I can do what I usually do with nvidia
[10:24] <slangasek> yeah, that's what I meant
[10:24] <slangasek> sorry, 2am fingers
[10:34] <tseliot> slangasek, persia: does dpkg --compare-versions get the version of a package if you pass it a name?
[10:34] <tseliot> shouldn't I pass it the version instead?
[10:34] <slangasek> tseliot: the "$2" is a version
[10:35] <slangasek> dpkg --compare-versions knows nothing about packages, it just tells you how two specified version numbers compare
[10:35]  * tseliot needs some glasses now ;)
[10:35] <tseliot> or more sleep
[10:35] <persia> tseliot: http://women.debian.org/wiki/English/MaintainerScripts
[10:36] <tseliot> persia: ok, it was as I thought
[10:36]  * slangasek notes the diagrams on that page didn't load for him today :(
[10:39] <tseliot> slangasek: http://pastebin.ubuntu.com/355429/
[10:39] <tseliot> ok?
[10:41] <tseliot> I'll take it as a yes ;)
[10:43] <slangasek> tseliot: yes
[10:43] <slangasek> (I'm a little hesitant about the || true, but as a first iteration this is certaintly fine)
[10:44] <tseliot> I don't want things to break, but yes
[10:44] <pitti> StevenK: FYI, we'll use lp:ubuntu/ubuntu-netbook-default-settings and commit stuff there (didn't find an existing bzr for this)
[10:44] <tseliot> slangasek: uploaded
[10:45] <slangasek> tseliot: thanks!
[10:45] <tseliot> oh, I forgot to give credit to you in the changelog
[10:45] <tseliot> sorry
 :)
[10:45] <bryyce> I see we have Recommends: intel-gpu-tools in xserver-xorg-video-intel, and a MIR was accepted for intel-gpu-tools, however:
[10:45] <bryyce> # apt-cache madison intel-gpu-tools
[10:45] <bryyce> intel-gpu-tools |    1.0.2-1 | http://us.archive.ubuntu.com lucid/universe Packages
[10:45] <slangasek> tseliot: my name is in enough changelogs already, don't sweat it ;)
[10:45] <bryyce> why's intel-gpu-tools still in universe?
[10:45] <tseliot> hehe
[10:46] <slangasek> bryyce: because http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - allow me to fix :)
[10:46] <bryyce> tseliot, slangasek's name is *everywhere*
[10:46] <bryyce> slangasek, awesome
[10:47] <tseliot> :-D
[10:48] <slangasek> bryyce: btw, please don't close MIR bugs upon seeding, it makes it harder for the archive admin to find the bug to reference for promotion :)
[10:48] <bryyce> oh
[10:48] <tseliot> then the next ubuntu flavour will be slangabuntu :-P
[10:48] <bryyce> slangasek, I don't remember closing the bug, but apologies if I did
[10:49] <bryyce> slangasek, btw what I'm working towards is enabling apport auto-capture of X freeze bugs for -intel
[10:50] <bryyce> next step is a packaging fix for -intel to install the apport script.  I can wait until post-a2 unless you think it would be valuable to have for the release.
[10:50] <slangasek> well, I haven't seen an intel kernel freeze myself for quite a while
[10:51] <bryyce> :-)
[10:51] <slangasek> so based on my own limited evidence I wouldn't think it's urgent for a2 - does the bug traffic say otherwise?
[10:51] <bryyce> fair enough, sounds reasonable to leave this until post-a2.  I've not yet confirmed it works.
[10:52] <bryyce> slangasek, I've decided there exist a band of merry gnomes who simply re-file the same 20 bugs over and over again, with slightly changed wording each time.
[10:52] <slangasek> (now having the sigsegv handler working, OTOH, /that/ would be nice :)
[10:52] <slangasek> heh
[10:53] <bryyce> yeah, I put in a patch to fix that but seems I didn't get something right.  I need to look at that deeper.
[10:53] <bryyce> the signal code in X changed around quite a bit, and I never really grokked it all the first time
[10:59] <tseliot> pitti: can you rescore this please? https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu5/+build/1442023
[11:03] <pitti> tseliot: done; amd64 too, or already building?
[11:03] <pitti> oh, built already
[11:03] <tseliot> it's building already
[11:03] <pitti> i386 is screwed
[11:03] <pitti> kdeutils/linux/oo.o
[11:04] <pitti> ah, kdeutils is purging already
[11:04] <pitti> so, shouldn't take long then
[11:04] <tseliot> ah, good
[11:06] <tseliot> pitti: BTW the new jockey won't be ready in time for alpha2
[11:06] <pitti> tseliot: due to the pykdeuic4 breakage?
[11:06] <tseliot> I didn't have the time to test it
[11:06] <tseliot> yes
[11:06] <pitti> ah, for nvidia-common support
[11:06] <tseliot> that too
[11:06] <pitti> -> release notes, then
[11:06] <tseliot> but now nvidia-common is in
[11:06]  * tseliot nods
[11:07] <StevenK> pitti: That sounds great
[11:09] <cjwatson> Riddell,superm1: I have an action from the last TB meeting to ask that the ubuntu-core-dev team be added as a member of kubuntu-dev and mythbuntu-dev, to reflect the fact that they can upload to those packages anyway. Would you guys be OK with making that change?
[11:10] <cjwatson> seb128: what was wrong with esc in grub> I was instructed to make grub not have a delay to wait for a keypress, and on the PC architecture the only keys whose state you can check instantaneously are the modifier keys
[11:11] <tjaalton> seb128: the blank screen problem was likely due to vesa (=failsafe) not working on top of kms
[11:11] <seb128> cjwatson, yeah, sorry for the non constructive comment, the new way is not very discoverable and quite frustrating when you try to get the menu to open
[11:12] <Riddell> cjwatson: ubuntu-core-dev has been invited to join, I guess something else needs to happen to actually join
[11:12] <seb128> I tried hitting all the side keys quickly and did that for several times without luck
[11:13] <cjwatson> seb128: I was told to make it undiscoverable, unfortunately :(
[11:13] <cjwatson> seb128: or rather I was given instructions that left no possible way to make it discoverable ...
[11:14] <seb128> cjwatson, I'm not sure that those small boot speed wins are an user experience win, but shrug
[11:14] <seb128> I'm not the one deciding
[11:14] <cjwatson> seb128: I agree, but ...
[11:14] <seb128> we have the same issue for desktop
[11:14] <seb128> we will likely need to drop some nice things to win a 1 second on boot
[11:15] <seb128> which in my opinion is not a win for user, I prefer to wait an extra second and have a system nicer to use
[11:15] <tseliot> cjwatson: pressing esc like crazy here doesn't seem to solve the problem i.e. I can't access the grub menu
[11:15] <seb128> tseliot, shift
[11:15] <cjwatson> tseliot: like I say, esc has no effect there
[11:16] <seb128> and you can keep it pressed
[11:16] <tseliot> oh, shift
[11:16] <tseliot> I missed that part then. I would have saved me a lot of swearing ;)
[11:16] <seb128> hehe
[11:16] <bryyce> tseliot, ditto
[11:16] <seb128> welcome to the club ;-)
[11:16] <bryyce> yeah it seems like esc should be supported as well as shift
[11:16] <cjwatson> Riddell: thanks, accepted
[11:16] <tseliot> :-)
[11:17] <cjwatson> bryyce: it's not possible, sorry
[11:17] <bryyce> cjwatson, why?
[11:17] <cjwatson> bryyce: 11:10 <cjwatson> seb128: what was wrong with esc in grub> I was instructed to make grub not have a delay to wait for a keypress, and on the PC architecture the only keys whose state you can check instantaneously are the modifier keys
[11:17] <bryyce> I see
[11:17] <cjwatson> if you make the delay non-zero, then esc works
[11:18] <cjwatson> I went through all this in the karmic cycle, this was about the best I could do, sorry
[11:18] <bryyce> too bad we can't just make ESC into a modifier key ;-)
[11:18] <cjwatson> pass the time machine
[11:18] <seb128> cjwatson, nobody is blaming you don't worry
[11:19] <tseliot> let's just document it then
[11:19] <tseliot> seb128: +1
[11:19] <seb128> I'm just blaming that boot speed crazyness
[11:19] <seb128> working on making sure we boot fast is a good idea
[11:19] <bryyce> seb128, yeah
[11:19] <seb128> but it should not be in detriment of the user experience
[11:20] <bryyce> we had to sacrifice wacom on the bootspeed altar
[11:20] <tseliot> bryyce: what???
[11:20] <bryyce> well, wacom-tools at least ;-)
[11:20] <cjwatson> I think this is a symptom of a broader issue: "user experience" is always taken to mean utter novices
[11:20] <tseliot> bryyce: because of the halsectomy?
[11:20] <bryyce> tseliot, yeah
[11:21] <cjwatson> there's no thought for the upward learning curve, escape hatches, etc.
[11:21] <cjwatson> seb128: oh, one thing you might like to know: if the system fails to boot, then grub2 will always show the menu next time round
[11:21] <seb128> right, but user experience should not just be what a new user will see on first boot when everything is working on standard hardware
[11:21] <bryyce> cjwatson, yep, and customer retention
[11:21] <cjwatson> seb128: so if you can't remember, just let the system start booting and immediately reboot :)
[11:21] <seb128> cjwatson, it didn't work in this case for some reason
[11:22] <cjwatson> seb128: odd
[11:22] <seb128> cjwatson, I did had to power off the box sitting on the power button to stop it
[11:22] <pitti> bryyce: hm, wacom was a victim of the hal deprecation, not the boot speed, wasn't it?
[11:22] <cjwatson> seb128: recent lucid?
[11:22] <seb128> and next boot didn't show the menu
[11:22] <pitti> speaking of that, hal is starting in recent lucid again, grr
[11:22] <seb128> cjwatson, yes, daily updated
[11:22] <cjwatson> seb128: ok, could be a regression in my most recent grub2 upload then
[11:22] <seb128> cjwatson, it usually works though, but I expect that video crash leaded to a state where the failed boot was not recorded
[11:23] <seb128> or the mini was to desktop before the 5 seconds sitting on power
[11:23] <tseliot> pitti: resistance to hal is futile :-P
[11:23] <seb128> so it registered as a working boot
[11:23] <bryyce> pitti, as was communicated to me, it was the bootspeed requirement which was the driver to eliminate hal
[11:23] <seb128> which is might have been, I just had no screen to see it
[11:23] <seb128> pitti, and it has a crasher
[11:24] <seb128> pitti, got an apport crash notification today and some users asked about that on -bugs too
[11:24] <slangasek> bryyce: halsectomy has been coming for a while; bootspeed made it happen before wacom had adapted
[11:24] <bryyce> slangasek, as I said :-)
[11:25] <pitti> bryyce: I thought there was a newer wacom release which doesn't need hal any more?
[11:25] <pitti> at least that's what the xorg-halsectomy blueprint says
[11:25] <tseliot> bryyce: if I can implement support for tags with udev and xorg.conf.d in time, things should be easier to deal with
[11:25] <cjwatson> seb128: it must be the latter - the way it works is that grub registers a failed boot, and that state is then cleared at the end of the boot sequence
[11:25] <pitti> seb128: "it" == ?
[11:25] <cjwatson> having to actively register a failed boot in userspace would be too fragile
[11:25] <seb128> cjwatson, ok
[11:25] <seb128> pitti, hald-probe-input
[11:26] <seb128> double free apparently
[11:26] <seb128> I didn't investigate just had a look to the apport summary
[11:26] <seb128> the bug was not retraced yet
[11:27] <bryyce> pitti, unless something changed in the last few days, the release is still "coming soon"
[11:27] <pitti> ah, fun
[11:27] <bryyce> pitti, but yeah likely we will get wacom working in time
[11:28] <seb128> pitti, bug #506260
[11:28] <tjaalton> bryyce: did you miss my email to ubuntu-x? ron released xf86-input-wacom
[11:28] <tseliot> slangasek: X was built 12 minutes ago, just FYI
[11:28] <tjaalton> with udev hotplug
[11:28] <tseliot> ah, right
[11:28] <seb128> pitti, or bug #500723
[11:29] <bryyce> tjaalton, wasn't there also some issues @ debian to resolve first?
[11:30] <tjaalton> bryyce: I don't know?
[11:31] <ion> Yay, i’ve been waiting for wacom fixage in lucid. :-) Why *is* there a wacom driver, btw, shouldn’t it be merged into evdev? Evdev already gets the coordinate information from my touchscreen perfectly, it would just need to recognize the buttons, touch pressure (and angle for the pads that support it).
[11:31] <tjaalton> haven't quite understood Thomas' post yet
[11:31] <bryyce> tjaalton, ok
[11:31] <bryyce> tjaalton, so "coming soon" in Ubuntu at least ;-)
[11:31] <tjaalton> ion: evdev doesn't, and never will, support the fancy features
[11:31] <seb128> pitti, btw new cheese in lucid uploaded
[11:31] <seb128> pitti, it uses gudev
[11:31] <pitti> seb128: I saw, thanks!
[11:31] <seb128> pitti, dunno if you keep a list of those somewhere
[11:31] <tjaalton> bryyce: yes, need to at least bump the epoch
[11:32] <seb128> pitti, you're welcome
[11:32] <tjaalton> otherwise ok
[11:32] <ion> tjaalton: I was under the impression evdev already contains axes for pressure, angle etc, it just doesn’t know how to read that information from a wacom device. I may be wrong.
[11:33] <tjaalton> ion: yeah, but stylus/eraser etc..
[11:33] <slangasek> tseliot: great, thanks
[11:34] <tseliot> pitti: also, can you remove envyng* from the archive, please?
[11:35] <pitti> seb128: tried to fix the lucid chroot, but new dash is terminally broken with fakechroot, so nevermind for now
[11:35] <pitti> seb128: (apport retracers)
[11:36] <pitti> tseliot: what should I put in as rationale? "superseded by jockey" or so?
[11:36] <seb128> ok
[11:36] <tseliot> pitti: yes, that would be fine
[11:37] <pitti> tseliot: done
[11:37] <tseliot> pitti: would it be possible to add transitional packages to jockey? (just to make sure that users don't keep envyng after dist-upgrades)
[11:37] <tseliot> thanks
[11:38] <tseliot> envyng-core was in universe though
[11:38] <seb128> tseliot, or use a conflicts, replaces, provides?
[11:39] <tseliot> seb128: whatever pitti prefers
[11:39] <tseliot> ;)
[11:39]  * tseliot has no strong opinions on this
[11:39] <pitti> I'm fine with adding a C/R/P
[11:39] <tseliot> ok then
[11:39] <pitti> tseliot: can you please commit?
[11:39] <tseliot> pitti: sure
[11:39] <pitti> we can't build it anyway, so no need to upload it right now
[11:40]  * pitti sighs at pykdeuic4
[11:40] <tseliot> pitti, Riddell: wasn't that updated ^^
[11:40] <tseliot> ?
[11:40] <tseliot> pykdeuic4, that is
[11:42] <tjaalton> pitti: there's a new -evdev available in unstable (uploaded ~10min ago). it'll work around the nasty problems with accelerometers, so syncing that for a2 is ok
[11:43] <pitti> tjaalton: please coordinate with slangasek; I have little mental bandwidth here at the sprint
[11:43] <tjaalton> pitti: ah, ok
[11:43] <tjaalton> will do
[11:43] <slangasek> tjaalton: and I'm about to pass out; file a sync request and drop me a pointer to the bug # for me to consider when I'm awake?
[11:44] <tjaalton> slangasek: ok, sounds good
[11:46] <Riddell> tseliot: kdebindings needs a new SIP which hasn't been released so I havn't been able to update it :(
[11:46] <hunger> Is there a reason for shipping /usr/lib/ld.so.conf or is that file just misplaced?
[11:53] <slangasek> ttx: UEC images are called 'server' now on the uec-images download site?  Is this an intended and permanent change?
[11:53] <tseliot> Riddell: oh, a new SIP? :-/
[11:55] <slangasek> ttx: (if so, I think it's unfortunate name collision with the server ISOs; but we at least need to get the ISO tracker and the weather report updated to know this)
[11:57] <Riddell> tseliot: yeah, it's not ABI compatible and I don't want to take a snapshot incase the final release has any more ABI changes
[12:01] <tseliot> Riddell: ok, no problem. I know that rebuilding kde every time is not a trivial task ;)
[12:13] <ttx> slangasek: i'm not sure what triggered it -- if there is no good reason it should be reverted, if only to allow already-written test scripts to continue working
[12:13] <ttx> slangasek: we'll ask smoser if he knows
[12:40] <ttx> pitti: arh
[12:41] <ttx> pitti: I missed your recent changes when uploading apport 1.11-0ubuntu5
[12:41] <pitti> ttx: np, it was just for setup-retracer; I only use that from the branch itself
[12:41] <pitti> ttx: please just move my changelog to ubuntu6 then
[12:42] <ttx> pitti: ok, will merge
[12:43] <davmor2> pitti: An issue I'm assuming due to plymouth has arisen in that there is no dialogue to press enter to continue shutdown once the install has completed
[12:44] <pitti> davmor2: the one in X? that shouldn't be related to plymouth
[12:44] <pitti> ah, the "press enter" after shutdown
[12:44] <ogra> pitti, the one that used to be in usplash
[12:44] <pitti> davmor2: can you please file a bug? (sorry, at sprint this week)
[12:45] <pitti> should be easy to fix, instead of usplash-send use the equivalent plymouth command
[12:45] <pitti> seb128: yay, I recreated the apport retracer environments in lucid, have working fakechroots now
[12:45]  * seb128 hugs pitti
[12:45] <seb128> you rock dude
[12:45] <davmor2> pitti: no probs I think it is in process now.  Is my assumption about it being plymouth correct and will the dialogue show up on a different tty?
[12:46] <pitti> I'm not sure; I'm a plymouth n00b
[12:46] <pitti> seb128: I didn't try retracing something yet; still remember the busted gdb -> busted stack traces that we had in jaunty?
[12:46] <seb128> yes
[12:47] <seb128> is that still an issue?
[12:47] <seb128> I think I downgraded gdb by then no?
[12:47] <davmor2> pitti: ta
[12:47] <pitti> seb128: right; I don't know if it's still an issue with latest gdb; I'll try
[12:48] <ttx> pitti: done, I didn't tag the release since it would be confusing ?
[12:48] <pitti> seb128: do you reckon we could shutdown the jaunty/karmic retracers for now?
[12:48] <pitti> ttx: you could tag the revision you uploaded
[12:49] <pitti> ttx: erm, nevermind
[12:49] <seb128> pitti, would be fine for me, nobody work actively on jaunty or karmic right now anyway and I doubt we get lot of new crashes there which are of interest
[12:52] <pitti> seb128: what I thought, but wanted to confirm
[12:52] <seb128> +1
[13:06] <persia> cjwatson: Thank you, as always, for the spellcheck.  I'll try to be more careful :)
[13:23] <zul> pitti: have you seen boris comment on the MIR autofs5 bug?
[13:25] <pitti> zul: yes, I saw it; seems fine
[13:25] <zul> pitti: so I should be able to go seed it correct?
[13:25] <pitti> zul: right; just didn't have time to process it further (I'm on a sprint this week, and was travelling yesterday)
[13:26] <zul> pitti: ah ok ill go seed it now then
[13:34] <zul> lool: ping
[13:37] <lool> zul: pong
[13:37] <zul> lool: i updated the ctdb package but im not sure how to fix the readdir warning
[13:39] <pitti> seb128: at least it properly identified 505219 as a dupe, so it can't be too broken
[13:40] <seb128> pitti, good ;-)
[13:40] <pitti> meh, so is the next bug
[13:40] <pitti> give me a fresh one..
[13:40] <pitti> at least it catches up with the backlog
[13:41] <lool> zul: Looking
[13:44] <lool> zul: So if you build ctdb, you see it fails a configure test for readdir
[13:44] <pitti> seb128: ok, I think gdb still hates me
[13:44] <lool> zul: Opening config.log and searching for that you'll find the cause of the issue
[13:44] <pitti> seb128: (bug 506125 )
[13:44] <lool> conftest.c:182:43: error: ./lib/replace/test/os2_delete.c: No such file or directory
[13:44] <pitti> I'll try with the old gdb
[13:44] <lool> zul: ./lib/replace/test/os2_delete.c doesn't exist, but ./lib/replace/tests/os2_delete.c does
[13:44] <seb128> pitti, :-(
[13:44] <lool> (s/test/tests)
[13:44] <seb128> pitti, let me know how it goes
[13:45] <zul> lool: ah ok..lemme have a look
[13:45] <lool> zul: This test is maintained in lib/replace/repdir.m4
[13:46] <lool> zul: I fixed the macro, but can't easily rerun autoconf for various reasons (apparently they miss some files and some vars) so I fixed configure manually as well; this fixed the warning
[13:47] <lool> configure:8134: checking for broken readdir
[13:47] <lool> configure:8160: result: no
[13:47] <lool> etc.
[13:47] <lool> zul: So just /os2_delete/s/test/tests/ in the lib/replace/repdir.m4 and configure
[13:48] <lool> Now it fails to build for me   :-(
[13:48] <lool> dh_installdocs: You asked that all arch in(dep) packages be built, but there are none of that type.
[13:48] <lool> I built with -b
[13:48] <zul> ok ill try it from here
[13:49] <lool> zul: Will read you in the MIR then; thanks
[13:49] <zul> lool: thanks for the help
[14:00] <didrocks> cjwatson: do you plan to do an ubiquity update before alpha2? I've something to fix with une and other derivatives using gdm for default session ppa:canonical-dx-team/release but there is an easy workaround, so it can wait
[14:04] <cjwatson> didrocks: ev just uploaded one today
[14:04] <cjwatson> didrocks: I don't know if there's more planned
[14:05] <ev> didrocks: patch?
[14:07] <didrocks> cjwatson: ev: ok, it's just that the default session is not available on installed system. (only on the live image) as postinst aren't executed. So, will need to launch a command to update it if want une/xubuntu/mythubuntu as a default after reboot. Nothing important for alpha2 btw
[14:11] <pitti> didrocks: could you add the workaround to the tech notes?
[14:21] <zul> pitti: one more thing for psycopg2 you need to confgiure a postgresql database in order to run the testsuite since it tries to login as root
[14:21] <pitti> zul: as root? that's strange; why doesn't it just connect as your user?
[14:22] <zul> pitti: no idea
[14:22] <zul> pitti: anyways we are fixing it in alpha3
[14:25] <didrocks> pitti: done
[14:36] <zul> lool: the latest upload fixes the readdir warnings for ctdb
[14:37] <pitti> seb128: retracers!
[14:38] <seb128> pitti, waouh!
[14:39] <pitti> seb128: I leave the jaunty/karmic ones disabled for now, no time to spend on that right now
[14:39] <seb128> ok
[14:40] <lool> zul: Ouch, I see you added a patch to hide the gcc warnings, but that's actually worse than the warnings in the first place
[14:41] <lool> zul: The failures need to be handled; in the case of read/write, it might be interrupted IO and that need to be retried or it might be errors in which case that need to fail the higher order logic
[14:41] <zul> lool: *sigh*
[14:41] <lool> zul: If you just hide the warning by adding a dummy var and ignoring it, it's *worse* because we don't even know that the error code is ignored
[14:41] <zul> lool: ok because some of the comments in the code it doesnt matter if it overflows
[14:41] <ScottK> lamont: Looks like builds aren't being dispatched on at least sparc and ia64 for some reason.
[14:42] <cjwatson> if it doesn't matter, arrange for the warning not to trigger in code, rather than by changing gcc options
[14:42] <lool> zul: Ok; if that's the case, you can add a dummy var /with a comment/ explaining that it's fine to ignore it
[14:42] <cjwatson> (maybe I'm misunderstanding)
[14:42] <zul> lool: ok ill go back at it then
[14:42] <lool> cjwatson: The change is a patch which saves the return code of the failing calls, but doesn't use the value
[14:43] <lool> cjwatson: http://paste.ubuntu.com/355533/
[14:43] <lool> zul: IOW what we want is safer software, not less warnings  ;-)
[14:43] <lool> zul: Thanks for looking into it
[14:43] <zul> lool: np
[14:44] <smoser> slacker_nl, ping
[14:44] <ttx> smoser: fail
[14:44] <cjwatson> I prefer 'if (read(...) < 0) { /* comment explaining why we're ignoring it */ }'
[14:44] <smoser> gah
[14:44] <smoser> slangasek, ping
[14:44] <smoser> sorry slacker_nl
[14:44] <slacker_nl> smoser: :)
[14:44] <ScottK> lamont: Actually flow is OK.  It's just hooker
[14:45] <ScottK> flow/floe
[14:46] <smoser> regarding <suite>-uec-<arch>  to <suite>-server-<arch>.tar.gz , the change was intentional, do deal with the fact that we now have 'desktop' image also.
[14:46] <smoser> i can absolutely change that to <suite>-<build_name>-uec-<arch> though
[15:01] <cjwatson> pitti: TB meeting?
[15:24] <pitti> argh, tseliot, help: since the last dist-upgrade I get an error "Failed to submit batchbuffer: Input/output error" and X is black
[15:24] <pitti> tseliot: could that be related to recent X.org changes?
[15:25] <pitti> cjwatson: finally managed to get online over CLI; sorry for delay
[15:25] <tseliot> pitti: does reinstalling xserver-xorg-core help?
[15:27] <pitti> tseliot: reinstalled, I'll try now
[15:28] <pitti> tseliot: should that change any files or so? anything I could test before starting X again? (that will mean a reboot and maually getting on the wifi again)
[15:28] <pitti> tseliot: it happened to didrocks as well
[15:28] <tseliot> pitti: you should have libglx.so and libdri.so in /usr/lib/xorg/modules/extensions
[15:29] <tseliot> if they are there, then it's ok
[15:29] <pitti> tseliot: I do
[15:29] <pitti> tseliot: ok, trying
[15:30] <cjwatson> pitti: thanks
[15:32] <pitti> tseliot: that worked
[15:32] <pitti> tseliot: thanks!
[15:33] <tseliot> pitti: good. BTW it's fixed in ubuntu5
[15:33] <tseliot> np
[15:33] <pitti> tseliot: I had that before, too
[15:33]  * tseliot -> dentist
[15:33] <tseliot> weird
[15:33] <tseliot> you might want to tell slangasek about that
[15:33] <pitti> tseliot: dentist> good luck
[16:14] <pitti> does anyone remember how to force the version of a single binary package? IIRC it was some trick to pass a version as an argument to dpkg-deb or so
[16:16] <davmor2> Guys on today's iso once installed with eng-uk locale evolution is removed
[16:17] <seb128> pitti, sudo apt-get install binary=version
[16:17] <pitti> seb128: no, I mean during source package build
[16:17] <seb128> oh
[16:17] <seb128> I don't know
[16:20] <pitti> ah, dpkg-gencontrol -v
[16:26] <lamont> ScottK: yeah - sometimes it doesn't like it when I upgrade the buildd... sigh
[16:40] <cr3> pitti: hi there, if you have a moment, I have a quick dbus problem which I suspect you might've seen already
[16:41] <pitti> cr3: (on sprint, and in a meeting); perhaps /msg me, and I'll answer later?
[16:41] <cr3> pitti: this is by no means urgent, so I'll send an email and feel free to answer at your convenience. thanks!
[16:51] <zul> lool: it should be ok now
[17:09] <ion> If i have ‘LP: #NNNN’ in debian/changelog for something that’s going to be uploaded, and the bug in question has been marked a duplicate of another bug #MMMM, will the upload mark #MMMM as fixed?
[17:09] <ccheney> wow the kernel really slowed down recently
[17:10] <ccheney> takes twice as long in the recent bootcharts
[17:43] <smoser> james_w, does something need to be kicked such that lp:ubuntu/ec2-init get updated? its been a dozen hours at least since the last upload
[17:43] <smoser> https://code.launchpad.net/ubuntu/+source/ec2-init
[17:54] <pitti> didrocks: deb http://ppa.launchpad.net/gm-dev-launchpad/ppa/ubuntu karmic main
[18:00] <tweakt> Is there an all in one tool which combines apt-move and apt-ftparchive?
[18:01] <tweakt> I'm trying to string together germinate, apt-get (download packages) and apt-move/apt-ftparchive to produce a mirror from a set of dependencies (seeds)
[18:03] <sladen> tweakt: perhaps germinator -> apt-mirror
[18:07] <tweakt> ahh, right. I will check it out.
[18:12] <tweakt> sladen: it looks like it can only produce a full or partial mirror, not accept a specific list of packages (and versions). Where I'm at now, I've already got a directory full of .debs that are needed. I just need to poolify them and generate the Packages files.
[18:14] <sladen> tweakt: the directory structure of the pool doesn't matter;  you could even have them in the same directory as the Packages files
[18:15] <tweakt> sladen: even for CD install?
[18:15] <tweakt> oh, yeah... good point.
[18:16] <tweakt> just put them all in /pool ?
[18:16] <superm1> cjohnston, okay i've invited ubuntu-core-dev
[18:17] <superm1> slangasek, things are sorted out now, it was because some stuff hadn't exited NEW yet
[18:18] <cjwatson> superm1: thanks
[18:32] <james_w> smoser: it does, yes. I'm going to try and get to it before the sprint starts this morning
[18:32] <smoser> ok. thanks.
[18:41] <kirkland> is anyone else having trouble running today's lucid-desktop-amd64.iso in a kvm?
[18:41] <kirkland> seems to be hanging the vm hard
[19:33] <highvoltage> mdz: have most people now at least casted their votes for the developer board?
[19:34] <ion> http://bazaar.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/revision/259#debian/changelog :-P
[20:30] <alkisg> chrisccoulson, hi, could I do something more to help in getting the patch for ltsp clients reboot/shutdown accepted? (LP #491940)
[20:31] <alkisg> I tested again the patch today, it works fine.
[20:32] <humphreybc> Hi all - I'm Benjamin Humphrey, head of the Ubuntu Manual project and I've got some questions about the Software Center in Lucid.
[20:32] <cjwatson> humphreybc: you probably want to wait until European working hours, for either mpt or mvo or both to be around.
[20:33] <humphreybc> Hmm.. I've only really got one question regarding the roadmap for Lucid - whether Software Center is planning to completely replace Synaptic
[20:33] <humphreybc> The wiki says "For Ubuntu 10.04 LTS, we plan to: Make the Ubuntu Software Center a viable alternative to Synaptic — presenting non-application packages in an understandable way, and allowing the same fine-grained package control and handling of error cases."
[20:33] <humphreybc> Whether "viable" means that Synaptic will be removed from the CD or not, I'm not 100% sure.
[20:36] <cemc> hi. could you take a look at this please? bug #96850 (last comment)
[20:37] <humphreybc> Does anyone know either mpt or mvo's email address?
[20:37] <cjwatson> humphreybc: should be on the appropriate people pages on Launchapd
[20:37] <cjwatson> Launchpad
[20:38] <beuno> humphreybc, https://edge.launchpad.net/~mpt and https://edge.launchpad.net/~mvo
[20:38] <humphreybc> thanks guys
[20:38] <humphreybc> Hey he's a kiwi...? .net.nz
[20:39] <beuno> humphreybc, yes, but living in the uk
[20:39] <humphreybc> Oh neat
[20:39] <cjwatson> e-mail addresses aren't necessarily strongly correlated with where people live. :-)
[20:39] <humphreybc> (I'm a kiwi too)
[20:39] <humphreybc> heh, well, not many people use a .nz address for no reason :)
[21:27] <ari-tczew> I'm looking for sponsor for main ...
[21:27] <Laney> there is a queue for that
[21:28] <Laney> ™
[21:31] <slangasek> smoser: I think server-uec would be preferable.  And in general, please don't change image names without coordination, this information is tracked on https://wiki.ubuntu.com/LucidLynx/ReleaseManifest and used in a number of places
[21:32] <smoser> sorry for trouble
[21:32] <smoser> so you'd prefer just {server|desktop}-uec ?
[21:32] <smoser> or lucid-{server|desktop}-uec
[21:33] <slangasek> always lucid-*
[21:34] <slangasek> lucid-(server|desktop)-uec-<arch>
[21:34] <smoser> ok. i'll make that change.
[21:43] <komputes> Is anyone available to compare some stacktraces?
[21:44] <komputes> the crash/bug reports are the following 3:
[21:44] <komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613
[21:44] <komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/178038
[21:44] <komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/192270
[21:47] <micahg> komputes: I already said I'd do that later tongiht
[21:47] <komputes> micahg: yes you did, slangasek told me to post it here as well.
[21:47] <komputes> micahg: thanks in advance
[21:53] <TheMuso> argh! Something in lucid is causing my desktop to randomly reset, but I don't know what, and I can't find anything in logs to indicate what happens.
[22:09] <cjohnston> superm1: im not sure what your referring to?
[22:11] <superm1> cjohnston, sorry i pinged the wrong person.  there's not usually two people in here that start with cj , so  i can tab complete
[22:24] <tweakt_> is there any way I can make apt-move respect the overrides so stuff ends up where it's supposed to? I'm getting things in non-free/contrib, etc.
[22:25] <mdz> highvolt1ge, over 50% turnout now
[22:27] <highvoltage> mdz: it's kind of disappointing, I would think that more people would care. are you going to send some kind of poll to people who didn't vote so that they could specify why they didn't vote?
[22:27] <highvoltage> (glad that it's now over 50% at least)
[22:31] <highvoltage> I guess some people might feel that all candidates are good ones. Or perhaps some feel that they don't know the candidates well enough (which would be weird if they're a developer)
[22:33] <cjohnston> ok superm1.. thanks
[22:34] <cjwatson> highvoltage: I know I care and just haven't quite got round to voting yet
[22:56] <slangasek> zul: can you clarify what you meant in bug #445958 by "no longer being maintained"?  The package was removed from karmic, but has shown back up in lucid via auto-sync because it is maintained in Debian and there was a new version uploaded.  Is there really a reason to blacklist this package, or does it just need to be unseeded from server-ship (...which never happened when the package was removed from the archive)?
[23:43] <seb128> hum
[23:43] <seb128> kees, did you have any bug about the nautilus change you put to bzr?
[23:44] <kees> seb128: I don't, would you like me to make one for it?
[23:44] <seb128> kees, not especially, I was going to upload my indicator application change but my push failed now
[23:44] <seb128> kees, I'm not sure if I should try to squeeze your change in the upload or delay to after alpha now
[23:45] <kees> seb128: ah, sorry, feel free to bump my revision (it was non-urgent, so I was waiting for the freeze to clear)
[23:45] <seb128> kees, could you explain what it does exactly, did you send that upstream too?
[23:45] <kees> nah, just bump my stuff.  I'll be uploading a bunch of packages all for the same thing.  I'll go open a bug.
[23:45] <seb128> ok thanks
[23:46] <kees> seb128: upstream will almost certainly not take it -- their dialog is after months of internal debate.  Ubuntu Tech Board happens to just not agree with it.  :P
[23:46] <seb128> :-(
[23:46] <seb128> I tend to not like things starting by "upstream will almost certainly not" ;-)
[23:48] <kees> seb128: yeah.  I tried to deviate as little as possible.
[23:49] <seb128> I've not looked at the change yet, doing my update and cleaning bzr before
[23:49] <seb128> but in any case please open an upstream bug with rational
[23:49] <seb128> to avoid having they unhappy about distro change not sent upstream, etcv
[23:50] <seb128> if they don't take it fine but at least we did have the discussion there
[23:50] <kees> I can, but it'll basically be reopening an old bug that they think is fixed already
[23:50] <kees> okay, I'll do it.
[23:50] <seb128> is that the "+x is required to run .destkop"?
[23:50] <kees> yes.
[23:50] <seb128> that should be fixed since karmic
[23:50] <seb128> or jaunty
[23:50] <seb128> in which case that doesn't work?
[23:50] <kees> their dialog offers a "run anyway" option which is not allowed by Ubuntu policy.
[23:51] <seb128> why not?
[23:51] <kees> my patch just drops the buttons.
[23:51] <kees> because it's useless security.
[23:51] <seb128> hum
[23:51] <seb128> why are those discussion not happening in public places?
[23:51] <kees> uhm...
[23:51] <kees> it was discussed at UDS for several sessions, and across weeks of tech board meetings.
[23:51] <seb128> who decided that is an ubuntu policy without discussing it with the people concerned first?
[23:52] <seb128> first time I read about it
[23:52] <seb128> but I don't follow security track or TB meetings
[23:52] <seb128> I do read mailing lists and meeting summaries usually though
[23:52] <kees> it was in the desktop track 2 UDSes ago
[23:52] <kees> it took 6 months to get through tech board.  :)
[23:52] <seb128> waouh
[23:53] <seb128> I'm quite surprised that a desktop policy got written, approved by tb, etc without me reading about it
[23:53] <kees> speed there was mostly from me not pushing hard enough
[23:53] <kees> it's not a desktop policy -- it's an ubuntu policy.
[23:53] <kees> it affects everything
[23:53] <seb128> still it impacts on desktop apps
[23:53] <kees> right
[23:53] <kees> I don't know why pitti didn't mention it.  it was in about 3 sessions in UDS Barcellona
[23:53] <seb128> I will talk to him tomorrow
[23:54] <kees> okay
[23:54] <seb128> I join them for the sprint
[23:54] <seb128> I'm not opposed to the change
[23:54] <seb128> I just think upstream had good argument
[23:54] <cjwatson> seb128: the TB decision was "this is OK subject to detailed discussion within the desktop team", so relax a little :-)
[23:54] <seb128> and I'm not sure I like to have desktop team non consulted there
[23:54] <cjwatson> like the desktop team technical lead? :-)
[23:54] <seb128> cjwatson, oh, not stressed sorry if it seems so
[23:55] <seb128> rather surprised
[23:55] <cjwatson> who is on the TB and has been in all the discussions on the subject
[23:55] <kees> the key difference is between allowing users to just run the thing anyway with a click vs blocking it.  Gnome came down on the "let them break their system" side, and we came down on the "protect their system" side.
[23:55] <seb128> cjwatson, point taken, I will talk to pitti
[23:55] <seb128> we sort have 2 desktop teams
[23:56] <seb128> one being GNOME who deals with updates, etc, one being the Canonical one where pitti is techlead ;-)
[23:56] <seb128> seems we have a communication issue between both ;-)
[23:57] <seb128> kees, I'm not sure I agree with the "break their system"
[23:57] <seb128> kees, it's rather "don't block them if they really know what they are doing and want to do the action anyway"
[23:57] <seb128> kees, like the desktop is there for years and being used and has not been +x-ed on upgrade
[23:58] <kees> seb128: right, agreed.  it's a binary choice for a huge grey area.  ultimately, if they know what they're doing, lacking +x isn't a problem.
[23:58] <kees> seb128: but, as cjwatson says, it will need more implementation details.
[23:58] <kees> (for reference, this is bug 506702)
[23:59] <seb128> I've the feeling that going to create quite some trouble for users
[23:59] <seb128> things in user dir they downloaded and use for years