[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<EMAIL_ADDRESS>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 ..."


[00:22] <roaksoax> infinity: cool, thanks for the info I'll try either
[00:23] <roaksoax> s/either/both
[00:34] <smoser> sabdfl, thanks.
[03:50] <chelz> is there anything like a preview release of beta 2 that is bootable? (besides beta 1)
[03:50] <chelz> the daily builds i'm guessing aren't guaranteed to boot
[04:12] <ScottK> chelz: They aren't guaranteed, but AFAIK should be pretty good.
[04:12] <ScottK> I booted yesterday's dailies just fine.
[04:13] <chelz> ah alright. is there any archive of previous daily builds so i could try older ones if the latest doesn't work?
[04:14] <ScottK> Yes.  If you look at cdimage.ubuntu.com and the directory with the type of image you want, you'll see a few days worth.
[04:17] <chelz> ScottK: ahh neat, thanks
[04:17] <ScottK> You're welcome.
[07:07] <PaoloRotolo> Hi all!
[08:27] <tumbleweed> bdrung: why did distro-info FTBFS? it test built for me...
[08:28] <tumbleweed> ah, I probably wasn't using distro-info-data 0.7
[11:19] <bdrung> tumbleweed: year 2038 bug on i386. i will fix it
[11:46] <tumbleweed> bdrung: ah :)
[13:18] <erguerghii> Hello*
[13:19] <erguerghii> I would like to report a bug, because I can't use Launchpad and Apport doesn't work.
[13:20] <jelmer> erguerghii: what about launchpad isn't working?
[13:20] <jelmer> (you might want to talk to us in #launchpad, that's a more appropriate channel than #ubuntu-devel)
[13:21] <erguerghii> jelmer: Just because I already have a account and I lost the old password and e-mail, and I want not to create a new account :/
[13:21] <erguerghii> ok for #launchpad
[15:50] <dr3mro> I know basic vala GTK / GLADE  and good experience in python GTK .. but I need to focus on one programming language to master it as I  take it as hobby only and I work as a physician but enjoy programming when I have some little free time in my vacation.... so do you suggest me continue the vala way or go python way .. for the future ot ubuntu develeopment what will be most widely used vala or python ??
[16:27] <ScottK> jelmer: Do we want to sync evolution-mapi from Debian?
[18:39] <jelmer> ScottK: not as-is, as unstable has a newer openchange that is incompatible with the current version of evolution-mapi in sid
[18:39] <ScottK> jelmer: OK.  Do we want to update samba4/openchange/evolution-mapi before release?
[18:41] <jelmer> ScottK: ideally, yes (probably would have to include ldb too though).
[18:41] <ScottK> OK.
[18:41] <ScottK> Could you prepare an FFe that explains what's needed?
[18:41] <ScottK> That seems like an area where having the latest crack for release is generally a good idea.
[18:42] <jelmer> ScottK: Yeah, I agree
[18:43] <ScottK> If you could put that together, it would be helpful.
[18:43] <jelmer> I've been holding off on that mostly for (irrational?) fear of having to deal with a large number of FFe and limited spare time
[18:43] <jelmer> *FFEs
[18:44] <jelmer> I'm happy to prepare the FFes though, and at least try.
[18:44] <ScottK> Make it one bug that explains them all together.
[18:44] <ScottK> Since it's interlinked it makes more sense to review it that way anyway.
[18:45] <jelmer> ok
[21:50] <Bluefoxicy> what do I do if reproducing a bug is doable with copyrighted content?
[21:50] <Bluefoxicy> on VLC I can watch Yu Yu Hakusho rip in english
[21:50] <Bluefoxicy> in Totem it plays in Japanese
[21:50] <Bluefoxicy> I found the sound track thing in totem, but when I switch to English it plays music, and when someone talks it mutes all audio until they shut up
[21:51] <Bluefoxicy> obviously, totem or gstreamer has no idea how to handle multiple audio tracks...
[21:51] <Bluefoxicy> ... also obviously I can't just attach non-distributable copyright material to bugs o.o
[22:03] <JanC> Bluefoxicy: I'm pretty sure that in most countries providing copyrighted content (which you have a legal copy of) directly to a developer (so not attached to a public bug report) for debugging purposes is fine
[22:04] <JanC> Bluefoxicy: alternatively, provide a very short "citation"?
[22:06] <JanC> Bluefoxicy: is it supposed to play multiple audio tracks in parallel?
[22:22] <Bluefoxicy> JanC: no it has English and Japanese voice acting for different markets
[22:26] <JanC> Bluefoxicy: hm, I've seen files with multiple audio tracks and apart from having to choose the right one manually (as Totem doesn't seem to be very clever about that) it always worked for me (not really tested on precise though)
[22:57] <lifeless> barry: mailman, storm, datetime
[22:57] <lifeless> barry: are you using postgresql ?


