[00:52] <mwhudson> so i've been told a bug i reported is fixed in a new package "which is due to be installed in the Debian FTP archive"
[00:52] <mwhudson> can i see this new version somehow?
[00:52] <mwhudson> it's not in http://packages.debian.org/sid yet
[00:53] <ScottK> mwhudson: Is this the python-defaults one?
[00:54] <ScottK> mwhudson: If it is, that was uploaded to Experimental, not Sid.
[00:54] <mwhudson> ScottK: yes
[00:54] <ScottK> It's in Experimental then.
[00:55] <mwhudson> ScottK: so what is experimental then?  is it a bit like -proposed for ubuntu?
[00:55] <ScottK> No.
[00:56] <ScottK> It's for stuff that's not suitable for Unstable and then Testing.  In this case, because Debian is frozen for the Squeeze release, it was uploaded there to keep Unstable clear for any emergent bug fixing needed for Squeeze.
[00:56] <mwhudson> ah ok
[00:57] <mwhudson> can/should i do anything to prod the fix into maverick?
[00:58] <ScottK> At this point you probably will.  I'd ask doko about it.
[00:58] <mwhudson> ok
[01:00] <doko> ScottK: ?
[01:01] <ScottK> doko: Do we want to update python-defaults from experimental before release?
[01:01] <ScottK> The 2.6.6-2 upload that was done today?
[01:01] <doko> ScottK: yes, but not now
[01:01] <ScottK> doko: OK.  When?
[01:02] <doko> oh, python-defaults, not 3. yes this is ok
[01:02] <ScottK> OK.
[01:02] <ScottK> mwhudson: It it's not done by Wednesday, please remind me.
[01:02] <mwhudson> ScottK: ok
[07:35] <pitti> Good morning
[07:35] <bilalakhtar> good morning pitti !
[07:43] <pitti> hey bilalakhtar, how are you?
[07:44] <bilalakhtar> pitti: fine, you?
[07:44] <pitti> bilalakhtar: I'm great, thanks! back from a week of vacation
[08:32] <tkamppeter> pitti, hi
[08:32] <pitti> hello tkamppeter, wie gehts?
[08:32] <pitti> tkamppeter: I saw your jockey patches, thanks! will look at them today
[08:33] <tkamppeter> Gut, Du hast gefehlt auf dem IRC.
[08:34] <pitti> tkamppeter: right, was on holiday, far away from the internets
[08:36] <tkamppeter> pitti, the patches are very important, as Epson expects their packages to auto-download on Maverick and Ricoh is complaining for more than a year that PPD package auto-download is too slow, most important factor being Jockey, but the s-c-p part I have also accelerated by the compressed PPD archives and a bug fix in s-c-p.
[08:37] <tkamppeter> pitti, the slow and space-consuming Foomatic XML database is also replaced by a compressed PPD archive now.
[09:07] <amitarora> pitti: ping
[09:07] <pitti> !ping | amitarora
[09:07] <pitti> bah
[09:07] <pitti> amitarora: hello; please just ask your question, don't ping
[09:07] <amitarora> pitti: I got your reference from amitk .. this regarding bug# 627975
[09:08] <amitk> bug 627975
[09:08] <amitarora> pitti: the bug has a patch for PowerTOP which makes it work on ARM boards as well ..
[09:08] <amitarora> pitti: its been accepted upstream. The last comment has the details ..
[09:09] <amitarora> pitti: can you please help getting it merged with PowerTOP branch for Maverick release ?
[09:10] <pitti> amitarora: yes, I can sponsor it; I'll assign it to me
[09:10] <amitarora> pitti: great, thanks!
[09:23] <tkamppeter> pitti, an important bug we need to get fixed for Maverick is bug 494141. The fix is already described in the bug report, but I cannot upload it as it has to be done in the Samba package. It is a one-line patch on /etc/init/smbd.conf.
[09:24] <pitti> tkamppeter: can you please discuss that one with slangasek?
[09:26] <tkamppeter> slangasek, can you have a look at bug 494141? It is a one-line patch which will help users a lot, both in Maverickj and as SRU for Lucid.
[09:37] <popey> greetings earthlings!
[09:38] <pitti> \\//
[09:38] <popey> bug 631103 could do with some attention, simple packaging error. Could a core-dev please take a look?
[10:43] <tkamppeter> pitti, about bug 604698, can we simply take my patch to do the Jockey (list packages) part and for the key verification part for Maverick simply include the Epson key in the distro (there is no other key yet) and implement the general key downloading in Natty?
[10:44] <pitti> tkamppeter: we need to filter for Epson packages only then
[10:44] <pitti> tkamppeter: but yes, that would work
[10:47] <tkamppeter> pitti, if Jockey installs a package, does it go through the standard mechanism with key verification, like it happens with apt-get (there I get a warning and asked whether I really want to do it if the package does not have a known signature)?
[10:47] <pitti> tkamppeter: yes, it does use apt for every package operation
[10:57] <\sh> siretart, ping could you start a backport process for fai maverick to lucid , kthxbye :)
[11:03] <tkamppeter> pitti, so we could use my patch plus including Epson's key in Maverick. Then we will create a key download functionality in Natty. If other manufacturers show up and want their drivers in Maverick, we could perhaps even add keys as update for Maverick.
[11:03] <pitti> tkamppeter: plus a filter "only epson packages"
[11:04] <pitti> (or noarch)
[11:06] <tkamppeter> pitti, assuming that there is a non-Epson package on OpenPrinting, so having a key which is not included in Maverick. What happens if the user sees this package in Jockey and clicks on "Install". Will then a message pop up telling the user that this package has no known signature and the user gets asked whether he really wants it?
[11:07] <pitti> no, such a question would be pointless
[11:07] <tkamppeter> pitti, what would really happen in such a case?
[11:07] <pitti> it would currently just install it anyway, since apt merely gives a warning if a key isn't present
[11:08] <tkamppeter> pitti, so the selection of packages we accept is hardcoded in Jockey and not data-driven?
[11:08] <pitti> tkamppeter: it's not hardcoded
[11:09] <pitti> tkamppeter: right now we only offer Ubuntu packages, and as a compromise, (unsigned) noarch packages from openprinting
[11:09] <pitti> adding epson key and a filter for it would start hardcoding
[11:11] <tkamppeter> pitti, this (and any SRU to satisfy other manufacturers) would be a Maverick-only interim solution. From Natty on we should have real support for OpenPrinting's key link facility.
[11:12] <pitti> *nod*
[11:12] <pitti> tkamppeter: also, your patch would remove the support for unsigned PPD-only packages, AFAICS?
[11:14] <tkamppeter> pitti, no, first, I have tested with Ricoh PPD packages, second, I have added a second search task to the task list. So when starting the task list two requests per printer are sent to OpenPrinting, one for the noarches and one for the signed.
[11:14] <pitti> tkamppeter: ah, that wasn't in the originally sent patch then
[11:16] <tkamppeter> pitti, the patch attached to bug 604698 does exactly this.
[11:16] <pitti> tkamppeter: I meant http://launchpadlibrarian.net/55226929/download-also-signed-binary-printer-driver-packages.patch
[11:17] <tkamppeter> pitti, I see, the patch is the wrong way around. Take the debdiff.
[11:17] <tkamppeter> pitti, and in the debdiff the patch on detection.py.
[11:18] <siretart> \sh: I put it on my todolist, but no promises, it is rather longish :-(
[11:25] <diwic> seb128, ping
[11:25] <seb128> hi
[11:25] <seb128> contextless ping are not really useful though
[11:25] <seb128> better to just ask your question
[11:26] <diwic> seb128, you're sebastien bacher, right?
[11:26] <seb128> yes
[11:26] <seb128> why?
[11:27] <diwic> seb128, you seem to have declined bug #433654 without giving a reason?
[11:27] <seb128> could be
[11:27] <diwic> for Maverick
[11:27] <seb128> I've declined over 300 bugs
[11:27] <seb128> the list had some 600 bugs
[11:27] <seb128> still quite some to clean
[11:28] <seb128> it's just that it's not tracked as a blocker for maverick, it's not a new issue
[11:28] <seb128> nothing prevent to fix it though
[11:28] <\sh> siretart, don't worry about time...I just want to have it from my table ;)
[11:28] <diwic> seb128, okay, so I can just go requesting a sponsorship as usual given I write a patch for it?
[11:29] <seb128> it's being discussed on #ubuntu-desktop by somebody else at the same time
[11:29] <seb128> weird timing
[11:29] <seb128> or you guys just discussed it somewhere else and decide to go ping different channels?
[11:29] <seb128> but yes you can get any change uploaded
[11:30] <diwic> seb128, probably there was a comment recently that woke us both up?
[11:30] <seb128> the nomination is just a way for people to track issues for the release
[11:30] <seb128> the release team can't track every bug
[11:31] <seb128> not accepting the nomination just need not tracking it as a blocker issue for this cycle, it doesn't mean a fix can't be uploaded
[11:31] <diwic> okay, I understand.
[11:31] <seb128> need->mean
[12:03] <cjwatson> in case anyone other than me noticed, I think I see why jigdo downloads of maverick always falsely claim an incorrect checksum right now
[12:14] <cjwatson> lex79: they already seemed to be there
[12:19] <tkamppeter> pitti, bug 604698 has an updated debdiff now.
[12:20] <pitti> tkamppeter: thanks
[12:21] <tkamppeter> pitti, stop, I got into the find() trap of Python. Please wait for the next debdiff.
[12:46] <tkamppeter> pitti, I have corrected the debdiff now, take the one of comment #5.
[13:00] <tkamppeter> slangasek, hi
[13:04] <htorque> hello, is irc-logging not working? http://irclogs.ubuntu.com/2010/09/13/ is empty.
[13:05] <tkamppeter> mv, glatzor, can you have a look into bug 633913?
[13:05] <tkamppeter> mvo, ^^\
[13:06] <tkamppeter> mvo, glatzor, this is rather annoying to get all the pop-ups when system-config-printer is searching a driver for an unsupported printer.
[13:24] <apw> pitti, something has gone very wrong with the burn down chart start value overrides for all my charts except for the overall
[13:24] <apw> pitti, i am suspicious they are all at the value defined by ['all']
[13:25] <apw> pitti, and so i am suspicious this is related to the burnup support that was merged recently
[13:30] <pitti> apw: right, they currently keep crashing
[13:30] <pitti> apw: I already mailed Clint
[13:30] <ogra> but it makes the trendlines looks so good ...
[13:47] <apw> pitti, i assume thats also why we have two days missing
[14:01] <smoser> pitti, or someone on sru team, can I please get bug 634102 into lucid-proposed soon?  this is fairly serious issue for people using our images and the new instance size on EC2. The simple diff is at http://launchpadlibrarian.net/55301846/cloud-init_0.5.10-0ubuntu1.2_0.5.10-0ubuntu1.3.diff.gz .  I'm really sorry to nag.
[14:03] <apw> cjwatson, we have an old binary package hanging around in the archive linux-libc-dev at version 2.6.35-903.8 for armel which is blocking binary uploads for armel.  this version is orphan against an old source package so I believe it should be reapable; who/how/what triggers that?
[14:04] <apw> (all in maverick)
[14:04] <cjwatson> I can check it out and remove it, but you still won't ever be able to upload the same package at the same version
[14:05] <apw> when you say same version, do you mean exactly that version?
[14:05] <cjwatson> yes
[14:05] <apw> that i can cope with
[14:05] <cjwatson> single-architecture removals don't always get noticed automatically
[14:05] <cjwatson> wait, this still means the version will go backwards
[14:05] <cjwatson> um, I don't have control over allowing that
[14:06] <cjwatson> it's disallowed because apt clients will never notice the downgrade automatically
[14:06] <apw> so the high water mark on a binary package is permentant regardless of the existance of a package at any version
[14:06] <cjwatson> yes
[14:07] <apw> cjwatson, is that something that can be fixed for this one binary package given enough genuflecting ?
[14:07] <cjwatson> I'd recommend artificially bumping the version of just that binary package
[14:07] <cjwatson> to something that's greater than 2.6.35-903.8 but less than 2.6.36-1.1
[14:07] <apw> the package was generated in error, from a different source package and should never have been installed
[14:07] <cjwatson> you can do this by invoking dpkg-gencontrol with the right options
[14:08] <cjwatson> (-vVERSIONYOUACTUALLYWANT)
[14:08] <cjwatson> so sed the source package version to replace the -21 part by (say) incrementing it by 1000
[14:09]  * cjwatson quickly ctrl-c's this removal and hopes I caught it in time
[14:09] <cjwatson> because if I remove linux-libc-dev then *nothing* will build on armel ...
[14:09] <apw> argle
[14:10]  * apw stares into the abys
[14:10] <cjwatson> you can pass arguments to dpkg-gencontrol via dh_gencontrol by saying dh_gencontrol -plinux-libc-dev -- -vblah
[14:11] <cjwatson> https://edge.launchpad.net/ubuntu/maverick/armel/linux-libc-dev/2.6.35-903.8 still says "Status: Published" so I hope I caught it
[14:12] <apw> cjwatson, ok that is totally vile ... what a mess ... will go figure out the cleanest fix
[14:34] <tkamppeter> pitti, have you seen my new debdiff?
[14:35] <tkamppeter> mvo, hi
[14:41] <tkamppeter> slangasek, ping
[14:41] <mvo> tkamppeter: hello
[14:43] <tkamppeter> mvo, it is about bug 633913, session-installer produces two annoying pop-ups when system-config-printer searches for drivers on the internet.
[14:44] <tkamppeter> mvo, first is simply an error message where session-installer should error out silently and the second is a crash (causing apport pop-up).
[14:45] <mvo> tkamppeter: ok, I check it out, thanks
[14:46] <tkamppeter> mvo, I would like to have them removed/fixed before Final Freeze so that manufacturer printer driver download goes smoothly and quickly.
[14:58] <mvo> tkamppeter: I uploaded a fix, please test once it hits the archive
[15:00] <tkamppeter> mvo, thanks, will try it as soon as it arrives.
[15:01] <kirkland> BlackZ: so have you tried booting a vm from PXE with the new etherboot package?
[15:01] <kirkland> BlackZ: does it work?
[15:01] <BlackZ> kirkland: no, that's the reason why I reintroduced the kvm-pxe package
[15:01] <kirkland> BlackZ: see: https://wiki.ubuntu.com/VirtFeatureVerification
[15:01] <kirkland> BlackZ: hallyn has a test case in there
[15:02] <BlackZ> kirkland: looking
[15:05] <BlackZ> kirkland: so, we should keep the kvm-pxe package, right? also, on http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt I read "# stevenk, we don't want qemu or kvm from Debian, talk to kirkland"
[15:12] <kirkland> BlackZ: right, well, we need *some* package to provide a bunch of binary ROMs to pxe boot VMs
[15:12] <kirkland> BlackZ: currently, that's kvm-pxe
[15:13] <kirkland> BlackZ: though it could be provided by some other package, I suppose, if there's good reason
[15:13] <kirkland> BlackZ: in that case, we'd need to update the depends/recommends throughout the archive on anything that has a dependency on kvm-pxe
[15:13] <kirkland> BlackZ: this should NOT be done in maverick at this point in the cycle, IMO
[15:14] <kirkland> BlackZ: as for qemu/kvm from Debian ... again, for Maverick, we're going to want to keep the qemu-kvm that we have in Ubuntu
[15:14] <kirkland> BlackZ: for Natty, we should re-examine (lool has requested it too) re-introducing the qemu package back into Ubuntu
[15:15] <kirkland> BlackZ: and possibly sourcing qemu-kvm from Debian
[15:15] <kirkland> BlackZ: when I created the qemu-kvm package in Ubuntu, it didn't exist in Debian;  I offered it to the Debian maintainers, but instead, a DD created their own qemu-kvm package and uploaded
[15:16] <BlackZ> kirkland: agreed; currently the package from Debian (etherboot-qemu) doesn't fix LP: #570870, maybe it's a path-related issue
[15:28] <tkamppeter> mvo, the new version of sessioninstaller fixed the problem. Thank you.
[15:29] <mvo> tkamppeter: cheers
[15:29] <mvo> tkamppeter: thanks for testing
[15:34] <chrisccoulson> hi, would a member of ubuntu-release be able to spare some minutes to look at bug 531867 please? :)
[15:39] <ScottK> didrocks: Would you please wait for the release team to approve FFe's before uploading.
[15:40] <fos> A question about language-pack-kde-de-base in hardy: Since security update 20090105 a few translation files are missing. Is this a regression worth fixing?
[15:40] <didrocks> ScottK: isn't seb128's comment an ack?
[15:40] <ScottK> didrocks: He's not on the release team.
[15:41] <fos> https://bugs.launchpad.net/ubuntu/+source/language-pack-kde-es/+bug/321297
[15:41] <didrocks> ScottK: http://paste.ubuntu.com/493144/ be agreed first…
[15:42] <didrocks> ScottK: so there is a mismatch there. knowing now. thanks
[15:44] <ScottK> OK.  In any case the main thing is to get the bughugger update in now.
[15:47] <didrocks> ScottK: right, rickspencer3 will fix it soon, but not today
[15:48] <rickspencer3> maybe today
[15:53] <seb128> ScottK, hey
[15:53] <ScottK> Hello seb128.
[15:53] <seb128> ScottK, every other cycle we had delegated approved for universe
[15:53] <seb128> that's not the case this cycle?
[15:54] <ScottK> Not that I'm aware of.
[15:54] <seb128> why did that change?
[15:54] <ScottK> Not sure.
[15:54] <seb128> like the r-t doesn't want to delegate for universe anymore?
[15:54] <seb128> it doesn't seem to make sense to me
[15:55] <seb128> you guys are just claiming for extra work when you don't keep with the one you had before
[15:55] <ScottK> seb128: I'm not trying to say the current situation is right or wrong.  Just that it is what it is.
[15:55] <seb128> well are you sure there is not delegating this cycle?
[15:55] <ScottK> We've changed a number of things with the merger of the motu-release.
[15:56] <seb128> or it's just that nobody came to write an email saying who has delegation?
[15:56] <ScottK> I recall someone suggested the idea on the -release list, but no one took it up.
[15:56] <seb128> well honestly I think I'm rather helping by reviewing desktop change in universe
[15:56] <seb128> but if you feel like it's adding work fine with me
[15:56] <seb128> just seems to doesn't make any sense
[15:57] <ScottK> We've gotten rid of almost all the difference between Main and Universe in the release processes and are aiming to eliminate it entirely.
[15:58] <ScottK> It seems to me that we're keeping up with FFe requests OK, so it's not essential to have more people reviewing.
[15:58] <ScottK> Personally, I'm a lot more worried about stuff like the Mesa FFe and what the implications of that are.
[15:59] <seb128> slangasek, pitti: ^
[15:59] <seb128> would it make sense to still have delegation?
[16:00] <seb128> or extra people able to accept exceptions?
[16:01] <pitti> I'd still trust seb128 for GNOME updates or Riddell for KDE, etc., so comments from you are highly appreciated
[16:01] <pitti> NB that I'm not that active in ~release this cycle, since I'm on rotation
[16:01] <cjwatson> I'm happy with delegations; I just don't particularly want it to seem as though we're riding roughshod over universe processes - there's a social benefit in making sure we're doing things right, so if there are delegations they should be explicit
[16:01]  * cjwatson emerges briefly from trying to get kgdb to work, and dives back in
[16:08] <tkamppeter> Can it be that LP is not automatically closing bugs on uploads with "LP: #..." in the debian/changelog any more?
[16:09] <tkamppeter> pitti, did you see my last debdiff on the Jockey bug?
[16:09] <pitti> tkamppeter: I saw it, yes
[16:09] <mr_pouit> tkamppeter: it's broken
[16:09] <pitti> tkamppeter: yes, LP has a regression for that, known
[16:09] <michLinuxGuy> I am installing the beta and it seems to be frozen at "Retrieving file 2 of 6".  Is there a debug log somewhere?  If I run it from a terminal window, will I see some useful messages to stdout/stderr?
[16:12] <cjwatson> tkamppeter: bigjools has promised me that the fix will be rolled out today.  In the meantime please close bugs manually
[16:12] <cjwatson> (and you'll have to close bugs for anything during the broken period anyway - I don't think it will be retroactive)
[16:13] <tkamppeter> cjwatson, mr_pouit, pitti, thank you, I have already manually closed a ptouch-driver bug today in the morning.
[16:16] <ScottK> michLinuxGuy: You'll probably have more luck in #ubuntu-installer.
[16:18] <michLinuxGuy> ScottK: thanks
[16:19] <ricotz> could some have a look at bug 635646 ?
[16:21] <ScottK> ricotz: I'll take a look at it.
[16:23] <ricotz> ScottK, thanks
[16:39] <pavolzetor> Hallo, could someone help me with indicator applet?
[16:39] <ScottK> ricotz: Done.
[16:40] <pavolzetor> I don't know in which format should be icon passed to libindicate
[16:41] <ScottK> pavolzetor: You might have more luck on #ayatana.  That's where the relevant developers tend to hang out.
[16:41] <pavolzetor> thanks
[16:41] <ricotz> ScottK, ta
[16:41] <ScottK> No problem.
[16:45] <kees> mdke: I'm uploading a small addition to the manpages. I don't think these are translated in the standard fashion, but do I need to send a note to ubuntu-translators still?
[16:54] <tkamppeter> slangasek, around?
[16:54] <Daviey> cjwatson, Are you still around?
[16:55] <cjwatson> Daviey: yes
[16:55] <Daviey> cjwatson, RE: the avahi udeb issue...  I essentially did a rebuild
[16:55] <Daviey> cjwatson, but not convinced the shlibs issue is resolved
[16:55] <cjwatson> doesn't seem to have worked
[16:55] <cjwatson> I did suggest you test it first :)
[16:55] <Daviey> ack
[16:56] <cjwatson> oh, blast, I mistyped
[16:57]  * SpamapS absolutely despises the tab completion setup for the sqlite3 command.. :-P
[16:57] <Daviey> cjwatson, Oh well..  Are you going to be able to fix it shortly.. if notm, i don't mind taking it.
[16:58] <cjwatson> Daviey: avahi 0.6.27-2ubuntu3 will be in the archive in a bit.  Once the binaries for that are published, you can rebuild eucalyptus
[16:58] <cjwatson> Daviey: I suggest doing it locally first to check though
[16:58] <Daviey> cjwatson, wilco... I guess i should test this from a local archive :)
[16:58] <Daviey> hah
[16:59] <cjwatson> ah, if you're going to increment Build-Depends, then you can upload straight away
[16:59] <cjwatson> it'll just dep-wait
[17:00] <Daviey> cjwatson, That is what i was *planning* to do... but i take your point about testing it locally first.
[17:03] <smb> pitti, Hi Martin. May I ask for some sru love for the Hardy kernel and Lucid LBM and mvl-dove kernel in the accept queue? They are feeling unnoticed (well ok not the lbm one)
[17:16] <ScottK> http://asset.soup.io/asset/1068/5622_78d3.png
[17:17] <ion> Heh
[17:32] <SpamapS> pitti: still around? I just pushed up fixes for the problems w/ the wi tracker
[17:34] <pitti> SpamapS: back from dinner
[17:35] <pitti> smb: probably not today; I had too much to do with post-holiday catch-up, I'm afraid
[17:35] <smb> pitti, NP. I know the feeling
[17:39] <slangasek> tkamppeter: replied on the bug
[17:40] <pitti> SpamapS: thanks, merged
[17:40] <slangasek> ScottK, seb128, pitti, cjwatson: I'm certainly ok with having such delegations, but am also unlikely to drive them forward right now, sorry
[17:42] <SpamapS> pitti: do you know if the 'all' charts have been showing as all foreign for a long time?
[17:43] <pitti> SpamapS: I'm not aware of that; but then again, I haven't actually looked at the charts that often in this cycle (I'm primarily focused on OEM matters)
[17:43] <SpamapS> pitti: got it, I think it may have been forever.. but not sure. :P
[17:45] <SpamapS> pitti: and thanks for merging. :)
[17:47] <tkamppeter> slangasek, what is suitable for an SRU, switching CUPS to upstart or making samba re-scanning for CUPS?
[17:47] <slangasek> tkamppeter: samba rescanning
[17:49] <Laney> re-ping — can someone please look at sponsoring bug 539814?
[17:49] <tkamppeter> slangasek, how will this re-scanning work, is this some change in the upstream code of Samba? Will you do this fix?
[17:49] <slangasek> it would need to be an upstream code change
[17:50] <slangasek> I'm not in a position to implement it right now, no; someone should take it to upstream
[17:51] <tkamppeter> pitti, WDYT, is there perhaps a solution on CUPS which is viable for Maverick (at least as SRU) to make CUPS being started before SAMBA?
[17:55] <pitti> tkamppeter: I don't know how you can express that in upstart, I'm afraid
[17:55] <pitti> you'd need to add a wait condition to samba which says "if cups is installed, wait for it to start, otherwise start right away"
[17:55] <pitti> Keybuk: ^ can this be expressed somehow?
[17:56] <slangasek> pitti: it can, but it gets tricky because you may also have cups installed without samba
[17:56] <slangasek> so what you want is cups 'start on starting smbd or filesystem'
[17:57] <Keybuk> you can't do that, no
[17:58] <Keybuk> you do what slangasek said
[17:59] <pitti> ah, and this will hold smbd in limbo while cups is being started?
[17:59] <Keybuk> in the starting state
[17:59] <Keybuk> so not limbo
[17:59] <Keybuk> o/~ how low can you go?
[18:00] <pitti> ah, thank you
[18:00] <pitti> so, seems upstartification of cups is in order then
[18:01] <tkamppeter> pitti, could we do an upstartification of CUPS in Maverick? Or at least as SRU for Maverick?
[18:01] <pitti> upstartification is not SRUable
[18:01] <pitti> so for maverick it might land still, yes; it's not that hard to test, after all
[18:02] <tkamppeter> pitti, did you already upstartify another package?
[18:03] <pitti> I wrote a tiny upstart job or two, nothing serious so far
[18:04] <tkamppeter> pitti, probably then it is better if upstartify CUPS, also because of the handling with Debian (does Debian also use upstart)?
[18:11] <tkamppeter> pitti, probably then it is better if you upstartify CUPS, also because of the handling with Debian (does Debian also use upstart)?
[18:14] <pitti> tkamppeter: Debian doesn't use upstart right now, so this would be Ubuntu specific
[18:14] <pitti> (i. e. dpkg-vendor query in debian/rules)
[18:16] <tkamppeter> cjwatson, in bug 636887 a user complains that during an update of Lucid the file /usr/lib/cups/backend/hp (probably the package hplip) gets lost. Can it be due to hplip only being recommended in ubuntu-desktop? Should we perhaps promote it to Depends:
[18:16] <pitti> Keybuk: while we are at this, do you think it's less of an evil hack to have cups' postinst add lp, ppdev, and parport_pc to /etc/modules? instead of having this in the init/upstart script?
[18:17] <Keybuk> I think that if it needs them, it should modprobe them
[18:17]  * ogra_ac disagrees
[18:17] <pitti> ok
[18:17] <ogra_ac> we dont have parports on arm :P
[18:18] <pitti> parport_pc has modaliases, so this one should really just go
[18:18] <ogra_ac> there should be a check if such a device is available at all
[18:18] <pitti> but lp and ppdev don't
[18:18] <pitti> ogra_ac: well, I surely hope that invalid modules in /etc/modules would just be ignored? (I'd test that, of course)
[18:18] <Keybuk> aren't lp and ppdev built in? :p
[18:18] <pitti> they aren't
[18:18] <ogra_ac> they arent
[18:18] <Keybuk> oh
[18:18] <pitti> I wouldn't mind at all if they were, of course
[18:18] <Keybuk> right, parport_pc is autoloaded
[18:18] <ogra_ac> currently ther is an ugly hack in teh upstart script
[18:19] <pitti> but I'd still need those for Debian
[18:19] <Keybuk> just modprobe them then
[18:19] <ogra_ac> building them in would be good
[18:19] <ogra_ac> then we could handle it in teh kernel config
[18:19] <ogra_ac> based on the arch
[18:20] <Keybuk> assumedly the parport_pc module doesn't even exist on arm?
[18:20] <Keybuk> so the modprobe would be a no-op anyway
[18:21] <ogra_ac> it does
[18:21] <ogra_ac> sadly
[18:21] <Keybuk> hmm, no, wait that's autoloaded
[18:21] <Keybuk> so it's only ppdev and lp
[18:21] <Keybuk> and you want those on arm, right? :p
[18:21] <ogra_ac> we had a bad bug that took us out of business because it was added to teh init script
[18:21] <Keybuk> how the hell did it take you out of business?
[18:21] <ogra_ac> and the kernel just locked up when it loaded
[18:21] <pitti> someone added parport_pc despite the modaliases, since it reportedly is required on some systems
[18:21] <Keybuk> did the module getting loaded cause the roof of your house to collapse?
[18:21] <Keybuk> well, that's a kernel bug
[18:21] <Keybuk> fix that bug
[18:21] <ogra_ac> already fixed
[18:22] <pitti> ogra_ac: do we really need to build parport_pc for arm systems in teh first place?
[18:22] <ogra_ac> was in the beginning of maverick
[18:22] <pitti> that's soo 1980
[18:22] <ogra_ac> no, we dont
[18:22] <ogra_ac> on arm you will always only have network or usb printers
[18:22] <pitti> as the world should be
[18:23] <ogra_ac> well, someone might develop an arm based network hub for printers at some point
[18:23] <ogra_ac> one that also supports parport
[18:23] <ogra_ac> but we'll worry if that happens :)
[18:23] <pitti> one might also develop an USB<->grammophone adapter *shrug*
[18:23] <ogra_ac> lol
[18:24] <ogra_ac> they exist
[18:25] <pitti> Keybuk: seems with upstart scripts I can completely drop all that pidfile voodoo?
[18:25] <ogra_ac> www.amazon.de/Lenco-3866-USB-Plattenspieler-silber/dp/B000KPQ7U2
[18:25] <ogra_ac> ;)
[18:26] <Keybuk> pitti: well, upstart always knows the pid, so sure
[18:32] <apw> pitti, i think those changes have merged up, but the burndown charts seem to still have bad starts
[18:32] <pitti> SpamapS: ^
[18:32] <pitti> apw: have to leave now, can you please take this up with SpamapS ?
[18:32] <SpamapS> ?
[18:32] <SpamapS> otp...
[18:33] <apw> SpamapS, ... the burndown charts, the start of the burndown lines seem to be fubar'd ...
[18:33] <apw> its looking like they are all the ['all'] value for the milestone versions, the overall graphs seem ok start wise
[18:34] <apw> so i suspect that the ['foo'] entries are working and the [('foo', 'milestone')] entries are not
[18:38] <pitti> tkamppeter: ok, I have a first upstart script for it, but I need to continue tomorrow; Taekwondo time now
[18:39] <SpamapS> pitti we should spar in orlando ;)
[18:39] <pitti> SpamapS: Kihap!
[18:46] <SpamapS> apw: ah so its missing the trend start settings?
[18:47] <apw> SpamapS, i'd say so, it looks like its chosen 'all'
[18:49] <SpamapS> apw: so the team entries are broken?
[18:49] <apw> SpamapS, if you look at the kernel team ones, the overall cycle one 'c-k-t' in the array appears sane and what i set
[18:50] <apw> SpamapS, the ones for the individual milestones are off the chart
[18:50] <apw> SpamapS, so the ones which would be [('c-k-t', 'maverick-alpha-1')] ... those look to have a massive value which I conjecture is the ['all'] value
[18:50] <SpamapS> apw: whoa! hah ok I see it now!
[18:51] <SpamapS> apw: and I think I know where its borked in the code too
[18:52] <apw> SpamapS, yay, i've never had to actually run the collector so have no test environment to debug it
[18:52] <SpamapS> apw: you can always just download maverick.db ;)
[18:52] <apw> SpamapS, well indeed, i guess i mean i only ever play with the wiki stuff not the rest of the report stuff
[18:52] <apw> as that bit always just works ... oops
[18:58] <SpamapS> http://paste.ubuntu.com/493232/
[18:58] <SpamapS> thats the offending code.. but it looks right to me.. hrm
[18:58] <apw> unless milestone is broken
[18:59] <apw> there is also an override in there in places, which might be makeing those get ignored
[18:59] <apw> generate-all:    report_tools.run_reports(my_path, opts.database, basename, opts.config, trend_override=str(trend_starts['all']))
[19:00] <apw> SpamapS, i am mildly interested in that line
[19:00] <apw> SpamapS, i had not realised I can trivially test this as its a report side thing ... perhaps you could pm me the incantation to run the reports
[19:00] <apw> and then i can try and debug it
[19:00] <SpamapS> apw: ./generate-all
[19:00] <SpamapS> ;)
[19:01] <apw> heh ... stupid apw, ok if you don't fix it before me, i'll have a poke later/tommrrow
[19:01] <SpamapS> actually its     ./generate-all -d path/to/maverick.db -c config/maverick.cfg
[19:01] <SpamapS> I'm thinking maybe trend_starts doesn't get passed in properly.. debugging now..
[19:02] <apw> ah ok let me know if you find it :)
[19:02] <SpamapS> oh and -o /path/to/output/dir
[19:02] <SpamapS> see Its not that easy.. there's still an incantation. ;)
[19:03]  * SpamapS should probably stop thinking in-channel
[19:22] <SpamapS> apw: oops.. if should have been elif ;)
[19:28] <apw> SpamapS, doh so it is
[19:28] <apw> SpamapS, you got a merge ?
[19:28] <SpamapS> https://code.launchpad.net/~clint-fewbar/launchpad-work-items-tracker/server-team-mods/+merge/35320
[19:31] <apw> SpamapS, ok that looks totally sane, merged
[19:33] <apw> SpamapS, we'll find out in an hour if it worked
[19:44] <jdstrand> slangasek: hey. would you mind looking at bug #628924 and giving an ACK or NAK as an ubuntu-sru member?
[19:46] <apw> ogasawara, ok those patches seem good to my testing, and they are in the pipe.  i will also kick off an armel build now but the more testing the better ... we do not want to double-beep the archive
[19:47] <shadeslayer> jono: around?
[19:48] <ogasawara> apw: ack.  I'll test it as well before I push.
[19:48] <jono> shadeslayer, hey, on the phone
[19:49] <shadeslayer> ok..
[19:53] <SpamapS> apw: cool thanks!
[20:15] <didrocks> cjwatson: hey, I got some reject when uploading gnome-bluetooth (dpkg-source can't extract it). kenvandine got the same issue last week and the workaround was to regenerate the tarball. Should I proceed or do you have some time to investigate?
[20:23] <james_w> didrocks: where's the tarball?
[20:24] <james_w> or better, the source package
[20:24] <didrocks> james_w: http://ftp.gnome.org/pub/gnome/sources/gnome-bluetooth/2.31/gnome-bluetooth-2.31.90.tar.gz
[20:24] <didrocks> hum, source package, can upload it somewhere, one sec
[20:28] <didrocks> james_w: you should be able to dget -x http://people.canonical.com/~didrocks/gnome-bluetooth_2.31.90-0ubuntu1.dsc
[20:28] <james_w> merci
[20:29] <didrocks> merci à toi :-)
[20:36] <james_w> didrocks: go "+1" this: https://bugs.edge.launchpad.net/soyuz/+bug/637507
[20:36] <james_w> apologies for that not clicking the other day
[20:38] <didrocks> james_w: confirmed. waow what an old bug, reading the link
[20:39]  * kenvandine is surprised we don
[20:39] <didrocks> james_w: the workaround is to redo the tar?
[20:39] <james_w> didrocks: which one is old?
[20:39] <kenvandine> t see it more
[20:39] <james_w> didrocks: that's the only one I know of
[20:40] <didrocks> james_w: (comment from william is quite old)
[20:40] <james_w> only just over a year old :-)
[20:40] <james_w> shows how many bugs are reported on Launchpad
[20:41] <didrocks> yeah, just suprised we don't get it more
[20:41] <didrocks> thanks a lot james_w :-)
[20:41] <james_w> np
[20:42] <james_w> seb128: retracers should work again on edge
[20:43] <james_w> seb128: lifeless recommends switching to production anyway
[20:43] <seb128> james_w, thanks, what was the issue?
[20:43] <seb128> james_w, the issue with production is that fixes can take ages to land and that we don't test what's coming next
[20:43] <james_w> seb128: edge was using mixed revisions of the code across different appservers, which screws up the API
[20:44] <seb128> ie if edge is broken and get rolled in production we are screwed
[20:44] <seb128> pitti, ^ just fyi
[20:44] <james_w> seb128: indeed, however lifeless is also on a quest to get rid of the split
[20:44] <seb128> james_w, ok, thanks for figuring that out
[20:45] <james_w> np
[21:29] <strycore> #ubuntu-app-devel
[21:30] <strycore> + /join plz , 'kthxbye
[21:46] <slangasek> jdstrand: ack or nack?  There's a choice? :)
[21:46] <jdstrand> slangasek: at least theoretically
[21:47] <jdstrand> slangasek: seriously though, there is a bit going on there and as this is an SRU and we don't have an exception in place yet, I felt uncomfortable pushing to -security without your guys
[21:47] <jdstrand> s/your guys/you guys/
[21:57] <jdstrand> slangasek: thanks for your ack. I'll copy over
[23:10] <ScottK> jdstrand: Somehow the -update for chromium-codecs-ffmpeg ended up in Main.
[23:10] <jdstrand> ScottK: I'll fix it. thanks
[23:11] <ScottK> jdstrand: You're welcome.
[23:14] <ScottK> jdstrand: Should I be suprised it looks different now?
[23:17] <jdstrand> ScottK: I haven't changed anything yet, but am presently
[23:17] <ScottK> OK.
[23:18] <ScottK> Looks like i have some kind of oxygen (KDE) theme running now.
[23:18] <jdstrand> yeah, went from 5.0 to 6.0
[23:18] <jdstrand> 5.0 is no longer supported
[23:19] <ScottK> OK.
[23:19] <ScottK> Seems to work OK, it was just a bit suprising.
[23:20] <jdstrand> welcome to the new world of browser updates
[23:20] <ScottK> Yeah.  No kidding.