[00:35] <bdrung> sebner: i am back. eclipse in lucid probably does not work with xulrunner 1.9.2. take eclipse 3.5.2-1 from sid.
[01:24] <ccheney> NCommand1r: ping
[01:24] <NCommand1r> ccheney: pong
[01:24] <ccheney> NCommand1r: do you know if we need binfilter on arm? i'm trying to reduce our diff with debian and notice they don't enable it on arm
[01:25] <NCommand1r> ccheney: I'd like to keep OOo on ARM as close as we can to i386/amd64
[01:25] <ccheney> NCommand1r: aiui it causes the build to take substantially longer
[01:25] <ccheney> NCommand1r: ok
[01:25]  * ccheney personally would prefer to drop it on all archs, but that would probably cause some users to be annoyed
[04:34] <xorl> This has got me brain stumped.
[04:34] <xorl> Trying to figure out why apache is user bound to the user id 33
[04:34] <xorl> driving me ape
[04:36] <micahg> xorl: that's the user id for it?
[04:36] <xorl> micahg: yeah, I have literally changed the www-data users name
[04:36] <micahg> xorl: why?
[04:36] <xorl> restarted apache, it took the name on, so it's some how bound to the straight uid
[04:37] <xorl> micahg: custom layout
[04:37] <xorl> I run 2 apache processes as different users (different access rights)
[04:37] <xorl> problem being, i run it as a different user, somehow www-data is always the first process then the SECOND process is the User I specified
[04:38] <xorl> was gonna rebuild the package but haven't found where said binding takes place
[04:38] <micahg> xorl: probably a better question for #ubuntu-server or #httpd
[04:39] <xorl> micahg: will head over there
[06:17] <pitti> Good morning
[06:18] <pitti> superm1: the intention of this thing was: (1) we assume that bash is always installed and from Ubuntu (at least right after installation), (2) if apt says that bash has no valid origin, then we assume that we do not have any package indexes and need to download them
[06:18] <pitti> superm1: this is for the case right after install when the apt cronjob didn't run yet
[06:18] <pitti> and thus any package info query fails
[06:19] <superm1> pitti, hm.  well i've got a situation that's not fitting that too well then.  i've got package indexes that are entirely valid, but are generated from a pool that won't necessarily contain bash at the time that jockey is run (during install)
[06:20] <superm1> pitti, so with the patch i showed you, it just checks that "something" is available (meaning that there is at least one package index available) - which i think should still work for your case too
[06:21] <pitti> superm1: yeah, maybe; it looks very expensive, though, since you need to iterate through thousands of package records?
[06:22] <superm1> pitti, well if you hit the first one and it's valid it's inexpensive...
[06:22] <pitti> superm1: right, but it won't right after installation
[06:23] <pitti> superm1: perhaps we should run a similar check again if we detect a handler which has a particular package, which we know nothing about
[06:23] <pitti> then it could try to fetch the indexes again
[06:23] <pitti> superm1: what is your use case? add a ppa and call jockey, but not run apt-get update in between or so?
[06:25] <superm1> pitti, well mv the existing sources.list out of the way, generate a pool from a directory with apt-ftparchive, and put that list in sources.list.d, apt-get update, mv the old sources.list back into place.  the net result is then anything in that pool is apt-get'able, and to disable it, just rm the sources.list.d file
[06:25] <superm1> so the idea is that it's easy to feed new/updated drivers into jockey by doing it that way
[06:27] <superm1> i'm starting to think  maybe a switch that blocks jockey-text from trying to fetch index updates would be better for me than trying to fit into the current constraints
[06:31] <pitti> superm1: hm, jockey already supports adding new repositories in handlers
[06:31] <superm1> pitti, well this isn't just for jockey, it's actually so that ubiquity can install out of this pool too
[06:31] <superm1> basically this gets run in an early command: http://linux.dell.com/git/?p=ubuntu-fid.git;a=blob;f=framework/scripts/pool.sh;h=648b81c7f95730bdc76871f9227b84bab1257222;hb=HEAD
[06:32] <pitti> superm1: so the problem in this case is that jockey fetches indexes again, although you don't want it ti?
[06:32] <pitti> s/ti/to/
[06:32] <superm1> pitti, that's what it eventually boils down to, yes
[06:33] <pitti> superm1: we could perhaps also check glob('/var/lib/apt/lists/*_Packages') != [] ?
[06:34] <pitti> superm1: since bash is an approximation anyway, this will do as well
[06:34] <superm1> pitti, that sounds like a saner way to go about it to me
[06:34] <pitti> I tried to avoid making assumptions about apt's internals, but this is fine for me
[06:41] <pitti> superm1: hm, I wonder if after an installation you would have a CD-ROM source
[06:42] <superm1> pitti, in my scenario?  it should be irrelevant i think since any drivers that were available will be installed
[06:42] <pitti> superm1: no, I mean for the original bug
[06:43] <superm1> pitti, i dont think i've been seeing a cdrom source after installs in installs i've done lately
[06:44] <superm1> i thought apt-cdrom used udev now for some of that magic too
[06:46] <pitti> yes, I think so, too, but I think I'll do another test install to be 100% sure
[08:05] <tkamppeter> elmo, hi
[08:39] <tkamppeter> pitti, hi
[08:39] <pitti> hi tkamppeter
[08:40] <tkamppeter> Can you have a look at bug 465916?
[08:40] <tkamppeter> It is about the problem of CUPS not broadcasting via DNS-SD/Zeroconf since 1.4.x.
[08:42] <tkamppeter> James Troup (elmo?) asks for how much work it is to solve this problem.
[08:43] <tkamppeter> pitti ^^
[08:45] <pitti> tkamppeter: is that the same problem that we discussed recently, abuot the old bonjour compat API of avahi vs. cups using the native api with that redhat patch?
[08:45] <pitti> tkamppeter: you mentinoed that you got cups to build with the compat library with very few code changes
[08:57] <cjwatson> pitti: you may well have a CD-ROM source after installation, yes, so you'll need to filter that out.  whether apt-cdrom uses libudev to get at it is irrelevant
[08:58] <pitti> cjwatson: ah, thanks
[08:58] <tkamppeter> pitti, I got it to build but it did not actually work. It needs some functions of the generic libdns which do not exist in the compat library of Avahi.
[08:59] <tkamppeter> With my changes I got it compiling with the result of a cupsd which did not broadcast.
[08:59] <pitti> tkamppeter: ok, that's not very useful then
[09:00] <tkamppeter> pitti, the Red Hat patch only makes CUPS' dnssd backend working with the Avahi compat library, not the CUPS daemon.
[09:01] <pitti> tkamppeter: hm, I thought it was the backend which would do the detection of bonjour-advertised printers on win/mac boxes?
[09:01] <pitti> and not the daemon itself
[09:01] <pitti> tkamppeter: or is it broadcasting cups' printers to mac/win over bonjour, i. e the other direction?
[09:01] <pitti> ah, apparently it is, silly me
[09:02] <tkamppeter> pitti, there are two parts: The dnssd backend makes available printers which advertize themselves via DNS-SD, as most modern network printers do, some cheaper ones even dropped the SNMP self-advertizing.
[09:02] <pitti> right, and this direction works AFAIK?
[09:03] <tkamppeter> The second (and not working) is as you say that the CUPS daemon should broadcast its locally defined queues via DNS-SD, so that Mac (and perhaps also Windows) clients see the printers.
[09:04] <tkamppeter> The first works. If you run /usr/lib/cups/backend/dnssd, you see entries from network printers which use DNS-SD.
[09:04] <tkamppeter> pitti ^^
[09:04] <pitti> right, got you
[09:14] <tseliot> pitti: the archive is still frozen (as per topic), right? If so, were the uploads that I see in lucid-changes approved?
[09:15] <cjwatson> any uploads land in the unapproved queue, so they must have been approved
[09:16] <seb128> speaking of which any eta for unfreeze?
[09:16] <cjwatson> universe uploads are still being waved through
[09:16] <cjwatson> seb128: a few hours, I think
[09:16] <tseliot> cjwatson: ah, ok, that's what I wanted to know. Thanks
[09:16] <seb128> I feel uncomfortable having an hundred of uploads landing in lucid after beta just when every runs away for weekend
[09:16] <seb128> cjwatson, ok thanks
[09:16] <persia> Could always not run away :)
[09:16] <seb128> everybody
[09:17] <seb128> persia, well experience tell me that people will not stay on friday night just to see if nothing breaks
[09:17] <persia> seb128: Sadly, my experience parallels yours.
[09:50] <directhex> cjwatson, so an archive admin could do a sync to universe if they felt like it, despite the freeze?
[09:52] <cjwatson> yes, though I'd expect most archive admins to have other priorities just at the moment
[09:54] <directhex> yeah, that was my guess
[10:01] <tkamppeter> pitti, in bug 465916 Mark Shuttleworth suggests to package libdns, but I have told Mark that we are after FF.
[10:04] <pitti> tkamppeter: but I guess that would also need new code in avahi to actually use it, no?
[10:04] <pitti> tkamppeter: or does cups already have that code, and will use it if it's there?
[10:29] <tkamppeter> pitti, CUPS will directly use the native libdns. If we package it, we remove Red Hat's patch for dnssd and then let CUPS use the native libdns for both daemon and dnssd, as designed by upstream.
[10:30] <pitti> ah, this is like a parallel implementation of avahi then?
[10:30] <tkamppeter> pitti, problem is only that we need to make CUPS use the native libdns and all other libdns-using packages of the distro the Avahi compat libdns to minimize possible regressions after the FF.
[10:31] <tkamppeter> Yes, avahi did their own implementation of libdns (and our package installs it as /usr/lib/libdns.so.*) but incompletely.
[10:31] <tkamppeter> pitti ^^
[10:32] <pitti> tkamppeter: I think libdns.so.* is from bind9
[10:33] <pitti> avahi is libdns_sd.so
[10:34] <tkamppeter> pitti, sorry, thanks. I mean indeed libdns_sd.so.
[10:50] <tkamppeter> pitti, will it be possible to have CUPS using the native libdns and all the rest using avahi compat?
[10:50] <lucas> Can I assume that the Packages.gz file in dists/$DIST/main/binary-i386/ will NEVER be modified, and that all updates are done through $DIST-updates and $DIST-security?
[10:51] <cjwatson> lucas: yes
[10:51] <lucas> even for releases like 10.04.1?
[10:51] <cjwatson> at least with our current archive model.  It does have the disadvantage that we can't remove a package in case of problems
[10:51] <cjwatson> yes
[10:51] <lucas> perfect, thanks
[10:52] <cjwatson> lucas: what's this for?  if we ever change it, I'll try to remember to let you know ...
[10:52] <lucas> that's great for legally-binding documents where you must write "MUST work with ubuntu 9.10" and describe what ubuntu 9.10 really is
[10:53] <cjwatson> right
[11:07] <pitti> tkamppeter: we'd need to name the libdns one differently
[11:07] <pitti> tkamppeter: or, as you say, add it to the cups package and link statically or so
[11:07] <pitti> tkamppeter: but I don't fancy a parallel implementation of avahi a lot, TBH
[11:11] <cjwatson> Keybuk: console-setup 1.34ubuntu12 should with any luck be a fraction more efficient
[11:11] <cjwatson> I can't see console-setup-tty on my bootchart any more
[11:17] <tkamppeter> pitti, what do you mean with "but I don't fancy a parallel implementation of avahi a lot, TBH"? To finally switch to the real libdns_sd?
[11:20] <pitti> tkamppeter: if libdns is a superset of the avahi API, then we can perhaps discuss that for lucid+1
[11:20] <pitti> tkamppeter: but for now, so many things build/link against avahi that it's out of the question to switch the implementation for lucid
[11:20] <pitti> (as a system library, I mean)
[11:35] <tkamppeter> pitti, so for Lucid the only way is to take the lib into the CUPS package and link it statically.
[11:36] <pitti> tkamppeter: yes, that or rename the installed library
[11:36] <pitti> tkamppeter: but I wouldn't like to give a blanket exception for including libdnsf
[11:36] <pitti> s/f$//
[11:36] <pitti> it doesn't seem to be a small harmless library after all
[11:37] <tkamppeter> pitti, how does one make a debian package with an extra upstream tarball, does one drop the extra upstream source into debian/local/?
[11:37] <pitti> so this should get a proper MIR/FFE
[11:37] <pitti> tkamppeter: no, please package it separately; it's way too messy otherwise
[11:38] <pitti> renaming the library sounds better
[11:38] <pitti> tkamppeter: forward-porting the 1.3 cups code for broadcasting is out of the question?
[11:39] <pitti> tkamppeter: (the receiving direction alreayd works fine with avahi, so no reason to touch that)
[11:40] <tkamppeter> pitti, thought also about that and it seems that the dns-sd code is not too much spread over CUPS. And due to the Red Hat patch we only need to forward-port the scheduler part.
[11:40] <daniel1234> I have a service that I want to write an apparmor-profile for, that service is using slapd. slapd already has a profile, but it doesn't cover the directories I need. Afaik, Apparmor doesn't support having multiple profiles for one binary and it doesn't support "inheritance".. And you shouldn't touch files from other packages. Does anyone have ideas?
[12:59] <mok0> Hm. Building atlas on the ppa fails for the following reason: Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU
[12:59] <mok0> Is there any way to request a specific builder?
[13:00] <persia> Not trivially.  Some of the buildd admins can hint stuff, but I think I remember the trick being something like "wait until everything but the target is busy, and then give the target job a priority of several milloin)
[13:01] <happyaron> jcastro: ping
[13:01] <mok0> persia: ... that's not a command mortals can use though?
[13:01] <persia> mok0: No.  Only buildd-admins
[13:01] <mok0> persia: ... and you can't upload a binary package to the ppa I guess
[13:02] <persia> Well, no.  You can upload a source package that contains only a binary blob, but you'll need to make sure the license you have permits that.
[13:02] <mok0> persia: The purpose would be to get the binary into the PPA
[13:02] <mok0> persia: now that it won't build
[13:22] <kitallis> pitti: there?
[13:35] <pitti> hi kitallis
[13:37] <kitallis> pitti: so apart from https://wiki.ubuntu.com/Apport/DeveloperHowTo ; any other documentation i can look at?
[13:37] <pitti> kitallis: what do you want to do?
[13:40] <kitallis> well, I want a way to access the crash report url it generates
[13:41] <pitti> kitallis: "access"?
[13:41] <pitti> kitallis: CrashDB.get_comment_url() generates that
[13:41] <kitallis> I obtain, grab the randomized key
[13:41] <pitti> for a particular crash dtabase
[13:41] <pitti> such as apport/crashdb_impl/launchpad.py
[13:42] <kitallis> ah
[13:42] <kitallis> okay.
[13:42] <kitallis> that should do.
[13:42] <kitallis> thanks
[14:18] <tseliot> Riddell, Keybuk: what can I do to trigger the problem with kdm and plymouth using the latest updates?
[14:19] <tseliot> (of course I have rebuilt kdm with my patch)
[14:19] <Keybuk> tseliot: which problem?
[14:20] <tseliot> Keybuk: the one that was blocking the beta
[14:20] <Keybuk> it's kinda tricky
[14:20] <Keybuk> we fixed it in a way that ensures you can't trivially get it back ;)
[14:20] <Keybuk> but you could, for example
[14:20] <Keybuk> plymouthd
[14:20] <Keybuk> plymouth --show-splash
[14:20] <Keybuk> plymouth quit --retain-splash
[14:20] <Keybuk> kdm
[14:20] <Keybuk> in a console
[14:20] <tseliot> ah, let me try
[14:23] <tseliot> Keybuk: plymouthd seems to be still active but kdm showed up correctly
[14:24] <Keybuk> err, if plymouth is active, you didn't get it right :p
[14:24] <Keybuk> you did quit before kdm ?
[14:25] <tseliot> right, there's something wrong
[14:25]  * tseliot checks his patch
[14:26] <tseliot> ah, wait there's the kdm log
[14:28] <Keybuk> your patch?
[14:28] <Keybuk> sorry, you've completely confusde me
[14:28] <Keybuk> what patch?
[14:30] <tseliot> Keybuk: here's what the log says: http://pastebin.ubuntu.com/397840/
[14:30] <Keybuk> tseliot: wait, rewind a minute!
[14:30] <Keybuk> *what* are you trying to test?
[14:30]  * tseliot should look for another log
[14:30] <Keybuk> what patch have you written?
[14:31] <tseliot> Keybuk: it's the plymouth_transition patch for kdm
[14:31] <Keybuk> yes
[14:31] <Keybuk> which has nothing to do with any bug we've fixed
[14:32] <Keybuk> the plymouth transition patch for kdm is about providing a seemless transition into kdm
[14:32] <tseliot> Keybuk: but that patch would also make plymouth quit
[14:32] <Keybuk> yes
[14:32] <Keybuk> that's part of the transition
[14:32] <Keybuk> to test it
[14:32] <Keybuk> plymouthd ; plymouth --show-splash
[14:32] <Keybuk> kdm
[14:32] <Keybuk> you should see plymouth stop animating, a mouse cursor appear, then KDE
[14:32] <Keybuk> with no black screen in between
[14:32] <Keybuk> and plymouthd should exit
[14:33] <tseliot> ok, I'll have to do something like "sleep 5 && sudo start kdm" as I'm using the same monitor for both my main computer and my testing box
[14:36] <tseliot> Keybuk: no, I'm seeing this: splash -> black screen + loading cursor -> kdm
[14:36] <tseliot> so, I did something wrong in my patch
[14:37] <tseliot> as plymouthd is still on
[14:37] <tseliot> but I would like to find the actual log to see what's happening
[14:38] <Keybuk> right
[14:38] <Keybuk> syslog?
[14:39] <tseliot> Keybuk: never mind, I forgot to put a "!" in the 2nd condition last night: if (d->plymouth_is_running && d->failsafex_is_running)
[14:39] <tseliot> no wonder plymouth is not stopped
[14:53] <radoe> Someone else with connection problems when trying to upload to a launchpad ppa with dput? I keep getting [Errno 111] Connection refused.
[14:57] <tseliot> Keybuk: ok, plymouth was stopped but I still can't see any kind of transition with nouveau but that's ok since somehow X was launched with -br instead of -nr: /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-gDWp6K
[14:58] <radoe> Never mind, launchpad FTP seems to be up again...
[14:59] <xnox> radoe: these type of questions are usually answered more quickly on #launchpad
[15:00] <radoe> xnox: well thx, just found the channel.
[15:02] <Keybuk> tseliot: there isn't a transition with nouveau
[15:02] <Keybuk> well, not as complete a one as -intel anyway
[15:02] <Keybuk> but yes, you need -nr
[15:03] <Keybuk> actually, sorry, that was misleading - you still should get a smooth transition into X
[15:03] <Keybuk> but it's not done using proper kernel buffers
[15:06] <tseliot> Keybuk:  right, in nouveau you only have a variable which says that it works with -nr
[15:06]  * tseliot has just found out that another patch sets -br -nolisten tcp in kdm/config.def :-/
[15:06] <Keybuk> right, I think nouveau supports -nr
[15:06] <Keybuk> was trying to remember ;)
[15:08] <tseliot> Keybuk: as you said, things were implemented properly in -intel though
[15:09] <mvo> bryceh: hey - why did you target bug #540519 ? do you know more aobut it (like e.g. how to reproduce)?
[15:10] <seb128> mvo, btw I want to sync new webkit from debian, what do you think about updating?
[15:10] <seb128> mvo, I think they are working toward a 1.2 stable serie
[15:10] <mvo> seb128: fine with me
[15:11] <mvo> seb128: I assume you do basic testing first ;)
[15:11] <mvo> seb128: but otherwise no objections, there is a patch I did for a a11y crash that we may want to import (or see if its fixed upstream already)
[15:12] <tseliot> still no transition with -nr. I should try with gdm
[15:14] <tseliot> Keybuk: I'm getting no smooth transition with gdm either. I'll test with -intel
[15:16] <seb128> mvo, ok
[15:19] <tseliot> Keybuk: I haven't ported the save_root_window patch which I guess it's the missing bit now
[15:20] <Keybuk> tseliot: I was never sure what that did
[15:20] <Keybuk> I think the purpose of that is to put the root pixmap in a special id
[15:20] <Keybuk> so when nautilus comes along later, it sees that
[15:20] <Keybuk> and rather than just painting its desktop image, it does a fadey transition
[15:20] <Keybuk> (which we have disabled atm anyway0
[15:23] <tseliot> Keybuk: right, gnome-settings-daemon was supposed to use that to create a cross fade effect
[15:26] <tseliot> Keybuk: http://blogs.gnome.org/halfline/2009/11/28/plymouth-⟶-x-transition/
[15:37] <Keybuk> tseliot: yes, I've read it ?
[15:37] <Keybuk> it's way out of date now
[15:38] <tseliot> Keybuk: yes, of course but it explains the purpose of the save_root patch, which we don't need
[15:38] <Keybuk> right
[15:38] <tseliot> well, that we don't use ;)
[15:39] <Keybuk> in a matches-what-I-said kind of way ;)
[15:39] <tseliot> yep
[16:15] <spersaud> haha #debian-dev is invite only
[16:15] <spersaud> debian is superior
[16:15] <spersaud> we are proud of debian, Ubuntu is winky dinky distro
[16:20] <cjwatson> (now it's invite-only for him - well, until he changes his IP address, but anyway)
[16:26] <cjwatson> mvo: I punted bug 420307 to beta-2 - are you on the hook to review that?
[16:27] <mvo> cjwatson: sure
[16:27] <cjwatson> thanks
[16:27] <mvo> cjwatson: there is a FFe comming from barry for computer-janitor 2.0
[16:27] <mvo> with dbus support
[16:28] <mvo> is this reproducable on your system?
[16:28] <mvo> I would bet its threading
[16:28] <mvo> and dbus makes it go away
[16:31] <cjwatson> no idea, just looking through our stale beta-1 work items ...
[16:34] <mvo> ok
[16:49] <bryceh> mvo, yeah I reproduced it after clicking on a few "More Info" buttons - no info showed up
[16:49] <mvo> bryceh: is it crashing?
[16:49] <mvo> bryceh: or "just" not showing anything, if the later its likely just *very* slow
[16:50] <mvo> bryceh: that is bug #514879
[16:50] <mvo> as in "several minutes"
[16:50] <bryceh> mvo, don't recall seeing any particular slowness.
[16:50] <bryceh> anyway, gotta run (pdx downtown meeting today).  hth
[16:51] <mvo> ok
[16:52] <mvo> pitti: is the exception in bug #531518 granted? I'm not fully sure by reading the updates or shoould I do another PPA upload that silences the deprecationwarnings first?
[16:53] <pitti> mvo: the verbosity of apt.Cache() is slightly worrying me, since this might break more stuff than just apport (which is fixed in UNAPPROVED)
[16:53] <pitti> mvo: if we can get this fixed, I'm fine with it
[16:53] <mvo> I can fix that
[16:54] <pitti> if it's not intended to be changed, it's also okay, but we need to watch out for regressions then
[16:54] <mvo> the verbosity
[16:54] <pitti> we have p-apt being used a lot, perhaps also in eucalyptus scripts and whatnot
[16:54] <pitti> mvo: thanks
[16:54] <mvo> well, the goal is to be 100% compatible
[16:55] <mvo> pitti: I updated the bug that the exception is approved providing those two issues are fixed: a) deprecation warnings silent b) apt.Cache() not verbose
[16:55] <pitti> mvo: *wipes off a tear* that'd be perfect, thanks!
[16:55] <mvo> pitti: :) np
[16:56] <seb128> if beta1 is released is there any reason to not unfreeze?
[16:56] <Sarvatt> Keybuk, tseliot: all the code to copy the fb contents is already in upstream nouveau so all they need is the canDoBGNoneRoot, thats why the intel patch is alot bigger
[16:57] <tseliot> Sarvatt: and do we have that code too?
[16:57] <Sarvatt> yeah
[16:57] <tseliot> maybe something else is broken here then
[16:57] <Sarvatt> i see a couple of other situations where you might not see a transition
[16:58] <Sarvatt> if the fb depth is different it wont copy it
[16:58] <tseliot> :-/
[17:01] <Sarvatt> there any warnings in the Xorg.0.log tseliot?
[17:02] <Sarvatt> looks like most of the failure paths copying it will print something in the log at least if it happens
[17:03] <tseliot> Sarvatt: I don't think I saw any errors. Let me try again
[17:05] <slangasek> zul: regarding your samba-common.dhcp change currently in the freeze queue... have you tested this?  I can see no reason that an extra space would change anything
[17:05] <zul> slangasek: that change is cosmetic i think
[17:06] <tseliot> Sarvatt: nothing, apart from these lines
[17:06] <tseliot> (--) Depth 24 pixmap format is 32 bpp
[17:06] <tseliot> (EE) NOUVEAU(0): Error creating GPU channel: -19
[17:06] <tseliot> (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
[17:06] <slangasek> zul: also, the idiomatic way to change the logrotate script would be to run 'reload nmbd' instead of looking at pid files (which might disappear in the future)
[17:06] <Sarvatt> ah tseliot give me the dmesg please
[17:06] <zul> slangasek: ok i can change that
[17:06] <slangasek> zul: oh; it had claimed to fix a bug, and I couldn't see how
[17:07] <seb128> slangasek, can we unfreeze lucid if beta1 is there?
[17:07] <slangasek> seb128: the LOSAs can - I've requested this
[17:07] <seb128> slangasek, thanks
[17:08] <Sarvatt> noaccel = no smooth transition afaik, should be able to figure out why from your dmesg
[17:09] <Sarvatt> does anyone know  how to force firmware into the initrd? nouveau has a module option to use the blob firmware which is much less likely to to have accel issues but its not easily testable because it needs to be in there and the module doesn't claim it needs it so initramfs-tools isnt packing it in
[17:10] <tseliot> Sarvatt: http://pastebin.com/QTP2zURs
[17:10] <Sarvatt> tseliot: nvidia isn't blacklisted on your system?
[17:11] <Sarvatt> can you pastebin the actual output from dmesg and not just /var/log/dmesg? the errors would be happening after what you pasted
[17:12] <tseliot> Sarvatt: that was the output of dmesg > myfile
[17:13] <Sarvatt> tseliot: try blacklisting nvidia, update-initramfs -u and reboot?
[17:13] <tseliot> Sarvatt: nvidia is not loaded and in dmesg nvidia complains that it couldn't load nvidia (obviously because of nouveau)
[17:17] <Sarvatt> tseliot: you're right, nevermind, I see the exact problem in  your log
[17:17] <Sarvatt> your card isn't supported yet
[17:18] <Sarvatt> basic 2D but not acceleration
[17:18] <Sarvatt> [    6.856086] [drm] nouveau 0000:02:00.0: I don't know how to make a ctxprog for your NVa3 card.
[17:20] <Sarvatt> tseliot: info for that card is desperately needed in #nouveau
[17:20] <tseliot> Sarvatt: ok, that's definitely a problem
[17:20] <tseliot> ah
[17:20] <Sarvatt> they couldn't find anyone with one of those to do a mmiotrace so they can support it
[17:29] <seb128> directhex, what does bug #536925 break in f-spot exactly?
[17:29] <tseliot> Keybuk: do you happen to have an mmiotrace enabled kernel?
[17:29] <tseliot> for lucid
[17:30] <Keybuk> tseliot: not on me
[17:31] <tseliot> heh
[17:31]  * ogra pokes mountall
[17:31] <Keybuk> didn't apw enable it in git now?
[17:31] <Keybuk> so you should just be able to build from there
[17:32] <tseliot> Keybuk: yep, Sarvatt has just given me the link
[17:32] <Sarvatt> he enabled it in the kernels we're testing for intel powersave issues - http://people.canonical.com/~apw/i915-fbc-broken-lucid/
[17:35] <tkamppeter> Can someone unfreeze the archives? My uploads still say "Waiting for approval".
[17:35] <ScottK> tkamppeter: It's been requested.  It takes a bit.
[17:35] <slangasek> The archive is unfrozen.  Packages that are already in the approval queue have to be flushed by hand, which I'm doing now
[17:35] <tkamppeter> slangasek, thanks, it is foo2zjs.
[17:39] <cjwatson> tkamppeter: it won't go appreciably faster for any single package :-)
[17:40] <Pici> hmm. Looks like http://www.ubuntu.com/testing/lucid/beta1 mentions the wrong version for nvidia-current
[17:43] <lool> Would someone be so kind to NEW the linux-ti-omap kernel?
[17:52] <tkamppeter> pitti, hi
[17:55] <Keybuk> [./plugin.c] flush_area:palette has 345 colours
[17:55] <Keybuk> tseliot: ^ you greedy person, you
[17:55] <tseliot> Keybuk: lol
[17:55]  * tseliot wants more colours
[17:58] <Keybuk> clearly
[17:59] <tseliot> Keybuk: you should be content with your 16 colours :-P
[18:00] <Keybuk> yes, but when I wrote a quick "best fit" palette
[18:00] <Keybuk> I got mostly white
[18:00] <Keybuk> no aubergine in sight
[18:00] <Keybuk> and it turns out, that's because you use 345 different shades of white to render the logo ;)
[18:01]  * tseliot blames it on our artists :-P
[18:02] <geser> a clear sign that the logo was designed by a woman as only women can distinguish that many colours :)
[18:02] <ScottK> Sigh.
[18:03] <ScottK> geser: I recognize the humor in that, but I suspect it's not the sort of thing that makes this feel like a welcoming place for the few women here.
[18:04]  * geser apologizes to all women
[18:06] <Keybuk> geser: I'll tell Otto you called him a woman
[18:08] <doko> pitti: I'm replacing tk8.4-dev with tk8.5-dev in supported-development-desktop
[18:16] <Pici> tseliot: ping.  I really hate to bug you, but we got a bunch of questions regarding the version of nvidia-graphics-drivers.  I saw on bug 13:56:31 >>>> tavish (~tavish@118.94.24.41) has quit [Ping timeout: 256 seconds]
[18:16] <Pici> arg.
[18:17] <Pici> I saw on bug 533224 that you uploaded/were going to upload a new version, but I don't see that in the upload or build queue.
[18:17] <tseliot> Pici: it doesn't depend on me
[18:17] <Pici> tseliot: oh? Who should I bother?
[18:18] <tseliot> cjwatson, slangasek: uploads are being processed now, right?
[18:20] <seb128> tseliot, yes
[18:20] <seb128> tseliot, see -changes and buildds
[18:20] <tseliot> seb128: ok, thanks
[18:21] <tseliot> Pici: you'll have to wait for a while I guess, until my upload is processed
[18:21] <Pici> tseliot: Okay :)
[18:21] <Pici> Just wanted to be able to give a status to people who ask.
[18:38] <jbebel> Does every package that goes into -updates go through -proposed first?
[18:40] <cjwatson> jbebel: some go through -security instead; all go through one or the other
[18:41] <cjwatson> -security is automatically bulk-copied to -updates provided that there isn't a conflict
[18:41] <jbebel> Ok.  I'm less concerned about -security.  If every non-security package goes through -proposed, that's good enough.
[18:41] <cjwatson> right
[18:41] <jbebel> Is there any required period of time that a package remains in -proposed, or is it just until someone verifies it, which could be very brief?
[18:42] <cjwatson> https://wiki.ubuntu.com/ArchiveAdministration#Moving%20Packages%20to%20Updates prescribes 7 days
[18:42] <cjwatson> occasionally an exception is made to that, but not often
[18:42] <jbebel> Excellent.  Thanks.
[18:43] <cjwatson> exceptions tend to be things like tzdata, for which we occasionally get very little notice of political changes
[18:57] <RoAkSoAx> can anyone from the release team please review bug #407722, since it contains a security fix? Thank you.
[19:14] <slangasek> zul: this vsftpd upload seems to not have the debian/vsftpd.apport file
[19:14] <slangasek> (accepted anyway, but if it doesn't FTBFS, at least the bug is still open...)
[19:14] <zul> slangasek: k
[19:37] <ccheney`> anyone happen to know why the new thinkpads no longer have the FHD lcd option?
[19:57] <xnox> james_w`: Just saw jono blog post =) Didn't I like ask you about it yesterday? =)
[20:05] <lamont> mdeslaur: wanna go chime in on bug 530107 for me?
[20:06] <Keybuk> tseliot: so I managed to get a 12-color palette that works
[20:07] <tseliot> Keybuk: 12? Lazy boy :-P
[20:07] <Keybuk> http://people.canonical.com/~scott/palette.html
[20:08] <tseliot> Keybuk: they should be enough for the theme, I guess
[20:08] <Keybuk> seems to be
[20:08] <tseliot> apart from the shades of white that you mentioned
[20:08] <tseliot> screenshots?
[20:08] <Keybuk> I stripped all but the top two bits of each colour, and that's how many unique 6bpp colours you have in the theme
[20:09] <Keybuk> so you have sufficient unique 6bpp colours to fit in a 4bpp palette
[20:09] <Keybuk> hard to take screenshots of VGA output ;-)
[20:09] <tseliot> you can use a camera
[20:10] <Keybuk> wouldn't really show the theme
[20:10] <Keybuk> it looks like the splash
[20:10] <Keybuk> just with fewer colours
[20:10] <tseliot> record a videoclip with the iphone perhaps?
[20:11]  * tseliot doesn't own an iphone and what kind of quality its videoclips can have
[20:11]  * tseliot uses a nexus :-)
[20:12] <tseliot> Keybuk: is the logo easier to read, compared to your previous screenshot?
[20:12] <Keybuk> yeah much
[20:12] <tseliot> very good :-)
[20:13] <tseliot> Keybuk: so, what's left now?
[20:27] <mok0> Whoa RainCT
[20:31] <Keybuk> http://people.canonical.com/~scott/vga16fb.jpg
[20:31] <Keybuk> tseliot: ^
[20:32] <Keybuk> can't really see from that
[20:36] <tseliot> Keybuk: it looks much much better than before
[20:36] <tseliot> congrats
[20:36] <tseliot> Keybuk: so, when are you going to upload it?
[20:37] <Keybuk> next week
[20:37] <tseliot> great, excellent work, I can't wait to try it with nvidia
[20:40] <tseliot> also, one of the nouveau guys has added the support for my nvidia card to the kernel driver (which I'm rebuilding) and I should be able to test the smooth transition with my nvidia card with nouveau soon :-)
[20:41] <Keybuk> what card is yours?
[20:42] <tseliot> GeForce GT 240
[20:43] <tseliot> Keybuk: if you give them an mmio-trace and the output of another program they can add the support for your card in minutes
[20:43] <tseliot> !
[20:43] <Keybuk> yeah I did that with my G80-based thing in the D620
[20:43] <Keybuk> darktama made a patch for me
[20:46] <tseliot> so the driver works for you too now
[20:46] <tseliot> :-)
[20:50] <jrtayloriv> I think it would be a good idea to change the default settings of the Transmission bittorrent client to not have the web client enabled by default.
[20:51] <jrtayloriv> Should I file a bug report for this? With whom, if so?
[20:51] <jrtayloriv> Is that something that would be done w/ the Ubuntu package maintainers?
[20:52] <mdeslaur> lamont: done
[20:53] <xnox> jrtayloriv: in terminal type $ ubuntu-bug transmission
[20:53] <xnox> to start bug reporting tool
[20:53] <jrtayloriv> xnox thank you
[20:54] <xnox> jrtayloriv: or you can use just launchpad https://edge.launchpad.net/ubuntu/+source/transmission/+filebug
[20:55] <lamont> ta
[20:56] <lamont> mdeslaur: ^^
[20:56] <micahg> xnox: regular users can't file a bug with that link
[20:57] <xnox> micahg: hmmm the edge bit?
[20:57] <xnox> micahg: or no having account on lp?
[20:57] <micahg> xnox: no, the filebug link redirects to the wiki
[20:57] <micahg> or help.u.c
[20:57] <xnox> really I didn't know. How come I can then?
[20:58] <micahg> xnox: maybe because you are a universe contributor?
[20:59] <xnox> micahg: aha =)
[20:59]  * xnox feels special
[21:00] <tseliot> Keybuk, slangasek: stopping plymouth from kdm either after or before calling failsafe X seems to leave the system in KD_GRAPHICS and I can't see the failsafe session but only a fixed image left by the bootsplash on the same vt. Running plymouth again (and killing failsafex) unlocks the system
[21:03] <slangasek> tseliot: plymouth quit --retain-splash?
[21:04] <cody-somerville> Whats the lang pack package name for pt_BR?
[21:07] <tseliot> slangasek: no, according to the log that was just a "plymouth quit"
[21:07] <Keybuk> plymouth quit won't leave the console in KD_GRAPHICS
[21:07] <tseliot> slangasek: doing "plymouth quit && start kdm" works well though
[21:08] <Keybuk> oh, wait
[21:08] <Keybuk> hang on
[21:08] <tseliot> ?
[21:08] <Keybuk> plymouth deactivate , plymouth quit ?
[21:08] <Keybuk> there may be a bug in -17 with that
[21:09] <tseliot> oh
[21:09] <tseliot> no, I think it's my fault
[21:09] <tseliot> at least in this case
[21:09] <Keybuk> I think the bug in -17 though is just that it won't dump console messages in that case
[21:10] <tseliot> I should have added more debug() lines
[21:12] <tseliot> Keybuk: what do you plan on doing about that? Make it more verbose when it does "deactivate"?
[21:12] <Keybuk> tseliot: about the bug?
[21:12] <Keybuk> I already fixed that
[21:12] <Keybuk> noticed it when I was sending the patches upstream
[21:14] <tseliot> Keybuk: yes, I was referring to the bug
[21:21] <Keybuk> tseliot: it's the if statement in on_quit that's the wrong way round
[21:21] <Keybuk> it needs to check the is_inactive case first
[21:23] <tseliot> Keybuk: ah, it makes sense
[21:23] <cody-somerville> Interesting. Even when you're not viewing a package with flash content, npviewer.bin causes tons of CPU wakeups.
[22:04] <tseliot> Keybuk: I'm already using plymouth 0.8.0~-17 :-/
[22:04] <Keybuk> yes?
[22:05] <tseliot> Keybuk: ah, so you haven't uploaded your fix yet
[22:05] <Keybuk> no, we were in beta freeze
[22:05] <ninefingers> Hi all, does anyone know if anyone's attempting to package mpir (www.mpir.org) for ubuntu?
[22:05] <Caesar> Keybuk: hey, you're around. Awesome.
[22:05] <tseliot> Keybuk: ok, I just wanted to be sure
[22:06] <Caesar> Keybuk: so from my observations, it seems like the runlevel 2 legacy init scripts can run before Upstart has brought up the network, leading to all sorts of sadness
[22:06] <Caesar> I've already filed bugs against autofs5 and syslog-ng because they get bitten by this
[22:06] <Caesar> But it's a fairly systemic problem
[22:10] <Keybuk> this has always been the way
[22:10] <Keybuk> it's not even a regression from pre-upstart days
[22:19] <Caesar> I'm finding that hard to believe?
[22:20] <Keybuk> *shrug* doesn't matter what you believe
[22:21] <psusi> by "the network" do you mean lo or eth0?
[22:21] <psusi> because I'm pretty sure upstart takes care to bring up lo first
[22:23] <Caesar> psusi: eth0
[22:23] <Caesar> e.g. syslog-ng's config has a remote loghost, syslog-ng fails to start because it can't resolve it
[22:23] <psusi> you never could rely on that being up
[22:23] <Caesar> e.g. autofs-ldap can't load its automount maps from LDAP, because the network isn't up yet
[22:24] <Caesar> psusi: with legacy init scripts, the network (eth0) came up in rcS
[22:24] <psusi> only if you configured it to
[22:24] <Keybuk> Caesar: no it didn't
[22:24] <Keybuk> not by default
[22:24] <Caesar> Servers, not using NetworkManager?
[22:24] <Keybuk> all rcS ever did was start the process of bringing up the network
[22:24] <Keybuk> it was always brought up in the background while everything else was booting
[22:25]  * Caesar looks at /etc/rcS.d/S40networking on Hardy
[22:25] <Caesar> It calls ifup -a
[22:26] <Caesar> You're telling me that ifup -a returns before the network has come up?
[22:26] <Keybuk> and ifup is called for network devices from udev
[22:26] <Keybuk> which means ifup -a ignores them
[22:27] <Caesar> I have "auto etho" and "iface eth0 inet dhcp" in my /e/n/i
[22:29] <Caesar> Keybuk: so when is udev also bringing up the network?
[22:29] <Caesar> /etc/rcS.d/10udev ?
[22:29] <ion> As soon as the network interfaces appear.
[22:30] <Caesar> That's what I'm trying to determine when
[22:31] <Caesar> It looks like /etc/rcS.d/10udev is a reasonable place to assume the network appears
[22:31] <Caesar> So that's even earlier than /etc/rcS.d/S40networking
[22:31] <psusi> it appears as soon as udev detects the interface
[22:32] <Caesar> So I'm not seeing any reason for the network *not* to be up by the end of rcS.d
[22:32] <psusi> you realize it can take some time for dhcpd to get a lease?
[22:34] <Caesar> Yes. I guess that's a possibility
[22:34] <Caesar> If udev isn't blocking on the ifup eth0 before it returns from a udevadm settle
[22:35] <cjwatson> udevadm settle means "wait for the udev event queue to be empty"; it doesn't mean "wait until all devices have appeared" (which is impossible to determine)
[22:36] <Caesar> cjwatson: ok, I wasn't sure if udev just spawned the ifup eth0 and waited for it or not
[22:37] <Caesar> Sounds like does not
[22:37] <cjwatson> when S10udev returns, the network device might not even have appeared yet
[22:37] <Caesar> Special
[22:37] <cjwatson> that's asynchronous device handling for you ...
[22:38] <cjwatson> (of course there are differing probabilities attached to what happens in practice in any given environment)
[22:40] <Caesar> I wonder if DHCP is slower on Lucid than Hardy for some reason...
[22:40] <Caesar> I wouldn't have thought so
[22:41] <Keybuk> Caesar: udev doesn't block
[22:41] <Keybuk> you might think we realised this was a problem
[22:41] <Keybuk> and that we'd need to have something that helped us sychronise things like this
[22:41] <Keybuk> you might even think we wrote a replacement init daemon to handle it
[22:41] <Keybuk> etc.
[22:41] <Caesar> lol
[22:42] <Caesar> Yes, I realise that the solution is to use an Upstart job
[22:42] <Caesar> They're currently lacking for the two packages I ran into problems with
[22:42] <Keybuk> but just pointing out that Upstart was not a solution looking for a problem
[22:43] <Caesar> I never thought it was
[22:43] <Caesar> I went to your talk in Barcelona :-)
 I'm finding that hard to believe?
[22:44] <Caesar> Keybuk: it just took some explaining :-)
[22:45] <slangasek> Keybuk: "ifup -a ignores them" - I'm not sure that's true, didn't it *attempt* them but with no guarantee that the underlying hardware was available yet?
[22:50] <cwillu_at_work> Caesar, conveniently, upstart jobs are ridiculously easy to write :p
[22:50] <Caesar> cwillu_at_work: I know, I've provided ones on the bugs I filed
[22:51] <Keybuk> slangasek: I wrote the patch to make ifup -a skip the ones udev was already mid-bringing up ;)
[22:51] <Keybuk> otherwise ifup -a would try and run a second dhclient for an interface already waiting for a dhcp lease
[22:51] <Keybuk> etc.
[22:52] <Caesar> That Keybuk, he's got his fingers in everything
[22:55] <Keybuk> heh
[22:55] <Keybuk> all bad apparently
[22:55]  * Keybuk made the mistake of reading the forums again
[22:55] <Keybuk> "I'm going out for a walk, I may be some time ..."