[00:09] <kiko-afk> mdz, no problem. thanks for pointing out the issue
[01:20] <superm1> can a launchpad admin look at this: https://edge.launchpad.net/~mythbuntu-hotfixes/+archive/+build/568707
[01:21] <superm1> it's failing because its the first package in the PPA
[01:21] <superm1> and won't build
[01:21] <superm1> "Failed to fetch http://ppa.launchpad.net/mythbuntu-hotfixes/ubuntu/dists/hardy/main/binary-i386/Packages.gz  404 Not Found"
[01:24] <stdin> a workaround would be to upload another version
[01:25] <stdin> superm1: but the file exists now, so try a rebuild
[01:25] <superm1> stdin, okay i'll hit the retry
[01:33] <superm1> yup that worked
[01:33] <superm1> thanks
[01:33] <superm1> how long until the binary publishes though?
[01:34] <superm1> it says it built and all
[01:55] <Fujitsu> stdin: Publisher runs every 20 minutes. The bug you encountered then was fixed this morning, so will be rolled out with 1.2.4
[01:55] <Fujitsu> Er, superm1 ^^
[04:03] <Hobbsee> kiko-afk: feel free to revert the cherry pick - i can't test it on production now anyway
[06:16] <ubotu> New bug: #221276 in launchpad "email obfuscation not working in Launchpad" [Undecided,New] https://launchpad.net/bugs/221276
[07:01] <ubotu> New bug: #221283 in soyuz "Not necessary to show the architecture in /+builds" [Undecided,New] https://launchpad.net/bugs/221283
[08:04] <carlos> morning
[08:35] <ubotu> New bug: #221296 in soyuz "Package diff component needs implementation" [Undecided,In progress] https://launchpad.net/bugs/221296
[09:30] <mpt> Gooooooooooood morning Launchpadders!
[09:33] <Fujitsu> Happy Hardy day, mpt.
[09:34] <mpt> Same to you, Fujitsu
[09:36] <ubotu> New bug: #221305 in soyuz "Present last 5 PPA uploads in $distro/+ppas" [Low,In progress] https://launchpad.net/bugs/221305
[13:39] <StevenK> I was curious in finding out when Launchpad processed deletions in PPAs?
[13:45] <stdin> SteveA: see the Help link in the top right of the delete page
[13:45] <stdin> SteveA: *top left
[13:47] <SteveA> stdin: okay. ;-)
[13:49]  * Hobbsee waves to SteveA
[13:49] <SteveA> hi Hobbsee
[13:51] <stdin> how many Steve's are there, sheesh :p
[13:55] <Hobbsee> stdin: lots.
[13:56] <ubotu> New bug: #221343 in launchpad "Register a branch hosted on LaunchPad creates an empty project" [Undecided,New] https://launchpad.net/bugs/221343
[13:57] <gmb_> stdin: They're indexed alphabetically.
[13:58] <stdin> but the A looks like a K with this font ;)
[13:59] <gmb> stdin: What weird-ass font makes an A look like a K?
[13:59]  * gmb boggles
[13:59] <StevenK> I'd have to agree with that.
[13:59] <stdin> some non-fixed width one, I was messing with it earlier and didn't change it back
[13:59] <StevenK> Besides, my nick has an 'n' in it.
[13:59] <gmb> StevenK: This is true. Though you could be a gestalt entity... Steve 'n K...
[13:59] <stdin> StevenK: well, that's just me being lazy and not checking there
[13:59] <gmb> Maybe not.
[14:21] <ubotu> New bug: #221353 in rosetta "Search through all plural forms of a translation" [Undecided,New] https://launchpad.net/bugs/221353
[14:23] <StevenK> Okay, so now it's been 40 minutes and the package is still listed in the Packages file.
[14:25] <Fujitsu> StevenK: How often does the help tab say they'll be removed.
[14:25] <Fujitsu> Empirically it seems to take up to 48 hours.
[14:25] <StevenK> "A deleted package disappears from the archive indexes in at most 20 minutes."
[14:26] <StevenK> I can't wait 48 hours.
[14:26] <Fujitsu> Oh, the indices should be quick, right.
[14:26]  * Fujitsu looks.
[14:27] <Fujitsu> StevenK: You know, it's probably because there's nothing to make it republish. Upload anything, and it should vanish.
[14:27] <StevenK> Argh, I didn't think I had to do that.
[14:27] <Hobbsee> StevenK: fairly sure that you do
[14:28] <StevenK> What about if it's something I already uploaded? :-)
[14:28] <Fujitsu> What do you mean?
[14:29] <Hobbsee> StevenK: before the delete?  still won't work
[14:29] <StevenK> I've already marked them for deletion.
[14:29] <Hobbsee> upload something random, delete that too
[14:30] <Fujitsu> I think you'll have to let it exist through one publisher run for it to do anything, though.
[14:40] <lool> cprov: Around?
[14:40] <lool> cprov: You mentionned that pagination issue fixed in edge for the list of ppa packages
[14:41] <lool> cprov: However, I think the issue is still present in the /+delete-packages page
[14:42] <cprov> lool: there is a note at the end to the table saying how many records are not presented. You should you the name filter to refine the results
[14:42] <cprov> lool: the form doesn't cope with the batch system
[14:44] <lool> cprov: That's not terribly usable; for example I just wanted to walk through all packages to drop gutsy stuff
[14:44] <lool> I'd have to browser it in two windows or something
[14:44] <lool> I am also dropping everything which has "~804" in the version string, so I was ^F / ^G-ing that and selecting delete, but that's not working either
[14:45] <cprov> lool: you need the distroseries filter
[14:45] <lool> So I would need one page load for any additional package after m now :-(
[14:45] <lool> cprov: Hmm I can't delete packages on edge either
[14:45] <lool> "
[14:45] <lool> "No matching source packages for ' '.
[14:46] <StevenK> I managed to about an hour ago
[14:46] <lool> cprov: It's not only per series, I have other criterions like simply looking at all changes and deciding to remove   :-/
[14:47] <cprov> lool: sorry, you said that the deletion is not working, is that true ?
[14:47] <lool> I'm trying again
[14:47] <lool> Hmm it worked for a subset of the packages I was selecting
[14:47] <lool> Can't reproduce it no
[14:47] <lool> w
[14:48] <lool> cprov: Anyway, do you think it's reasonable to request pagination for the /delete-packages page?
[14:48] <lool> cprov: Ah the error was my bad, I had spaces in the "Only show sources matching" filter
[14:49] <cprov> lool: no, as I said we can't preseve the selections done in previous page
[14:49] <cprov> lool: you can request better filtering
[14:49] <cprov> lool: with I already plan to do very soon in 1.2.5
[14:50] <cprov> lool: filtering by distroseries and status definitely
[14:50] <lool> cprov: How different is it to click "Next" in a paginated list with deleted packages selected and changing the source filter?
[14:50] <lool> Wont peole loose the selected packages for deletion if they filter the list by source package name too?
[14:52] <cprov> lool: yes, they will lose the selection always and that's not ideal
[14:53] <cprov> lool: I don't see how pagination makes it any clear.
[14:53] <lool> cprov: I would be more happy if I could still do it per 50 packages
[14:53] <lool> Instead of having to filter package per package
[14:54] <cprov> lool: mass-anything is difficult in LP
[14:54] <lool> Yeah
[14:54] <lool> cprov: Oh well, thanks for discussion
[14:55] <cprov> lool: yes, np, I will improve filtering ASAP
[14:55] <cprov> but mass-deletion will continue to be a problem, requiring a lot of clicks
[14:56] <cprov> lool: btw, if you have time, file a bug about this and describe your use cases.
[15:09] <lool> With pleasure
[15:09] <lool> cprov: soyuz with ppa tag right?
[15:10] <cprov> lool: yes, please.
[15:12] <lool> cprov: Did you people discuss keeping archived copies of sources uploaded to a ppa?
[15:13] <cprov> lool: how do you mean ? keep them published in the archive (bzr-team request) or just keeping the files somewhere you can download ?
[15:15] <lool> Keeping the history so that we don't lose .dsc, .tar.gz, .diff.gz when someone uploads crap and we need ot revert it
[15:16] <lool> I'd rather not see ALL ever uploaded packages published or visible, this would be a bit confusing I think
[15:17] <lool> Back to that pagination, I would simply be happy if I could see all packages (no limit)
[15:17] <lool> If I think about bugzilla, I think it allows you to limit how many bugs you'd like to see
[15:20] <lool> Wow /me discovers /+filebug-advanced
[15:25] <ubotu> New bug: #221370 in launchpad "Cannot checkout a Launchpad hosted project" [Undecided,New] https://launchpad.net/bugs/221370
[15:25] <ubotu> New bug: #221371 in soyuz "Not easy to cleanup ppa for ubuntu-mobile; needs mass deletion or better filtering" [Undecided,New] https://launchpad.net/bugs/221371
[15:26] <lool> cprov: So you say there's something which you can enable on the side of launchpad to keep the old sources in some place?
[15:26] <lool> Or only published?
[15:28] <cprov> lool: only published version remain in the archive disk (ppa.l.n/xxx/ubuntu/pool)
[15:28] <cprov> lool: however all source ever uploaded and binaries ever built remain in librarian (lp internal storage)
[15:28] <lool> cprov: Is it possible to keep the .dsc in the pool, but not visible on the web page?
[15:29] <lool> Are the binaries removed?
[15:29] <lool> cprov: Ohh
[15:29] <lool> cprov: How can I access these in librarian?
[15:29] <cprov> lool: the opposite, files removed from the pool but available in the ui
[15:29] <cprov> lool: https://bugs.edge.launchpad.net/soyuz/+bug/193996
[15:29] <ubotu> Launchpad bug 193996 in soyuz "PPA packages unavailable once deleted" [Medium,In progress]  - Assigned to Celso Providelo (cprov)
[15:30] <lool> cprov: What I'd like is that superseded packages (by new uploads) be still reachable; not deleted packages as deleted from the web page
[15:30] <cprov> lool: sources are already visible forever (see the links in the expandable area for any deleted/superseded record)
[15:31] <ubotu> New bug: #221372 in launchpad "Beta team need updates of new features on Edge" [Undecided,New] https://launchpad.net/bugs/221372
[15:31] <cprov> lool: right, that was always possible for sources. I will make it the same for binaries.
[15:31] <lool> We're talking about ppa here, right?
[15:31] <cprov> lool: yes, we are.
[15:32] <lool> I fail to see how I can browse to old versions of packages which were in the ppa
[15:32] <lool> And other people around me complained frequently about not being able to do exactly this, so you're about to reveal a pretty good news I think :)
[15:32] <cprov> lool: https://edge.launchpad.net/~ubuntu-mobile/+archive?field.name_filter=cairo&field.status_filter=superseded
[15:33] <lool> Wow
[15:33] <lool> Cool \o/
[15:33] <cprov> lool: click in the arrow for cairo and you will see the sources files linking to librarian below.
[15:33] <lool> cprov: I have to leave to jump around the office here and tell everybody about it
[15:33] <lool> cprov: I missed the "Superseded" drop down near search
[15:34] <lool> Probably because I very rarely use search
[15:34] <cprov> :)
[15:35] <lool> cprov: What's the bug about keeping the binaries too?
[15:35] <lool> https://launchpad.net/bugs/221372
[15:36] <ubotu> Launchpad bug 221372 in launchpad "Beta team need updates of new features on Edge" [Undecided,New]
[15:36] <lool> No, that's something else
[15:36] <lool> cprov: Should I file a bug for keeping binaries too?
[15:36] <lool> Ah https://bugs.edge.launchpad.net/soyuz/+bug/193996
[15:36] <ubotu> Launchpad bug 193996 in soyuz "PPA packages unavailable once deleted" [Medium,In progress]  - Assigned to Celso Providelo (cprov)
[15:37] <cprov> lool: yes, already in my plate ;)
[15:37] <lool> Cool
[15:37] <lool> cprov: People here have a mirror of the ppa just for this use case :)
[15:38] <cprov> lool: well, a mirror is required if you need to sign the archive
[15:38]  * cprov doesn't believe he mentioned that ... errrr
[15:39] <lool> Indeed
[15:39] <lool> But we don't really need that yet
[15:42] <lool> Hmm bzr branch lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy has been running since 4 minutes with no output; it's over bzr+ssh this time around; a bzr pull over http was also stuck, weird
[15:43] <lool> I can load bazaar.launchpad.net over http fine
[15:53] <lool> is bazaar infrastructure impacted by the hardy release?
[16:52] <ubotu> New bug: #221397 in launchpad "fmt:link icon could be presented better using CSS" [Undecided,New] https://launchpad.net/bugs/221397
[17:20] <LaserJock> bigjools: ping?
[17:22] <bigjools> LaserJock: yes?
[17:45] <ubotu> New bug: #221418 in launchpad "Pageid isn't set for views using attribute" [Medium,Triaged] https://launchpad.net/bugs/221418
[17:46] <ahasenack> can anybody help with ppa? I uploaded smart_0.52-landscape8 a few hours ago (1 or 2) and it just disappeared. Nothing shows up for it in https://launchpad.net/~landscape/+archive/+builds in any state
[17:47] <ahasenack> I got the email saying it was accepted (but only for two distros: gutsy and hardy; I uploaded to dapper, edgy and feisty too)
[17:48] <cprov> ahasenack: haven't you received a rejection message for the missing ones ?
[17:48] <ahasenack> no
[17:49] <ahasenack> cprov: but there might be something wrong about that on my side
[17:49] <ahasenack> cprov: I'm checking the history of the terminal where I ran the command
[17:50] <ahasenack> cprov: assuming those other three were not sent, what about the two that got sent and confirmed via email:
[17:50] <ahasenack> ?
[17:52] <cprov> I can see a gutsy & hardy failure, then a gutsy accepted
[17:52] <cprov> hardy accepted too
[17:53] <cprov> ahasenack: that's it you haven't upload anything else today (last 12 hours)
[17:53] <ahasenack> the last accepted email I have is from 2h ago (14:50 UTC)
[17:53] <ahasenack> cprov: yes, there were many failures before
[17:56] <ahasenack> cprov: forget about the other three "missing" targets/distros, it's only gutsy and hardy indeed
[17:57] <cprov> ahasenack: just a tip, if you allow me.  If the upload doesn't show up within 10 minutes after being uploaded, *no question* it won't appear anymore, something is broken on your side, be 100 % sure your system is ok and your source is signed and re-upload it.
[17:57] <ahasenack> cprov: even if I got the accepted email, right?
[17:57] <cprov> ahasenack: the upload-processor hasn't failed once this year, so it's reliable enough
[17:58] <ahasenack> I guess I'm cursed then
[17:59] <cprov> ahasenack: if you have received the acceptance message, the package will show up in the PPA page as pending, zero change of not.
[17:59] <ahasenack> cprov: you want me to forward the accept email to you?
[17:59] <ahasenack> cprov: maybe you can see something I can't (honestly)
[18:00] <cprov> ahasenack: okay, forward it.
[18:01] <cprov> ahasenack: [PPA ahasenack] not landscape.
[18:02] <ahasenack> cprov: ah, there you go
[18:02] <ahasenack> cprov: thanks
[18:02] <cprov> ahasenack: np
[18:58] <Rinchen> ==> Come join the Launchpad Developers meeting in #launchpad-meeting starting in 1 minute :-)
[19:10] <ubotu> New bug: #221449 in malone "Bug reported on source package begins "Binary package hint:"" [Undecided,New] https://launchpad.net/bugs/221449
[19:37] <Rinchen> updated next meeting date
[20:01] <steveire> Hey, does launchpad have a list of all the projects it hosts?
[20:04] <steveire> https://launchpad.net/projects/+all << 6300- Wow


[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:<IP_ADDRESS>2-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:<IP_ADDRESS>2-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:<IP_ADDRESS>2-1ubuntu1 installed when I last restarted X, upgraded to 2:<IP_ADDRESS>2-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:<IP_ADDRESS>2-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:<IP_ADDRESS>2-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:<IP_ADDRESS>2-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 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