[00:59] <guiverc_t> UWN doc looks empty; but if two week ed; should contain the planet stuff i added last week; summary written & stuff from last week... ?
[04:05] <pleia2> guiverc_t: it was added to the wiki already
[04:05] <pleia2> s/added/moved
[04:06] <pleia2> so this week's stuff will just be added on there later
[04:24] <guiverc_t> thanks pleia2 - didn't think of wiki :)


[04:50] <austin6598> is there any way to get click lock in kubuntu?
[07:20] <lordievader> Good morning.
[08:29] <nveselinov> Hello, I have Ubuntu 15.04 - how to install old KDE(4)?
[08:30] <lordievader> nveselinov: For as far as I know, you cant without reinstalling 14.04.
[08:31] <nveselinov> :(
[12:42] <BluesKaj> Hiyas all
[18:19] <hangman13us> hey all.
[18:19] <hangman13us> I have sort of a problem. I run my PC on Kubuntu 15.04 and I use Grub to switch win 8.1 and Kubuntu.
[18:20] <hangman13us> My Windows totally is totally f**ked and I decided to remove it completely. I'd like to use my windows part of the HDD
[18:21] <hangman13us> To format it and to store there stuff I download using my Linux.
[18:21] <hangman13us> And recommendations how to do this? I don't really have access on these partitions when I'm in Linux/
[18:31] <mrbinaer> hangman13us: Hey!
[18:32] <mrbinaer> hangman13us: If u want a graphical solution, you can use the KDE Partition Manager and format your windows partition.
[18:46] <hangman13us> I'm not too advanced in Linux so graphical solution maybe better than codes in konsole.
[18:47] <hangman13us> I will search in the net for this application, thanks mrbiarer
[18:47] <hangman13us> @mrbinaer
[18:53] <mrbinaer> hangman13us: no problem
[20:38] <ubernoob> hi. anyone know how to change the application launcher icon?
[20:51] <akasic> hey ubernoob
[20:51] <ubernoob> hello akasic
[20:51] <akasic> u can try to
[20:52] <akasic> go to ->   /usr/share/icons/breeze/apps/toolbar/
[20:52] <akasic> and then the kde.svg
[20:52] <akasic> u can put some other there with the kde.svg name
[20:53] <akasic> a png or similar, but if its not svg wont scale probably
[20:53] <akasic> try to replace it, if not work ill search more
[22:01] <aadrujinin> Чего за тема?
[22:52] <MichaelP> What plasma version and Qt version will 15.10 release with ?


[02:32] <jbailey> doko: Got bored this morning and decided to take out glibc bugs? =)
[02:35] <doko> jbailey: it's afternoon ;-P
[02:35] <jbailey> =)


