| hyperair | hmm what's this --git format in bzr? | 00:05 |
|---|---|---|
| hyperair | as far as i can see, bzr init-repo --git = git init | 00:05 |
| hyperair | and bzr upgrade --git crashes and burns | 00:05 |
| hyperair | oh and bzr fails so hard that git-bzr stopped working | 00:06 |
| hyperair | some weird exception about LocalGitBzrDir not having repository_format | 00:06 |
| hyperair | wonderful. | 00:06 |
| === zyga is now known as zyga-afk | ||
| doko_ | bryceh: ping | 00:28 |
| cjwatson | 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:49 |
| cjwatson | 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:50 |
| persia | 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 |
| persia | (but I have no objection to an archive admin deciding to also sponsor such a request if submitted directly) | 00:51 |
| cjwatson | I think "in complete agreement for the most part" may be the most persia turn of phrase I've ever read. :-) | 00:52 |
| bryceh | heh | 00:53 |
| persia | heh. | 00:53 |
| persia | 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:54 |
| cjwatson | fortunately removals are fairly rare | 00:55 |
| cjwatson | removal requests anyway, versus ones mirrored from Debian | 00:56 |
| persia | 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) | 00:57 |
| ari-tczew | awesome! Debian is starting to support our patches in parallel mode! | 01:08 |
| ari-tczew | e.g. lilo or packagekit | 01:08 |
| === Amaranth_ is now known as Amaranth | ||
| broder | 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 |
| ubottu | 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:30 |
| broder | looks like...no. oh well | 01:32 |
| persia | 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 |
| broder | no, that came up on the mailing list recently. i think you're right | 01:33 |
| broder | 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 |
| broder | though that wouldn't be SRU-able, which is kind of unfortunate | 01:34 |
| persia | 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:35 |
| persia | 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 |
| persia | (not that this necessarily addresses the need to SRU something) | 01:36 |
| broder | it's still a problem on lucid. possibly on maverick as well | 01:36 |
| broder | (i just updated the nominations to reflect that) | 01:36 |
| broder | 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 |
| broder | so i wonder if you could conditionalize that check on $UPSTART_EVENTS | 01:37 |
| persia | 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:37 |
| broder | 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:40 |
| persia | So one might use [ -n "$UPSTART_EVENTS" -o "$FROM_SINGLE_USER_MODE" = "yes"] ? | 01:43 |
| broder | 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 |
| persia | Or, rather, use the considtional for the exit? | 01:43 |
| persia | I suspect it's frequently dbus starting | 01:44 |
| broder | no, all of the conditions for gdm to start have already run before you get to the recovery menu | 01:48 |
| broder | (so filesystems are mounted, hardware has been scanned, dbus is running, etc) | 01:48 |
| broder | er......wait | 01:52 |
| broder | i bet the bug isn't that check of /proc/cmdline, but rather that *nothing triggers the gdm job when the runlevel changes* | 01:53 |
| broder | looking at logs from a verbose boot, i'm pretty sure that's the issue | 01:55 |
| * kees wonders if we can do this for Natty? http://domsch.com/blog/?p=455 | 02:00 | |
| lifeless | kees: I can't decide if its awesome or terrible | 02:01 |
| lifeless | kees: the # in names seems liable to cause grief | 02:01 |
| kees | lifeless: it doesn't preclude overriding the names, but for server people, it's _great_. | 02:01 |
| broder | we talked about doing this in one of the uds sessions...the consensus seemed to be that we should | 02:02 |
| broder | let me see if i can find the blueprint... | 02:02 |
| broder | https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-n-network-stack | 02:03 |
| broder | cjwatson took the WI :) | 02:03 |
| kees | ah-ha | 02:03 |
| cjwatson | 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 |
| maco | /proc/asound/card0/codec\#0 does the # thing already....whats one more spot? :P | 02:04 |
| cjwatson | still need to ponder | 02:04 |
| kees | neato. | 02:05 |
| kees | $ sudo ./biosdevname -i eth0 | 02:06 |
| kees | em1 | 02:06 |
| kees | that really would be a namepocalypse | 02:06 |
| kees | on the other hand, /etc/udev/rules.d/70-persistent-net.rules will already keep the old name | 02:06 |
| persia | Is there any sane way to have both entries available, to ease transition? | 02:06 |
| broder | based on the WI, i'm assuming that the plan would be to only do this for new installations, not upgrades | 02:06 |
| kees | broder: yeah | 02:06 |
| kees | persia: no, unfortunately, that's part of the pain, AIUI. | 02:07 |
| kees | cjwatson: for new installs, this actually should be pretty easy, as long as it's before udev rule "70". | 02:07 |
| kees | anyway... just got distracted for a moment... | 02:07 |
| persia | 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 |
| kees | persia: network interfaces do not have /dev entries :( | 02:08 |
| kees | therefore, no symlinks | 02:08 |
| persia | I was hoping there was some parallel. Oh well :( | 02:09 |
| cjwatson | kees: it's a medium-priority item for me, so I haven't got to it yet | 02:10 |
| cjwatson | quite tempted to make it server-only too, BTW. | 02:11 |
| kees | cjwatson: cool | 02:11 |
| cjwatson | or even a non-default preseeding option, possibly | 02:11 |
| kees | cjwatson: yeah, it could just be an optional package that carries the udev rule, and the server seed includes it from the start. | 02:11 |
| cjwatson | or server-ship or something, and install it dynamically from the installer | 02:12 |
| cjwatson | I think it might need a udeb too though | 02:12 |
| kees | yeah | 02:12 |
| broder | oh, whoa. i missed that they were changing the names of all interfaces. *weird* | 02:13 |
| * kees goes to try it on a machine that actually has multiple nics... | 02:14 | |
| james_w | I thought it kept eth0 if you just had one nic | 02:14 |
| kees | woo. em1 and em2. how exciting. ;) | 02:15 |
| broder | james_w: http://domsch.com/blog/?p=455&cpage=1#comment-801 | 02:15 |
| cjwatson | broder: I think it's because swapping interfaces doesn't work reliably | 02:15 |
| cjwatson | and all their attempts to fix that in the kernel were rebuffed in one way or another | 02:15 |
| james_w | I must have misunderstood that point in the article then | 02:16 |
| ari-tczew | cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this | 02:19 |
| === Amaranth_ is now known as Amaranth | ||
| cjwatson | ari-tczew: I'd rather doko did it | 02:25 |
| cjwatson | ari-tczew: seeing as he's the Debian maintainer, I tend to leave sponsoring Ubuntu changes to it to him :) | 02:25 |
| ari-tczew | cjwatson: but what - sponsor or full merge? | 02:25 |
| cjwatson | up to him I guess | 02:25 |
| cjwatson | I don't have an opinion on that, I just mean I'd rather doko dealt with it than I did | 02:26 |
| === Amaranth_ is now known as Amaranth | ||
| ari-tczew | cjwatson, doko_: in general, I'd like to not touch that package, just finish started merge by udienz. | 02:26 |
| cjwatson | I only commented on that merge because it was my patch pilot day, I think | 02:27 |
| doko_ | ? which package? | 02:27 |
| cjwatson | 02:19 <ari-tczew> cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this | 02:27 |
| doko_ | ahh, ok | 02:27 |
| cjwatson | actually I commented on it in my report. https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/032318.html | 02:28 |
| doko_ | delaying for the next upstream release | 02:28 |
| ari-tczew | doko_: could you look on curl FTBFS? https://launchpad.net/~ari-tczew/+archive/testing/+buildjob/2223498 | 02:45 |
| doko_ | no, ENOTIME | 02:45 |
| ari-tczew | thanks | 02:47 |
| snowrichard | hello | 03:06 |
| snowrichard | Just got a version 1 of my application for scheduling my prescription drugs done | 03:06 |
| snowrichard | i just added the code for the alarms to display the list of drugs to take at a particular time. | 03:07 |
| snowrichard | about 24 hours work done on the whole project -- but I'm not very experienced with Java, or Android yet. | 03:09 |
| snowrichard | oh sorry i am in the wrong channel -- my bad | 03:11 |
| === Amaranth_ is now known as Amaranth | ||
| pitti | micahg: if it's a regression, then yes | 05:58 |
| micahg | pitti: ok, thanks, and good morning :) | 05:59 |
| pitti | Good morning | 05:59 |
| micahg | pitti: err, not technically a regression as that part of the doc didn't exist before | 05:59 |
| micahg | 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:06 |
| pitti | micahg: ah, then not; I thought you said it was a regression | 06:09 |
| micahg | 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 |
| pitti | micahg: sounds good | 06:11 |
| micahg | pitti: thanks | 06:11 |
| micahg | pitti: how soon does the testdrive fix need to be tested? | 06:23 |
| pitti | micahg: depends on whether testdrive is on any of the images we release as part of 10.04.2 | 06:24 |
| pitti | if so, within a week; otherwise it doesn't matter too much | 06:24 |
| micahg | pitti: ok, I can test this weekend then | 06:25 |
| micahg | pitti: actually, doesn't have a Task, so I'm guessing it's not seeded | 06:27 |
| pitti | 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:09 |
| pitti | the current libaqbanking complexity was a nice test case :) | 08:10 |
| dholbach | good morning | 08:18 |
| didrocks | good morning dholbach | 08:19 |
| dholbach | salut didrocks | 08:19 |
| === zyga-afk is now known as zyga | ||
| === tkamppeter_ is now known as tkamppeter | ||
| cjwatson | pitti: cool! | 08:50 |
| cjwatson | pitti: can I remove stuff at some point, or do you want your useful test cases preserved for a little while longer? :) | 08:51 |
| === smb` is now known as smb | ||
| pitti | cjwatson: I think they can go now | 09:04 |
| pitti | as soon as qbankmanager builds again, the next bunch will disappear | 09:04 |
| bdrung | dholbach: the harvest tool is lacking a man page, a license header, needs to be mentioned in d/control, d/copyright | 09:16 |
| dholbach | ugh | 09:16 |
| quadrispro | hi all | 09:17 |
| dholbach | bdrung, I'll revert it | 09:17 |
| quadrispro | any archive-admin here? | 09:17 |
| dholbach | bdrung, reverted | 09:18 |
| bdrung | dholbach: you reverted it? why? | 09:19 |
| dholbach | bdrung, because I won't have time this or next week to write a manpage, etc | 09:19 |
| bdrung | ok | 09:19 |
| seb128 | sucks | 09:20 |
| bdrung | dholbach: once you have time, please use optparse in the script | 09:20 |
| seb128 | can't you just let the command as an experimental one | 09:20 |
| bdrung | dholbach: or ask tumbleweed to write one | 09:21 |
| jibel | 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 |
| ubottu | 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:38 |
| cjwatson | jibel: good catch, thanks | 09:42 |
| pitti | hi jibel! looking | 09:47 |
| pitti | ah, nice catch indeed; I'll see how to make it check for only the recent session | 09:49 |
| mr_pouit | pitti: is optipng really really really safe? Because it's kind of destroying the latest window manager theme for xubuntu ;D | 10:00 |
| pitti | 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:03 |
| pitti | if something uses a different library, or relies on a particular bit depth, it might indeed lead to problems | 10:04 |
| ion | I wonder if all PNG compressors such as pngcrush break compatibility with whatever the Xfce WM uses. | 10:05 |
| mr_pouit | 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 |
| pitti | mr_pouit: it doesn't change the actual colors | 10:05 |
| pitti | mr_pouit: it does compress palettes and reduce bit depth, though | 10:05 |
| pitti | 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:06 |
| ochosi | hi pitti | 10:14 |
| pitti | hi ochosi | 10:14 |
| ochosi | pitti: i'm doing the artwork that was eaten by optipng (what mr_pouit mentioned) | 10:14 |
| ochosi | so you're converting the mode from rgb to indexed? | 10:15 |
| pitti | mr_pouit, ochosi: if you want, I can generally blacklist "*xfce*" packages from PNG optimizing | 10:15 |
| pitti | ochosi: if it reduces the image size, yes | 10:15 |
| mr_pouit | pitti: I quickly checked, and this particular theme seems the only one affected | 10:15 |
| ochosi | pitti: sure, i'd rather find out why it scrambles the images in the first place | 10:16 |
| ochosi | pitti: what's the exact optipng command you're running? | 10:16 |
| ochosi | pitti: (so i can test it locally) | 10:16 |
| pitti | individual packages can do "export NO_PNG_PKG_MANGLE=1" in debian/rules to disable it, FYI | 10:16 |
| pitti | ochosi: optipng -o4 -preserve "$f"; then | 10:16 |
| pitti | oops, sorry | 10:16 |
| pitti | ochosi: optipng -o4 -preserve $f; advpng -z4 $f | 10:17 |
| ochosi | pitti: k, thanks, i'll try to debug it and get back to you | 10:17 |
| ochosi | 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:18 |
| pitti | ochosi: many thanks | 10:19 |
| mr_pouit | well, visually, I can't find any difference between the two pngs :P | 10:19 |
| pitti | 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 |
| ubottu | Ubuntu bug 669457 in optipng (Ubuntu Natty) "[MIR] optipng" [Undecided,Fix released] | 10:20 |
| ochosi | mr_pouit: seems it's really not as optimized as i'd have hoped, optipng just cut the size by half... | 10:20 |
| === ogra_ is now known as ogra | ||
| mr_pouit | ok | 10:22 |
| ochosi | pitti, mr_pouit: ok, i don't even have to run advancecomp on the file, optipng already breaks it | 10:22 |
| pitti | ochosi: right, advancecomp alone really shouldn't break anything | 10:22 |
| pitti | it doesn't change any of the file properties, just optimizes Huffman tables etc. | 10:23 |
| ochosi | pitti: weird, optipng didn't change the mode to indexed but to greyscale... | 10:23 |
| mjr | grayscale is 8 bits per pixel too, and doesn't need the palette | 10:26 |
| ochosi | hm, i seem to get closer, converting the png to an indexed palette with gimp also breaks the xfwm theme | 10:26 |
| ochosi | mr_pouit: the other themes you tested, do they use pngs at all or xpms? | 10:27 |
| mr_pouit | I tested all available themes, including bluebird ;-) | 10:27 |
| ochosi | mjr: right, thanks :) | 10:27 |
| ochosi | mr_pouit: bluebird uses xpms ;) | 10:28 |
| mr_pouit | arf, my bad | 10:28 |
| ochosi | hehe | 10:28 |
| ochosi | pitti: i think i was able to pinpoint the issue, but it's a bit awkward and xfwm related | 10:41 |
| pitti | ochosi: so does it rely on a particular palette? | 10:42 |
| pitti | or color format rather | 10:42 |
| ochosi | hm, not really | 10:42 |
| ochosi | it seems that if i optimize a png that contains transparency, everything works out fine | 10:42 |
| ochosi | but as soon as i optimize a png that doesn't contain transparent pixels xfwm breaks | 10:43 |
| pitti | ah, so it would at least take away the alpha channel? | 10:43 |
| ochosi | i guess that's due to the fact that usually you would use xpms for non-transparent images in themes | 10:43 |
| ochosi | yeah, i guess taking away the alpha channel from the pngs is what breaks it | 10:43 |
| mjr | (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 |
| pitti | jibel: fix uploaded, thanks! | 10:44 |
| ochosi | mjr: changing the colorspace is not what creates problems necessarily, it's really the alpha-channel | 10:46 |
| ochosi | (just tested it again with gimp to be sure) | 10:46 |
| === cking is now known as cking-afk | ||
| === amitk is now known as amitk-afk | ||
| * 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:08 | |
| pitti | cjwatson: good luck, and beware of the Piranhas | 11:09 |
| * doko_ wonders about another upload-rinse-and-clean series of kde uploads | 11:10 | |
| pitti | how do you mean? it's the 4.6 final uploads? | 11:12 |
| pitti | ah, we can demote hupnp again, thanks | 11:12 |
| doko_ | watch the build failures, no proper build dependencies like xfce | 11:13 |
| === JanC_ is now known as JanC | ||
| mr_pouit | uh? | 11:15 |
| === 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 | ||
| ochosi | 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! | 12:52 |
| pitti | ochosi: heh, didn't do anything; great debugging, thanks! | 13:05 |
| === MacSlow|lunch is now known as MacSlow | ||
| shadeslayer | what development files does one use for mono? libmono-devel isnt cutting it | 13:16 |
| mvo | @pilot in | 13:21 |
| === 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 | ||
| shadeslayer | cli-common-dev did the trick ... thank :) | 13:22 |
| === cking-afk is now known as cking | ||
| cjwatson | pitti: where can I find/edit the code that generates nbs.html? | 13:38 |
| cjwatson | ah, never mind, ubuntu-archive-tools | 13:38 |
| pitti | cjwatson: right | 13:38 |
| ari-tczew | mvo: ready to sponsorship? | 13:50 |
| mvo | ari-tczew: yep | 13:50 |
| ari-tczew | mvo: bug 705383 | 13:51 |
| ubottu | 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:51 |
| mvo | ari-tczew: looking at it now | 13:55 |
| mvo | ari-tczew: geh, that is a big debdiff | 13:59 |
| ari-tczew | mvo: yea | 14:01 |
| * mvo makes a cup of tea, that review will take a little bit | 14:02 | |
| Laney | lapsang souchong? | 14:02 |
| mvo | Laney: sencha ragi actually :) | 14:04 |
| Laney | :) | 14:04 |
| orangecard | join #ubunt-app-devel | 14:06 |
| seb128 | pitti, the libclutter-eglx- binaries on NBS don't really have rdepends | 14:25 |
| seb128 | not sure if that's a bug | 14:25 |
| seb128 | things depends on libclutter-1.0-0 | ... | 14:25 |
| seb128 | ie we could probably clean the eglx binaries without breaking anything | 14:26 |
| pitti | it's half of a bug in checkrdepends | 14:26 |
| pitti | seb128: ah, thanks | 14:26 |
| fta | pitti, http://paste.ubuntu.com/558548/ | 14:26 |
| fta | (hi) | 14:26 |
| pitti | seb128: ok, I'll clean them up, thanks! | 14:26 |
| seb128 | pitti, thanks | 14:26 |
| pitti | hey fta | 14:27 |
| pitti | fta: meh, that looks like a new upstart behaviour | 14:28 |
| pitti | $ sudo start apport; echo $? | 14:28 |
| pitti | start: Job is already running: apport | 14:28 |
| pitti | 1 | 14:28 |
| pitti | jhunt: ^ known? | 14:28 |
| pitti | that used to silently succeed | 14:28 |
| jhunt | pitti: that's correct behaviour I believe. See section "Instances" in "man 5 init". | 14:30 |
| pitti | jhunt: did it use to do that in maverick, too? | 14:35 |
| jhunt | yup. | 14:35 |
| pitti | jhunt: perhaps fta just ran into a weird package state (since usually upgrading should stop before) | 14:35 |
| pitti | jhunt: ok, thanks for confirming | 14:35 |
| pitti | fta: anyway, that snippet gets added by dh_installinit, so I don't think it's apport specific | 14:36 |
| fta | pitti, i'm not sure what to tell you. only apport complained. http://paste.ubuntu.com/558554/ | 14:39 |
| pitti | fta: hm, the prerm should have stopped apport, but apparenlty didn't | 14:40 |
| pitti | fta: if you apt-get install --reinstall apport, does that reproduce the problem? | 14:40 |
| fta | pitti, --reinstall wants to finish the update first :P | 14:41 |
| fta | (the configure) | 14:42 |
| fta | stopping apport manually worked though | 14:43 |
| pitti | right, "sudo stop apport; sudo dpkg --configure -a" | 14:43 |
| pitti | should do | 14:43 |
| fta | i assume i won't be the only one to hit that | 14:43 |
| === zul_ is now known as zul | ||
| jibel | pitti, I've nothing against apport today, really, but could you look at bug 707971, that's what fta is describing. | 14:45 |
| ubottu | 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:45 |
| jhunt | fta: did you notice what state apport was in before you stopped it? | 14:46 |
| fta | jhunt, I assume it was active, i always have it active in all my desktops | 14:46 |
| jhunt | fta: sorry, I meant what upstart state apport was in (ie "initctl status apport") | 14:47 |
| fta | jhunt, i get it's too late now i've killed it | 14:48 |
| seb128 | pitti, well I'm still on the old version and it has | 14:49 |
| seb128 | set -e | 14:49 |
| seb128 | # Automatically added by dh_installinit | 14:49 |
| seb128 | if [ -e "/etc/init/apport.conf" ]; then | 14:49 |
| seb128 | # start fails if already running | 14:49 |
| seb128 | start apport || : | 14:49 |
| seb128 | fi | 14:49 |
| fta | oh, it's reproducible | 14:49 |
| seb128 | fta, jhunt, jibel: ^ | 14:49 |
| seb128 | seems dh_installinit changed? | 14:49 |
| fta | jhunt, http://paste.ubuntu.com/558564/ | 14:50 |
| seb128 | http://launchpadlibrarian.net/62684664/debhelper_8.0.0ubuntu1_8.0.0ubuntu2.diff.gz | 14:51 |
| pitti | ah, that would be it then | 14:54 |
| seb128 | # Automatically added by dh_installinit | 14:54 |
| seb128 | if [ -e "/etc/init/apport.conf" ]; then | 14:54 |
| seb128 | invoke-rc.d apport start || exit $? | 14:54 |
| seb128 | it does that now | 14:54 |
| pitti | I'll reassign the bug and give some extra info | 14:55 |
| seb128 | slangasek, ^ you broke dh_installinit ;-) | 14:55 |
| pitti | bug updated | 14:57 |
| seb128 | pitti, danke | 14:58 |
| === psurbhi is now known as csurbhi-afk | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| pitti | barry: hey, how are you? did you have a chance to review the computer-janitor pygi branch? | 15:06 |
| barry | pitti: not yet, but i still plan to. i'll get to that later today | 15:07 |
| pitti | barry: cool, thanks | 15:07 |
| barry | no, thank *you* :) | 15:07 |
| lool | 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 |
| lool | (somewhere == between loop mount and blkid) | 15:12 |
| pitti | lool: if you want to ensure that it does probe, please use -p | 15:12 |
| cjwatson | lool: I don't think I know any better than you wrt raciness | 15:13 |
| lool | pitti: Do you think I need -p? | 15:13 |
| lool | pitti: I guess -p needs root in any case? | 15:13 |
| pitti | lool: yes, I think so; I don't see any value that the cache could bring for a fresh loop mount | 15:13 |
| pitti | lool: yes, it does, but so does loop-mounting, so I guess you have root? | 15:14 |
| lool | Yes we have root | 15:14 |
| pitti | well | 15:14 |
| pitti | it needs to be able to open the device | 15:14 |
| lool | (I just decide command by command whether to run it as root, and prefer running commands non-root if I can) | 15:14 |
| pitti | not for the actual probing | 15:14 |
| pitti | so it really depends on the device node | 15:14 |
| lool | pitti: Yup, I see -p only works as root | 15:14 |
| pitti | you can probe the image file with -p without root, of course | 15:14 |
| pitti | blkid -p download/ubuntu/natty-desktop-amd64.iso | 15:15 |
| pitti | works just fine | 15:15 |
| lool | pitti: So if I -p, I probably don't care about udevadm settle | 15:15 |
| lool | or -c | 15:15 |
| pitti | settle won't help you with the cache update | 15:15 |
| lool | I thought that udev might be running blkid itself | 15:15 |
| ogra | it does | 15:15 |
| pitti | 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 |
| lool | pitti: anyway, if I use -p, it doens't matter I guess | 15:16 |
| ogra | in /lib/udev/rules.d/60-persistent-storage.rules | 15:16 |
| pitti | lool: where "wait a bit" means "wait for the change uevent on the block device" | 15:16 |
| lool | 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 |
| lool | pitti: Is there something we can do which is better than sleep? | 15:17 |
| lool | I tried udevadm settle, but it didn't help | 15:17 |
| cjwatson | udevadm settle only helps when the uevent has already entered udev's queue when udevadm starts | 15:17 |
| lool | Yes | 15:17 |
| pitti | lool: right, unfortunately udevadm settle stops too early | 15:17 |
| lool | I suspect the events are not emitted yet | 15:17 |
| cjwatson | because all udevadm settle does is wait for the udev queue to be empty, basically | 15:18 |
| lool | Yeah; I just don't know of anything better | 15:18 |
| pitti | lool: at that point, udisks gets the uevent and does its own probing | 15:18 |
| cjwatson | ideally the kernel needs to hand back a token which losetup can wait on | 15:18 |
| cjwatson | that's done in a few other places (devmapper?) | 15:18 |
| pitti | lool: do you have C/python, or need shell? | 15:18 |
| lool | pitti: Ah, so even after the event is full processed, UDisks will have to take some time before accounting for it? | 15:18 |
| lool | pitti: python | 15:18 |
| pitti | lool: the "canonical" way is to wait for udisk's D-BUS signal to indicate the change event on the loop device | 15:18 |
| lool | pitti: Ah that sounds good | 15:19 |
| lool | pitti: Ok; I will look in that direction, thanks | 15:19 |
| === csurbhi-afk is now known as psurbhi | ||
| slangasek | seb128: no, I fixed dh_installinit. What's wrong with invoke-rc.d? | 15:29 |
| cjwatson | I think it's the #ERROR_HANDLER# being complained about, not the invoke-rc.d | 15:29 |
| cjwatson | the old code had || :, the new code has || #ERROR_HANDLER# | 15:30 |
| pitti | it expands to "exit $?" instead of ":" | 15:30 |
| seb128 | slangasek, see the apport bug just before my ping | 15:30 |
| slangasek | yes, it's *supposed* to expand to 'exit $?' | 15:30 |
| slangasek | and 'invoke-rc.d apport start' is not supposed to fail if the job is already running | 15:31 |
| slangasek | oh, apport runs but has no pid | 15:31 |
| slangasek | right, /that/ bug | 15:31 |
| pitti | slangasek: according to jhunt, "start foo" exiting with 1 if already running is correct | 15:32 |
| pitti | I guess that's why the previous scripts used || : | 15:32 |
| slangasek | pitti: yes, we're not *calling* 'start foo', we're calling 'invoke-rc.d foo start' | 15:32 |
| slangasek | which is *not* supposed to behave that way | 15:32 |
| slangasek | bug #585001 | 15:33 |
| ubottu | 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 |
| slangasek | this is a bug in upstart-job's init script emulation | 15:33 |
| * cjwatson retitles that to something more useful :) | 15:34 | |
| === bjf[afk] is now known as bjf | ||
| slangasek | actually, looks like bug #603934 is the better-triaged | 15:36 |
| ubottu | 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:36 |
| ari-tczew | oh, slangasek, I catch you. did you see my yeserday message about nvclock? | 15:37 |
| slangasek | 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:38 |
| ari-tczew | slangasek: ok thanks for info. FYI, now only remaining change is smartdimmer in nvclock. | 15:39 |
| slangasek | sure | 15:39 |
| ari-tczew | but I;m going to add next changes - replace nvidia-glx with nvidia-current | 15:40 |
| pitti | not that we'd care much about hal any more | 15:40 |
| pitti | GNOME, Xfce, and now also KDE stopped using it | 15:40 |
| pitti | I actually pondered dropping that patch from hal and syncing hal from Debian | 15:40 |
| slangasek | pitti: why is hal still in main, then? | 15:41 |
| === deryck is now known as deryck[lunch] | ||
| pitti | slangasek: there is still some straggling packages which depend on libhal1 | 15:42 |
| pitti | and apparently landscape-client still depends on it | 15:42 |
| slangasek | ah | 15:42 |
| pitti | I talked to them about switching to udev long ago, but apparently they didn't yet | 15:43 |
| slangasek | hmm, checkrdepends seems to think gimp is the only thing keeping it in | 15:43 |
| pitti | right | 15:43 |
| pitti | hm, I don't actually have libhal1 installed | 15:44 |
| seb128 | gimp?! | 15:44 |
| pitti | ah, I didn't reinstall gimp after my recent laptop reinstall | 15:44 |
| === sconklin-afk is now known as sconklin | ||
| === doko_ is now known as doko | ||
| nemo | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND | 16:02 |
| nemo | 2280 nemo 20 0 1781m 790m 12m S 0 20.6 25:28.56 nautilus | 16:02 |
| nemo | :) | 16:02 |
| nemo | pretty much all heap. guess I could try a gdb dump. oh well | 16:03 |
| * nemo kills nautilus | 16:03 | |
| ScottK | barry: FYI, sip4 is now in Natty with Python3 support. PyQt4 in progress and then PyKDE not far behind. | 16:06 |
| barry | ScottK: rock on | 16:06 |
| * ScottK waves at Quintasan (who did the sip4 work) | 16:07 | |
| Quintasan | \o/ | 16:07 |
| barry | pitti: pygobject git head doesn't seem to want to compile on natty. doesn't like the version of gobject-introspection apparently: | 16:24 |
| barry | configure: error: Package requirements (glib-2.0 >= 2.24.0 | 16:25 |
| barry | gobject-introspection-1.0 >= 0.10.2 | 16:25 |
| barry | ) were not met: | 16:25 |
| barry | 16:25 | |
| barry | No package 'gobject-introspection-1.0' found | 16:25 |
| barry | 16:25 | |
| zul | pitti: is the desktop team still handling likewise-open? | 16:44 |
| * SpamapS stretches | 16:47 | |
| pitti | barry: right, needs g-i HEAD, too :/ | 16:51 |
| pitti | zul: we never really did; we were basically just sponsoring the upstream versions, and they triaged the bugs themselves | 16:51 |
| === deryck[lunch] is now known as deryck | ||
| * SpamapS loves when upstream triages bugs themselves | 16:51 | |
| zul | 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 |
| mvo | @pilot out | 16:52 |
| === 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: | ||
| barry | pitti: k, i'll take another look after lunch | 16:52 |
| pitti | zul: if you want to, please do; thanks | 16:52 |
| zul | pitti: k | 16:53 |
| === cmagina is now known as cmagina-lunch | ||
| pitti | slangasek: dup-of-dup: lp-set-dup masterid yourid1 yourid2 ... will DTRT with those | 17:07 |
| pitti | slangasek: i. e. make all dupes of youridX a dupe of masterid first | 17:07 |
| seb128 | pitti, launchpad does the right thing nowadays as well | 17:08 |
| pitti | oh, slangasek just seemed to have that problem | 17:09 |
| seb128 | i.e it doesn't complain about the bug have duplicates but just reassign those | 17:09 |
| slangasek | oh, does it? | 17:09 |
| slangasek | I didn't actually try, I saw there were many many duplicates and ran away ;) | 17:10 |
| slangasek | decided I should do real work, like maybe fixing the bug | 17:10 |
| cjwatson | slangasek: http://blog.launchpad.net/cool-new-stuff/dupety-dupe | 17:17 |
| slangasek | ah, neat :) | 17:18 |
| === Kmos is now known as Guest50434 | ||
| === mnepton is now known as mneptok | ||
| SpamapS | this is maddening.. strace shows php doing an strace .. but gdb never traps one.. >:| | 17:41 |
| SpamapS | rrrrr | 17:41 |
| SpamapS | lets try that agin | 17:41 |
| SpamapS | this is maddening.. strace shows php doing an ioctl .. but gdb never traps one.. >:| | 17:41 |
| apw | SpamapS, where are you putting hte breakpoint in gdb | 17:42 |
| SpamapS | b ioctl | 17:42 |
| SpamapS | it does break on some other cases w/ ioctl | 17:43 |
| apw | SpamapS, could it be using another interface like ioctl_compat or syscall() direct ? | 17:43 |
| SpamapS | trying to find where libedit is taking control of the terminal. :-P | 17:43 |
| SpamapS | apw: would that show in strace as ioctl( ? | 17:43 |
| apw | some might well yes | 17:43 |
| SpamapS | *arg* | 17:43 |
| apw | as thats someone crossing the syscall infterface asking for SYS_ioctl | 17:44 |
| apw | not which library routine they are using | 17:44 |
| SpamapS | I don't really see ncurses or libedit doing that.. | 17:44 |
| SpamapS | but who knows | 17:44 |
| SpamapS | that may be the very root of the problem I'm trying to debug.. that they've gone too low level | 17:44 |
| apw | SpamapS, good luck trying to figure that one out | 17:45 |
| SpamapS | apw: maybe strace can help me.. | 17:45 |
| apw | not sure how? | 17:46 |
| apw | it only sees the kernel side of the line | 17:46 |
| SpamapS | well its showing an ioctl where gdb isn't... | 17:46 |
| SpamapS | ahhh | 17:46 |
| SpamapS | ltrace -S shows SYS_ioctl | 17:46 |
| apw | ltrace ? | 17:46 |
| SpamapS | yeah.. ltrace. :) | 17:47 |
| apw | but either way i assume that means it is seeing a real call to the kernel, just not from the libc ioctl call | 17:50 |
| apw | which is what we suspected | 17:50 |
| SpamapS | yeah, so ltrace at least shows me the library calls that surround the SYS_ioctl calls | 17:50 |
| apw | oh nice, so which one | 17:50 |
| SpamapS | I can hook in there and step into the rabbit hole | 17:50 |
| apw | SpamapS, let me know when you find out, useful to store away for next time | 17:52 |
| SpamapS | apw: yeah, this little annoying bug in libedit has really driven me nuts | 17:52 |
| === bjf is now known as bjf[afk] | ||
| === cmagina-lunch is now known as cmagina | ||
| === sforshee is now known as sforshee-lunch | ||
| smoser | just a question. i type 'apt-get install ctags' and it says: | 18:18 |
| smoser | Note, selecting 'exuberant-ctags' instead of 'ctags' | 18:18 |
| smoser | what manages that "alias" ? | 18:18 |
| cjwatson | exuberant-ctags is the only package that Provides: ctags | 18:20 |
| smoser | ah. i should have guessed. thanks cjwatson | 18:21 |
| cjwatson | if there'd been more than one Provides, you'd have got an error telling you to explicitly select one instead | 18:21 |
| rsalveti | can any archive admin help me publishing the new x-loader package version? | 18:34 |
| rsalveti | https://launchpad.net/ubuntu/+source/x-loader | 18:34 |
| rsalveti | still waiting to be published | 18:34 |
| ogra | and while that archive admin is at it, an unleashing of unity-2d from NEW would also be appreciated | 18:35 |
| ogra | :) | 18:35 |
| ogra | (unity-2d-default-settings was merged into the unity-2d source package) | 18:36 |
| * highvoltage wondered where unity-2d was (stgraber told me it existed so I wanted to test it :p) | 18:37 | |
| ogra | oh, and its cjwatson's archive day | 18:38 |
| ogra | highvoltage, its there since two weeks now :) | 18:39 |
| ogra | but only with this package you can apt-get install unity-2d | 18:39 |
| ogra | before you needed unity-2d-default-settings | 18:39 |
| SpamapS | apw: btw its tcgetattr that is confusing things | 18:39 |
| SpamapS | 41 retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios); | 18:39 |
| apw | SpamapS, nice | 18:40 |
| SpamapS | apw: luckily called only about 5 lines into the library function before my ioctl :) | 18:40 |
| ogra | jhunt, any news about the serial stuff ? | 18:40 |
| jdstrand | seb128: hey, shotwell has a build-depends on valac-0.10, but valac-0.10 is NBS. would you mind get that tested/fixed? (I'd ask robert_ancell, but he doesn't see to be around) | 18:41 |
| seb128 | jdstrand, there is a list a things that still use vala-0.10 | 18:41 |
| seb128 | jdstrand, it's on my list of things to discuss with the desktop team, we might bring back vala-0.10 as a different source | 18:41 |
| seb128 | or we need to port the remaining items | 18:42 |
| seb128 | jdstrand, robert_ancell is at lca this week | 18:42 |
| jdstrand | seb128: ok, thanks | 18:42 |
| seb128 | do you need that sorted now or can it wait a few days? | 18:42 |
| jdstrand | seb128: I think it can wait | 18:43 |
| seb128 | jdstrand, ok, I will probably bring it at our meeting next week | 18:43 |
| seb128 | jdstrand, I will get back to you when we have it sorted | 18:43 |
| jdstrand | thanks! | 18:43 |
| === sforshee-lunch is now known as sforshee | ||
| ion | pitti: A small typo in jockey/handlers/nvidia.py: s/accelleration/acceleration/. Btw, is the incomplete sentence in which the word occurs intentional? How about changing it to something like “You should install it if you wish to…”? | 18:56 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| SpamapS | ogra: its being discussed quite a bit on upstart-devel as to how to do it for the future... | 19:04 |
| SpamapS | ogra: also cjwatson brought up that d-i will setup a special ttySomething.conf if a serial console is used for the install.. | 19:04 |
| ogra | SpamapS, i know, arm doesnt use d-i | 19:04 |
| ogra | SpamapS, jhunt wanted to give me an update today | 19:05 |
| SpamapS | ogra: so we'll have to disable that in d-i if we come up with a more generic solution that respects the kernel args | 19:05 |
| hallyn | what is d-i exactly? | 19:05 |
| SpamapS | debian-installer | 19:05 |
| ogra | (well, arm uses d-i as anything else, but our current preinstalled images are preinstalled indeed) | 19:05 |
| hallyn | thx | 19:05 |
| SpamapS | used by minimal and alternative install right? server and deskto puse ubiquity IIRC | 19:06 |
| ogra | we dont build minimal or alternate atm, but yes | 19:06 |
| ogra | we currently build preinstalled images, one for server is in the works | 19:06 |
| ogra | they are fully focused on SD cards and just expand the installation partition on first boot | 19:07 |
| ogra | the install is done beforehand | 19:07 |
| SpamapS | ogra: given that upstart doesn't expose the kernel commandline stuff to jobs .. and will have to be patched to do so.. I think its a safe bet that parsing /proc/cmdline after the filesystem event is going to be fine in terms of not hurting boot time too much. | 19:07 |
| ogra | k | 19:07 |
| ogra | i thought there was a kernel patch added in maverick that was supposed to exactly do that | 19:08 |
| SpamapS | ogra: its more of making sure that we don't step on d-i's toes and that we don't slow the boot accidentally. | 19:08 |
| ogra | apw, was that patch ripped out again ? | 19:08 |
| SpamapS | ogra: the kernel patch passes the console params as env vars to init yes | 19:08 |
| ogra | right | 19:08 |
| SpamapS | ogra: but init doesn't do anything with them | 19:08 |
| ogra | so we should have the values | 19:08 |
| SpamapS | no they're not copied into the child environments | 19:08 |
| ogra | init doesnt pass them on the the jobs ?` | 19:08 |
| ogra | ah | 19:08 |
| ogra | then i misunderstood completely | 19:09 |
| SpamapS | Though I haven't tested whether that can be enabled by simply saying 'env console' ... meaning to do that... but I think the way I read the code, that didn't seem to be useful. | 19:09 |
| ogra | ok | 19:09 |
| sebrock | I need to contact the developer or maintainer of a certain package in Lucid. However it simply says its most likely the Debian maintainer. How does that work? Who packages it for Ubuntu? | 19:10 |
| SpamapS | for performance reasons (I think) init doesn't pass anything to children that isn't defined in the job or the events. | 19:10 |
| ogra | so we either go with what we have as distro patch or we need to keep the existign hackery | 19:10 |
| ogra | i would still prefer an upstart patch instead of the hacks | 19:10 |
| ari-tczew | mr_pouit: around? | 19:10 |
| SpamapS | ogra: I think there are some tentative +1's for the proc cmdline patch to go forward until init does the right thing w/ those env vars. | 19:10 |
| ogra | ah, great | 19:11 |
| SpamapS | ogra: my crazy idea was why don't we just have getty leave the serial port settings untouched and let the kernel manage them. :-P | 19:11 |
| ogra | make the kernel pull from console= ? | 19:12 |
| SpamapS | the kernel already sets the params from console= .. | 19:12 |
| ogra | could be dangerous if the user heavily mistypes | 19:12 |
| SpamapS | so if getty didn't make any attempt to change them, they'd be set correctly already | 19:12 |
| ogra | oh | 19:12 |
| ogra | i didnt know that | 19:12 |
| ogra | i agree that would be cooler | 19:12 |
| kees | wendar: oh, nice additional finds in bsdmainutils. I clearly didn't look hard enough. | 19:12 |
| ogra | i thought getty needs them | 19:12 |
| SpamapS | right, well its already getting stuff spewed out by kprint | 19:12 |
| SpamapS | getty does need them, but we could patch getty to have a '--no-setserial' | 19:13 |
| SpamapS | just open and go | 19:13 |
| wendar | kees: thanks! | 19:13 |
| SpamapS | but then if anything changes them.. you want getty to reset them | 19:13 |
| SpamapS | so if the upstart job can save them off somewhere and restore them later.. that would work. | 19:14 |
| wendar | kees: should I request a sync on the 8.2.2 debian release, or are you doing it? | 19:14 |
| ogra | what would change them between init and getty ? | 19:14 |
| SpamapS | ogra: getty has a cool hack where if you send a BRK then it cycles through all known baud rates | 19:14 |
| SpamapS | ogra: useful when you want to just plugin and go and don't know the baud rate | 19:15 |
| ogra | yeah | 19:15 |
| kees | wendar: either way. I was going to, but requestsync doesn't see 8.2.2 yet | 19:15 |
| SpamapS | ogra: but you'd still want it to go back to whatever the kernel had specified | 19:15 |
| ogra | well, i like that approach | 19:15 |
| SpamapS | me too.. the question is.. where do we store the settings? | 19:15 |
| ogra | does it need persistance over boots ? | 19:16 |
| wendar | kees: okay, cool, I'll leave it with you. Will make a note in the LP ticket. | 19:16 |
| ogra | else i'd say /var/run | 19:16 |
| kees | wendar: cool | 19:16 |
| SpamapS | ogra: right, /var/run is my suggestion too... I was also trying to see if there's a way to store it in an env var in the upstart job. | 19:19 |
| SpamapS | ogra: definitely doesn't need to survive reboot | 19:19 |
| ogra | right, then /var/run/serial or some such | 19:19 |
| SpamapS | ogra: for the future upstart console handling.. I think upstart will keep track of it. | 19:19 |
| ogra | or something like /var/run/console-settings | 19:19 |
| ogra | sweet | 19:20 |
| SpamapS | btw, does anybody know what the policy is on /etc/default files and upstart jobs? It seems like to support upgrades, all converted init.d->upstart job files need to keep sourcing that file. | 19:20 |
| SpamapS | zul: ping, I bet you know. | 19:21 |
| SpamapS | slangasek: ^^ | 19:21 |
| zul | SpamapS: as i understand it you shouldnt use /etc/default with upstart | 19:21 |
| === bjf[afk] is now known as bjf | ||
| SpamapS | zul: but that *completely* breaks upgrades | 19:22 |
| zul | SpamapS: i could be wrong | 19:22 |
| * SpamapS looks through release notes to see if its at least mentioned there | 19:24 | |
| slangasek | SpamapS: there's no "policy", just a set of opinions :) | 19:25 |
| slangasek | SpamapS: I've consistently taken your approach when upstarting packages - preserve behavior on upgrades where reasonable | 19:25 |
| SpamapS | slangasek: I think /etc/default files should be sourced and respected still, or the change in behavior mentioned in the release notes. | 19:27 |
| cjwatson | ogra: d-i> my point was more that it needs not to conflict, and that the lessons learned while implementing it in d-i should be carried over | 19:29 |
| ogra | cjwatson, ah, indeed | 19:29 |
| cjwatson | rsalveti: done | 19:30 |
| rsalveti | cjwatson: thanks! | 19:30 |
| slangasek | SpamapS: amusingly, I've just discerned why gssd and idmapd don't suffer from the startup race with equal incidence - it's because idmapd is (uselessly) sourcing /etc/default/nfs-common in a script, and gssd is execing rpc.gssd directly | 19:33 |
| slangasek | SpamapS: anyway, yes, anywhere that /etc/default might have contained relevant config information, I've preserved that when converting to upstart even though this makes the start-up less efficient | 19:33 |
| cjwatson | ogra: accepted unity-2d. could you please make its Conflicts/Replaces be Breaks/Replaces instead, per current policy? | 19:34 |
| ogra | oops, will do | 19:34 |
| SpamapS | slangasek: I knew there had to be something fixing rpc.gssd other than "its just special" ;) | 19:35 |
| SpamapS | slangasek: I do think we'd also be fine if we put in the release notes something about it, and maybe included a script that told you what non-default values you've used in /etc/default. | 19:36 |
| SpamapS | slangasek: its the old deprecated conffile problem all over again isn't it? | 19:37 |
| slangasek | well, more or less | 19:37 |
| slangasek | if I were going to drop an /etc/default file, I would do it by migrating the settings to the upstart job and then deleting the file from /etc/default | 19:38 |
| slangasek | which is touchy, which is why I haven't done this yet | 19:38 |
| slangasek | now, here's a question | 19:39 |
| SpamapS | slangasek: it seems like it should be ok.. but it would break with conffile policy to do it in maintainer scripts.. | 19:39 |
| slangasek | is it right for upstart-job to be a no-op for 'start' just because 'status' shows a PID? | 19:39 |
| slangasek | SpamapS: yes, I like to live in my own special gray area where conffiles are concerned :) | 19:39 |
| slangasek | (maybe that's another reason I haven't done this yet) | 19:40 |
| SpamapS | well in this case you're technically just merging the old one into the new one.. :) | 19:40 |
| slangasek | upstart-job> consider the case where the job has a post-stop script and the status is stop/stopping $pid | 19:40 |
| slangasek | that doesn't sound to me like a case to turn 'start' into a no-op | 19:40 |
| SpamapS | slangasek: right I think it has to already bean in a goal of start. | 19:40 |
| SpamapS | bean.. hrm.. almost lunch time.. ;) | 19:41 |
| slangasek | SpamapS: so do you think start/.* $PID is the right boundary? Or should it just be start/running, with no PID check? | 19:45 |
| slangasek | (a 'start' for a job that's still starting is a no-op anyway, isn't it?) | 19:45 |
| SpamapS | slangasek: its conceivable that some jobs will use pre-start and post-stop to run whatever it is they're doing, and not have a pid. | 19:46 |
| slangasek | yes, that's the precise bug I'm fixing right now | 19:46 |
| slangasek | (upstart-job handles apport wrong) | 19:46 |
| SpamapS | is it a task? | 19:47 |
| slangasek | but what I'm wondering is if we should *only* be checking for start/running status, and ignore PIDs completely | 19:47 |
| slangasek | I'm inclined to say the answer is "yes" | 19:48 |
| slangasek | because bzr says I wrote the original code here | 19:48 |
| slangasek | and I think I was wrong :) | 19:48 |
| SpamapS | I agree on principle, but I'm not sure I understand where upstart-job is handling apport incorrectly. | 19:48 |
| slangasek | SpamapS: it's not a task, it's a pre-start+post-stop w/ no main process | 19:49 |
| seb128 | is there any way to delete something from the unaccepted queue if I just uploaded? | 19:49 |
| SpamapS | are you saying that when its in start/running already, that it runs start again, but fails, and this is a problem? | 19:49 |
| slangasek | SpamapS: so upstart-job says "oh, you want to start this thing w/ no PID, let me do that for you" and then fails | 19:49 |
| slangasek | seb128: unaccepted -> unapproved? If so, yes | 19:49 |
| seb128 | slangasek, how? | 19:49 |
| slangasek | seb128: q reject $thingy | 19:50 |
| Keybuk | right, it's perfectly cromulent for Upstart jobs to have no main process | 19:50 |
| slangasek | seb128: unless this was a generic "you"; I'm assuming I'm talking to the "you" who is an archive admin :-) | 19:50 |
| * SpamapS thinks Cromulence should be a chief goal of any pid 1 replacement | 19:50 | |
| seb128 | slangasek, well that acts on "NEW" no? | 19:50 |
| Keybuk | SpamapS: it really embiggens the feature set | 19:50 |
| SpamapS | slangasek: right, ok I understand, and looking at the code.. yeah.. you shouldn't care about the PID, just the state. | 19:51 |
| seb128 | slangasek, or q -Q unapproved? | 19:51 |
| seb128 | slangasek, well I've been lucky on this one the upload got rejected because it was a revision update and the tarball is not in natty | 19:51 |
| seb128 | slangasek, but that can be useful for next time ;-) | 19:51 |
| slangasek | seb128: yes, it's 'q -Q unapproved -s $foo-proposed reject $thingy' | 19:51 |
| seb128 | slangasek, well that was an upload to natty | 19:52 |
| seb128 | not to a moderated queue | 19:52 |
| slangasek | seb128: oh, then there's no unapproved queue at all :) | 19:52 |
| slangasek | so no, sorry, no way to intercept AFAIK | 19:52 |
| seb128 | I was wondering if there was a way to catch it before the next run | 19:52 |
| seb128 | ok, what I think | 19:52 |
| seb128 | though | 19:52 |
| seb128 | slangasek, thanks | 19:52 |
| slangasek | pitti, seb128, cjwatson, SpamapS: I've pushed my fix for bug #603934 to lp:ubuntu/upstart, then; I'm still testing it here, more eyeballs before I upload would be appreciated | 19:58 |
| ubottu | Launchpad bug 603934 in upstart (Ubuntu Natty) "upstart-job returns SysV-incompatible value for 'start' when job is already running" [Critical,Triaged] https://launchpad.net/bugs/603934 | 19:58 |
| SpamapS | slangasek: that code actually reads much easier too. :) | 20:02 |
| cjwatson | seb128: if you're quick enough then you can sudo to lp_queue and nuke it before process-accepted runs (*/5), but you do have to be quick | 20:06 |
| cjwatson | once it hits the accepted queue, build jobs will be created and all the rest of it | 20:06 |
| seb128 | cjwatson, where is it on disk? | 20:06 |
| cjwatson | ~lp_queue/ubuntu-queue/incoming/ | 20:07 |
| seb128 | cjwatson, ok, worth knowing, thank you | 20:07 |
| mnabil | hello guys , i want to participate in ubuntu development cycle ? | 21:39 |
| mnabil | is there any process i should follow ? | 21:40 |
| SpamapS | mnabil: what do you want to do? | 21:46 |
| SpamapS | mnabil: this might be a good place to start https://wiki.ubuntu.com/UbuntuDevelopment | 21:47 |
| mnabil | SpamapS, i know C/C++/Python and i'm involved in Lxcenter and cloud | 21:47 |
| mnabil | i can be helpful :) | 21:47 |
| SpamapS | https://bugs.launchpad.net/ubuntu ... there are 87367 bugs to choose from.. have fun! ;) | 21:49 |
| JackyAlcine | Only 87367? | 21:50 |
| mnabil | SpamapS, thanks alot for you help | 21:58 |
| === sconklin is now known as sconklin-gone | ||
| cody-somerville | I assume libdrm-nouveau1a breaking natty bootstrap process is known? | 23:14 |
| RAOF | It should be fixed now. | 23:14 |
| === bjf is now known as bjf[afk] | ||
| cjwatson | cody-somerville,RAOF: maybe not entirely fixed - I've just made a pair of override changes in the archive which should help, in about an hour's time | 23:38 |
| cjwatson | though xserver-xorg-video-nouveau will still have trouble installing | 23:40 |
| RAOF | The new nouveau upload should be installable | 23:40 |
| ari-tczew | Debian will be released 5th/6th February :> | 23:41 |
| real_ate | hi all! quick question... is there a page anywhere detailing or documenting how to create "quickly" templates? | 23:47 |
| real_ate | my searches are ending up fruitless | 23:48 |
| blueyed | zul: can you sponsor a munin upload for me? I've just noticed that it is in main, after uploading. I upload the package to own webspace, ok? | 23:51 |
| blueyed | zul: it is here now: http://codeprobe.de/spool/debian/munin_1.4.5-3ubuntu2.dsc | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!