=== jbicha is now known as Guest63357 === jalcine- is now known as Jacky === Jacky is now known as Guest58047 === Guest58047 is now known as Jacky === Guest63357 is now known as jbicha === jbicha is now known as Guest7463 === Guest7463 is now known as jbicha_ [05:19] Good morning [05:19] bdmurray: thanks, will do [06:01] Daviey: want me to remove nova from oneiric-proposed? it's superseded by a security update, right? [06:23] Riddell: rejecting lightdm-kde SRU upload; changelog says "Fixes LP: #", but no actual bug number [06:26] apw, ogasawara: why are we suddenly using "normal" SRU for the kernel again? (kernel in https://launchpad.net/ubuntu/precise/+queue?queue_state=1) === Jacky is now known as [Jacky] === [Jacky] is now known as Jacky [07:01] good morning === smb` is now known as smb [08:09] pitti, I heard Leann say something about day0 upload yesterday... [08:14] Anyway... errm... I think I see something very strange here... Doing an install of the desktop 64bit image in a Dell 1521 I got. Selecting install on the choice of try or install. Everything seems to go ok during install, but when I login there appears to be no launcher (left side) and terminal windows only half a line high (and not rezizeable)... checksumming the usb stick iso was ok, but I should re-download the image to be sure. This is 3d o [08:14] nly, 2d seems to work ok [08:16] smb: ok, so we're not using the usual kernel SRU process for that one; ok, will process in a bit [08:17] pitti, That is what I am guessing. You could wait for apw for confirmation to be sure [08:18] RAOF, In case you are still awake... The D1521 uses some ati (X1200 not the most current) and the radeon driver. In case there is something known about that... [08:18] pitti, yep that should be the day-0 kernel, i heard that would be going in via -proposed === jalcine- is now known as Jacky [08:25] apw: right, but all the other kernel updates are also going via -proposed, but are usually built in the PPA and have a tracking bug [08:26] apw: so we need to improvise a bit here and declare an arbitrary bug from the update as "tracking bug" where QA does the regression testing, etc. [08:26] pitti, ahh i see your point [08:26] so this kernel would actually build in proposed instead of in teh PPA as usual [08:26] I don't mind that, I'm more worried about the tracking bug and QA procedure [08:30] pitti, yeah, if we need to repurpose one of the bugs, i'd steal leanns own config change one ... [08:33] ev: http://people.canonical.com/~ubuntu-archive/apport-duplicates/apport_duplicates.db [08:34] ev: might be more convenient than having to parse the text files :) [08:34] pitti: cheers, I'll have a play with that [08:34] ev: it's what apport-retrace uses as -d argument [08:34] i. e. what python-apport crashdb.py API uses [08:35] Oh firetruck without the iretr... its the external monitor in mirror mode... [08:36] stats in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000954.html [08:36] for Q I propose that we abolish Fridays [08:36] and replace it with a second Tuesday [08:40] apw: ok, accepted linux, will accept the rest once linux built and is through binNEW -- old style [08:41] pitti, i thought the point of using -proposed in this context was that we could rely on the depwaits but ... i'll defer to you [08:41] apw: if lbm's build deps are set up accordingly, we can, yes [08:42] pitti, i'll investigate, but assume not :/ [08:42] ah, seems it is [08:42] ahh good [08:42] just chhecked the diff [08:42] apw: lbm refers to bug 978324, can you please make that public? [08:42] Error: Launchpad bug 978324 could not be found [08:43] apw: linux-meta doesn't bump build deps, so keeping that in the queue until linux and lbm are in [08:43] pitti, ack [08:43] apw: I assume it's private, but could also be a typo of course [09:36] cjwatson, Was apt_http_proxy= the magic to put on the grub command line of a desktop ? I sadly seem to forget over and over again by using mostly the alternate cd... :/ [09:38] smb: No. What are you trying to do? [09:39] cjwatson, Convince the desktop install to use a apt proxy (which I believe has no dialog box anymore) [09:39] Or I missed that miserably [09:40] changing the network proxy in control-center and clicking "apply system-wide" ought do do that; it doesn't any more? [09:40] ubuntu-system-service is supposed to set both the "general" proxy as well as the apt configuration [09:40] I haven't tested that in a while, though [09:41] smb: desktop => not my department [09:41] oh, sorry, installer [09:41] Well for the install ... meaning casper I do :) [09:41] * cjwatson learns to read [09:41] (also, probably not grub) [09:41] I know that feeling :) [09:41] smb: mirror/http/proxy= [09:42] cjwatson, Oh ok... yeah, for some reason I say grub when it is isolinux. Right that looks familiar [09:42] thanks [09:43] * smb tries to learn using the right terms... === G4MBY2 is now known as G4MBY === doko_ is now known as doko === MacSlow is now known as MacSlow|lunch === greyback is now known as greyback|lunch [11:21] should dh_installman use the -n option for zcat in order to allow manpages in a multiarch-enabled package, or should they always be shipped in a foreign -data package? [11:22] dh_installman doesn't do compression; that's dh_compress' job. [11:22] hmm ok [11:22] And dh_compress uses -n. [11:22] zcat decompresses, not compresses :-) [11:22] of course, duh [11:23] should dh_compress do the same in debian too? [11:23] Yes [11:24] ok maybe it's the manpage build going wrong then.. [11:24] need to double-check [11:24] Perhaps your upstream source is compressing stuff [11:25] Not entirely uncommon [11:25] according to the build log it shouldn't [11:35] it installs the manpages as uncompressed, but xsltproc creates a timestamp which obviously breaks it.. [11:39] right, would do [12:00] ok so debian doesn't have "multiarch metadata" for docbook, maybe that's the issue (the bug against sssd was filed on debian) === greyback|lunch is now known as greyback [12:03] umm, no [12:05] either strip the timestamp or move to a foreign package, preferably the former [12:05] yeah [12:05] how frozen are we? :) (unseeded package) [12:06] see the mailing list :) [12:06] ah there it is :) [12:07] ok I'll target -proposed, there are a couple of other changes too.. === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === jbicha_ is now known as jbicha === scottl-work is now known as scott-work === dendro-afk is now known as dendrobates [13:50] @pilot in === udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine === salem_ is now known as _salem [14:05] * dholbach hugs kenvandine [14:05] :) [14:05] kenvandine: great to have a fully open archive to play with, isn't it? [14:06] err.. wait [14:06] hehe [14:06] (I know, I know -- branch review, SRU, patch forwarding; SCNR) [14:06] there is always stuff to do :) [14:07] just doesn't feel as productive without actually uploading [14:07] well, cleaning the queue from stuff that we wouldn't upload anyway feels just as good [14:08] e. g. I saw a lot of manpage or pacakge description typo fixes there [14:08] i do have a universe upload i am sponsoring [14:08] which usually belong forwarded to Debian and not uploaded anyway [14:08] What is Ubuntu's policy about archival material, like old specs or blueprints in the wiki? Do we like to keep that stuff around, or delete it, or what? [14:09] mterry, ask jcastro :) [14:09] We don't care about archival material in debian/changelog [14:09] he would say delete, delete, delete [14:09] kenvandine, I know his answer :) [14:09] specs and stuff you should keep [14:09] kenvandine, but this is history, for future archivists! [14:09] in case we need to refer to them again [14:09] I'm all for keeping bluepritns and related wiki pages [14:10] the annoyance i have is i keep finding "specs" on the wiki that never actually got done [14:10] jcastro, you surprise me sir. I imagine you every spring throwing out all your belongings and buying new ones. :) [14:10] argh. lightdm is really horrible to debug. why won't it log me in?! [14:10] if they get in the way, maybe they might be retroactively moved to the namespace we use today, like https://wiki.ubuntu.com/DesktopTeam/Specs/Precise/ [14:11] mterry: it's for the "Ok who was the idiot that thought this feature was a good idea? Oh, it was me, 4 years ago, and here are my notes. Ok, maybe it is a good idea." [14:11] pitti, yar instead of the once-common just-have-them-be-toplevel-no-one-will-mind? :) [14:12] OK! Will keep. And maybe move. I wish the wiki had better support for redirects after moving something [14:17] I often refer either myself or other people to old specs [14:18] In fact I dug up a five-year-old (implemented) one as a reference for somebody else just yesterday === _salem is now known as salem_ === yofel_ is now known as yofel [15:09] great, so if your wallpaper is in your $HOME, and your $HOME is not readable by lightdm, unity-greeter hangs while trying to log you in [15:10] hahaha [15:10] i think i only hang out in this channel these days to hear things like that [15:11] and dear lightdm was so vague in its error messages that it took me over an hour of trial and error to figure this out [15:11] * hyperair sighs [15:12] and just my luck, it had been 7 days since i last logged in. [15:12] the change happened 7 days ago [15:12] whee [15:20] hyperair, I doubt that's true [15:20] something is broken on your system [15:20] seb128: what exactly? [15:20] hyperair, dunno, seems like the stat call is hanging rather than return a permission error? [15:20] the other day apt-get crapped up and removed gnome-session among a whole bunch of other packages [15:20] do you use nfs or something? [15:20] nope [15:20] dunno then [15:21] are you sure it's stat? [15:21] no [15:21] it looks like gdk_pixbuf_load_from_file() [15:21] but I'm sure it doesn't hang with my ecryptfs user [15:21] and that ends with an error [15:21] because after that it logs that there's an error loading the background [15:21] and it for sure fails to access the dir [15:21] right [15:21] problem is *after* that, it refuses to log in [15:21] that shouldn't "hang" anything though [15:21] yeah, it shouldn't [15:22] I've played with putting invalid background files to reproduce a bug on unity-greeter recently [15:22] maybe there's a race condition or something.. [15:22] the greeter just loads the default background when the one it wants is not accessible [15:22] yeah it does [15:22] it just refuses to log in [15:22] wfm [15:22] urgh [15:23] where should i begin debugging this? [15:23] we would have heard about it loudly if that was happening to everybody having non world readable user dirs [15:23] can you pastebin your /var/log/lightdm/lightdm.log? [15:24] it should have the auth, session start, etc steps [15:24] to see where it "stops" [15:24] hang on, lemme reproduce this again [15:24] i'll have to log out [15:24] also when you say "refuses to log in", does it bail out on an error? [15:24] and chmod -r [15:24] no it doesn't [15:24] or just hang on an empty background? [15:24] or...? [15:24] it just says "Logging in..." [15:24] and stops there [15:24] the password field vanishes [15:24] so you sudo chmod -r an user dir [15:24] replaced by the text "Logging in..." [15:24] and try to log into that user? [15:24] let me try on a test user [15:25] you have to change your wallpaper [15:25] to be inside $HOME [15:25] and then chmod o-r $HOME [15:25] i just tried with a wallpaper in /tmp, and that worked out fine [15:27] so user-only-readable home dir and custom wallpaper [15:28] hyperair, maco: wfm, I selected an image from ~/Images in the g-c-c panel, logged out, did a "sudo chmod o-r testuserdir" [15:28] logged in [15:28] works fine [15:28] hmmm [15:29] hyperair: do you have 700 or 770? [15:29] i wonder if its running as lighdm user and & you group [15:30] weirdly enough, i can log in now. [15:30] maco: 750 [15:30] were you running at 700 before, when logging in was failing? [15:30] seb128: aha. it doesn't work to just log out and log back in. you need to stop lightdm, and start it again. [15:31] maco: no, the one that works is 755. the one that doesn't is 750 [15:31] ok [15:34] this might be a race condition or something [15:34] it seems completely random [15:34] okay, not completely. it's biased more towards not working [15:35] I got it once here after doing a chmod 700 on the user dir [15:35] I can move between users on the login screen now but I can't type passwords [15:35] seems like an issue for mterry ;-) [15:35] * mterry reads [15:36] mterry, bug #987614 [15:36] Launchpad bug 987614 in lightdm (Ubuntu) "Stuck at login screen with status "Logging in..."" [Undecided,New] https://launchpad.net/bugs/987614 [15:36] mterry, seems like unity-greeter sometimes stay stucked on "Logging in..." after validating your password for user dirs with not world readable permissions when a custom wallpaper is set [15:37] mterry, i.e I got it there by setting a background from ~/Picture, doing a chmod 700 on the user dir and try to log in [15:37] seems bad [15:37] mterry, unity greeter wrote "logging in..." but never closed the greeter, I can move between users on the greeter screen now but not type anythin [15:38] will reproduce here [15:38] mterry, http://pastebin.ubuntu.com/945849/ is the bottom of the x-2-greeter.log [15:39] ignore the "fail to write" warning, that seems to happen for every login looking at that log [15:39] mterry, thanks [15:39] seb128: on my system, it seems to fail on every cold-start of lightdm. [15:39] i.e. stop lightdm, start lightdm [15:40] if, when it hangs, i do killall -u lightdm, the next attempt succeeds. [15:40] I didn't restart lightdm here, I didn't want to close my session [15:40] however, if i just kill unity-greeter, the next attempt continues to fail [15:40] right [15:40] weird [15:41] lemme try checking the lightdm before/after.. [15:43] mterry: okay, this seems to be related to pulseaudio. [15:43] wth? [15:43] stop lightdm; ps -u lightdm shows some lightdm-owned pulseaudio processes running [15:43] i.e. pulseaudio and the gconf-helper [15:43] if i kill those and start lightdm, it logs in [15:43] hmm [15:44] if i don't kill those before starting lightdm, it refuses to log in. [15:44] i'm going to try that /tmp/ wallpaper thing again to see if it's really the wallpaper causing the issue. [15:44] i think earlier when i did the /tmp/ wallpaper thing, i didn't restart lightdm [15:46] okay, this is really weird. [15:47] if the wallpaper is accessible, then even if the zombie pulseaudio/gconf-helper processes hang around, it logs in successfully. [15:48] * mterry reboots === salem_ is now known as _salem [15:54] * mterry looks for reproduction steps again; couldn't reproduce [15:56] mterry: set custom wallpaper in $HOME, chmod o-r $HOME; log out; sudo stop lightdm; sudo start lightdm; try to log in. [15:57] mterry, chmod o-r was not enough for me (or I got lucky on first try), I did chmod 700 [15:58] I didn't need to restart lightdm either [15:59] hyperair, seb128: I tried those steps (chmod 700), but without stopping lightdm and haven't gotten it yet [15:59] mterry, for me it was log into "testuser", copy an image to ~/Images, select if from the appareance capplet, log out, sudo chmod 700 testuser (the user dir), go up down on the unity-greeter, try to log in [15:59] seb128, that sounds like me [15:59] it worked the first time [15:59] I hit the bug on second try [15:59] I've tried a few times. Let me double confirm I have the setup right [15:59] try to log out and in again? [16:00] yar I did that. will do a few more [16:01] nope. ecryptfs isn't involved, eh? [16:02] my main user is using it, the test user isn't [16:03] same here [16:04] * hyperair uses dm-crypt, but that shouldn't bother lightdm imo [16:04] also, in all cases where this bug was triggered, gnome-session was not executed at all. [16:05] seems like something got wrong in the auth between the greeter and lightdm [16:05] i tried moving it aside and replacing it with a script that logged its output to /tmp thinking that might be the issue, but there was no output [16:05] the actual session start job never kicked in [16:06] I would assume lightdm is a in a weird state since it does hang on any auth until restart [16:06] like not even a guest session would start now [16:06] * mterry will try stopping and starting lightdm. will be back online in a bit [16:06] it does the same "login in..." and not login in behaviour [16:06] mterry, same here [16:12] hyperair: no luck still. is seb128 rebooting? === deryck is now known as deryck[lunch] [16:22] mterry, no luck reproducing it here now :-( [16:22] seb128, hah, I fixed it [16:23] mterry, oh? what was it? [16:23] New Ubuntu Instafix (tm) === carif_ is now known as carif [16:23] seb128, sorry, no joking [16:23] tssss [16:23] mterry, yeah, just got it :p [16:23] seb128, shouldn't get your hopes up :) [16:23] it took me a few seconds; I should wait before typing :p [16:23] mterry, I've bugs for you in any case :p [16:23] seb128, couldn't reproduce myself after rebooting or restarting lightdm [16:23] seb128, I was just starting to actually look at those gnome-settings-daemon crashes [16:24] mterry, good, I will not keep you away from that ;-) [16:25] mterry, I will open the small leaks valgrind found on unity-greeter in launchpad [16:25] seb128, oh nice [16:26] mterry, do you prefer one "you have leaks in your code" bug, or one bugs by leak? [16:26] seb128, one [16:31] mterry, https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/988409 [16:31] Launchpad bug 988409 in unity-greeter (Ubuntu) "small leaks in unity-greeter" [Undecided,New] [16:33] seb128, thanks! they might end up being vala bugs, but great to have a list [16:33] mterry, they could indeed, and they are mostly small ones, and the greeter usually doesn't run for days === _salem is now known as salem_ === plars_ is now known as plars [17:01] how do you extract real leaks from the horrible mess that valgrind produces with glib-using applications [17:01] ? [17:05] hyperair: I have nothing constructive to respond with, but that provides me yet another reason to avoid glib. :) [17:06] SpamapS, stop the trolling thanks [17:06] glib doesn't leak nor spam valgrind [17:06] doesn't it? [17:06] i've had gtk+ hello world applications showing a crapton of things [17:06] * SpamapS is only slightly kidding.. I use glib every day when I open up Terminator. :) [17:07] I've just been running unity greeter under valgrind for a several time, there is no noise from glib [17:07] hmm weird [17:07] hyperair, dunno, pastebin? what tends to spam valgrind here is fontconfig and libpng [17:08] seb128: oh yeah, that's right. it used to contain a lot of weird things from glib as well, but i guess that's all fixed now [17:08] hmm maybe i can actually run indicator-mesages-service in valgrind now [17:08] hyperair, you can also do a valgrind suppr file to filter out noise === dendrobates is now known as dendro-afk [17:09] cking: hey, can I ask your advice for bug #952556? [17:09] Launchpad bug 952556 in hdparm (Ubuntu) "[Precise] [Hardware-killer] HD restarts every few seconds" [High,Confirmed] https://launchpad.net/bugs/952556 [17:09] seb128: yeah, but the last time i tried using valgrind's memcheck, i couldn't find a suppr that filtered out the noise sufficiently (and there a *lot* of noise) === dendro-afk is now known as dendrobates === carif_ is now known as carif [17:23] mterry, I've a "lightdm --session-child 178 195" process stucked in a read, that's weird (got the bug again) [17:23] mterry, gdb to it is: http://pastebin.ubuntu.com/946021/ [17:23] does that makes any sense to you? [17:25] * mterry looks [17:25] strace on the process does [17:25] Process 10603 attached - interrupt to quit [17:25] read(178, [17:26] sitting there [17:26] seb128, sure, that's lightdm waiting for greeter data [17:26] mterry, ok, so it seems unity-greeter didn't send enough or stopped sending [17:26] seb128, maybe greeter sent it a malformed message (said it would send 80 bytes but only sent 20) [17:26] seb128, there is code in there to prevent that though... [17:27] mterry, can you point me to unity-greeter code for the write? maybe guide me to put a printf debug info somewhere [17:27] seb128, that's in lightdm trunk, in liblightdm-gobject/greeter.c I believe [17:27] seb128, write_message() or any of the write_() methods [17:27] mterry, when you say in trunk you mean trunk only not precise? [17:28] seb128, sorry no, just that it's in lightdm not u-g [17:28] ok [17:28] thanks [17:28] ok [17:29] write_message() has [17:29] g_warning ("Refusing to write malformed packet to daemon: declared size is %u, but actual size is %zu", [17:30] yeah, that's the code to prevent it... [17:30] mterry, there is a gdebug in there, do you know what I need to get the output from it? [17:30] Oh right, glib changed to not print those by default.... [17:31] oh [17:31] G_MESSAGE_DEBUG=all [17:31] yup [17:31] ok, bbiab [17:31] What's the easiest way to run unity-greeter under that? /etc/environment? [17:31] mterry, hum, is setting it for lightdm enough? [17:31] seb128, you want it for unity-greeter, not lightdm [17:32] mterry, what I figured, I was going to do the same thing I did for valgrind [17:32] seb128, a wrapper script? [17:32] i.e mv unity-greeter unity-greeter.real and made a wrapper script [17:32] yes [17:32] I don't know of a better way [17:32] slangasek, sorry, I was -afk for a while there [17:33] * mterry misses g_debug by default [17:35] slangasek, so should we opt for hdparm -B 128 for the default rather than 127 just to be safe? [17:35] well, that's my question [17:35] it seems that something is waking up people's disks incessantly [17:36] and if we can't fix that, we might as well not spin down in the first place [17:36] unless we think that the spinning up&down isn't actually a hardware problem here? [17:36] sure, 128 is good, but for some stupid ultra green drives only 255 seems to work [17:37] cking: well I don't want to go down the path of trying to whitelist individual drive models :P [17:38] do you think there's anything else we could do in SRU to improve the spin up/down problem? Is this a filesystem-layer issue? [17:39] slangasek, we could delay write back but that means we have a greater risk of losing data when we lose power. [17:40] but isn't that expected, and part of why ordered is the default? [17:40] but the spin ups could be reads, which we can't avoid either. I'm included to disable spin down altogether. [17:40] well, I would expect my desktop to fit in my disk cache [17:40] maybe that's naive :) [17:40] maybe 10 years ago [17:41] no, my disk cache 10 years ago was 10 years smaller ;) [17:41] only 306 running processes on my system, kernel threads inclusive... how big can it be? :P [17:41] heh :-) [17:42] so I'm ok with pushing this back to 128 if it'll make a difference [17:42] that sounds very sane to me [17:43] but I think something's still wrong in the rest of our stack if people are seeing 10s wakeups in normal use [17:43] and I would like to figure out what that is, so we can squeeze more power savings out [17:43] we need to get pitti's script to monitor what's going on in these use cases, perhaps its some badly behaving application which we haven't yet identified [17:44] "pitti's script"> fatrace? [17:44] yep [17:44] I think, I can't recall the name off the top of my head [17:45] that's the one that he blogged and packaged :) [17:45] http://www.piware.de/2012/02/power-usage-report-find-power-drain-causes/ [17:45] * slangasek nods [17:45] I do think that data loss due to poweroff is the wrong priority [17:46] if we're on battery, it's more important to save power so we *don't* run out of juice [17:46] well, as we move to SSDs, this is going to be less of an issue anyhow [17:46] and if our filesystem isn't already proofed by default against corruption on powerloss, it darn well should be :) [17:47] is the gap in price per byte closing between SSDs and rotationals? [17:47] slowly [17:47] well, until it does, it's an issue :) [17:47] * cking nods [17:47] ok, so I'll SRU hdparm to switch back to 128 [17:48] do you think it would be worth doing some kind of power clinic at UDS? [17:48] ... and maybe we should ask the users who are seeing frequent spin-ups to try pitti's script [17:48] yes, a power clinic at UDS is a good idea [17:48] we should all move to eMMCs [17:49] are we going to revisit power consumption for Q? [17:49] * ogra_ never has probs on his arm netbook [17:49] ogra_, nah, just move it all to the cloud, who needs local storage ;-) [17:49] kenvandine: You're about a day too late for uploads to Universe in the release pocket. [17:49] cking, ++ [17:49] even better [17:49] If it's SRUable it should go to -proposed. [17:49] cking: do you think anything's changed that we should revisit? or is it now just a matter of constant vigilance? :) [17:51] slangasek, constant vigilance for sure and also I'd like to get a broader check for mis-behaving applications [17:51] seems like we should have some kind of automated metering in place just like boot speed [17:51] I really think we need a process manager of some kind inside firefox [17:51] that or just switch to chromium [17:52] the fact that runaway javascript can only be killed by drilling through firefox menus, or by waiting for firefox itself to decide it's run away, is !good [17:52] well, I'd like to seek and destroy all bad poll() and select() calls and kill off any stupid logging [17:52] (especially when FF is so busy that it won't feed the menus to unity ;) === Guest85884 is now known as Jacky === Jacky is now known as Guest70035 [17:53] SpamapS, we've got the kit to do the monitoring, we just need to automate it, the groundwork as been done. === Guest70035 is now known as Jacky === Jacky is now known as Guest53736 === deryck[lunch] is now known as deryck [17:55] slangasek, we need something like the OOM killer for badly behaving CPU sucking apps ;-) === Guest53736 is now known as Jacky [17:56] cking: isn't that called "nice"? :) [17:56] perhaps auto-nice'ing bad apps [17:56] (hard killing a program because it's used too much CPU... yes, you can do that with ulimits, but there's a reason people don't ;) [17:58] I think the main problem is that there are thousands of applications, and if just one or two misbehave we see power suckage issues, so auto identifying them is one issue, fixing another issue, and making sure they stay fixed is another issue :-/ [17:59] * slangasek nods [17:59] whac-a-mole [18:02] ScottK, oh, the release schedule says the 26th [18:04] ScottK, whoops... i forgot the (Tue) in there is the archive freeze :) [18:04] sorry === dendrobates is now known as dendro-afk [18:43] No problem. [19:23] barry, hey === dendro-afk is now known as dendrobates [19:36] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [19:42] seb128: hiya [19:42] barry, hey [19:44] barry, those "... has bogus #! line" python bugs, could you add a rational out of "it's wrong"? like actual explanation of why it's wrong and if it's wrong in Ubuntu only, or in Debian as well, or in upstream tarballs...? [19:45] seb128: sure. i'd rather not have to do it to every bug i filed though ;) is there one in particular you'd like me to comment on? [19:45] barry, no, but for opening such bugs I think it would be could to have some arguments, I'm not likely to act on them on upstream them if I don't understand why the current way is wrong [19:46] barry, and I guess if upstream doesn't understand they are not likely to "fix" it either [19:46] upstream gwibber has fixed it already :) [19:46] barry, i.e your call but I'm going to ignore those on my package until a convincing explanation of "why" comes with those ;-) [19:46] barry: maybe blog about it and link to the blog post in the bug? [19:46] micahg: that's what i was thinking [19:46] kenvandine, did you wonder why it was wrong or just changed it to close a bug ? :p [19:46] seb128: the proper interpreter is defined by Debian python policy, at least [19:47] it's not a MUST in the debian python policy [19:47] i assume because you can't predict which interpreter it would be [19:47] slangasek, that would be useful info in the bug, still it doesn't tell me if I should upstream those [19:47] there are times when #!/usr/bin/env python is preferable [19:47] is that the issue barry reported bugs on? Missing bug numbers for context here :) [19:47] slangasek, of if that's a distro patch to carry [19:47] slangasek, bug #988391 [19:48] Launchpad bug 988391 in gtk+2.0 (Ubuntu) "/usr/bin/gtk-builder-convert has bogus #! line" [Undecided,New] https://launchpad.net/bugs/988391 [19:48] got a few of those [19:48] tumbleweed: it probably should be a must actually. my opinion is that it's fine for development of the package, but installed, i can't think of any reason to use /usr/bin/env [19:48] * kenvandine also trusts barry [19:48] and it was inconsistent with gwibber-service which didn't use env [19:48] kenvandine, well, still not very useful to convince an upstream who would like a rational on why that's wrong and why they need to change [19:48] barry: how about twistd in a virtualenv with site-packages enabled? [19:49]