[00:43] <grepory> is there a google calendar or something that i can subscribe to that will give me bugdays and the like?
[00:43] <grepory> because that, my friends, would be awesome.
[00:47] <mrooney|w1> grepory: that is true, a calendar with bugsquad/control/qa meeting would be neat
[00:48] <grepory> mrooney|w: super useful.  and bug days.  basically any of these events that i get e-mails about.  or even just attaching ics invites would be handy.
[00:52] <hggdh> I think there is one somewhere...
[00:54] <hggdh> well here it is: http://fridge.ubuntu.com/calendar but it is not listing bugsquad meetings right now (we moved out of -meetings into here
[00:54] <micahg> I thought they were thinking about that with the fridge
[00:55] <grepory> nice
[00:55] <grepory> that is so awesome
[00:57] <grepory> i guess a separate QA calendar that isn't so noisy would be nice, too.
[00:57] <grepory> or i can just turn off the ubuntu calendar when i don't want to see it. :)
[00:58] <grepory> or just copy events from the fridge calendar to a calendar of my own when i want to attend.  regardless.. very nice.
[01:21] <grepory> should bug 358339 be set to confirmed?  i'm not sure there needs to be more action taken on it
[01:21] <ubot4> Launchpad bug 358339 in notify-osd "Use a slight gradient in notifications" [Wishlist,New] https://launchpad.net/bugs/358339
[01:22] <crimsun> it's already assigned to someone, so i'd let mpt adjust status
[01:22] <grepory> kk
[01:23] <grepory> i think that most of the remaining new bugs are in situations like this one.
[01:23] <grepory> or not.
[01:30] <micahg> If anyone thinks that bug 406454 would be helpful, maybe you should select This bug affects me too
[01:30] <ubot4> Launchpad bug 406454 in malone "[Usability] cannot figure out in which package version a fix was released" [Undecided,Confirmed] https://launchpad.net/bugs/406454
[01:31] <hggdh> just did it
[01:31]  * kklimonda too :)
[01:32] <kklimonda> I also don't like that package branches are linked to bugs :/
[01:33] <micahg> hmmm
[01:33] <micahg> that can be helpful for packagers :)
[01:33] <micahg> so they don't have to work to hard to patch something
[01:34] <micahg> you can just branch the branch and then they can pull the revision with the patch (or something of the sort)
[01:35] <bdmurray> kklimonda: why don't you like it?
[01:38] <kklimonda> bdmurray: when I click on a branch linked to bug I'd expect to get to the page where I can see a branch that fixes a bug and not packaging branch linked to 3 dozens of other bugs
[01:40] <micahg> kklimonda: that's the branch home page
[01:41] <micahg> maybe LP 3.0 would have better UI
[01:41] <micahg> *will
[01:42] <micahg> kklimonda: on the LP-dev list, they are talking about 3.0 UI right now, maybe you want to sign up and comment?
[01:42] <kklimonda> micahg: I know where does the link take me. What I don't get is how is packaging branch linked to actual fix of a bug if it doesn't contain a fix itself and only a "metadata" (i.e. debian/ directory)
[01:43] <bdmurray> kklimonda: could you provide an example?
[01:43] <micahg> kklimonda: so whoever is going to fix it, knows where to pull the code from for the most updated version
[01:44] <micahg> AFAIUI
[01:44] <kklimonda> bdmurray: for example https://code.edge.launchpad.net/~ubuntu-desktop/transmission/ubuntu
[01:45] <kklimonda> bdmurray: now, I don't see a connection between this branch and fix for any SIGSEGV.
[01:45] <kklimonda> (for example)
[01:45] <micahg> kklimonda: it can load the latest upstream source code
[01:46] <micahg> and show you the latest ubuntu/debian dir associated
[01:46] <kklimonda> micahg: hmm?
[01:46] <micahg> so depending on where the changes are needed you can make them
[01:46] <bdmurray> these are more interesting
[01:46] <micahg> generally, an ubuntu fix will become a patch in the debian dir
[01:46] <bdmurray> https://code.edge.launchpad.net/ubuntu/+source/transmission
[01:47] <bdmurray> and https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic/transmission/karmic
[01:47] <kklimonda> bdmurray: I agree - here at least I have whole code so I can actually try to find a piece that fixes a bug
[01:48] <micahg> maybe the wrong branch was linked?
[01:48] <bdmurray> yes, that's what I would think
[01:49] <kklimonda> no, both branches - ~ubuntu-desktop/<package>/ubuntu and ~ubuntu-branches/<release>/<package>/ are now linked to bugs
[01:49] <micahg> kklimonda: maybe ask the maintainer of the branches the purpose?
[01:49] <kklimonda> (I think it's a step forward and so my understanding is that it's still work in progress..)
[01:53] <kklimonda> I think I'll have to take to james_w about his work on bzr-buildpkg and whole vcs-pkg idea. I'm really interested in it
[03:07] <crimsun> andresmujica: you probably want to idle in #ubuntu-audio-help
[03:07] <crimsun> since you're triaging these linux+pulseaudio bugs
[03:08] <andresmujica> done :)
[07:01] <dholbach> good morning
[09:32] <matti> *blink*
[14:28] <Awsoonn> fresh install of karmic with encrypted home, first login gives an error "Could not update ICEauthority file /home/dereck/.ICEathority" what package whould this be reported against?
[14:38] <dez> Hi, I just want to start helping on ubuntu development and thought the first step should be bugfxing. anyone can help me with some questions?
[14:39] <pedro_> dez, best place to ask is #ubuntu-devel
[14:39] <pedro_> here we discuss bug management rather than fixing
[14:39] <pedro_> look at the topic
[14:40] <dez> pedro_: sorry I have just joined this channel because I read it on bugsquad/gettingInvolved webpage
[14:42] <Awsoonn> dez: I'll take any questions you have in either channel
[14:42] <Awsoonn> welcome to the community :)
[14:43] <dez> Awsoonn: thanks :)
[14:43] <dez> Awsoonn: the point is that I am computer engineer and since I have beed using ubuntu for years I want to start helping
[14:44] <dez> Awsoonn: and I really don't know how to start... :P
[14:44] <Awsoonn> great! I assume you know c/c++?
[14:44] <dez> yes
[14:45] <Awsoonn> awesome, well the best way to start is to find somethign that annoys you and fix it. It's prety generic advice I know, but it works. :)
[14:45] <dez> Awsoonn: I assume there is a bug list or something like this, right?
[14:45] <Awsoonn> of course, http://launchpad.net
[14:46] <Awsoonn> there are a few 100,000 bugs there though
[14:46] <dez> cool! so this will be my entrance point... :)
[14:46] <Awsoonn> what kind of area of development are you most interested?
[14:47] <dez> I prefer working on core features, but for starting I will be glad to help on whatever needed
[14:49] <Awsoonn> cool, I am interested in the same area. You can do it to, my first patch ever was in apt afterall, and it doesn't get much more core than that. :)
[14:49] <dez> yes, you are right :)
[14:51] <dez> I supposse the first fix is hard to implement, mostly in the how-to-start and how-to-pack-it rather than the coding side
[14:51] <Awsoonn> *nods*
[14:52] <Awsoonn> you might even try fixing a typo for your firxt bug just to learn the workflow. :)
[14:54] <dez> I will check the buglist and then read some info. I will come back with more questions later
[14:54] <dez> many thanks Awsoonn :)
[14:54] <Awsoonn> anytime ;)
[14:55] <dez> Awsoonn, is there any page where the bugfixing workflow is explained?
[14:56] <Awsoonn> yes and no, there is a 'bug fixing tutorial' somewhere in there
[14:56]  * Awsoonn looks for the link
[14:57] <Awsoonn> https://wiki.ubuntu.com/Bugs/HowToFix
[14:58] <dez> Awsoonn, many thanks again.
[16:22] <ColdWind> cans omeone raise importance on bug #409673 ?
[16:22] <ubot4> Launchpad bug 409673 in poppler "latest poppler prevents pdftex/pdflatex from working correctly" [Low,Confirmed] https://launchpad.net/bugs/409673
[16:22] <ColdWind> seb128: ping? ^^^
[16:22] <seb128> ColdWind, changing status will not make any difference
[16:22] <seb128> it just needs sponsoring
[16:22] <ColdWind> it affects basic functionality of pdftex, pdflatex, kile, and probably other programs based on those
[16:22] <ColdWind> seb128: ok :p
[16:22] <seb128> try asking #ubuntu-devel
[16:23] <seb128> I would upload if that was not so much to download
[16:23] <ColdWind> thanks seb128
[18:26] <charles_> is there anyone here who can do admin-type work on brainstorm.ubuntu.com?
[18:27] <Pici> charles_: Have you tried asking in #ubuntu-brainstorm ?
[18:27] <charles_> yes, I'm asking there too :)
[18:28] <charles_> just trying to cast a wider net
[18:28] <Pici> Just making sure ;)
[18:33] <chrisccoulson> hggdh - can you trigger bug 413660?
[18:33] <ubot4> Launchpad bug 413660 in brasero "nautilus crashed with SIGSEGV in strcmp()" [Medium,Triaged] https://launchpad.net/bugs/413660
[18:33] <hggdh> chrisccoulson, under gnome it was immediate, and made the system unusable. Under kde, I could
[18:33] <hggdh> at will
[18:34] <chrisccoulson> hggdh - would you mind posting the output of "gvfs-mount -li" to somewhere like pastebin?
[18:34] <chrisccoulson> i can see where the issue is but i'm just interested;)
[18:36] <chrisccoulson> it seems to be related to the fact you have a GVolume without an associated unix device path, which is quite believable, but I'm not sure of what sort of volume that would be
[18:36] <hggdh> chrisccoulson, http://pastebin.com/f3525b313
[18:38] <chrisccoulson> hggdh - thanks
[18:38] <chrisccoulson> as suspected, you've got a volume with no unix-device property
[18:38] <chrisccoulson> that's wierd though :-/
[18:38] <chrisccoulson> would be good to attach that to the bugzilla report
[18:42] <chrisccoulson> hggdh - do you have a CD in your drive?
[18:49] <hggdh> chrisccoulson, I *should* not, let me check
[18:49] <hggdh> nope, no CD loaded
[18:50] <chrisccoulson> hggdh - thanks. i just chatted to davidz on #gnome-hackers and he said that nothing should assume that a GVolume has a unix-device property. so the fix i have on my computer here seems correct
[18:52] <hggdh> cool. Fix to libbrasero, or to Nautilus?
[18:56] <hggdh> chrisccoulson, if you want me to test it, no prob. I can build it here
[19:08] <chrisccoulson> hggdh - if you don't mind building it, the patch i was going to propose is here: http://pastebin.com/m49c24780
[19:08] <chrisccoulson> i've got to disappear to make some dinner now
[19:08] <hggdh> chrisccoulson, will build it
[19:08] <chrisccoulson> thanks:)
[19:19] <hggdh> ok, now building a2~ppa1 to test (locally)
[19:22] <hggdh> huh? I am getting "only garbage was found in patch input". Time to look at it :-(
[20:42] <hggdh> chrisccoulson, it works. At least, so far ;-)
[21:03] <chrisccoulson> hggdh - thanks for testing. it's fixed upstream now too, although there are some extra checks in the upstream fix too
[21:04]  * albert23 just verified the upstream patch :-)
[21:09] <hggdh> chrisccoulson, welcome. At least now I have a working gnome ;-). I guess we can wait for the upstream fix (we do have a bypass)
[21:10] <chrisccoulson> hggdh - upstream already fixed it too. i'm going to push the change to bzr now - probably not a good idea to wait for the next upstream tarball with this one ;)
[21:12] <hggdh> chrisccoulson, personally, I agree with pushing it now, since I am not sure on what conditions will cause the error (yes, I did understand the patch, but am still unsure on *why* I got it
[21:12] <hggdh> and a lot of people did not
[21:12] <hggdh> albert23, so you are all set?
[21:13] <albert23> hggdh: yes I am
[21:13] <hggdh> cool. One more bug bites the dust
[21:13] <chrisccoulson> hggdh, you got it because the GduVolumeMonitor on your machine lists a GVolume without a unix-device property (that's as much as I can say, as I'm not sure why that volume doesn't have this property though)
[21:13] <chrisccoulson> i chatted with davidz, and he said that property is not mandatory
[21:13] <albert23> hggdh: do you also see a non existing cdrom drive in nautilus? I think that might trigger the bug?
[21:13] <chrisccoulson> so it's totally normal for it to be not there
[21:14] <chrisccoulson> a non-existing cdrom drive could be related actually
[21:14] <chrisccoulson> you mean there is an icon for a drive which isn't there?
[21:14] <hggdh> chrisccoulson, yes. But I *do* have a DVD/CD unit
[21:14] <albert23> If I click it it says /dev/scd1 does not exist, which is correct, the real cd is scd0
[21:15] <chrisccoulson> albert23 - could you post the output of "devkit-disks --dump" and "gvfs-mount -li" somewhere (pastebin)?
[21:15] <chrisccoulson> hggdh - in your case then, i think there is probably no other issue than the brasero bug :)
[21:15] <hggdh> heh
[21:15] <hggdh> bloody brasero, mesays
[21:17] <hggdh> I correct myself -- there is a cdrom0, pointed to /dev/hda
[21:17] <chrisccoulson> hmmm, that is a bit wierd then
[21:19] <hggdh> I wonder if this is a left over, this machine has gone through Hardy to Karmic upgrades
[21:20] <albert23> chrisccoulson: http://paste.ubuntu.com/253344/ is devkit-disks
[21:21] <albert23> and http://paste.ubuntu.com/253346/ is gvfs-mount
[21:22] <chrisccoulson> do you have a CD drive anywhere in your /etc/fstab?
[21:22] <hggdh> there you go!
[21:22] <albert23> chrisccoulson: arg, yes indeed
[21:22] <hggdh> yay. Certainly a left over
[21:22] <chrisccoulson> could you try deleting it?
[21:23] <hggdh> http://pastebin.com/f6f3e1001
[21:23] <hggdh> much better, now
[21:24] <albert23> chrisccoulson: yes, it's gone now
[21:24] <hggdh> so, I guess, this might impact only users that have been upgrading since before devkit
[21:24] <chrisccoulson> albert23 - fantastic:)
[21:24] <chrisccoulson> yeah, i will mention this to pitti when he's back and ask him what he thinks
[21:24] <hggdh> btw, my fstab entry was for /dev/hda, so there
[23:04] <BUGabundo> hey guys
[23:27] <plars> bdmurray, or anyone else that might know... I'm curious if there are any documented policies concerning a pragmatic support to old bugs, for instance, bugs that say "hey I tested this daily build of {hardy, intrepid, jaunty, etc} and it won't install for me"
[23:29] <plars> is it realistic to go through the process of "install the final intrepid image and see if it was still broke", wait 3 months for them to never respond, then mark it invalid?  Or is there any problem with saying "hey, sorry this went so long with nobody responding, but we're in karmic now.  Would appreciate your further testing with karmic and file a new bug if it's still not working for you"
[23:34] <mrooney|w> plars: I think either is acceptable
[23:34] <mrooney|w> If the bug sounds easy to reproduce, I'd try to verify on a livecd / VM
[23:34] <mrooney|w> on Karmic
[23:35] <plars> mrooney|w: my particular issue is with bugs that are very very old, and on things like daily images for a past release cycle
[23:35] <plars> mrooney|w: right, on current release it's a whole different story
[23:35] <greg-g> the most common thing done is option 2, if it is fixed in Karmic/$DevVersionOfUbuntu and really important to backport to older supported releases, they can file  a SRU
[23:35] <mrooney|w> plars: yeah it doesn't matter so much if it is fixed in Intrepid final, unless it is important enough to warrant an SRU
[23:36]  * greg-g nods
[23:36]  * mrooney|w waves to greg-g
[23:36] <greg-g> heya mrooney|w, how goes?
[23:37] <mrooney|w> pretty good, how about yourself?
[23:38] <plars> to take the notion a step further...
[23:39] <plars> would it be worth considering writing a quick script to generate a list of all the bugs file before hardy development started
[23:39] <plars> exclude things like bug#1 of course
[23:39] <plars> and have a bug day where that list is searched for bugs that are obviously against versions where support has long expired
[23:39] <plars> and close them with some friendly stock reply
[23:40] <greg-g> mrooney|w: doing really good, actually. :)
[23:40] <plars> I don't think you could just script the whole process... there may be some things lurking in there that are clearly reaching further than the current release
[23:40] <greg-g> plars: bugs filed from that era could still be around
[23:41] <greg-g> no reason why a bug in vrsion 1.2 in some package isn't inherently  valid in version 1.9 in Karmic
[23:41] <greg-g> which is why we need someone to test the test case for each bug in Karmic
[23:41] <plars> greg-g: true, but I suspect there's a lot of cruft that could easily be removed
[23:41] <plars> packages that don't exist any more, image doesn't work, etc
[23:42] <greg-g> if the package doesn't edist anymore in any support Ubuntu version, then yeah
[23:42] <plars> additionally - unless someone is willing to go back and retest, the bug is not going to progress
[23:42] <greg-g> well, again,  the prefered/most common method is to test in development, and if fixed and need to backport, do an SRU
[23:42] <greg-g> no need to test old images of Ubuntu until the fix is in Karmic
[23:43] <greg-g> of course, I'm not the bugmaster
[23:43] <greg-g> :)
[23:43] <plars> greg-g: but in this case, if the bug was against a version for which an SRU can no longer be filed...
[23:43] <greg-g> plars: make sure that the bug is not present in Karmic, still.
[23:43] <plars> sorry, it's friday afternoon and I'm just being philosophical :)
[23:44] <greg-g> 'tis cool :)
[23:44] <greg-g> always test in Dev, move on from that outcome of that.
[23:48] <greg-g> does my reasoning make sense?
[23:49] <plars> of course, just thinking about the general volume of bugs problem
[23:50] <greg-g> yeah, that one is a tough one to deal with.
[23:51] <greg-g> I've mostly just tried to find packages that I use a lot myself and sign up for the bug mail so i can stay on top of it (in theory)
[23:51] <greg-g> we just need more of that and $some_awesome_new_process