[00:00] all packages that pass testing will be pushed to stable on wednesday. this is also when i will be checking the ppas and uploading any new packages to testings [00:01] i have system worked out just cuz ive been doing this so long with my old linux distro :P [00:02] ryan22: well I dont think the system is for me but each to their own :) [00:02] eh. time will tell. [00:02] yep [00:02] its radical, but i think it is needed. which is why i created it ;) [00:03] ill keep in touch === dendro-afk is now known as dendrobates === tkamppeter_ is now known as tkamppeter === fta_ is now known as fta [02:57] software center gets its descriptions from the control file in the package, right? [03:01] I believe so, yes. [03:01] I'm pretty sure it also scrapes some information from the .desktop file the package ships. [03:01] ok === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta [05:26] Good morning [05:26] cjwatson: libusb> will do [05:27] kees: sourceful retracing> no, since it causes trouble with some packages; this needs some time to figure out === fta_ is now known as fta [06:11] does anyone know what an application has to support for it to be able to be restarted from its last state when you boot gnome? (The Remembered Running Applications) [06:11] is that part of the free desktop specification? [06:21] solid_liq: It needs to register with the session manager. [06:21] solid_liq: That's the session-management protocol, via DBus. [06:22] Actually... it might not be exclusively dbus. I forget :) === fta_ is now known as fta [06:28] RAOF, any idea of where I can find any docs for it? [06:28] RAOF, I'd like to add that capability to xchat [06:30] I believe http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Fwww.xfree86.org%2Fcurrent%2Fxsmp.pdf&ei=DKg6TMamLYu4ca_HifwO&usg=AFQjCNG_yk4ra0Lk4JZC4-nrV09wjO4mrg&sig2=y1Vjp0xpmYnRYm8qXkK6cA is still current [06:34] cool thanks! :) [06:34] http://live.gnome.org/SessionManagement/GnomeSession might be better [06:50] RAOF, oh sweet, thanks! === yofel_ is now known as yofel [07:28] cjwatson: libusb update for bug 595650 uploaded; can you review/accept, please? [07:28] Launchpad bug 595650 in libusb (Ubuntu Lucid) "After the last updates HP printer stopped working" [Critical,In progress] https://launchpad.net/bugs/595650 [07:28] or slangasek [07:59] good morning === fta_ is now known as fta [08:34] bryceh, tjaalton, RAOF: there's a bunch of X related stuff on http://qa.ubuntu.com/reports/sponsoring/ - just wanted to let you know [08:38] can an archive admin please process the open syncs? [08:38] dholbach, hmm, I paged through that but didn't see anything, just a few sync requests? [08:39] bryceh: yeah, I wasn't sure if it was a good idea to sync that stuff from experimental so I thought I'd leave that to you guys [08:40] dholbach, the titles for those sync requests indicate they're sync'd from unstable, which should be just fine [08:40] dholbach, even for experimental that'd probably be fine [08:40] bryceh: oh sorry, then it was some sync request last week I think [08:41] ah yes [08:41] in any case: just wanted to let you guys know [08:41] Thanks. [08:41] :) [08:43] heya RAOF [08:44] bryceh: Howdie. === bryceh is now known as 40FAA7E1T [08:44] 40FAA7E1T: Your robotic nature is outed at last? [08:50] slomo, hello, is there some progress packaging gdk-pixbuf 2.21.5 and gtk 2.21.4? [08:51] <40FAA7E1T> RAOF, oh was it in the closet? [08:52] ricotz: nope, but seb128 wanted to do it === 40FAA7E1T is now known as bryyce [08:54] -NickServ- You are now identified for bryce2. [08:54] --- 40FAA7E1T :Nick collision, forcing nick change to your unique ID [08:54] You are now known as 40FAA7E1T [08:54] wild [08:56] slomo, ok, is there a package name structure for gdk-pixbuf set yet? the old one is pretty outdate and might be updated to meet the structure of glib or atk? [08:57] slomo, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1229696/+listing-archive-extra [08:58] this package still misses some installation scripts out of the gtk package [08:58] yes, all these scripts are the most work ;) [08:58] the package names look good btw [09:01] slomo, i know, but for now there is where my knowledge ends to properly update it, would take me much more time to go through it than for you :( [09:02] ricotz: maybe tell seb128 about it later today when he's here, i'm quite busy in the next days [09:02] yes, the names should be good which matches the other gnome lib package well === fta_ is now known as fta [09:03] slomo, ok, and hopefully there will be a gtk+3.0 package soon ;-) [09:04] cjwatson, ubuntu policy document ... 1) is the version in your people the offical version and 2) can you remind me where the 'what to check when updating from x.y.z to x.y.z+1' list is for it? [09:15] StevenK, lool: is hildon-desktop something that we still actually want/need in maverick? it hasn't been updated since karmic, and not a lot since hardy [09:16] StevenK, lool: same question for libosso (not updated since hardy) [09:17] pitti: It certainly has "diminishing returns" [09:18] we could sync them from Debian, or remove them [09:18] pitti: It's not used in any of our images anymore, and the version we had was patched in a very complex way [09:18] So in theory we have some nice patches in there, but the changes are complex to look at [09:18] those are part of Colin's "stale merges" list [09:18] Yes, guessed that, I saw it too and was scared [09:19] I wouldn't mind a sync personally; people can extract the patches from older source packages if they really want them [09:20] so they weren't appropriate for upstream, etc? [09:24] seb128: wrt. the "stale merges" list, I'm looking at libgtop2 [09:24] pitti, ok, it's basically a can sync one I think, but there is no interest change so we went "who cares" until now [09:24] pitti, but if you feel like versions should be updated feel free ;-) [09:24] it's a new upstream series now (2.28) [09:25] seb128: yes, better to keep in sync IMHO [09:25] well we are mostly in sync I think [09:25] I'll check/sync [09:25] ok === fta_ is now known as fta [10:00] Could an archive admin please kill default-jdk-builddep from the NBS list. default-jdk-builddep got renamed to gcj-native-helper (which still provides default-jdk-builddep) and the stale deb prevents that packages build-depending on it can't currently get build. Except tex4ht all dependencies on default-jdk-builddep are unversioned so they are still fulfilled by gcj-native-helper. For tex4ht bug [10:00] #603101 awaits sponsoring. Thanks. [10:05] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/603919 => this is also a cool one :) [10:05] Launchpad bug 603919 in pygobject (Ubuntu) ""python packages" crashed with ImportError in ()" [High,Confirmed] [10:12] geser: referring to the java bug, look at the comment from nthykier on the related debian bug === almaisan-away is now known as al-maisan [10:18] bdrung: I saw that comment but I don't know enough about java packaging to know what to do with it :( I prefer to wait on the DD with the proper fix. I just proposed to drop the version from the build dependency as it's the only package with one. [10:20] and as long the stale default-jdk-builddep deb is in the archive, any package build-depending on default-jdk-builddep can't get build as the buildd try to install the stale default-jdk-builddep and fail because of depends [10:22] geser: removing, thanks for pointing out === fta_ is now known as fta === Lutin is now known as Guest82489 [10:49] pitti: thanks, will look [10:51] apw: yes, the version I have is the official one, though you can use the package in the archive too. install the ubuntu-policy package and look at /usr/share/doc/ubuntu-policy/upgrading-checklist.txt.gz [10:51] cjwatson, ahh thanks [10:52] cjwatson, seems we are a little behind debian in the policy version, but it also seems to be a sync'd package from them. do we have a policy on when we update the policy ? [10:52] apw: same as other merges, when I get round to it :) [10:52] apw: it's not that vitally important [10:53] apw: if you want to update to debian-policy 3.9.0, feel free [10:53] ubuntu-policy basically has additions rather than any significant number of changes [10:54] ok makes sense === Guest82489 is now known as Lutin === smb is now known as smb-afk === al-maisan is now known as almaisan-away [11:59] cjwatson, ev: after oem-config has run, is it supposed to purge itself and the dependencies (ubiquity, libicu42, reiserfsprogs, etc0 [12:00] ? [12:00] pitti, yes [12:00] (and it does that on our omap images) [12:00] ogra: thanks [12:01] I dunno if somebody can take a look @ https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/603919 ? Its a quite important bug, as ALOT of python packages are broken because of it (check duplicate bugs it has already) [12:01] Launchpad bug 603919 in pygobject (Ubuntu) ""python packages" crashed with ImportError in ()" [High,Confirmed] [12:02] cjwatson, do you know where the chvt occurs in the boot process is that before or in plymouth ? === DrPepperKid is now known as MacSlow [12:10] apw: I think it's in plymouth itself [12:10] dupondje, I'm about to upload a fix [12:10] cjwatson, could well be, it knows how to for sure. how it knows where to go to i have no idea [12:10] dupondje, you are sure they are broken? it seems it triggers apport but softwares work [12:10] apw: hardcoded, I imagine [12:11] hello [12:11] cjwatson, i am struggling to work out how to tell whether i have maintained the screen till the vt switch as i don't really know when it occurs :/ does the world work if i strip plymouth out ? [12:12] seb128: dunno really about apport-gtk, but for example pybootchartgui doesn't even start ... [12:12] and alot of other packages are affected [12:12] dupondje, well lot trigger apport but I doubt that break softwares [12:12] apw: it's in debian/rules [12:12] --with-boot-tty=/dev/tty7 \ [12:12] --with-shutdown-tty=/dev/tty7 [12:12] StevenK, hi, could you renew my membership to bluetooth group [12:12] dupondje, it's an error in the introspection that nothings is using [12:12] apw: plymouth is required; at least some things will very likely break without it [12:13] cjwatson, so it is ... bah thanks [12:13] apw: a plymouth splash is not required, though [12:13] important distinction, plymouth doesn't imply a splash screen [12:14] cjwatson, but presumably if its there, it will VT switch [12:14] as even without 'splash' X is on 7 [12:14] (but hearing you) [12:14] apw: I don't recall for certain, but I think that it only VT-switches when showing the splash [12:15] X does its own chvt if it needs to [12:15] seb128: can't test more atm, as i'm on another computer atm :) but ah well, if its getting fixed we are happy :) [12:15] cjwatson, ahh hrm [12:15] you can for sure see it triggers apport lol, all those duplicate bugs [12:15] apw: you can boot without the 'splash' argument to test [12:15] yeah i think that is working and telling me i am broken [12:16] yeah, it's the splash plugin that calls ply_terminal_activate_vt === DrPepperKid is now known as MacSlow [12:27] micahg: to fix the xulrunner-1.9.2 build failures on sparc, you may want to build with -mcpu=v9 [12:27] doko: thanks, is that for the previous releases? It seems to build in Maverick [12:28] micahg: I thought you did do the mozilla-security-ppa uploads [12:28] doko: chrisccoulson did the uploads there [12:28] jaunty & karmic. lucid and maverick default to ultrasparc [12:29] doko - ok, thanks. i hadn't had a chance to look at those yet [12:29] hi, any chance to see thunderbird 3.1 in maverick [12:30] ricotz: yes [12:32] chrisccoulson: I don't know yet the cause for the armel build failure in jaunty [12:32] micahg, nice, is there a timeframe yet, i think 3.1.1 will be out soon [12:33] ricotz: before beta 1, 3.1.1 should be out sometime next week [12:34] micahg, ok [12:34] ricotz, hi [12:34] ricotz, slomo said you worked on gdk-pixbuf packages, do you have those somewhere? [12:34] seb128, hi [12:35] seb128, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1230542/+listing-archive-extra [12:35] ricotz, you don't work in a vcs? [12:36] ricotz, would make easier to review changes and contributes fixes etc [12:36] seb128, sorry no [12:36] ok, thanks anyway [12:37] do you work to get those in debian? [12:37] or should I try to get those there? === MacSlow is now known as MacSlow|lunch [12:38] seb128, i want to have a gtk+3.0 package for g-s ;-) so gdk-pixbuf is needed [12:38] seb128, feel free to use it and get it in debian [12:38] seb128, it still needs some work [12:39] ricotz, what does it need? [12:40] seb128, idno yet, it is work in progress, i might missed some files and some debian policies like the copyright file [12:41] ricotz, ok, thanks === gnarl is now known as smb [12:57] seb128: ~ https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/604415 -- I remember we talked a long while back about how Wine should declare itself as the default handler on double click once it's installed, but that wasn't possible at the time since archive manager was the default... is this fixable now? [12:57] Launchpad bug 604415 in wine (Ubuntu) "nautilus tries to open windows executables with file roller instead of wine" [Undecided,New] [12:58] YokoZar, hi, no that didn't change I think === freeflyi1g is now known as freeflying [12:58] YokoZar, but neither nautilus nor our default list changed since lucid [12:58] so if something changed I guess that's on the wine side [12:59] seb128: No, you still have to right click->open with wine. [12:59] seb128: The real solution sidesteps the question anyway since the default action should be the exe-handler I describe at the wine integration spec (which would have different behavior if wine was installed/not installed) [13:00] Thanks === fta_ is now known as fta === psurbhi is now known as csurbhi-afk [13:28] mvo: https://bugs.edge.launchpad.net/ubuntu/+source/sessioninstaller/+bug/604577 [13:28] Launchpad bug 604577 in sessioninstaller (Ubuntu) "Sync sessioninstaller 0.20-1 (universe) from Debian unstable (main)" [Undecided,New] [13:29] Needs an ACK [13:30] thanks juliank [13:30] juliank: doing that now [13:30] mvo: I had to create a tarball from bzr, because glatzor's was broken [13:31] juliank: the ftbfs in python-apt (in debian) should also be fixed in bzr, if you have a amd64 chroot availalbe it would be nice if you could do a test-build to be sure [13:31] juliank: aha, ok [13:33] james_w: if you have a moment, it would be great if you could sync bug #604577 [13:33] Launchpad bug 604577 in sessioninstaller (Ubuntu) "Sync sessioninstaller 0.20-1 (universe) from Debian unstable (main)" [Medium,Confirmed] https://launchpad.net/bugs/604577 [13:35] mvo: Seems you forgot the status file: http://paste.debian.net/80258/ [13:37] seb128, there is something wrong with your libgtop2 sync [13:38] ogra: iz pitti sync [13:38] juliank: *cough* sorry. fixing [13:38] ogra: what is wrong with it? [13:38] mvo: Moving the data for the test into data/test_debs would also be a good idea [13:38] seb128, whoops, mixed maintainer with changed-by [13:38] seb128, seems it doesnt build the -common package at all [13:38] they dropped it? [13:39] oh, wait, it built it on x86 but it doesnt get synced to the ports archive [13:39] ogra: it should be built on i386 [13:39] (indeed its arch all) [13:39] ogra: ok, now it makes some sense ;-) [13:39] http://ports.ubuntu.com/ubuntu-ports/pool/main/libg/libgtop2/ has the armel binary but not the arch all one [13:39] s/one/ones [13:40] -dev is missing as well [13:40] seb128, could it be hanging in NEW ? [13:42] ogra: yes, it's in binNEW [13:42] ha, great, so i'm not brian-molten yet :) [13:42] *brain even [13:43] juliank: please update to r432, should be better now [13:44] mvo: I still get AssertionError: Unexpected result for package 'gdebi-test3.deb' (got False wanted True) [13:47] mvo: Because it tests against the system (amd64) cache which contains no i386 packages. === MacSlow|lunch is now known as MacSlow [13:49] mvo: Removing apt_pkg.config.set("APT::Architecture","i386") fixes it [13:49] juliank: hm, odd, it should use the fixture status file that is pre-populated with i386 packges with the right dependencies (well, no dependencies :) [13:50] mvo: OK, I missed that. [13:50] mvo: You probably need an apt_pkg.init_system() after setting the status file. [13:51] As the system stores the location internally during init(). [13:51] juliank: for me (with the current code) print len(self.cache) print "3" (that is the amount of fixture data I put in) [13:53] mvo: Running test_debfile directly gives me http://paste.debian.net/80260/ [13:54] juliank: thanks, let me improve the test failure output a bit [13:54] mvo: the new version isn't visible on the mirror used by cocoplum yet, so I can't sync yet [13:56] james_w: Yes, it's at http://incoming.debian.org/sessioninstaller_0.20-1.dsc until dak ran. [13:56] zul, ping [13:56] smoser: yo [13:56] i think free was expecting you were going to push on https://bugs.launchpad.net/landscape-client/+bug/594594 a bit. [13:56] Launchpad bug 594594 in landscape-client (Ubuntu Karmic) "Update jaunty, karmic, lucid and maverick to landscape-client 1.5.2" [Undecided,New] [13:57] smoser: yeah its waiting to be accepted [13:57] cjwatson: ^^^ === fta_ is now known as fta [13:58] its waiting on https://bugs.launchpad.net/landscape-client/+bug/597000 [13:58] Launchpad bug 597000 in landscape-client (Ubuntu Karmic) "get_active_interfaces reports duplicated interfaces" [High,New] [13:58] (see last comment in that bug) [14:00] cjwatson, you can ignore zul's ping above [14:02] juliank: what do you get from r433? anything more useful? I added the error message in the assert failure output [14:04] mvo, juliank: done [14:04] * mvo hugs james_w [14:05] mvo: Adds Dependency is not satisfiable: pkg-that-does-not-exists|apt when run via test_all === csurbhi-afk is now known as psurbhi [14:10] hm, daily maverick installer cd doe snot have an 'ok' button in the 'Where are you' panel, so i can't get past choosing a time zone :) [14:11] mvo: My system is a bit broken [14:12] juliank: thanks, let me add a check for this as well, its rather silly that it break in test3 in a case like this :) [14:12] mvo: I had old code in my build/ directory which was used. [14:13] juliank: aha, ok. many thanks for this info. is it working when that is fixed? [14:14] mvo: http://paste.debian.net/80261/ fixes it [14:15] The init_system() is needed everytime Dir::State::status changes, because the system copies the value of Dir::State::status [14:16] juliank: great, thanks. if it works now, I upload a new version [14:21] mvo: test works, but sphinx is causing the build to fail currently. [14:21] (for me) [14:21] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559572 [14:21] Debian bug 559572 in python-sphinx "python-sphinx: doesn't remove python-central leftovers" [Serious,Open] [14:22] might be it [14:23] or not [14:29] LucidFox: (I didn't see where your odd licensing question got answered): It's probably undistributable due to conflicting licensing terms. [14:31] mvo: http://bugs.debian.org/588807 [14:33] So... [14:35] Are the CSD/RGBA patches going to be re-enabled later in the Maverick cycle? [14:36] yes [14:36] rgba at least [14:36] csd likely not [14:38] so windicators(R) are going to be pushed until maverick+1? [14:38] dunno [14:38] they could be made in the decorator as well [14:38] they will need in any case since not every software is gtk === fta_ is now known as fta === amitk is now known as amitk-afk === jtechidna is now known as JontheEchidna === dendrobates is now known as dendro-afk === almaisan-away is now known as al-maisan [15:07] slangasek, seb128, apachelogger: all set? :) [15:07] dholbach: aye [15:08] dholbach, yes [15:08] * dholbach still needs to prepare :-P === dendro-afk is now known as dendrobates === LucidFox_ is now known as LucidFox [15:36] pitti: Would you please rescore kdebindings (just affects ia64)? === fta_ is now known as fta === jono is now known as Guest68844 [15:57] Is Maverick going to include GTK3? [15:57] LucidFox: nope [15:57] hmmm [15:58] so which GNOME version is it going to ship with? [15:59] LucidFox: as far as the desktop pacakges , the team is assessing each package and updating/backporting as required.. so it depends [15:59] the desktop team* [16:00] Mostly not 3.0 afaik. Migration is supposed to happen in two releases, likely conservatively.. [16:13] is it possible to use locakfile-create with upstart/ === dendrobates is now known as dendro-afk [16:14] I need archive admin help. need to get 'grub-legacy-ec2' approved here : https://launchpad.net/ubuntu/maverick/+queue?queue_state=0&queue_text=cloud-init === fta_ is now known as fta [16:34] pitti: do you know what happened to the jaunty packages on http://ddebs.ubuntu.com/dists/? [16:40] ev: Hey [16:41] ev: LP #603299 is the perl FTBFS assigned to you [16:41] Launchpad bug 603299 in perl (Ubuntu Maverick) "[amd64] perl FTBFS in maverick" [High,Confirmed] https://launchpad.net/bugs/603299 [16:41] ev: I just uploaded perl earlier today with a fix for the Linaro issue (unrelated I think), and it built [16:41] ev: Did you reproduce yourself? Shall we close for now? [16:41] Hmm thinking about it, I wonder whether it could be under PPA buildds [16:41] ev: ^ [16:42] the virtual kernel behaving differently from the Ubuntu one or so [16:42] lool: I've been unable to reproduce it [16:42] I think we should close it [16:42] ev: Agreed; let's close it for now, and if someone reproduces, we shall ask more about the environment [16:43] done, thanks! [16:44] ah done too [16:44] I had marked it incomplete, but will move back to fix released [16:44] okay [16:44] done [16:45] cool, thanks [16:48] https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 12 minutes in #ubuntu-classroom [16:50] Okay, just updated to Maverick, went better than I expected in general [16:51] something's wrong with GTK, though, theme rendering is screwed up [16:51] let me try disabling RGBA... [16:51] from the custom PPA === bjf[afk] is now known as bjf === MacSlow is now known as MacSlow|break [16:54] * apachelogger giggles [16:55] JontheEchidna: btw, I need a fanclub for widgetcrafting [16:55] ScottK: it's currently building [16:55] mdeslaur: jaunty was cleaned up the other day, I think [16:56] pitti: I thought you had rescored it once I saw that. Thanks for checking. [16:56] pitti: ah, I see. was just wondering... [17:02] hi, what's the chances that mavrick daily wil work if alpha 2 didn't want to boot im my pc? [17:03] I've tried lucid with kernel-ppa just downloaded 2.6.35-2-generic-pae and 2.6.35-7-generic-pae, not one of them boots [17:03] not even in recovery mode [17:09] i see a 'quilt-setup' entry in debian/rules of openssh package. This is needed to set up the .pc directory of quilt to convince it that all patches have already been applied. [17:10] this seems to be infrastructure needed by all quilt 3.0 format packages. is there anything that is being done to make it common ? [17:10] smoser: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 [17:10] Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] [17:10] cjwatson, thanks [17:26] Could a core-dev please give-back: libxerces2-java. The problem got resolved today so it builds again. Thanks [17:26] geser: doing === beuno is now known as beuno-lunch === MacSlow|break is now known as MacSlow [18:00] pitti, hi === fta_ is now known as fta [18:02] ok. so i'm looking at bug 43574. which says xinetd should be an upstart job. what upgrade cases do i need to handle ? If i add xinetd.upstart and it gets pulled in, do I need to attempt to read the previous defaults/xinetd.conf? [18:02] Launchpad bug 43574 in xinetd (Ubuntu) "Needs Ubuntu-style init script" [Wishlist,Triaged] https://launchpad.net/bugs/43574 [18:03] per upstart design, the upstart doc, should not read /etc/defaults/xinetd.conf . but if i ignore it, and move the existing /etc/init.d/xinetd to an upstart job, then the xinetd server may then start with different options for a user who had modified xinetd.conf [18:03] smoser: while there's no policy that requires you to continue honoring /etc/default when converting from sysvrc to upstart, I consider it bad form to not do so in some fashion [18:03] er... who had modified default/xinetd.conf [18:04] dholbach: yep, I'm ready :) [18:05] slangasek, so what would you recommend ? i surely dont want to modify etc/init/xinetd.conf based on contents of /etc/defaults/xinetd . should I just source it if it exists, generally honor the old behavior but not lay a new one down [18:05] ? [18:06] smoser: source if it exists, but set sensible defaults within the upstart job itself; don't ship the defaults file in the new package; on upgrade, remove /etc/defaults/xinetd iff it's unmodified, using the standard conffile runes for this [18:06] slangasek, thanks. [18:06] and i think dh_installinit does most of that. [18:07] it doesn't help you with any of that, AFAIK :) [18:07] oh, and the standard runes for obsolete conffiles move the file aside if it's modified, so you have to take care not to do that [18:32] gah... I've been reading news about Pinta 0.4, and all the vitriol-laden comments about how Mono is the work of the Devil really irritate me [18:33] some users don't give the program a try just because it's Mono-based [18:41] can someone from the foundations team review ntpd upstart conversion for me? https://bugs.edge.launchpad.net/ubuntu/+source/ntp/+bug/604717 [18:41] Launchpad bug 604717 in ntp (Ubuntu) "Please convert init script to upstart" [Undecided,New] === beuno-lunch is now known as beuno [18:48] LucidFox: the best thing the mono team could do is reboot pinata on vala [18:49] mono isnt that bad, but there is no real reason for a runtime when you can can compile into c [18:51] though, the monodevelop guys do need to get around implementing things like supporting breakpoints in the external console and input in the internal console === fta_ is now known as fta [18:52] ive got my compu sci dept pretty much sold on dual-booting with a thin-client based version of ubuntu, but i can't even think going any furthur until they implement those features ;) [18:53] jono ping see pm [18:54] ryan22, right, like if C was the best language for every purpose :) [18:54] it is damn fast [18:55] and bashee takes 5 -10 sec to load [18:55] though i do love it anyways :) [18:55] ryan22, not from a development perspective for certain type of apps [18:55] nah. well im certianly not pushing it for my uni [18:55] but it does make more sense for desktop apps [18:56] and desktop search engines *cough* beagle *cough* [19:02] Jono_ ping please see off topic pm [19:03] porthose, on the phone, won't be long [19:04] jono_ k [19:12] joaopinto: perfection is paralysis. linux has tried to be perfect for too long ;) [19:13] it just needs to *work* [19:24] in "upstarting" a daemon, should i basically ditch the pidfile ? [19:25] and instead just rely on upstart to track it. [19:32] smoser: upstart doesn't care about pidfiles; I wouldn't include anything in the upstart job to specifically create / manage one [19:33] smoser: perhaps you want to come to the 'authoring upstart jobs' session at 2000 UTC? :) https://wiki.ubuntu.com/UbuntuDeveloperWeek [19:33] indeed i would [19:34] slangasek, well, the reason i asked aobut pidfiles is that xinetd kills with sigquit, not sigkill in the existing init.d script. [19:34] so i thought i'd kill similarly in pre-stop [19:34] but needed to determine pid [19:35] kills what? [19:35] you should definitely not be killing the xinetd process in pre-stop [19:36] hm... ok. [19:37] kills the xinetd daemon [19:37] yeah, don't do that. [19:37] i thought of doing that per man page: [19:37] pre-stop ... [19:38] It is typically used to send any necessary shutdown commands to the main process... [19:39] smoser: upstart sends sigterm, waits, then sends sigkill. As long as xinetd handles TERM sensibly, you don't need any other special handling [19:40] pitti, hi [19:40] hm... so with xinetd , as i'm reading its man page, sigquit quits the daemon. sigterm takes all running servers, then quits [19:40] so if i can't deliver a sigquit, i'll be changing behavior. and a stop to inetd would kill all its sub-servers. [19:41] well, you /can/ send -QUIT in pre-stop. I'm not sure which behavior should be considered correct [19:41] or what happens if xinetd receives the -TERM while the -QUIT handler is still running [19:41] how would i send -quit ? with kill ? [19:41] yes [19:41] right. its going to be busted anyway [19:42] busted? [19:42] busted as in different behavior than before [19:42] as i undertsand it, if you were using the /etc/init.d script, and someone had started a long running ftp download that was initiated via xinetd [19:42] and you did /etc/init.d/xinetd stop [19:43] the ftp download would continue [19:43] correct [19:43] but with upstart if the TERM is sent, it will be gone [19:43] yes [19:43] and we can't think of a way to keep the old behavior [19:43] yes we can [19:43] ok, then i missed something [19:44] 11:41 < slangasek> well, you /can/ send -QUIT in pre-stop. I'm not sure which behavior should be considered correct [19:44] if that's the behavior you want, that's the way to do it [19:44] well right. but then the sigterm is going to come through after pre-stop exits [19:44] so i must be missing how you're suggesting to send -QUIT [19:45] no, I'm suggesting that you should make sure xinetd's signal handlers are correct [19:45] yeah, i am confused. [19:45] sorry for killing your imte on this. [19:46] i dont necissarily care what is "correct" [19:46] more concerned with what is consistent [19:46] and consistent is sending a single SIGQUIT [19:46] you don't have that choice [19:46] you need to make sure xinetd's signal handlers are correct instead [19:46] and that a -TERM after -QUIT won't cause the subprocesses to be killed [19:47] anyway, here's the script you want: [19:47] pre-stop script [19:48] kill -QUIT $(status | awk 'stop\/pre-stop/ { print $NF }') [19:48] end script [19:49] well, yes. which is what i was initially going to try, but my guesss is that sigterm is going to come right after that and xinetd will then take out all the servers. [19:50] and i somewhat would consider it incorrect if it didn't do that [19:50] but oh wel. [19:50] thanks for your time sla [19:50] slangasek, [19:50] why would that be incorrect? [19:51] if the process has already been told to exit without killing servers, why should a later signal telling it to kill the servers override that? [19:54] same question can be asked in reverse. if a process has been told to quit and kill the servers, why would it not do so? [19:55] but i'll look [19:56]