=== jtechidna is now known as JontheEchidna === nemo__ is now known as nemo [00:35] 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] NCommand1r: ping [01:24] ccheney: pong [01:24] 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] ccheney: I'd like to keep OOo on ARM as close as we can to i386/amd64 [01:25] NCommand1r: aiui it causes the build to take substantially longer [01:25] NCommand1r: ok [01:25] * ccheney personally would prefer to drop it on all archs, but that would probably cause some users to be annoyed === NCommand1r is now known as NCommander [04:34] This has got me brain stumped. [04:34] Trying to figure out why apache is user bound to the user id 33 [04:34] driving me ape [04:36] xorl: that's the user id for it? [04:36] micahg: yeah, I have literally changed the www-data users name [04:36] xorl: why? [04:36] restarted apache, it took the name on, so it's some how bound to the straight uid [04:37] micahg: custom layout [04:37] I run 2 apache processes as different users (different access rights) [04:37] 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] was gonna rebuild the package but haven't found where said binding takes place [04:38] xorl: probably a better question for #ubuntu-server or #httpd [04:39] micahg: will head over there [06:17] Good morning [06:18] 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] superm1: this is for the case right after install when the apt cronjob didn't run yet [06:18] and thus any package info query fails [06:19] 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] 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] superm1: yeah, maybe; it looks very expensive, though, since you need to iterate through thousands of package records? [06:22] pitti, well if you hit the first one and it's valid it's inexpensive... [06:22] superm1: right, but it won't right after installation [06:23] 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] then it could try to fetch the indexes again [06:23] superm1: what is your use case? add a ppa and call jockey, but not run apt-get update in between or so? [06:25] 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] so the idea is that it's easy to feed new/updated drivers into jockey by doing it that way === astralja1a is now known as astraljava [06:27] 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] superm1: hm, jockey already supports adding new repositories in handlers [06:31] pitti, well this isn't just for jockey, it's actually so that ubiquity can install out of this pool too [06:31] 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] superm1: so the problem in this case is that jockey fetches indexes again, although you don't want it ti? [06:32] s/ti/to/ [06:32] pitti, that's what it eventually boils down to, yes [06:33] superm1: we could perhaps also check glob('/var/lib/apt/lists/*_Packages') != [] ? [06:34] superm1: since bash is an approximation anyway, this will do as well [06:34] pitti, that sounds like a saner way to go about it to me [06:34] I tried to avoid making assumptions about apt's internals, but this is fine for me [06:41] superm1: hm, I wonder if after an installation you would have a CD-ROM source [06:42] pitti, in my scenario? it should be irrelevant i think since any drivers that were available will be installed [06:42] superm1: no, I mean for the original bug [06:43] pitti, i dont think i've been seeing a cdrom source after installs in installs i've done lately [06:44] i thought apt-cdrom used udev now for some of that magic too [06:46] yes, I think so, too, but I think I'll do another test install to be 100% sure === free` is now known as free === tkamppeter_ is now known as tkamppeter [08:05] elmo, hi === debfx_ is now known as debfx [08:39] pitti, hi [08:39] hi tkamppeter [08:40] Can you have a look at bug 465916? [08:40] Launchpad bug 465916 in cups "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [High,Triaged] https://launchpad.net/bugs/465916 [08:40] It is about the problem of CUPS not broadcasting via DNS-SD/Zeroconf since 1.4.x. [08:42] James Troup (elmo?) asks for how much work it is to solve this problem. [08:43] pitti ^^ [08:45] 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] tkamppeter: you mentinoed that you got cups to build with the compat library with very few code changes [08:57] 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] cjwatson: ah, thanks [08:58] 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] With my changes I got it compiling with the result of a cupsd which did not broadcast. [08:59] tkamppeter: ok, that's not very useful then [09:00] pitti, the Red Hat patch only makes CUPS' dnssd backend working with the Avahi compat library, not the CUPS daemon. [09:01] tkamppeter: hm, I thought it was the backend which would do the detection of bonjour-advertised printers on win/mac boxes? [09:01] and not the daemon itself [09:01] tkamppeter: or is it broadcasting cups' printers to mac/win over bonjour, i. e the other direction? [09:01] ah, apparently it is, silly me [09:02] 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] right, and this direction works AFAIK? [09:03] 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] The first works. If you run /usr/lib/cups/backend/dnssd, you see entries from network printers which use DNS-SD. [09:04] pitti ^^ [09:04] right, got you [09:14] pitti: the archive is still frozen (as per topic), right? If so, were the uploads that I see in lucid-changes approved? [09:15] any uploads land in the unapproved queue, so they must have been approved [09:16] speaking of which any eta for unfreeze? [09:16] universe uploads are still being waved through [09:16] seb128: a few hours, I think [09:16] cjwatson: ah, ok, that's what I wanted to know. Thanks [09:16] I feel uncomfortable having an hundred of uploads landing in lucid after beta just when every runs away for weekend [09:16] cjwatson, ok thanks [09:16] Could always not run away :) [09:16] everybody [09:17] persia, well experience tell me that people will not stay on friday night just to see if nothing breaks [09:17] seb128: Sadly, my experience parallels yours. [09:50] cjwatson, so an archive admin could do a sync to universe if they felt like it, despite the freeze? [09:52] yes, though I'd expect most archive admins to have other priorities just at the moment === jpds_ is now known as jpds [09:54] yeah, that was my guess [10:01] pitti, in bug 465916 Mark Shuttleworth suggests to package libdns, but I have told Mark that we are after FF. [10:01] Launchpad bug 465916 in cups "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [High,Triaged] https://launchpad.net/bugs/465916 [10:04] tkamppeter: but I guess that would also need new code in avahi to actually use it, no? [10:04] tkamppeter: or does cups already have that code, and will use it if it's there? === Guest58723 is now known as Lutin [10:29] 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] ah, this is like a parallel implementation of avahi then? [10:30] 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] Yes, avahi did their own implementation of libdns (and our package installs it as /usr/lib/libdns.so.*) but incompletely. [10:31] pitti ^^ [10:32] tkamppeter: I think libdns.so.* is from bind9 [10:33] avahi is libdns_sd.so [10:34] pitti, sorry, thanks. I mean indeed libdns_sd.so. [10:50] pitti, will it be possible to have CUPS using the native libdns and all the rest using avahi compat? [10:50] 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] lucas: yes [10:51] even for releases like 10.04.1? [10:51] 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] yes [10:51] perfect, thanks [10:52] lucas: what's this for? if we ever change it, I'll try to remember to let you know ... [10:52] 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] right === andreasn_ is now known as andreasn [11:07] tkamppeter: we'd need to name the libdns one differently [11:07] tkamppeter: or, as you say, add it to the cups package and link statically or so [11:07] tkamppeter: but I don't fancy a parallel implementation of avahi a lot, TBH [11:11] Keybuk: console-setup 1.34ubuntu12 should with any luck be a fraction more efficient [11:11] I can't see console-setup-tty on my bootchart any more [11:17] 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] tkamppeter: if libdns is a superset of the avahi API, then we can perhaps discuss that for lucid+1 [11:20] 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] (as a system library, I mean) === Johnm is now known as g-unit === ogra_ is now known as ogra === matti_ is now known as matti === mnepton is now known as mneptok [11:35] pitti, so for Lucid the only way is to take the lib into the CUPS package and link it statically. [11:36] tkamppeter: yes, that or rename the installed library [11:36] tkamppeter: but I wouldn't like to give a blanket exception for including libdnsf [11:36] s/f$// [11:36] it doesn't seem to be a small harmless library after all [11:37] 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] so this should get a proper MIR/FFE [11:37] tkamppeter: no, please package it separately; it's way too messy otherwise [11:38] renaming the library sounds better [11:38] tkamppeter: forward-porting the 1.3 cups code for broadcasting is out of the question? [11:39] tkamppeter: (the receiving direction alreayd works fine with avahi, so no reason to touch that) [11:40] 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] 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? === nixternal_ is now known as nixternal === apachelogger_ is now known as apacehlogger === MacSlow is now known as MacSlow|lunch === g-unit is now known as Johnm [12:59] 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] Is there any way to request a specific builder? [13:00] 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] jcastro: ping [13:01] persia: ... that's not a command mortals can use though? [13:01] mok0: No. Only buildd-admins [13:01] persia: ... and you can't upload a binary package to the ppa I guess [13:02] 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] persia: The purpose would be to get the binary into the PPA [13:02] persia: now that it won't build === apacehlogger is now known as apachelogger === Chex_ is now known as chex [13:22] pitti: there? [13:35] hi kitallis [13:37] pitti: so apart from https://wiki.ubuntu.com/Apport/DeveloperHowTo ; any other documentation i can look at? [13:37] kitallis: what do you want to do? [13:40] well, I want a way to access the crash report url it generates [13:41] kitallis: "access"? [13:41] kitallis: CrashDB.get_comment_url() generates that [13:41] I obtain, grab the randomized key [13:41] for a particular crash dtabase [13:41] such as apport/crashdb_impl/launchpad.py [13:42] ah [13:42] okay. [13:42] that should do. [13:42] thanks === jbernard_ is now known as jbernard === sconklin-gone is now known as sconklin === jamie is now known as Guest44677 [14:18] Riddell, Keybuk: what can I do to trigger the problem with kdm and plymouth using the latest updates? [14:19] (of course I have rebuilt kdm with my patch) [14:19] tseliot: which problem? [14:20] Keybuk: the one that was blocking the beta [14:20] it's kinda tricky [14:20] we fixed it in a way that ensures you can't trivially get it back ;) [14:20] but you could, for example [14:20] plymouthd [14:20] plymouth --show-splash [14:20] plymouth quit --retain-splash [14:20] kdm [14:20] in a console [14:20] ah, let me try [14:23] Keybuk: plymouthd seems to be still active but kdm showed up correctly [14:24] err, if plymouth is active, you didn't get it right :p [14:24] you did quit before kdm ? [14:25] right, there's something wrong [14:25] * tseliot checks his patch [14:26] ah, wait there's the kdm log [14:28] your patch? [14:28] sorry, you've completely confusde me [14:28] what patch? === dendrobates is now known as dendro-afk [14:30] Keybuk: here's what the log says: http://pastebin.ubuntu.com/397840/ [14:30] tseliot: wait, rewind a minute! [14:30] *what* are you trying to test? [14:30] * tseliot should look for another log [14:30] what patch have you written? [14:31] Keybuk: it's the plymouth_transition patch for kdm [14:31] yes [14:31] which has nothing to do with any bug we've fixed [14:32] the plymouth transition patch for kdm is about providing a seemless transition into kdm [14:32] Keybuk: but that patch would also make plymouth quit [14:32] yes [14:32] that's part of the transition [14:32] to test it [14:32] plymouthd ; plymouth --show-splash [14:32] kdm [14:32] you should see plymouth stop animating, a mouse cursor appear, then KDE [14:32] with no black screen in between [14:32] and plymouthd should exit === NCommand1r is now known as NCommander [14:33] 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] Keybuk: no, I'm seeing this: splash -> black screen + loading cursor -> kdm [14:36] so, I did something wrong in my patch [14:37] as plymouthd is still on [14:37] but I would like to find the actual log to see what's happening [14:38] right [14:38] syslog? === mbarnett` is now known as mbarnett [14:39] 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] no wonder plymouth is not stopped === dendro-afk is now known as dendrobates [14:53] Someone else with connection problems when trying to upload to a launchpad ppa with dput? I keep getting [Errno 111] Connection refused. [14:57] 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] Never mind, launchpad FTP seems to be up again... [14:59] radoe: these type of questions are usually answered more quickly on #launchpad [15:00] xnox: well thx, just found the channel. [15:02] tseliot: there isn't a transition with nouveau [15:02] well, not as complete a one as -intel anyway [15:02] but yes, you need -nr [15:03] actually, sorry, that was misleading - you still should get a smooth transition into X [15:03] but it's not done using proper kernel buffers [15:06] 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] right, I think nouveau supports -nr [15:06] was trying to remember ;) [15:08] Keybuk: as you said, things were implemented properly in -intel though [15:09] bryceh: hey - why did you target bug #540519 ? do you know more aobut it (like e.g. how to reproduce)? [15:09] Launchpad bug 540519 in software-center "software-center crashed with SIGSEGV in webkit_web_view_execute_script()" [Undecided,Confirmed] https://launchpad.net/bugs/540519 [15:10] mvo, btw I want to sync new webkit from debian, what do you think about updating? [15:10] mvo, I think they are working toward a 1.2 stable serie [15:10] seb128: fine with me [15:11] seb128: I assume you do basic testing first ;) [15:11] 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] still no transition with -nr. I should try with gdm [15:14] Keybuk: I'm getting no smooth transition with gdm either. I'll test with -intel [15:16] mvo, ok [15:19] Keybuk: I haven't ported the save_root_window patch which I guess it's the missing bit now [15:20] tseliot: I was never sure what that did [15:20] I think the purpose of that is to put the root pixmap in a special id [15:20] so when nautilus comes along later, it sees that [15:20] and rather than just painting its desktop image, it does a fadey transition [15:20] (which we have disabled atm anyway0 [15:23] Keybuk: right, gnome-settings-daemon was supposed to use that to create a cross fade effect [15:26] Keybuk: http://blogs.gnome.org/halfline/2009/11/28/plymouth-⟶-x-transition/ [15:37] tseliot: yes, I've read it ? [15:37] it's way out of date now [15:38] Keybuk: yes, of course but it explains the purpose of the save_root patch, which we don't need [15:38] right [15:38] well, that we don't use ;) [15:39] in a matches-what-I-said kind of way ;) [15:39] yep === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === robbiew_ is now known as robbiew === beuno is now known as beuno-lunch === dendro-afk is now known as dendrobates [16:15] haha #debian-dev is invite only [16:15] debian is superior [16:15] we are proud of debian, Ubuntu is winky dinky distro === deryck is now known as deryck[lunch] [16:20] (now it's invite-only for him - well, until he changes his IP address, but anyway) [16:26] mvo: I punted bug 420307 to beta-2 - are you on the hook to review that? [16:26] Launchpad bug 420307 in computer-janitor "computer-janitor-gtk crashed with SIGSEGV in gdk_window_set_geometry_hints()" [Medium,Confirmed] https://launchpad.net/bugs/420307 [16:27] cjwatson: sure [16:27] thanks [16:27] cjwatson: there is a FFe comming from barry for computer-janitor 2.0 [16:27] with dbus support [16:28] is this reproducable on your system? [16:28] I would bet its threading [16:28] and dbus makes it go away [16:31] no idea, just looking through our stale beta-1 work items ... === beuno-lunch is now known as beuno [16:34] ok === slangasek changed the topic of #ubuntu-devel to: Lucid Beta 1 released! | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === emma_ is now known as emma [16:49] mvo, yeah I reproduced it after clicking on a few "More Info" buttons - no info showed up [16:49] bryceh: is it crashing? [16:49] bryceh: or "just" not showing anything, if the later its likely just *very* slow [16:50] bryceh: that is bug #514879 [16:50] Launchpad bug 514879 in software-center "details update very very slow" [High,Triaged] https://launchpad.net/bugs/514879 [16:50] as in "several minutes" [16:50] mvo, don't recall seeing any particular slowness. [16:50] anyway, gotta run (pdx downtown meeting today). hth [16:51] ok [16:52] 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:52] Launchpad bug 531518 in python-apt "Feature Freeze exception request" [Undecided,Confirmed] https://launchpad.net/bugs/531518 [16:53] 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] mvo: if we can get this fixed, I'm fine with it [16:53] I can fix that [16:54] if it's not intended to be changed, it's also okay, but we need to watch out for regressions then [16:54] the verbosity [16:54] we have p-apt being used a lot, perhaps also in eucalyptus scripts and whatnot [16:54] mvo: thanks [16:54] well, the goal is to be 100% compatible [16:55] 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] mvo: *wipes off a tear* that'd be perfect, thanks! [16:55] pitti: :) np [16:56] if beta1 is released is there any reason to not unfreeze? [16:56] 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] Sarvatt: and do we have that code too? [16:57] yeah [16:57] maybe something else is broken here then [16:57] i see a couple of other situations where you might not see a transition [16:58] if the fb depth is different it wont copy it [16:58] :-/ === yofel_ is now known as yofel [17:01] there any warnings in the Xorg.0.log tseliot? [17:02] looks like most of the failure paths copying it will print something in the log at least if it happens [17:03] Sarvatt: I don't think I saw any errors. Let me try again [17:05] 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] slangasek: that change is cosmetic i think [17:06] Sarvatt: nothing, apart from these lines [17:06] (--) Depth 24 pixmap format is 32 bpp [17:06] (EE) NOUVEAU(0): Error creating GPU channel: -19 [17:06] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel [17:06] 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] ah tseliot give me the dmesg please [17:06] slangasek: ok i can change that [17:06] zul: oh; it had claimed to fix a bug, and I couldn't see how [17:07] slangasek, can we unfreeze lucid if beta1 is there? [17:07] seb128: the LOSAs can - I've requested this [17:07] slangasek, thanks === deryck[lunch] is now known as deryck [17:08] noaccel = no smooth transition afaik, should be able to figure out why from your dmesg [17:09] 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] Sarvatt: http://pastebin.com/QTP2zURs [17:10] tseliot: nvidia isn't blacklisted on your system? [17:11] 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] Sarvatt: that was the output of dmesg > myfile [17:13] tseliot: try blacklisting nvidia, update-initramfs -u and reboot? [17:13] Sarvatt: nvidia is not loaded and in dmesg nvidia complains that it couldn't load nvidia (obviously because of nouveau) [17:17] tseliot: you're right, nevermind, I see the exact problem in your log [17:17] your card isn't supported yet [17:18] basic 2D but not acceleration [17:18] [ 6.856086] [drm] nouveau 0000:02:00.0: I don't know how to make a ctxprog for your NVa3 card. [17:20] tseliot: info for that card is desperately needed in #nouveau [17:20] Sarvatt: ok, that's definitely a problem [17:20] ah [17:20] they couldn't find anyone with one of those to do a mmiotrace so they can support it [17:29] directhex, what does bug #536925 break in f-spot exactly? [17:29] Launchpad bug 536925 in gnome-keyring-sharp "gnome-keyring-sharp uses deprecated socket interface; apps cannot use keyring" [Critical,Confirmed] https://launchpad.net/bugs/536925 [17:29] Keybuk: do you happen to have an mmiotrace enabled kernel? [17:29] for lucid [17:30] tseliot: not on me [17:31] heh [17:31] * ogra pokes mountall [17:31] didn't apw enable it in git now? [17:31] so you should just be able to build from there [17:32] Keybuk: yep, Sarvatt has just given me the link [17:32] he enabled it in the kernels we're testing for intel powersave issues - http://people.canonical.com/~apw/i915-fbc-broken-lucid/ [17:35] Can someone unfreeze the archives? My uploads still say "Waiting for approval". [17:35] tkamppeter: It's been requested. It takes a bit. [17:35] 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] slangasek, thanks, it is foo2zjs. [17:39] tkamppeter: it won't go appreciably faster for any single package :-) [17:40] hmm. Looks like http://www.ubuntu.com/testing/lucid/beta1 mentions the wrong version for nvidia-current [17:43] Would someone be so kind to NEW the linux-ti-omap kernel? [17:52] pitti, hi [17:55] [./plugin.c] flush_area:palette has 345 colours [17:55] tseliot: ^ you greedy person, you [17:55] Keybuk: lol [17:55] * tseliot wants more colours [17:58] clearly === sconklin is now known as sconklin-afk [17:59] Keybuk: you should be content with your 16 colours :-P [18:00] yes, but when I wrote a quick "best fit" palette [18:00] I got mostly white [18:00] no aubergine in sight [18:00] 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] a clear sign that the logo was designed by a woman as only women can distinguish that many colours :) [18:02] Sigh. [18:03] 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] geser: I'll tell Otto you called him a woman === doko__ is now known as doko [18:08] pitti: I'm replacing tk8.4-dev with tk8.5-dev in supported-development-desktop [18:16] 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] Launchpad bug 13 in baz "empty signing rules lead to invalid checksums" [Medium,Fix released] https://launchpad.net/bugs/13 [18:16] arg. [18:17] 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] Launchpad bug 533224 in nvidia-graphics-drivers "fan speed issue in 195.36.08 and 195.36.03 (may potentially destroy the GPU)" [Medium,Fix committed] https://launchpad.net/bugs/533224 [18:17] Pici: it doesn't depend on me [18:17] tseliot: oh? Who should I bother? [18:18] cjwatson, slangasek: uploads are being processed now, right? [18:20] tseliot, yes [18:20] tseliot, see -changes and buildds [18:20] seb128: ok, thanks [18:21] Pici: you'll have to wait for a while I guess, until my upload is processed [18:21] tseliot: Okay :) [18:21] Just wanted to be able to give a status to people who ask. [18:38] Does every package that goes into -updates go through -proposed first? === radoe_ is now known as radoe [18:40] jbebel: some go through -security instead; all go through one or the other [18:41] -security is automatically bulk-copied to -updates provided that there isn't a conflict [18:41] Ok. I'm less concerned about -security. If every non-security package goes through -proposed, that's good enough. [18:41] right [18:41] 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] https://wiki.ubuntu.com/ArchiveAdministration#Moving%20Packages%20to%20Updates prescribes 7 days [18:42] occasionally an exception is made to that, but not often [18:42] Excellent. Thanks. === maxb_ is now known as maxb [18:43] exceptions tend to be things like tzdata, for which we occasionally get very little notice of political changes [18:57] can anyone from the release team please review bug #407722, since it contains a security fix? Thank you. [18:57] Launchpad bug 407722 in lighttpd "[FFe] Please merge lighttpd 1.4.26-1 from Debian testing" [Wishlist,New] https://launchpad.net/bugs/407722 [19:14] zul: this vsftpd upload seems to not have the debian/vsftpd.apport file [19:14] (accepted anyway, but if it doesn't FTBFS, at least the bug is still open...) [19:14] slangasek: k [19:37] anyone happen to know why the new thinkpads no longer have the FHD lcd option? [19:57] james_w`: Just saw jono blog post =) Didn't I like ask you about it yesterday? =) [20:05] mdeslaur: wanna go chime in on bug 530107 for me? [20:05] Launchpad bug 530107 in bind9 "Please sync bind 9.7.0.dfsg.P1-1 from debian" [High,Confirmed] https://launchpad.net/bugs/530107 [20:06] tseliot: so I managed to get a 12-color palette that works [20:07] Keybuk: 12? Lazy boy :-P [20:07] http://people.canonical.com/~scott/palette.html [20:08] Keybuk: they should be enough for the theme, I guess [20:08] seems to be [20:08] apart from the shades of white that you mentioned [20:08] screenshots? [20:08] 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] so you have sufficient unique 6bpp colours to fit in a 4bpp palette [20:09] hard to take screenshots of VGA output ;-) [20:09] you can use a camera [20:10] wouldn't really show the theme [20:10]