[00:00] <ryan22> 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] <ryan22> i have  system worked out just cuz ive been doing this so long with my old linux distro :P
[00:02] <fagan> ryan22: well I dont think the system is for me but each to their own :)
[00:02] <ryan22> eh. time will tell.
[00:02] <fagan> yep
[00:02] <ryan22> its radical, but i think it is needed. which is why i created it ;)
[00:03] <ryan22> ill keep in touch
[02:57] <spikeb> software center gets its descriptions from the control file in the package, right?
[03:01] <RAOF> I believe so, yes.
[03:01] <RAOF> I'm pretty sure it also scrapes some information from the .desktop file the package ships.
[03:01] <spikeb> ok
[05:26] <pitti> Good morning
[05:26] <pitti> cjwatson: libusb> will do
[05:27] <pitti> kees: sourceful retracing> no, since it causes trouble with some packages; this needs some time to figure out
[06:11] <solid_liq> 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] <solid_liq> is that part of the free desktop specification?
[06:21] <RAOF> solid_liq: It needs to register with the session manager.
[06:21] <RAOF> solid_liq: That's the session-management protocol, via DBus.
[06:22] <RAOF> Actually... it might not be exclusively dbus.  I forget :)
[06:28] <solid_liq> RAOF, any idea of where I can find any docs for it?
[06:28] <solid_liq> RAOF, I'd like to add that capability to xchat
[06:30] <RAOF> 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] <solid_liq> cool thanks!  :)
[06:34] <RAOF> http://live.gnome.org/SessionManagement/GnomeSession might be better
[06:50] <solid_liq> RAOF, oh sweet, thanks!
[07:28] <pitti> cjwatson: libusb update for bug 595650 uploaded; can you review/accept, please?
[07:28] <pitti> or slangasek
[07:59] <dholbach> good morning
[08:34] <dholbach> 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] <dholbach> can an archive admin please process the open syncs?
[08:38] <bryceh> dholbach, hmm, I paged through that but didn't see anything, just a few sync requests?
[08:39] <dholbach> 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] <bryceh> dholbach, the titles for those sync requests indicate they're sync'd from unstable, which should be just fine
[08:40] <bryceh> dholbach, even for experimental that'd probably be fine
[08:40] <dholbach> bryceh: oh sorry, then it was some sync request last week I think
[08:41] <bryceh> ah yes
[08:41] <dholbach> in any case: just wanted to let you guys know
[08:41] <RAOF> Thanks.
[08:41] <dholbach> :)
[08:43] <bryceh> heya RAOF
[08:44] <RAOF> bryceh: Howdie.
[08:44] <RAOF> 40FAA7E1T: Your robotic nature is outed at last?
[08:50] <ricotz> 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] <slomo> ricotz: nope, but seb128 wanted to do it
[08:54] <bryyce> -NickServ- You are now identified for bryce2.
[08:54] <bryyce> --- 40FAA7E1T :Nick collision, forcing nick change to your unique ID
[08:54] <bryyce>  You are now known as 40FAA7E1T
[08:54] <bryyce> wild
[08:56] <ricotz> 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] <ricotz> slomo, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1229696/+listing-archive-extra
[08:58] <ricotz> this package still misses some installation scripts out of the gtk package
[08:58] <slomo> yes, all these scripts are the most work ;)
[08:58] <slomo> the package names look good btw
[09:01] <ricotz> 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] <slomo> ricotz: maybe tell seb128 about it later today when he's here, i'm quite busy in the next days
[09:02] <ricotz> yes, the names should be good which matches the other gnome lib package well
[09:03] <ricotz> slomo, ok, and hopefully there will be a gtk+3.0 package soon ;-)
[09:04] <apw> 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] <pitti> 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] <pitti> StevenK, lool: same question for libosso (not updated since hardy)
[09:17] <lool> pitti: It certainly has "diminishing returns"
[09:18] <pitti> we could sync them from Debian, or remove them
[09:18] <lool> 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] <lool> So in theory we have some nice patches in there, but the changes are complex to look at
[09:18] <pitti> those are part of Colin's "stale merges" list
[09:18] <lool> Yes, guessed that, I saw it too and was scared
[09:19] <lool> I wouldn't mind a sync personally; people can extract the patches from older source packages if they really want them
[09:20] <pitti> so they weren't appropriate for upstream, etc?
[09:24] <pitti> seb128: wrt. the "stale merges" list, I'm looking at libgtop2
[09:24] <seb128> 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] <seb128> pitti, but if you feel like versions should be updated feel free ;-)
[09:24] <pitti> it's a new upstream series now (2.28)
[09:25] <pitti> seb128: yes, better to keep in sync IMHO
[09:25] <seb128> well we are mostly in sync I think
[09:25] <pitti> I'll check/sync
[09:25] <seb128> ok
[10:00] <geser> 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] <geser> #603101 awaits sponsoring. Thanks.
[10:05] <dupondje> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/603919 => this is also a cool one :)
[10:12] <bdrung> geser: referring to the java bug, look at the comment from nthykier on the related debian bug
[10:18] <geser> 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] <geser> 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] <pitti> geser: removing, thanks for pointing out
[10:49] <cjwatson> pitti: thanks, will look
[10:51] <cjwatson> 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] <apw> cjwatson, ahh thanks
[10:52] <apw> 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] <cjwatson> apw: same as other merges, when I get round to it :)
[10:52] <cjwatson> apw: it's not that vitally important
[10:53] <cjwatson> apw: if you want to update to debian-policy 3.9.0, feel free
[10:53] <cjwatson> ubuntu-policy basically has additions rather than any significant number of changes
[10:54] <apw> ok makes sense
[11:59] <pitti> cjwatson, ev: after oem-config has run, is it supposed to purge itself and the dependencies (ubiquity, libicu42, reiserfsprogs, etc0
[12:00] <pitti> ?
[12:00] <ogra> pitti, yes
[12:00] <ogra> (and it does that on our omap images)
[12:00] <pitti> ogra: thanks
[12:01] <dupondje> 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:02] <apw> cjwatson, do you know where the chvt occurs in the boot process is that before or in plymouth ?
[12:10] <cjwatson> apw: I think it's in plymouth itself
[12:10] <seb128> dupondje, I'm about to upload a fix
[12:10] <apw> cjwatson, could well be, it knows how to for sure.  how it knows where to go to i have no idea
[12:10] <seb128> dupondje, you are sure they are broken? it seems it triggers apport but softwares work
[12:10] <cjwatson> apw: hardcoded, I imagine
[12:11] <baptistemm> hello
[12:11] <apw> 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] <dupondje> seb128: dunno really about apport-gtk, but for example pybootchartgui doesn't even start ...
[12:12] <dupondje> and alot of other packages are affected
[12:12] <seb128> dupondje, well lot trigger apport but I doubt that break softwares
[12:12] <cjwatson> apw: it's in debian/rules
[12:12] <cjwatson>                 --with-boot-tty=/dev/tty7 \
[12:12] <cjwatson>                 --with-shutdown-tty=/dev/tty7
[12:12] <baptistemm> StevenK, hi, could you renew my membership to bluetooth group
[12:12] <seb128> dupondje, it's an error in the introspection that nothings is using
[12:12] <cjwatson> apw: plymouth is required; at least some things will very likely break without it
[12:13] <apw> cjwatson, so it is ... bah thanks
[12:13] <cjwatson> apw: a plymouth splash is not required, though
[12:13] <cjwatson> important distinction, plymouth doesn't imply a splash screen
[12:14] <apw> cjwatson, but presumably if its there, it will VT switch
[12:14] <apw> as even without 'splash' X is on 7
[12:14] <apw> (but hearing you)
[12:14] <cjwatson> apw: I don't recall for certain, but I think that it only VT-switches when showing the splash
[12:15] <cjwatson> X does its own chvt if it needs to
[12:15] <dupondje> 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] <apw> cjwatson, ahh hrm
[12:15] <dupondje> you can for sure see it triggers apport lol, all those duplicate bugs
[12:15] <cjwatson> apw: you can boot without the 'splash' argument to test
[12:15] <apw> yeah i think that is working and telling me i am broken
[12:16] <cjwatson> yeah, it's the splash plugin that calls ply_terminal_activate_vt
[12:27] <doko> micahg: to fix the xulrunner-1.9.2 build failures on sparc, you may want to build with -mcpu=v9
[12:27] <micahg> doko: thanks, is that for the previous releases?  It seems to build in Maverick
[12:28] <doko> micahg: I thought you did do the mozilla-security-ppa uploads
[12:28] <micahg> doko: chrisccoulson did the uploads there
[12:28] <doko> jaunty & karmic. lucid and maverick default to ultrasparc
[12:29] <chrisccoulson> doko - ok, thanks. i hadn't had a chance to look at those yet
[12:29] <ricotz> hi, any chance to see thunderbird 3.1 in maverick
[12:30] <micahg> ricotz: yes
[12:32] <doko> chrisccoulson: I don't know yet the cause for the armel build failure in jaunty
[12:32] <ricotz> micahg, nice, is there a timeframe yet, i think 3.1.1 will be out soon
[12:33] <micahg> ricotz: before beta 1, 3.1.1 should be out sometime next week
[12:34] <ricotz> micahg, ok
[12:34] <seb128> ricotz, hi
[12:34] <seb128> ricotz, slomo said you worked on gdk-pixbuf packages, do you have those somewhere?
[12:34] <ricotz> seb128, hi
[12:35] <ricotz> seb128, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1230542/+listing-archive-extra
[12:35] <seb128> ricotz, you don't work in a vcs?
[12:36] <seb128> ricotz, would make easier to review changes and contributes fixes etc
[12:36] <ricotz> seb128, sorry no
[12:36] <seb128> ok, thanks anyway
[12:37] <seb128> do you work to get those in debian?
[12:37] <seb128> or should I try to get those there?
[12:38] <ricotz> seb128, i want to have a gtk+3.0 package for g-s ;-) so gdk-pixbuf is needed
[12:38] <ricotz> seb128, feel free to use it and get it in debian
[12:38] <ricotz> seb128, it still needs some work
[12:39] <seb128> ricotz, what does it need?
[12:40] <ricotz> seb128, idno yet, it is work in progress, i might missed some files and some debian policies like the copyright file
[12:41] <seb128> ricotz, ok, thanks
[12:57] <YokoZar> 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:58] <seb128> YokoZar, hi, no that didn't change I think
[12:58] <seb128> YokoZar, but neither nautilus nor our default list changed since lucid
[12:58] <seb128> so if something changed I guess that's on the wine side
[12:59] <YokoZar> seb128: No, you still have to right click->open with wine.
[12:59] <YokoZar> 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] <YokoZar> Thanks
[13:28] <juliank> mvo: https://bugs.edge.launchpad.net/ubuntu/+source/sessioninstaller/+bug/604577
[13:29] <juliank> Needs an ACK
[13:30] <mvo> thanks juliank
[13:30] <mvo> juliank: doing that now
[13:30] <juliank> mvo: I had to create a tarball from bzr, because glatzor's was broken
[13:31] <mvo> 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] <mvo> juliank: aha, ok
[13:33] <mvo> james_w: if you have a moment, it would be great if you could sync bug #604577
[13:35] <juliank> mvo: Seems you forgot the status file: http://paste.debian.net/80258/
[13:37] <ogra> seb128, there is something wrong with your libgtop2 sync
[13:38] <seb128> ogra: iz pitti sync
[13:38] <mvo> juliank: *cough* sorry. fixing
[13:38] <seb128> ogra: what is wrong with it?
[13:38] <juliank> mvo: Moving the data for the test into data/test_debs would also be a good idea
[13:38] <ogra> seb128, whoops, mixed maintainer with changed-by
[13:38] <ogra> seb128, seems it doesnt build the -common package at all
[13:38] <seb128> they dropped it?
[13:39] <ogra> oh, wait, it built it on x86 but it doesnt get synced to the ports archive
[13:39] <seb128> ogra: it should be built on i386
[13:39] <ogra> (indeed its arch all)
[13:39] <seb128> ogra: ok, now it makes some sense ;-)
[13:39] <ogra> http://ports.ubuntu.com/ubuntu-ports/pool/main/libg/libgtop2/ has the armel binary but not the arch all one
[13:39] <ogra> s/one/ones
[13:40] <ogra> -dev is missing as well
[13:40] <ogra> seb128, could it be hanging in NEW ?
[13:42] <seb128> ogra: yes, it's in binNEW
[13:42] <ogra> ha, great, so i'm not brian-molten yet :)
[13:42] <ogra> *brain even
[13:43] <mvo> juliank: please update to r432, should be better now
[13:44] <juliank> mvo: I still get AssertionError: Unexpected result for package 'gdebi-test3.deb' (got False wanted True)
[13:47] <juliank> mvo: Because it tests against the system (amd64) cache which contains no i386 packages.
[13:49] <juliank> mvo: Removing apt_pkg.config.set("APT::Architecture","i386") fixes it
[13:49] <mvo> 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] <juliank> mvo: OK, I missed that.
[13:50] <juliank> mvo: You probably need an apt_pkg.init_system() after setting the status file.
[13:51] <juliank> As the system stores the location internally during init().
[13:51] <mvo> 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] <juliank> mvo: Running test_debfile directly gives me http://paste.debian.net/80260/
[13:54] <mvo> juliank: thanks, let me improve the test failure output a bit
[13:54] <james_w> mvo: the new version isn't visible on the mirror used by cocoplum yet, so I can't sync yet
[13:56] <juliank> james_w: Yes, it's at http://incoming.debian.org/sessioninstaller_0.20-1.dsc until dak ran.
[13:56] <smoser> zul, ping
[13:56] <zul> smoser: yo
[13:56] <smoser> i think free was expecting you were going to push on https://bugs.launchpad.net/landscape-client/+bug/594594 a bit.
[13:57] <zul> smoser: yeah its waiting to be accepted
[13:57] <zul> cjwatson: ^^^
[13:58] <smoser> its waiting on https://bugs.launchpad.net/landscape-client/+bug/597000
[13:58] <smoser> (see last comment in that bug)
[14:00] <smoser> cjwatson, you can ignore zul's ping above
[14:02] <mvo> juliank: what do you get from r433? anything more useful? I added the error message in the assert failure output
[14:04] <james_w> mvo, juliank: done
[14:04]  * mvo hugs james_w
[14:05] <juliank> mvo: Adds Dependency is not satisfiable: pkg-that-does-not-exists|apt when run via test_all
[14:10] <hallyn> 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] <juliank> mvo: My system is a bit broken
[14:12] <mvo> 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] <juliank> mvo: I had old code in my build/ directory which was used.
[14:13] <mvo> juliank: aha, ok. many thanks for this info. is it working when that is fixed?
[14:14] <juliank> mvo: http://paste.debian.net/80261/ fixes it
[14:15] <juliank> The init_system() is needed everytime Dir::State::status changes, because the system copies the value of Dir::State::status
[14:16] <mvo> juliank: great, thanks. if it works now, I upload a new version
[14:21] <juliank> mvo: test works, but sphinx is causing the build to fail currently.
[14:21] <juliank> (for me)
[14:21] <juliank> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559572
[14:22] <juliank> might be it
[14:23] <juliank> or not
[14:29] <ScottK> LucidFox: (I didn't see where your odd licensing question got answered): It's probably undistributable due to conflicting licensing terms.
[14:31] <juliank> mvo: http://bugs.debian.org/588807
[14:33] <LucidFox_> So...
[14:35] <LucidFox_> Are the CSD/RGBA patches going to be re-enabled later in the Maverick cycle?
[14:36] <seb128> yes
[14:36] <seb128> rgba at least
[14:36] <seb128> csd likely not
[14:38] <LucidFox_> so windicators(R) are going to be pushed until maverick+1?
[14:38] <seb128> dunno
[14:38] <seb128> they could be made in the decorator as well
[14:38] <seb128> they will need in any case since not every software is gtk
[15:07] <dholbach> slangasek, seb128, apachelogger: all set? :)
[15:07] <apachelogger> dholbach: aye
[15:08] <seb128> dholbach, yes
[15:08]  * dholbach still needs to prepare :-P
[15:36] <ScottK> pitti: Would you please rescore kdebindings (just affects ia64)?
[15:57] <LucidFox> Is Maverick going to include GTK3?
[15:57] <vish> LucidFox: nope
[15:57] <LucidFox> hmmm
[15:58] <LucidFox> so which GNOME version is it going to ship with?
[15:59] <vish> LucidFox: as far as the desktop pacakges , the team is assessing each package and updating/backporting as required.. so it depends
[15:59] <vish> the desktop team*
[16:00] <arand> Mostly not 3.0 afaik. Migration is supposed to happen in two releases, likely conservatively..
[16:13] <zul> is it possible to use locakfile-create with upstart/
[16:14] <smoser> 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
[16:34] <mdeslaur> pitti: do you know what happened to the jaunty packages on http://ddebs.ubuntu.com/dists/?
[16:40] <lool> ev: Hey
[16:41] <lool> ev: LP #603299 is the perl FTBFS assigned to you
[16:41] <lool> ev: I just uploaded perl earlier today with a fix for the Linaro issue (unrelated I think), and it built
[16:41] <lool> ev: Did you reproduce yourself?  Shall we close for now?
[16:41] <lool> Hmm thinking about it, I wonder whether it could be under PPA buildds
[16:41] <lool> ev: ^
[16:42] <lool> the virtual kernel behaving differently from the Ubuntu one or so
[16:42] <ev> lool: I've been unable to reproduce it
[16:42] <ev> I think we should close it
[16:42] <lool> ev: Agreed; let's close it for now, and if someone reproduces, we shall ask more about the environment
[16:43] <ev> done, thanks!
[16:44] <lool> ah done too
[16:44] <lool> I had marked it incomplete, but will move back to fix released
[16:44] <ev> okay
[16:44] <lool> done
[16:45] <ev> cool, thanks
[16:48] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 12 minutes in #ubuntu-classroom
[16:50] <LucidFox> Okay, just updated to Maverick, went better than I expected in general
[16:51] <LucidFox> something's wrong with GTK, though, theme rendering is screwed up
[16:51] <LucidFox> let me try disabling RGBA...
[16:51] <LucidFox> from the custom PPA
[16:54]  * apachelogger giggles
[16:55] <apachelogger> JontheEchidna: btw, I need a fanclub for widgetcrafting
[16:55] <pitti> ScottK: it's currently building
[16:55] <pitti> mdeslaur: jaunty was cleaned up the other day, I think
[16:56] <ScottK> pitti: I thought you had rescored it once I saw that.  Thanks for checking.
[16:56] <mdeslaur> pitti: ah, I see. was just wondering...
[17:02] <scar_> hi, what's the chances that mavrick daily wil work if alpha 2 didn't want to boot im my pc?
[17:03] <scar_> 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] <scar_> not even in recovery mode
[17:09] <smoser> 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] <smoser> 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] <cjwatson> smoser: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
[17:10] <smoser> cjwatson, thanks
[17:26] <geser> Could a core-dev please give-back: libxerces2-java. The problem got resolved today so it builds again. Thanks
[17:26] <pitti> geser: doing
[18:00] <tkamppeter> pitti, hi
[18:02] <smoser> 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:03] <smoser> 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] <slangasek> 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] <smoser> er... who had modified default/xinetd.conf
[18:04] <slangasek> dholbach: yep, I'm ready :)
[18:05] <smoser> 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] <smoser> ?
[18:06] <slangasek> 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] <smoser> slangasek, thanks.
[18:06] <smoser> and i think dh_installinit does most of that.
[18:07] <slangasek> it doesn't help you with any of that, AFAIK :)
[18:07] <slangasek> 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] <LucidFox> 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] <LucidFox> some users don't give the program a try just because it's Mono-based
[18:41] <zul> can someone from the foundations team review ntpd upstart conversion for me? https://bugs.edge.launchpad.net/ubuntu/+source/ntp/+bug/604717
[18:48] <ryan22> LucidFox: the best thing the mono team could do is reboot pinata on vala
[18:49] <ryan22> mono isnt that bad, but there is no real reason for a runtime when you can can compile into c
[18:51] <ryan22> though, the monodevelop guys do need to get around implementing things like supporting breakpoints in the external console and input in the internal console
[18:52] <ryan22> 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] <porthose> jono ping see pm
[18:54] <joaopinto> ryan22, right, like if C was the best language for every purpose :)
[18:54] <ryan22> it is damn fast
[18:55] <ryan22> and bashee takes 5 -10 sec to load
[18:55] <ryan22> though i do love it anyways :)
[18:55] <joaopinto> ryan22, not from a development perspective for certain type of apps
[18:55] <ryan22> nah. well im certianly not pushing it for my uni
[18:55] <ryan22> but it does make more sense for desktop apps
[18:56] <ryan22> and desktop search engines *cough* beagle *cough*
[19:02] <porthose> Jono_ ping please see off topic pm
[19:03] <jono_> porthose, on the phone, won't be long
[19:04] <porthose> jono_ k
[19:12] <ryan22> joaopinto: perfection is paralysis. linux has tried to be perfect for too long ;)
[19:13] <ryan22> it just needs to *work*
[19:24] <smoser> in "upstarting" a daemon, should i basically ditch the pidfile ?
[19:25] <smoser> and instead just rely on upstart to track it.
[19:32] <slangasek> smoser: upstart doesn't care about pidfiles; I wouldn't include anything in the upstart job to specifically create / manage one
[19:33] <slangasek> smoser: perhaps you want to come to the 'authoring upstart jobs' session at 2000 UTC? :) https://wiki.ubuntu.com/UbuntuDeveloperWeek
[19:33] <smoser> indeed i would
[19:34] <smoser> slangasek, well, the reason i asked aobut pidfiles is that xinetd kills with sigquit, not sigkill in the existing init.d script.
[19:34] <smoser> so i thought i'd kill similarly in pre-stop
[19:34] <smoser> but needed to determine pid
[19:35] <slangasek> kills what?
[19:35] <slangasek> you should definitely not be killing the xinetd process in pre-stop
[19:36] <smoser> hm... ok.
[19:37] <smoser> kills the xinetd daemon
[19:37] <slangasek> yeah, don't do that.
[19:37] <smoser> i thought of doing that per man page:
[19:37] <smoser> pre-stop ...
[19:38] <smoser> It is typically used to send any necessary shutdown commands to the main process...
[19:39] <slangasek> 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] <tkamppeter> pitti, hi
[19:40] <smoser> hm... so with xinetd , as i'm reading its man page, sigquit quits the daemon. sigterm takes all running servers, then quits
[19:40] <smoser> 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] <slangasek> well, you /can/ send -QUIT in pre-stop.  I'm not sure which behavior should be considered correct
[19:41] <slangasek> or what happens if xinetd receives the -TERM while the -QUIT handler is still running
[19:41] <smoser> how would i send -quit ? with kill ?
[19:41] <slangasek> yes
[19:41] <smoser> right. its going to be busted anyway
[19:42] <slangasek> busted?
[19:42] <smoser> busted as in different behavior than before
[19:42] <smoser> 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] <smoser> and you did /etc/init.d/xinetd stop
[19:43] <smoser> the ftp download would continue
[19:43] <slangasek> correct
[19:43] <smoser> but with upstart if the TERM is sent, it will be gone
[19:43] <slangasek> yes
[19:43] <smoser> and we can't think of a way to keep the old behavior
[19:43] <slangasek> yes we can
[19:43] <smoser> ok, then i missed something
[19:44] <slangasek> 11:41 < slangasek> well, you /can/ send -QUIT in pre-stop.  I'm not sure which behavior should be considered correct
[19:44] <slangasek> if that's the behavior you want, that's the way to do it
[19:44] <smoser> well right. but then the sigterm is going to come through after pre-stop exits
[19:44] <smoser> so i must be missing how you're suggesting to send -QUIT
[19:45] <slangasek> no, I'm suggesting that you should make sure xinetd's signal handlers are correct
[19:45] <smoser> yeah, i am confused.
[19:45] <smoser> sorry for killing your imte on this.
[19:46] <smoser> i dont necissarily care what is "correct"
[19:46] <smoser> more concerned with what is consistent
[19:46] <smoser> and consistent is sending a single SIGQUIT
[19:46] <slangasek> you don't have that choice
[19:46] <slangasek> you need to make sure xinetd's signal handlers are correct instead
[19:46] <slangasek> and that a -TERM after -QUIT won't cause the subprocesses to be killed
[19:47] <slangasek> anyway, here's the script you want:
[19:47] <slangasek> pre-stop script
[19:48] <slangasek> kill -QUIT $(status | awk 'stop\/pre-stop/ { print $NF }')
[19:48] <slangasek> end script
[19:49] <smoser> 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] <smoser> and i somewhat would consider it incorrect if it didn't do that
[19:50] <smoser> but oh wel.
[19:50] <smoser> thanks for your time sla
[19:50] <smoser> slangasek,
[19:50] <slangasek> why would that be incorrect?
[19:51] <slangasek> 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] <smoser> 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] <smoser> but i'll look
[19:56] <slangasek> because it was already told to exit without killing the servers, and shouldn't have been around to receive that signal at all except that there's a race condition! :)
[19:56] <smoser> well thats a very good point
[19:56] <smoser> :)
[19:57] <smoser> thanks again
[19:57] <slangasek> sure :)
[20:19] <johnc4510> jcastro: ping
[20:19] <johnc4510> amber graner said you might help me with the beta fonts problem i have
[20:20] <johnc4510> Failed to fetch http://ppa.launchpad.net/ubuntu-font-beta-testing/ppa/ubuntu/dists/lucid/main/binary-i386/Packages.gz  404  Not Found
[20:20] <jcastro> yep, one sec
[20:20] <johnc4510> thx
[20:21] <jcastro> johnc4510: you need the sources.list information from here: https://launchpad.net/people/+me/+archivesubscriptions (click on the view link)
[20:22] <jcastro> johnc4510: it will be something like "deb https://yourusername:(randomstuff)@private-ppa-blah blah"
[20:22] <johnc4510> jcastro: i added those two links to my sources.list via nano
[20:23] <johnc4510> i reset my password too thinking it might need that
[20:23] <johnc4510> but that was over an hour ago and still no luck
[20:23] <johnc4510> lol
[20:23] <jcastro> launchpad will regen you a password
[20:24] <jcastro> but it's not your launchpad password btw
[20:24] <johnc4510> sure
[20:24] <jcastro> may I pm you?
[20:24] <johnc4510> it's just for the ppa's as i understand it
[20:24] <johnc4510> sure
[20:58] <bigon> mmm it seems that tracker has been demoted to universe, but brasero still build-dep on it
[20:59] <bigon> didrocks: ^ as you made the last upload
[21:51] <tkamppeter> pitti, still there?
[22:05] <squarebracket> is there a reason the wacom.ko kernel module wasn't in the -23 release?
[22:06] <smoser> slangasek, around ?
[22:06] <smoser> i read some of your session, will read more later. it looked very informative.
[22:07] <smoser> i was playing with the 'kill -QUIT $(awk '/stop\/pre-stop/ { print $NF })' in a pre-stop script.
[22:07] <smoser> that seems to end up in a losing battle withi 'respawn' keyword in place.
[22:07] <smoser> even though, as far as I can tell 'kill -QUIT <pid>' will cause xinetd to exit 0.
[22:08] <Nevon> Hey guys. I seem to be having a bit of problems with DesktopCouch. I'm pulling my hair out trying to read some values from a record I have created.
[22:08] <Nevon> Does anyone here have experience with DesktopCouch?
[22:08] <smoser> by losing battle i mean that it gets restarted on 'stop xinetd'
[22:10] <resmo> hi
[22:11] <bigon> is there any particular rules on virt-viewer sync?
[22:13] <slangasek> smoser: oh, heh - then perhaps it needs to not be respawn?
[22:13] <bigon> because version is über old and doesn't appears in merge.u.com
[22:18] <bdrung> bigon: probably a merge is required (because there are changes made in ubuntu).
[22:18] <tumbleweed> bdrung/main sponsor: I reviewed Bug #603681 by mistake, looks good to go
[22:19] <ari-tczew> slangasek: have you got 5 minutes for sponsoring?
[22:20] <bigon> I will do the merge of virt-viewer then (still wondering why it's not in the merges web page)
[22:20] <slangasek> ari-tczew: what's up?
[22:21] <ari-tczew> slangasek: bug 604795
[22:22] <slangasek> ari-tczew: ok; will take me a bit to grab the branches, but I'll look at it, yes
[22:23] <ari-tczew> slangasek: thanks
[22:24] <smoser> slangasek, but i want it to be respawn.
[22:24] <smoser> for the reasons that you'd have 'respawn'
[22:25] <slangasek> smoser: sure; but I'm afraid I don't know any way to reconcile those two requirements
[22:25] <smoser> i tihnk its a bug in upstart that a 'exit 0'  ends up causing a respawn.
[22:25] <BlackZ> slangasek: could you look at bug #554823 ?
[22:25] <slangasek> smoser: maybe
[22:25] <smoser> oh. maybe not.
[22:25] <smoser> "Tasks may exit with a zero exit status  to  prevent  being respawned"
[22:25] <smoser> i read that as "daemons"
[22:26] <smoser> don't know if that was intended or if it truely was limited to 'tasks'
[22:26] <slangasek> smoser: I don't either - you could file a bug against upstart and see what Keybuk thinks
[22:26] <slangasek> BlackZ: hmm, I can't promise that I'll get to it today - you might ask on #ubuntu-motu generally?
[22:26] <smoser> yeah. thanks for your input,sl
[22:27] <BlackZ> slangasek: it's in main, I think it's offtopic there ;)
[22:27] <slangasek> BlackZ: well, I don't think it's offtopic there, I think we agreed several cycles ago that #ubuntu-motu is a bad name for the channel :)
[22:28] <bdrung> tumbleweed: uploaded
[22:28] <BlackZ> slangasek: but MOTUs can't upload to the 'main' component
[22:29] <bdrung> BlackZ: MOTUs, which are core-devs, can upload to main :P
[22:29] <BlackZ> bdrung: right but not all MOTUs are core-devs
[22:30] <bdrung> just kidding.
[22:30] <BlackZ> yeah :p
[22:33] <tumbleweed> bdrung: thanks
[22:33] <bdrung> yw
[22:33] <BlackZ> bdrung: BTW, if you have some time could you look at it?
[22:34] <bdrung> BlackZ: i doubt that i have time today. you could ping me tomorrow.
[22:35] <BlackZ> bdrung: sure, thanks
[22:35] <Laney> is it urgent? or is the sponsor queue somehow not working?
[22:36] <bdrung> BlackZ: i can offer a free sponsorship if you find the reason for this FTBFS:  https://launchpad.net/~eclipse-team/+archive/debian-package/+build/1865773
[22:36] <BlackZ> Laney: no, it's not urgent and the sponsor queue is working perfectly
[22:36] <bdrung> Laney: the sponsor queue lacks man power as usual
[22:37] <Laney> ok, I just get concerned when I see people pinging sponsors directly
[22:37] <BlackZ> bdrung: I'm not very good with java stuff but I could have a look
[22:38] <bdrung> BlackZ: i have to warn you, it won't be easy
[22:38] <ari-tczew> notice from me: I'm not impatient. just my merge has latest upload by slangasek and I want to got sponsorship by slangasek, so I think that ask slangasek for sponsoring my patch is accurate.
[22:39] <Laney> I don't think it's a problem if a package is regularly touched by a person
[22:39] <Laney> as they are likely to be interested in it
[22:39] <ari-tczew> Laney: I don't understand?
[22:40] <Laney> which part?
[22:40] <ari-tczew> [23:39] <Laney> I don't think it's a problem if a package is regularly touched by a person
[22:40] <ari-tczew> what do you mean? that I shouldn't touch a package?
[22:41] <Laney> no
[22:41] <Laney> that asking isn't a problem in that situation
[22:42] <ari-tczew> ah
[22:42] <ari-tczew> okay, got it
[22:53] <slangasek> ari-tczew: this branch doesn't appear to have used bzr merge-package?
[22:54] <slangasek> ari-tczew: so it doesn't show up as an actual merge of the Debian package changes
[22:57] <ari-tczew> slangasek: I don't like to use this method. In bug you'll see diff ubuntu-to-ubuntu.
[22:58] <slangasek> ari-tczew: if you're going to provide a branch, it should be a branch that can be merged without losing information
[22:59] <ari-tczew> slangasek: which informations are be losing?
[23:00] <slangasek> ari-tczew: the bzr revision history for the Debian uploads
[23:01] <ari-tczew> slangasek: should do I merge with this branch? https://code.launchpad.net/~ubuntu-branches/debian/squeeze/slang2/squeeze
[23:01] <ari-tczew> then we should see a diff debian-to-ubuntu
[23:01] <ari-tczew> ?
[23:03] <slangasek> ari-tczew: following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging gives a branch that is the result of merging the Debian branch into the Ubuntu branch, with full bzr history, and can be diffed against both the Debian and Ubuntu branches as needed
[23:03]  * tumbleweed hates UDD (bzr) for merging new versions from Debian. It requires a lot of work to see exactly what's going on
[23:05] <ari-tczew> slangasek: in this case I think that my method is enough. what's the decission?
[23:05] <slangasek> ari-tczew: I will not commit a merge that discards bzr history
[23:06]  * micahg should try UDD again for my next merge
[23:06] <slangasek> if you're not following the UDD merge process, it doesn't make sense why you would push a branch at all instead of just providing a debdiff?
[23:07] <maco> how do you get on the list of people who get merge proposal emails anyway?
[23:08] <slangasek> ari-tczew: I've re-done the merge locally with your changelog entry now and will commit that
[23:08] <ari-tczew> debdiff in bzr is like a new patch viewer
[23:08] <ari-tczew> slangasek: and without my key signed?
[23:08] <slangasek> key signed?
[23:09] <tumbleweed> micahg: I scripted most of a udd-grab-merge (not that it's hard). But kept running into udd branches that were out of date
[23:09] <slangasek> maco: hmm, I guess that's answered somewhere in the ubuntu-devel thread james_w drove?
[23:09] <ari-tczew> slangasek:  -- name surname  <e-mail@adress> date -R
[23:10] <slangasek> ari-tczew: that's included in the changelog entry I used
[23:10] <ari-tczew> aha
[23:10] <micahg> tumbleweed: need help finishing it?
[23:10] <micahg> tumbleweed: s/need/want
[23:11] <tumbleweed> micahg: this is what I was using: http://paste.ubuntu.com/462711/
[23:11] <tumbleweed> (i.e. not much)
[23:13] <tumbleweed> the big issue I'be been seeing recently is 3.0 (quilt) interacting badly with bzr. People can't see that their merge will generate an auto-quilt-patch
[23:14] <micahg> tumbleweed: maybe file a bug against the udd project
[23:15] <tumbleweed> micahg: it's not udd's fault. rather, something that's hard to see unless you test building a source package
[23:16] <ari-tczew> going to asleep, bye
[23:16] <micahg> tumbleweed: maybe it could get documented at least so people are aware
[23:18] <Laney> how is that a problem of udd/bzr?
[23:19] <tumbleweed> micahg: yeah. Oh, re the outdated udd branch problem, I guess the best solution is to run rmadison in udd-grab-merges and throw an error if a branch is out of date
[23:19] <tumbleweed> Laney: it's not a problem with udd/bzr, but with a workflow that doesn't involve generating source packages that get read / diffed
[23:20] <tumbleweed> they'd be obvious if the merge was in debdiff format (although even then people miss them)
[23:21] <Laney> isn't there a lintian warning for this?
[23:22] <tumbleweed> Ubuntu mergers read lintian output? :)
[23:22] <Laney> I would expect uploaders to
[23:22] <Laney> anyway it was an actual question: I don't know if there is one
[23:25] <tumbleweed> Laney: doesn't appear to be
[23:25] <Laney> it's along the lines of the patch system but changes in diffgz one
[23:26] <Laney> 3.0-quilt-but-debian-changes
[23:28] <tumbleweed> I find it a big misfeature in 3.0 (quilt) I'd prefer an error to an auto-generated patch. But I can understand why it's like that :/
[23:29] <Laney> it matches the historical behaviour of dpkg-source
[23:32] <tumbleweed> yup. What's really fun is when it generates an anti-patch, reversing one of the quilt patches
[23:44] <Laney> tumbleweed: just reported debian #588873
[23:44] <tumbleweed> Laney: thanks. we are starting to see quite a few packages coming from Debian with them, too