[00:05] hmm what's this --git format in bzr? [00:05] as far as i can see, bzr init-repo --git = git init [00:05] and bzr upgrade --git crashes and burns [00:06] oh and bzr fails so hard that git-bzr stopped working [00:06] some weird exception about LocalGitBzrDir not having repository_format [00:06] wonderful. === zyga is now known as zyga-afk [00:28] bryceh: ping [00:49] persia: I certainly don't object to our workload being reduced; but contrariwise I don't want people who know about a package, but who can't upload it yet, to feel discouraged from filing removal requests for it directly, if that seems appropriate [00:50] persia: of course if any archive admin feels they'd rather not review an unsponsored request directly, but have it sponsored instead, I think that's up to them [00:51] Ah, then we're in complete agreement for the most part. Personally, I'd rather use the metric of PPU to determine that people know about a package, but there's work to be done to make that feel less complicated. [00:51] (but I have no objection to an archive admin deciding to also sponsor such a request if submitted directly) [00:52] I think "in complete agreement for the most part" may be the most persia turn of phrase I've ever read. :-) [00:53] heh [00:53] heh. [00:54] By that I mean that we're agreeing not only in principle, but in details for most of the space: the remainder being things that aren't yet clearly defined in either code or policy. [00:55] fortunately removals are fairly rare [00:56] removal requests anyway, versus ones mirrored from Debian [00:57] I think part of that comes from increased understanding of how to file RoQA removal requests (and bddebbian's tireless work in the past to drop all sorts of stuff) [01:08] awesome! Debian is starting to support our patches in parallel mode! [01:08] e.g. lilo or packagekit === Amaranth_ is now known as Amaranth [01:30] hmm...does the startup event export any environment variables that you could check for in a child job? i'm wondering if you could solve bug #436936 that way [01:30] Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936 [01:32] looks like...no. oh well [01:33] I believe there was some work to make upstart have the commandline as environment variables, so that jobs would check the environment rather than the actual commandline. My understanding is that it was implemented, but isn't yet widely used. I may be completely mistaken. [01:33] no, that came up on the mailing list recently. i think you're right [01:34] Keybuk talked about passing bare arguments instead of just foo=bar arguments, which means that you could check for $text instead of grepping /proc/cmdline for it [01:34] though that wouldn't be SRU-able, which is kind of unfortunate [01:35] True, but a fix that prevents the class of error in the future is superior to none, even if it can't solve the past. [01:36] I'd hope that most Karmic users were well into their plans to upgrade to Lucid at this point though, as otherwise they may find themselves with difficulties soon. [01:36] (not that this necessarily addresses the need to SRU something) [01:36] it's still a problem on lucid. possibly on maverick as well [01:36] (i just updated the nominations to reflect that) [01:37] i wonder what triggers the gdm job when you come out of recovery mode, though. presumably it's not the filesystem and started dbus and (drm-device-added or stopped udevtrigger) that triggers it organically [01:37] so i wonder if you could conditionalize that check on $UPSTART_EVENTS [01:37] I'd recommend finding a fix for natty first, and then fussing about the older releases. I suspect that fiddling the environment is a way to do that. [01:40] hmm...so the recovery mode is started by the rcS job (start on runlevel S), and does a start --no-wait rc-sysinit FROM_SINGLE_USER_MODE=y when the menu exits [01:43] So one might use [ -n "$UPSTART_EVENTS" -o "$FROM_SINGLE_USER_MODE" = "yes"] ? [01:43] i'm not sure that variable would actually propagate all the way down. i'm still trying to figure out what specifically triggers the gdm job [01:43] Or, rather, use the considtional for the exit? [01:44] I suspect it's frequently dbus starting [01:48] no, all of the conditions for gdm to start have already run before you get to the recovery menu [01:48] (so filesystems are mounted, hardware has been scanned, dbus is running, etc) [01:52] er......wait [01:53] i bet the bug isn't that check of /proc/cmdline, but rather that *nothing triggers the gdm job when the runlevel changes* [01:55] looking at logs from a verbose boot, i'm pretty sure that's the issue [02:00] * kees wonders if we can do this for Natty? http://domsch.com/blog/?p=455 [02:01] kees: I can't decide if its awesome or terrible [02:01] kees: the # in names seems liable to cause grief [02:01] lifeless: it doesn't preclude overriding the names, but for server people, it's _great_. [02:02] we talked about doing this in one of the uds sessions...the consensus seemed to be that we should [02:02] let me see if i can find the blueprint... [02:03] https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-n-network-stack [02:03] cjwatson took the WI :) [02:03] ah-ha [02:04] I was thinking of making it optional somehow. The namepocalypse kind of worries me and I'd sort of like us to try it out before committing to it [02:04] /proc/asound/card0/codec\#0 does the # thing already....whats one more spot? :P [02:04] still need to ponder [02:05] neato. [02:06] $ sudo ./biosdevname -i eth0 [02:06] em1 [02:06] that really would be a namepocalypse [02:06] on the other hand, /etc/udev/rules.d/70-persistent-net.rules will already keep the old name [02:06] Is there any sane way to have both entries available, to ease transition? [02:06] based on the WI, i'm assuming that the plan would be to only do this for new installations, not upgrades [02:06] broder: yeah [02:07] persia: no, unfortunately, that's part of the pain, AIUI. [02:07] cjwatson: for new installs, this actually should be pretty easy, as long as it's before udev rule "70". [02:07] anyway... just got distracted for a moment... [02:08] I thought part of the point of udev was that one could have multiple device entries for the same device more safely. Does that not work in the case of network interfaces for some reason? [02:08] persia: network interfaces do not have /dev entries :( [02:08] therefore, no symlinks [02:09] I was hoping there was some parallel. Oh well :( [02:10] kees: it's a medium-priority item for me, so I haven't got to it yet [02:11] quite tempted to make it server-only too, BTW. [02:11] cjwatson: cool [02:11] or even a non-default preseeding option, possibly [02:11] cjwatson: yeah, it could just be an optional package that carries the udev rule, and the server seed includes it from the start. [02:12] or server-ship or something, and install it dynamically from the installer [02:12] I think it might need a udeb too though [02:12] yeah [02:13] oh, whoa. i missed that they were changing the names of all interfaces. *weird* [02:14] * kees goes to try it on a machine that actually has multiple nics... [02:14] I thought it kept eth0 if you just had one nic [02:15] woo. em1 and em2. how exciting. ;) [02:15] james_w: http://domsch.com/blog/?p=455&cpage=1#comment-801 [02:15] broder: I think it's because swapping interfaces doesn't work reliably [02:15] and all their attempts to fix that in the kernel were rebuffed in one way or another [02:16] I must have misunderstood that point in the article then [02:19] cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this === Amaranth_ is now known as Amaranth [02:25] ari-tczew: I'd rather doko did it [02:25] ari-tczew: seeing as he's the Debian maintainer, I tend to leave sponsoring Ubuntu changes to it to him :) [02:25] cjwatson: but what - sponsor or full merge? [02:25] up to him I guess [02:26] I don't have an opinion on that, I just mean I'd rather doko dealt with it than I did === Amaranth_ is now known as Amaranth [02:26] cjwatson, doko_: in general, I'd like to not touch that package, just finish started merge by udienz. [02:27] I only commented on that merge because it was my patch pilot day, I think [02:27] ? which package? [02:27] 02:19 cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this [02:27] ahh, ok [02:28] actually I commented on it in my report. https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/032318.html [02:28] delaying for the next upstream release [02:45] doko_: could you look on curl FTBFS? https://launchpad.net/~ari-tczew/+archive/testing/+buildjob/2223498 [02:45] no, ENOTIME [02:47] thanks [03:06] hello [03:06] Just got a version 1 of my application for scheduling my prescription drugs done [03:07] i just added the code for the alarms to display the list of drugs to take at a particular time. [03:09] about 24 hours work done on the whole project -- but I'm not very experienced with Java, or Android yet. [03:11] oh sorry i am in the wrong channel -- my bad === Amaranth_ is now known as Amaranth [05:58] micahg: if it's a regression, then yes [05:59] pitti: ok, thanks, and good morning :) [05:59] Good morning [05:59] pitti: err, not technically a regression as that part of the doc didn't exist before [06:06] pitti: so, my question is, does a bug introduced by the -proposed package that isn't a regression and is just an annoyance worth reuploading for? [06:09] micahg: ah, then not; I thought you said it was a regression [06:11] pitti: I thought it was, I had charlie-tca verify for me and he said it was a new block of text, so no regression, but introduced by the update, I'll target for 10.04.3 then? [06:11] micahg: sounds good [06:11] pitti: thanks [06:23] pitti: how soon does the testdrive fix need to be tested? [06:24] micahg: depends on whether testdrive is on any of the images we release as part of 10.04.2 [06:24] if so, within a week; otherwise it doesn't matter too much [06:25] pitti: ok, I can test this weekend then [06:27] pitti: actually, doesn't have a Task, so I'm guessing it's not seeded [08:09] cjwatson: I added "closed subgraph" detection to http://people.canonical.com/~ubuntu-archive/nbs.html now; that indeed found some more packages which can be safely removed [08:10] the current libaqbanking complexity was a nice test case :) [08:18] good morning [08:19] good morning dholbach [08:19] salut didrocks === zyga-afk is now known as zyga === tkamppeter_ is now known as tkamppeter [08:50] pitti: cool! [08:51] pitti: can I remove stuff at some point, or do you want your useful test cases preserved for a little while longer? :) === smb` is now known as smb [09:04] cjwatson: I think they can go now [09:04] as soon as qbankmanager builds again, the next bunch will disappear [09:16] dholbach: the harvest tool is lacking a man page, a license header, needs to be mentioned in d/control, d/copyright [09:16] ugh [09:17] hi all [09:17] bdrung, I'll revert it [09:17] any archive-admin here? [09:18] bdrung, reverted [09:19] dholbach: you reverted it? why? [09:19] bdrung, because I won't have time this or next week to write a manpage, etc [09:19] ok [09:20] sucks [09:20] dholbach: once you have time, please use optparse in the script [09:20] can't you just let the command as an experimental one [09:21] dholbach: or ask tumbleweed to write one [09:38] pitti, hi, just to bring it to your attention, during last release meeting cjwatson mentioned that many reports were wrongly affected to initramfs-tools, I think that bug 580419 is causing this. [09:38] Launchpad bug 580419 in apport (Ubuntu Natty) "apport used wrong source package when filing package installation failure" [High,Triaged] https://launchpad.net/bugs/580419 [09:42] jibel: good catch, thanks [09:47] hi jibel! looking [09:49] ah, nice catch indeed; I'll see how to make it check for only the recent session [10:00] pitti: is optipng really really really safe? Because it's kind of destroying the latest window manager theme for xubuntu ;D [10:03] mr_pouit: I ran an automatic comparison for about 3.000 images which didn't show problems; but of course this only tested with libpng [10:04] if something uses a different library, or relies on a particular bit depth, it might indeed lead to problems [10:05] I wonder if all PNG compressors such as pngcrush break compatibility with whatever the Xfce WM uses. [10:05] I need to compare the files after and before. But if it changed a bit the colours (e.g. used a lighter grey to optimize), this would explain the issue [10:05] mr_pouit: it doesn't change the actual colors [10:05] mr_pouit: it does compress palettes and reduce bit depth, though [10:06] i. e. if you have an RGB32 PNG which actually just uses 10 colors, it'll convert it to a 4-bit indexed image with a palette [10:14] hi pitti [10:14] hi ochosi [10:14] pitti: i'm doing the artwork that was eaten by optipng (what mr_pouit mentioned) [10:15] so you're converting the mode from rgb to indexed? [10:15] mr_pouit, ochosi: if you want, I can generally blacklist "*xfce*" packages from PNG optimizing [10:15] ochosi: if it reduces the image size, yes [10:15] pitti: I quickly checked, and this particular theme seems the only one affected [10:16] pitti: sure, i'd rather find out why it scrambles the images in the first place [10:16] pitti: what's the exact optipng command you're running? [10:16] pitti: (so i can test it locally) [10:16] individual packages can do "export NO_PNG_PKG_MANGLE=1" in debian/rules to disable it, FYI [10:16] ochosi: optipng -o4 -preserve "$f"; then [10:16] oops, sorry [10:17] ochosi: optipng -o4 -preserve $f; advpng -z4 $f [10:17] pitti: k, thanks, i'll try to debug it and get back to you [10:18] pitti, mr_pouit fwiw i've used optipng on themes i made before but never had any problems with it. maybe a gimp-export thing... [10:19] ochosi: many thanks [10:19] well, visually, I can't find any difference between the two pngs :P [10:20] mr_pouit: right, there shouldn't be; see https://bugs.launchpad.net/ubuntu/+source/optipng/+bug/669457/comments/2 for the testing I made [10:20] Ubuntu bug 669457 in optipng (Ubuntu Natty) "[MIR] optipng" [Undecided,Fix released] [10:20] mr_pouit: seems it's really not as optimized as i'd have hoped, optipng just cut the size by half... === ogra_ is now known as ogra [10:22] ok [10:22] pitti, mr_pouit: ok, i don't even have to run advancecomp on the file, optipng already breaks it [10:22] ochosi: right, advancecomp alone really shouldn't break anything [10:23] it doesn't change any of the file properties, just optimizes Huffman tables etc. [10:23] pitti: weird, optipng didn't change the mode to indexed but to greyscale... [10:26] grayscale is 8 bits per pixel too, and doesn't need the palette [10:26] hm, i seem to get closer, converting the png to an indexed palette with gimp also breaks the xfwm theme [10:27] mr_pouit: the other themes you tested, do they use pngs at all or xpms? [10:27] I tested all available themes, including bluebird ;-) [10:27] mjr: right, thanks :) [10:28] mr_pouit: bluebird uses xpms ;) [10:28] arf, my bad [10:28] hehe [10:41] pitti: i think i was able to pinpoint the issue, but it's a bit awkward and xfwm related [10:42] ochosi: so does it rely on a particular palette? [10:42] or color format rather [10:42] hm, not really [10:42] it seems that if i optimize a png that contains transparency, everything works out fine [10:43] but as soon as i optimize a png that doesn't contain transparent pixels xfwm breaks [10:43] ah, so it would at least take away the alpha channel? [10:43] i guess that's due to the fact that usually you would use xpms for non-transparent images in themes [10:43] yeah, i guess taking away the alpha channel from the pngs is what breaks it [10:44] (there's -nx or the more spesific -n? options for disabling optipng from changing colorspace stuff but still doing other optimizing if necessary) [10:44] jibel: fix uploaded, thanks! [10:46] mjr: changing the colorspace is not what creates problems necessarily, it's really the alpha-channel [10:46] (just tested it again with gimp to be sure) === cking is now known as cking-afk === amitk is now known as amitk-afk [11:08] * cjwatson takes a very very deep breath and dives into an strace of 'apt-get install console-setup' across the breakage a couple of weeks ago, to try to figure out why its debconf handling went berserk [11:09] cjwatson: good luck, and beware of the Piranhas [11:10] * doko_ wonders about another upload-rinse-and-clean series of kde uploads [11:12] how do you mean? it's the 4.6 final uploads? [11:12] ah, we can demote hupnp again, thanks [11:13] watch the build failures, no proper build dependencies like xfce === JanC_ is now known as JanC [11:15] uh? === amitk-afk is now known as amitk === diwic is now known as diwic_afk === MacSlow is now known as MacSlow|lunch === bilalakhtar_ is now known as cdbs === diwic_afk is now known as diwic [12:52] pitti: i reported the optipng-issue to xfce-upstream, the bug is already confirmed/reproduced, so nothing else to do on your side. thanks for your support! [13:05] ochosi: heh, didn't do anything; great debugging, thanks! === MacSlow|lunch is now known as MacSlow [13:16] what development files does one use for mono? libmono-devel isnt cutting it [13:21] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mvo [13:22] cli-common-dev did the trick ... thank :) === cking-afk is now known as cking [13:38] pitti: where can I find/edit the code that generates nbs.html? [13:38] ah, never mind, ubuntu-archive-tools [13:38] cjwatson: right [13:50] mvo: ready to sponsorship? [13:50] ari-tczew: yep [13:51] mvo: bug 705383 [13:51] Launchpad bug 705383 in emacs23 (Ubuntu) "Please merge emacs 23.2+1-7 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/705383 [13:55] ari-tczew: looking at it now [13:59] ari-tczew: geh, that is a big debdiff [14:01] mvo: yea [14:02] * mvo makes a cup of tea, that review will take a little bit [14:02] lapsang souchong? [14:04] Laney: sencha ragi actually :) [14:04] :) [14:06] join #ubunt-app-devel [14:25] pitti, the libclutter-eglx- binaries on NBS don't really have rdepends [14:25] not sure if that's a bug [14:25] things depends on libclutter-1.0-0 | ... [14:26] ie we could probably clean the eglx binaries without breaking anything [14:26] it's half of a bug in checkrdepends [14:26] seb128: ah, thanks [14:26] pitti, http://paste.ubuntu.com/558548/ [14:26] (hi) [14:26] seb128: ok, I'll clean them up, thanks! [14:26] pitti, thanks [14:27] hey fta [14:28] fta: meh, that looks like a new upstart behaviour [14:28] $ sudo start apport; echo $? [14:28] start: Job is already running: apport [14:28] 1 [14:28] jhunt: ^ known? [14:28] that used to silently succeed [14:30] pitti: that's correct behaviour I believe. See section "Instances" in "man 5 init". [14:35] jhunt: did it use to do that in maverick, too? [14:35] yup. [14:35] jhunt: perhaps fta just ran into a weird package state (since usually upgrading should stop before) [14:35] jhunt: ok, thanks for confirming [14:36] fta: anyway, that snippet gets added by dh_installinit, so I don't think it's apport specific [14:39] pitti, i'm not sure what to tell you. only apport complained. http://paste.ubuntu.com/558554/ [14:40] fta: hm, the prerm should have stopped apport, but apparenlty didn't [14:40] fta: if you apt-get install --reinstall apport, does that reproduce the problem? [14:41] pitti, --reinstall wants to finish the update first :P [14:42] (the configure) [14:43] stopping apport manually worked though [14:43] right, "sudo stop apport; sudo dpkg --configure -a" [14:43] should do [14:43] i assume i won't be the only one to hit that === zul_ is now known as zul [14:45] pitti, I've nothing against apport today, really, but could you look at bug 707971, that's what fta is describing. [14:45] Launchpad bug 707971 in apport (Ubuntu) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [High,Triaged] https://launchpad.net/bugs/707971 [14:46] fta: did you notice what state apport was in before you stopped it? [14:46] jhunt, I assume it was active, i always have it active in all my desktops [14:47] fta: sorry, I meant what upstart state apport was in (ie "initctl status apport") [14:48] jhunt, i get it's too late now i've killed it [14:49] pitti, well I'm still on the old version and it has [14:49] set -e [14:49] # Automatically added by dh_installinit [14:49] if [ -e "/etc/init/apport.conf" ]; then [14:49] # start fails if already running [14:49] start apport || : [14:49] fi [14:49] oh, it's reproducible [14:49] fta, jhunt, jibel: ^ [14:49] seems dh_installinit changed? [14:50] jhunt, http://paste.ubuntu.com/558564/ [14:51] http://launchpadlibrarian.net/62684664/debhelper_8.0.0ubuntu1_8.0.0ubuntu2.diff.gz [14:54] ah, that would be it then [14:54] # Automatically added by dh_installinit [14:54] if [ -e "/etc/init/apport.conf" ]; then [14:54] invoke-rc.d apport start || exit $? [14:54] it does that now [14:55] I'll reassign the bug and give some extra info [14:55] slangasek, ^ you broke dh_installinit ;-) [14:57] bug updated [14:58] pitti, danke === psurbhi is now known as csurbhi-afk === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [15:06] barry: hey, how are you? did you have a chance to review the computer-janitor pygi branch? [15:07] pitti: not yet, but i still plan to. i'll get to that later today [15:07] barry: cool, thanks [15:07] no, thank *you* :) [15:12] cjwatson: Hey; I have a couple of questions around blkid that I'm pretty sure you came across :-) first, just after creating a loop device from a file (with an offset), should I call blkid on loop, blkid -c /dev/null on loop, sudo blkid on loop, or sudo blkid -c /dev/null on loop? I've seen the former misbehave / be a bit racy, but I'm not sure how far to go; should I call udevadm settle somewhere? [15:12] (somewhere == between loop mount and blkid) [15:12] lool: if you want to ensure that it does probe, please use -p [15:13] lool: I don't think I know any better than you wrt raciness [15:13] pitti: Do you think I need -p? [15:13] pitti: I guess -p needs root in any case? [15:13] lool: yes, I think so; I don't see any value that the cache could bring for a fresh loop mount [15:14] lool: yes, it does, but so does loop-mounting, so I guess you have root? [15:14] Yes we have root [15:14] well [15:14] it needs to be able to open the device [15:14] (I just decide command by command whether to run it as root, and prefer running commands non-root if I can) [15:14] not for the actual probing [15:14] so it really depends on the device node [15:14] pitti: Yup, I see -p only works as root [15:14] you can probe the image file with -p without root, of course [15:15] blkid -p download/ubuntu/natty-desktop-amd64.iso [15:15] works just fine [15:15] pitti: So if I -p, I probably don't care about udevadm settle [15:15] or -c [15:15] settle won't help you with the cache update [15:15] I thought that udev might be running blkid itself [15:15] it does [15:16] lool: so after the loop mount you should either wait a bit and get the new propertoes from the udev db (to avoid re-probing), or call blkid yourself [15:16] pitti: anyway, if I use -p, it doens't matter I guess [15:16] in /lib/udev/rules.d/60-persistent-storage.rules [15:16] lool: where "wait a bit" means "wait for the change uevent on the block device" [15:17] pitti: It's actually awesome that you replied to these questions because I have another similar issue which is typically a pitti question :-) we also have a case where we create a fs and loop mount it, and then ask UDisks whether it's mounted; that fails unless we sleep a bit [15:17] pitti: Is there something we can do which is better than sleep? [15:17] I tried udevadm settle, but it didn't help [15:17] udevadm settle only helps when the uevent has already entered udev's queue when udevadm starts [15:17] Yes [15:17] lool: right, unfortunately udevadm settle stops too early [15:17] I suspect the events are not emitted yet [15:18] because all udevadm settle does is wait for the udev queue to be empty, basically [15:18] Yeah; I just don't know of anything better [15:18] lool: at that point, udisks gets the uevent and does its own probing [15:18] ideally the kernel needs to hand back a token which losetup can wait on [15:18] that's done in a few other places (devmapper?) [15:18] lool: do you have C/python, or need shell? [15:18] pitti: Ah, so even after the event is full processed, UDisks will have to take some time before accounting for it? [15:18] pitti: python [15:18] lool: the "canonical" way is to wait for udisk's D-BUS signal to indicate the change event on the loop device [15:19] pitti: Ah that sounds good [15:19] pitti: Ok; I will look in that direction, thanks === csurbhi-afk is now known as psurbhi [15:29] seb128: no, I fixed dh_installinit. What's wrong with invoke-rc.d? [15:29] I think it's the #ERROR_HANDLER# being complained about, not the invoke-rc.d [15:30] the old code had || :, the new code has || #ERROR_HANDLER# [15:30] it expands to "exit $?" instead of ":" [15:30] slangasek, see the apport bug just before my ping [15:30] yes, it's *supposed* to expand to 'exit $?' [15:31] and 'invoke-rc.d apport start' is not supposed to fail if the job is already running [15:31] oh, apport runs but has no pid [15:31] right, /that/ bug [15:32] slangasek: according to jhunt, "start foo" exiting with 1 if already running is correct [15:32] I guess that's why the previous scripts used || : [15:32] pitti: yes, we're not *calling* 'start foo', we're calling 'invoke-rc.d foo start' [15:32] which is *not* supposed to behave that way [15:33] bug #585001 [15:33] Launchpad bug 585001 in upstart (Ubuntu) "package nfs-common 1:1.2.0-2ubuntu8 failed to install/upgrade: el subproceso script post-installation instalado devolvió el código de salida de error 1" [Medium,Triaged] https://launchpad.net/bugs/585001 [15:33] this is a bug in upstart-job's init script emulation [15:34] * cjwatson retitles that to something more useful :) === bjf[afk] is now known as bjf [15:36] actually, looks like bug #603934 is the better-triaged [15:36] Launchpad bug 603934 in upstart (Ubuntu) "package nfs-common 1:1.2.0-2ubuntu8 failed to install/upgrade: start: Job is already running: idmapd" [Low,Triaged] https://launchpad.net/bugs/603934 [15:37] oh, slangasek, I catch you. did you see my yeserday message about nvclock? [15:38] ari-tczew: hi there - smartdimmer is split out so hal can recommend it without pulling all of nvclock into main; as long as hal recommends it, it should be split. [15:39] slangasek: ok thanks for info. FYI, now only remaining change is smartdimmer in nvclock. [15:39] sure [15:40] but I;m going to add next changes - replace nvidia-glx with nvidia-current [15:40] not that we'd care much about hal any more [15:40] GNOME, Xfce, and now also KDE stopped using it [15:40] I actually pondered dropping that patch from hal and syncing hal from Debian [15:41] pitti: why is hal still in main, then? === deryck is now known as deryck[lunch] [15:42] slangasek: there is still some straggling packages which depend on libhal1 [15:42] and apparently landscape-client still depends on it [15:42] ah [15:43] I talked to them about switching to udev long ago, but apparently they didn't yet [15:43] hmm, checkrdepends seems to think gimp is the only thing keeping it in [15:43] right [15:44] hm, I don't actually have libhal1 installed [15:44] gimp?! [15:44] ah, I didn't reinstall gimp after my recent laptop reinstall === sconklin-afk is now known as sconklin === doko_ is now known as doko [16:02] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [16:02] 2280 nemo 20 0 1781m 790m 12m S 0 20.6 25:28.56 nautilus [16:02] :) [16:03] pretty much all heap. guess I could try a gdb dump. oh well [16:03] * nemo kills nautilus [16:06] barry: FYI, sip4 is now in Natty with Python3 support. PyQt4 in progress and then PyKDE not far behind. [16:06] ScottK: rock on [16:07] * ScottK waves at Quintasan (who did the sip4 work) [16:07] \o/ [16:24] pitti: pygobject git head doesn't seem to want to compile on natty. doesn't like the version of gobject-introspection apparently: [16:25] configure: error: Package requirements (glib-2.0 >= 2.24.0 [16:25] gobject-introspection-1.0 >= 0.10.2 [16:25] ) were not met: [16:25] [16:25] No package 'gobject-introspection-1.0' found [16:25] [16:44] pitti: is the desktop team still handling likewise-open? [16:47] * SpamapS stretches [16:51] barry: right, needs g-i HEAD, too :/ [16:51] zul: we never really did; we were basically just sponsoring the upstream versions, and they triaged the bugs themselves === deryck[lunch] is now known as deryck [16:51] * SpamapS loves when upstream triages bugs themselves [16:52] pitti: right there a couple of merge proposals for me do you want me to take care of them or do you want me to pass them off to the desktop team [16:52] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [16:52] pitti: k, i'll take another look after lunch [16:52] zul: if you want to, please do; thanks [16:53] pitti: k === cmagina is now known as cmagina-lunch [17:07] slangasek: dup-of-dup: lp-set-dup masterid yourid1 yourid2 ... will DTRT with those [17:07] slangasek: i. e. make all dupes of youridX a dupe of masterid first [17:08] pitti, launchpad does the right thing nowadays as well [17:09] oh, slangasek just seemed to have that problem [17:09] i.e it doesn't complain about the bug have duplicates but just reassign those [17:09] oh, does it? [17:10]