== Logs == TZ UTC +1 ''thanks PriceChild for the log'' {{{ 15:54:35 * agoliveira waves all 15:55:26 good afternoon 15:55:54 * asac waves 15:56:00 mdz: are you around? 15:56:40 hello 15:56:49 heya 15:57:00 hey bryce 15:57:16 hey hey 15:57:18 hey all 15:57:26 calc, doko, Riddell, mvo_, Mithrandir, soren: ping 15:57:35 pong 15:57:35 hi cjwatson 15:57:42 ohh crap, my report ... 15:57:43 are kees or mathias around today? 15:58:02 pong 15:58:02 mathiaz, rather 15:58:44 soren is around. I have not heard from mathiaz or kees today. 15:59:10 I talked to kees some minutes ago 15:59:11 cjwatson: I'm not sure but I think he's flying back with Chris Kenyon. 15:59:19 kees was talking on #ubuntu-devel 10 minutes ago 15:59:33 my clock must be behind. :) 16:00:07 hello cjwatson 16:00:11 hi 16:00:22 agoliveira: ok 16:00:30 heno: I guess it's you and me then 16:00:38 yep 16:00:48 I'm here now. 16:00:56 I just got a -ENOINTERNET from Mathiaz. 16:01:06 ok 16:01:16 we have a relatively full agenda today, so let's move right along 16:01:27 I haven't seen the agenda.. 16:01:36 apparently I missed several apologies, which is to be expected just after Ubuntu Live 16:01:39 here 16:01:40 https://wiki.ubuntu.com/DevelTeamMeeting20070726 16:01:54 no new starters this week 16:02:07 any extra items for the agenda 16:02:08 ? 16:02:13 * agoliveira is amazed by that! 16:02:49 * heno waves to bdmurray 16:03:26 agoliveira: by which? 16:03:49 cjwatson: "no new starters this week" :) 16:04:01 * Hobbsee waves 16:04:12 I'll take that as no extra items 16:04:16 mathiaz: You made it! 16:04:23 soren: yop :) 16:04:24 mathiaz: welcome 16:04:24 # 16:04:24 (pitti) What's the schedule for a new kernel upload? We need to get fixed dailies to test #126964 soon, just in case the /usr/bin/id (& friends) file corruption is yet another bug. 16:04:29 # 16:04:32 BenC: you had a plan for this, please share :-) 16:04:48 my primary concern about the fs corruption has been preemptively fixed by pkl 16:04:49 * pitti hugs pkl_ 16:04:53 pitti: also pkl's activity report is pretty relevant 16:04:54 indeed 16:04:54 Got an upload comming tomorrow 16:05:09 but it would still be interesting, since we didn't manage to get it into T3, and there was a kernel (almost) ready apparently 16:05:09 pkl_: are your fixed in lum now? 16:05:15 if so, we can probably do a build of that now 16:05:26 hey people 16:05:30 BenC: I'll push the fixes immediately after the meeting. 16:05:35 BenC: I'm not implying particular urgency (any more), just curious about the timing 16:05:39 ok, I'll do an upload after that 16:05:55 pitti: would be nice to have a working daily without waiting for tribe-4 16:05:56 BenC: just to avoid having the same awkward situation as with t3 16:06:04 pitti: as I think was mentioned earlier, from here on in, the plan is to schedule kernel releases for the Friday before a milestone 16:06:05 BenC: I agree 16:06:21 which means they should all have built by Monday, and we have a few days for emergency patch-up sessions 16:06:24 cjwatson: that's still pretty tight to sort out major problems 16:06:42 but if that works best for the kernel team, I'm fine with it 16:06:58 I don't want to squash the kernel cycle up too tight 16:07:06 (and I had real problems not typing "squashfs" there) 16:07:09 maybe s/for the Friday/by Friday/ 16:07:37 pitti: we could do uploads my time Thur night, so it's building on everyone's Friday morning 16:07:42 but generally it will be on Friday 16:08:01 TBH I think it's better to suck up that buildd time over the weekend when it's less contended 16:08:24 ok, good for me 16:08:24 cjwatson: then agian, if it happens to be in european night, relatively few uploads are being made anyway... 16:08:39 pitti: and with new deps in linux-meta, we can now do a full upload of everything at once, and not wait for kernel build to be done 16:08:42 seeing as most of the team is on european, or close to european timezone. 16:08:47 Hobbsee: Ben's night is early European morning 16:08:57 which would mean a kernel build lasting through most of the European day 16:09:03 BenC: that's great, decoupling archive admin steps from upload 16:09:22 cjwatson: erk. i'm messing my people in countries again. apologies 16:09:23 pitti: right, hoping that will alleviate some of the hand-holding for the process 16:09:39 we need to be careful not to accept ABI-changing kernel binaries until all the architectures have built 16:09:57 ack 16:09:58 Ben doesn't want the subsequent stages to happen until that's done, for internal ABI-management reasons 16:10:38 makes sense 16:10:43 BenC: seconded on having working dailies, will help with live CD installer wok 16:10:46 work 16:10:49 ok, next 16:10:49 # 16:10:51 (pitti) Please feel urged to have a look at the dapper point release TODO: 16:10:54 * 16:10:57 [WWW] https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2 We need to get these SRUs in the next two weeks to release it on time. 16:11:00 # 16:11:16 oh, did I write that as agenda? was meant as a general ping in the report 16:11:38 * BenC acks kernel work 16:11:42 well, yeah, I already annoyed some of you recently, and I'm afraid I have to do more status inquiries 16:11:51 after tomorrow's upload, I'll be shifting to dapper point work 16:12:17 I've looked at the highest priority 2.6.15 bugs for that list, should we dig deeper in that list? 16:12:29 that's quite a few bugs to cope with over the next couple of weeks 16:12:34 pitti: I think so 16:12:35 (iow, has someone else / can someone else have a look too?) 16:12:42 right, I wouldn't extend it much further 16:12:47 particularly with a tribe over the next couple of weeks too... 16:12:58 heno: unless you stumble upon something that's relatively easy and would truly improve dapper considerably 16:13:05 will we do something like a dapper.2 beta? 16:13:15 pitti: this means a lot of sru-verification for the next 2 weeks? 16:13:19 asac: I expect we'll have daily builds for a while leading up to .2 16:13:22 asac: test candidates 16:13:46 mvo_: yes, probably; a lot of hw specific issues, though, so we'll need the support team and DC guys, too for that 16:13:51 pitti: ok 16:13:55 since the focus is on making it work on new server hw 16:13:57 for those who weren't in the small meeting in London about this, the current plan is only to update the alternate/server images 16:14:05 mvo_: so we'll have to change the verification procedure a bit 16:14:05 I agree that the list is already long 16:14:17 for the reason pitti cites 16:14:28 pitti: ok 16:14:31 if you install dapper desktop now, you aren't getting very much longer support lifetime than if you install edgy anyway 16:14:40 we currently have two or three important desktop fixes, but they'll reach dapper-updates, too, and can be done independently 16:14:44 er, feisty 16:15:23 this will keep the workload down, and make it more feasible for the point release to happen without affecting gutsy development too seriously 16:16:13 you're aiming for .2 at the end of august, presumably? 16:16:20 btw, is there an "easy" way for someone with LTS to determine if a package is part of the "server" seed? 16:16:21 we'll need to figure out how to handle d-i uploads to dapper; I have a feeling we might need two, in order that we can test the hw-detect change before having new kernel 16:16:24 Hobbsee: current goal (set by mdz) is Aug 25 16:16:25 Hobbsee: thereabouts, yes 16:16:42 keescook: "easy"? dunno, but http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu-dapper/server 16:16:42 keescook: look at the server CD package .list file? 16:16:47 or what pitti said 16:16:59 (server also includes server-ship though) 16:17:09 cjwatson: can we build test CDs with -proposed? 16:17:10 pitti, cjwatson: yeah, that's the closest I've seen. 16:17:13 brilliant. directly when tribe 5 is due. cd testing might get interesting, then. 16:17:14 I meant http://people.ubuntu.com/~ubuntu-archive/germinate-output/dapper/server 16:17:25 Hobbsee: yes, it's always going to collide with something 16:17:32 not doing so is essentially impossible 16:17:37 pitti: yes 16:18:12 case $DIST in 16:18:12 dapper) 16:18:12 #export PROPOSED=1 16:18:12 ;; 16:18:13 BenC: oh, did you already see a change which will require an abi bump in all cases? 16:18:14 esac 16:18:17 just uncomment that ... 16:18:23 cjwatson: that's a point, when you get that late in the release cycle 16:18:29 btw is gutsy+1 (lts) planned for 8.04 or 8.06 ? 16:18:36 cjwatson: ok, let's discuss the technical bits out of band 16:18:42 pitti: for dapper or gutsy? 16:18:46 BenC: dapper 16:18:47 for dapper, not yet 16:19:05 calc: I think currently 8.04, though delaying isn't being ruled out; I don't particularly like the idea of a delay personally unless we have a really strong reason for it 16:19:11 BenC: I remember one fix which required an abi change, but it was only a 'bonus' type of thing; it would be utterly cool to avoid it, of course :) 16:19:14 I think dapper's delay had quite a negative effect on edgy 16:19:34 BenC: so far many bugs were actually quite simple, like adding modules to the initramfs and such 16:19:35 cjwatson: ok, i'm going to be off on a cruise sometime next spring/summer so need to determine when it is safe to plan that ;) 16:19:43 calc: noted 16:19:57 pitti: yeah, that's what I've gotten too...couple updated drivers and one or two new ones 16:20:12 * calc doesn't want to be gone at an important time 16:20:37 ok, I'm done with that meeting topic 16:21:06 rest -> #ubuntu-devel or #ubuntu-kernel or whatever's appropriate, and if you have items assigned to you please look at them forthwith 16:21:09 (tkamppeter) Decide on which printer setup tool should be default in Gutsy (gnome-cups-manager or system-config-printer). 16:21:21 ah 16:21:24 pitti: do you think your visual objections to s-c-p are substantially difficult to solve? 16:21:33 so, I quickly tried s-c-p today 16:21:48 I must admit that tkamppeter makes a compelling argument 16:21:52 it has a significantly harder UI than g-c-m, but as Till says, it's at least maintained upstream 16:22:03 it still has a lot of warts, but nothing unfixable, of course 16:22:26 And very important: It fixes some of my and pitti s specs from Mountain View: 16:22:27 apart from the serious bugs, my main concern is that it is much harder to install a printer with current s-c-p than with g-c-m 16:22:55 with g-c-m, it's "new printer", "ack the one from autodetect list", "press ok on the details page" 16:23:18 cjwatson: delaying> I think the current plan is to stretch the release for hunky a little bit, but not so much that itchy gets as painful as edgy. 16:23:21 with s-c-p, you don't see the list of detected printers at first and have to invent a name, location, description, etc., and the detected list is very confusing 16:23:37 Mithrandir: please don't tell me those are the actual names :P 16:23:49 that could be rectified with fully automatic printer installation, of course 16:24:01 cjwatson: no idea, but I would be surprised if they were. :-P 16:24:11 tkamppeter: I didn't see how to call s-c-p for auto-configuration, but if that's possible in general, let's talk about that in #u-d later 16:24:20 * agoliveira would *not* be surprised... 16:24:29 hunky he-man ;) 16:24:42 Mithrandir: of course it'll be "Harry Hogwarts" :-P 16:24:58 pitti: I don't even know if we'll be skipping H because of 5.04 16:25:22 I don't think we ought to switch to s-c-p straight away if it has known UI regressions that make it harder to install printers; however it is in main already and we still have a couple of weeks before feature freeze 16:25:33 pitti, hal-cups-utils has a script which auto-configures the printers, it only has a little bug that HAL does not actually call the script when plugging the printer. We need a HAL expert to look into that. 16:25:44 tkamppeter: do you think you can tackle the most urgent concerns as a prerequisite for switching to s-c-p by default? 16:25:45 tkamppeter: I can have a look at that 16:27:01 cjwatson, I can look into some, like filtering the list of auto-detected printers somewhat and taking care that HPLIP is always used if the printer supports it 16:27:02 (examples: enabling browsing or sharing messes up cupsd.conf and doesn't restart cups, s-c-p only runs as root without an apparent reason, detected printer list is not filtered for human consumption) 16:27:04 assuming we switch, I recommend that at beta time (when Canonical folks other than the distro team are liable to upgrade) we get non-technical folks in the London office to set up the printer there using s-c-p 16:27:32 * boredand1logging is now known as boredandblogging 16:27:40 and the UI is still quite complex in general, it's nothing for novices 16:27:59 lots of good features, of course 16:28:02 pitti, for handling the server config options correctly something on your non-root mode of CUPS needs to be improved. Web interface has the same problem. 16:28:29 tkamppeter: right, cupsd doesn't know how to reload its configuration without dropping the tcp port binding 16:28:49 tkamppeter: a mere /etc/init.d/cupsys force-reload works fine 16:29:26 pitt, if you could improve the CUPS patches, we could perhaps fix both s-c-p and web interface. 16:29:26 so, I didn't see anything that isn't fixable, as I said, but someone's got to do it 16:29:50 tkamppeter: I doubt it's easy to fix that properly; a complete restart is much easier 16:30:12 pitti, how does g-c-m fix the problem? 16:30:43 tkamppeter: /etc/init.d/cupsys force-reload 16:31:04 This works as non-root? 16:31:07 so, just to keep the meeting short, I propose that some of us install s-c-p and play around with it 16:31:20 ACTION: pitti to file the worst s-c-p bugs in LP 16:31:21 who volunteers? 16:31:34 Then we could perhaps make a simple patch on s-c-p to do the same thing. 16:31:34 o/ (for testing and bug filing) 16:31:37 (one of these days I must plug in our printer) 16:31:37 I can test on deskjet printers (local and windows share) 16:31:39 tkamppeter: no, as root 16:32:05 o/ also testing and bug filing 16:32:19 tkamppeter: currently s-c-p runs as root anyway (it shouldn't need to just to configure printers, that's another issue) 16:32:37 pitti, this one could probably also do in s-c-p, with a SUID helper or asking for the password to do a "sudo" call. 16:32:43 perhaps post a request to the gutsy forum section 16:32:47 ? 16:32:48 tkamppeter: gksu, yes 16:32:59 heno: I think that's the second step, after the distro team 16:33:09 but yes, that should be done 16:33:09 (or dev link section if that's active at all) 16:33:18 it's the default frontend for xubuntu, so maybe there are even some bugs already 16:33:45 pitti, I am runninh s-c-p always as normal (privileged) user and I can set up queues but not configure the server (as I also can run lpadmin). 16:33:51 tkamppeter: could you post any necessary instructions to ubuntu-devel@ and call for testers? 16:34:00 tkamppeter: I cannot connect to the server as normal user 16:34:07 including any particular items that are known, and areas that need attention 16:34:09 tkamppeter: (and yes, I'm in lpadmin, too) 16:34:45 pitti: What exactly can't you do without root? Does it not start at all? 16:34:56 pitti, once you need to update to the newest version, I did a small patch 16:35:05 soren: it starts, but it doesn't display any printers or my localhost server, and manually connecting to it fails 16:35:07 ACTION: tkamppeter to post s-c-p call for testing and instructions to ubuntu-devel@ 16:35:12 let's move on, as time is getting short 16:35:13 (tkamppeter) Should we stay with CUPS 1.2.x in Gutsy or advance to 1.3.x (Red Hat has already switched over in Rawhide)? 16:35:15 pitti: Ah, ok. 16:35:22 tkamppeter: I'm up to date in gutsy 16:35:41 tkamppeter: do you have a summary of changes? (preferably a link rather than all pasted in here) 16:35:46 second, I can only add, modifiy and delete queues, not any changes on cupsd.conf 16:35:51 based on my experience with migrating to 1.2 from 1.1 late in the process, I'd recommend keeping 1.2 at this stage 16:36:19 http://www.cups.org/articles.php?L479 16:36:27 the early 1.2.x broke a lot of stuff, and we played catchup with SRUs a lot in dapper 16:36:39 pitti, after the meeting I will help you to set up s-c-p. 16:37:02 tkamppeter: later, preferably, I gotta leave immediately after the meeting (dinner invitation); tomorrow? 16:37:10 tkamppeter: what would we get with 1.3? 16:37:18 cjwatson, so perhaps we keep 1.2 then and give 1.3 half a year to mature. 16:37:19 in terms of Great Features? 16:37:50 tkamppeter: it also depends on what we gain with it, of course 16:37:52 pitti, lets move it out to tomorrow. 16:37:54 maybe better to push a new version this cycle than for lts? 16:38:20 mdns support is cool, of course 16:38:37 pitti: but apparently avahi support isn't quite there yet 16:38:43 tkamppeter: ^ that obsoletes the cups specific browsing protocl, I take it? 16:38:54 see the comments at the bottom of the article I posted above 16:39:07 http://www.cups.org/documentation.php/whatsnew.html 16:39:19 ldap and kerberos are not so terribly urgent, since main ubuntu doesn't support it OOTB very well 16:39:19 This is a summary of the new features. 16:40:08 I think avahi is to find network printers, less to connect CUPS servers, or not? 16:40:45 tkamppeter: right 16:41:09 tkamppeter: avahi tells clients where to find the server, and the correct ipp:// address, and those clients can then use that address in their local cups spooler for printing to the remote queue 16:41:42 tkamppeter: very roughly, it has the same task than the cups browsing protocol 16:42:42 is the peer credentials stuff used by s-c-p? 16:43:27 ah, that looks like replacing the cert hack in /var/run/cups/certs/ 16:43:48 cjwatson, I do not know, as I did not try rawhide. 16:44:01 tkamppeter: is that cert -> peer cred change exposed at all? this should be completely opaqued by libcups 16:44:38 The new cupsctl command is also interesting, it makes it much easier to write printer setup tools with server config support. 16:45:05 tkamppeter: is that something s-c-p supports? 16:45:05 pitti, I do not know about the architecture of this one. 16:45:14 so, I think the answer to your question is that there doesn't seem to be anything compelling that *requires* an upload, but some potentially useful features, and the main concern is stability; ultimately, since we're not at upstream version freeze yet, I think it's between you and your sponsor 16:45:16 --w-r----- 1 cupsys lpadmin 32 2007-07-26 15:30 /var/run/cups/certs/0 16:45:33 in 1.2, everyone who can read this (i. e. lpadmins) are allowed to access cups without password 16:45:34 I do not know, I tested s-c-p only on Gutsy with CUPS 1.2.. 16:45:55 which is pretty much same effect like unix socket peer credential check for lpadmin group 16:46:27 Side-Channel API is also interesting to make drivers with -bi-di support and better error reporting. 16:47:08 so, if you guys want, I can try to build an 1.3 test package and see how much work it is to port our patches over 16:47:28 very few have been accepted by upstream, but we have to carry most of them ourselves unfortunately (even bug fixes) 16:47:37 pitti: seems like something Till should prepare, and you should review 16:47:47 WFM 16:48:23 for a mere test package we don't even need to port the derooting patches, that'll be much easier 16:48:26 tkamppeter: ^ 16:48:34 ACTION: tkamppeter to prepare test packages of cupsys 1.3, pitti to review 16:48:36 for a production package I would be very sad to see them go, though 16:48:45 cupsys offers an awful lot of attack vectors 16:49:02 pitti: does upstream refuse to use our patches? or didn't we submit them? 16:49:05 I think carrying over the patches is better done by pitti, as he has created the non-root mode and so knows better about for what the patches are good ofr. 16:49:07 I don't think it's worth reviewing an incomplete patchset 16:49:22 tkamppeter: it's subject to pitti having time 16:49:22 asac: I submitted a lot, but upstream keeps insisting that cupsd needs to run as root 16:49:44 asac: none of his arguments were compelling, though 16:49:47 pitti: maybe there are valid arguments? why would they insist otherwise? 16:50:01 tkamppeter: as I said, for a test package we can probably do without the derootign 16:50:31 asac: they presented a list of five-ish reasons, and I explained them why each of those doesn't need root *shrug* 16:50:46 pitti: did discussion just stopped then? 16:50:48 so Till can port the patches other than derooting, and Martin can finish it off? 16:50:52 I guess that's ok .. 16:50:56 pitti: maybe its worth reviving that? 16:51:01 of course the derooting patch is not perfect, but as long as they don't even support the general approach, I'm not very encouraged to clean them up 16:51:05 pitti, so I will make test packages without non-root. 16:51:10 asac: stopped> pretty much, yes 16:51:48 let's take the rest to -devel, as we still have a reviewers meeting to squeeze in here 16:51:55 any other business for today's meeting? 16:51:57 * jsgotangco (n=JSG@ubuntu/member/jsgotangco) has joined #ubuntu-meeting 16:52:07 I'd just like to mention consistent-login-screen. 16:52:28 We (seb128, Amaranth and I) had some discussion about it earlier and it looks like we might need to change our plans. 16:52:34 (to put it mildly) 16:52:48 iwj: oh, that's why my gdm screen is now blue, to match KDE? :-) 16:52:52 No. 16:52:53 iwj: can you give a quick summary? 16:52:54 please don't tell me we need to use the stupid splash screen again 16:53:07 I'm going to write up the situation for a decision. 16:53:08 heh, I wondered about that 16:53:24 Summary is upstream are doing / have done something quite different already in the last few weeks. 16:53:35 bryce: ♥ gnome flower :-) 16:53:37 cjwatson: basically FC7 fixed most of the usuability issues using consolekit and the code is to upstream GNOME now 16:53:40 So (a) if you would like to receive this mail let me know now. 16:53:43 from what I heard earlier it seemed to be dependent on gdm3? 16:53:47 iwj: o/ 16:53:47 Or (b) say it should be on ubuntu-devel. 16:54:02 * pitti votes for (b) 16:54:03 cjwatson: No, but the gdm2 patches I have don't work in my tests. 16:54:04 ubuntu-devel seems entirely reasonable .. 16:54:10 OK, (b) it is. 16:54:13 Expect a mail. 16:54:26 ok, gdm3 was the bit that scared me 16:54:40 (most) 16:54:46 cjwatson: that's planned for next cycle 16:55:04 if we need a splash screen again someone let me know as I am not on that list 16:55:13 kwwii: this is, AIUI, nothing to do with splash screens 16:55:20 ahhh, cool 16:55:24 kwwii: you should be on ubuntu-devel surely - it's moderated so relatively quiet 16:55:46 * jsgotangco has quit (Client Quit) 16:55:48 hm 16:55:52 cjwatson is correct; the splash screen is a different bug/situation. 16:56:23 anything else before we close? 16:56:42 only that there are too many bugs. *drowns in more bugs* 16:57:17 So do you approve of my automated tester ? :-) 16:57:23 * bryce pimps brian's bug plots - http://people.ubuntu.com/~brian/testing_graphs/ 16:57:31 It seems to have churned through main already. I wonder if I should set it going on universe. 16:57:32 Hobbsee: please welcome Pedro our new triager next week :) 16:57:40 heno: oh nice! 16:57:50 cjwatson: can I be excused now? I have a RL appointment now 16:57:59 We're done now surely. 16:58:11 pitti: yes 16:58:12 lovely per-package plots :) 16:58:18 thanks to everyone 16:58:29 I think we're drifting, so yes, we seem to be done 16:58:38 anyone prepared to run a reviewers meeting? dholbach isn't here 16:58:47 bryce: nice! 16:59:04 if not, let me pimp http://daniel.holba.ch/sponsoring/ 16:59:13 dholbach will clean up the UI later 16:59:23 cjwatson: what is the reviewers meeting about? 16:59:36 seb128: standing item to deal with unassigned code review items 16:59:37 seb128: ack? 16:59:51 asac: ack what? 17:00:08 confirmed your question 17:00:21 ah ;) 17:01:54 unassigned review items seem to be 96586 (inkscape), 95852 (adept), 63506 (adduser), 62396 (manpages), 128137 (espeak), 128028 (mysql-dfsg-5.0), 127273 (laptop-mode-tools), 125384 (linux-source-2.6.22), 119821 (dh-make) 17:02:04 volunteers? 17:02:15 I may have missed some where patch submitters have assigned themselves 17:02:46 cjwatson: Riddell should grab adept, but i thought there were a couple more patches on launchpad 17:03:00 cjwatson: wasn't the idea that we assign them to people we think are capable to do the review? 17:03:07 I would say bryce for the inkscape one since he's upstream ;) 17:03:10 asac: yes, but volunteers are always better first 17:03:18 seb128: indeed, but he's not in core-dev yet ... 17:03:29 I can take 96586 17:03:38 I was just about to suggest you. :) 17:03:45 I reviewed the inkscape one yesterday 17:03:49 I'm looking at 62396 17:03:52 I'll assign Riddell for adept 17:04:01 yes, there's a bunch of adept patches I hope to look at today 17:04:53 I'll do the trivial sync ones 17:05:08 (I extirpated my sponsorship guilt by dealing with grub today) 17:05:35 I can take 119821 too; but I'm unclear if the XSBC stuff is right. 17:05:59 if you're dh_make'ing for ubuntu, shouldn't the person doing it be the list (@u.c) maintainer? 17:06:07 keescook: for 96586, the backporter team bounced it back to the sru team before they'll do a backport. All the information is there to do either sru or backport, it just needs done. 17:06:10 cjwatson: I'll take adduser (63506). 17:06:22 bryce: but the patch looks complete? 17:07:08 * kwwii moves on to the next meeting....thanks everyone 17:07:17 bug 96586 Launchpad bug 96586 in inkscape "Correct multiple inkscape issues in Feisty (SRU and Backport)" [Low,Fix released] https://launchpad.net/bugs/96586 17:07:23 yes 17:07:35 I keep finding these rather trivial manpage bugs. 17:07:35 bryce: cool; I'll start shoving it. 17:08:00 * beuno has quit ("Ex-Chat") 17:08:03 iwj: thanks. yes, I'm not sure how much effort they're worth ... 17:08:06 oh darn, wrong bug 17:08:12 bug 119821 Launchpad bug 119821 in dh-make "dh_make does not follow blueprint" [Undecided,Incomplete] https://launchpad.net/bugs/119821 17:08:24 cjwatson: Yes. Ideally I'd just write a Debian bug report and let it follow through in the normal course of events. 17:08:28 (and grr, it DEFINITELY should be hash not pound) 17:08:34 (Not sure where upstream for adduser is.) 17:08:37 damn americanisms 17:08:47 iwj: Debian I think 17:08:52 iwj: I'm going to send it to Debian now 17:09:02 seb128: If you've got the mail already written by all means. 17:09:19 I'm happy to do it though. 17:09:31 I'll take espeak, Luke's good so that should be straightforward 17:09:37 iwj: yes 17:09:46 keescook: assuming that the package is going to universe first, that XSBC stuff should be fine 17:09:52 Yes you've got the mail written I take it. OK. 17:10:05 Hobbsee: okidoky 17:10:12 keescook: and it clearly wont go to main without a MIR anyway, so can be changed then. or can be changed if the user overrides it, knowing that it's going to go to main, etc. 17:10:14 BenC: can you look after that kernel bug (125384)? it's not appropriate for the normal sponsorship process 17:10:49 (or ping it back to lirc, it's not immediately clear to me where it belongs) 17:10:54 Hobbsee: I was thinking that if a new package was being made, the uploader would be the maintainer, which is allowed in the maintainer blueprint. 17:11:08 but, generally, I guess the diff is correct 17:11:14 cjwatson: ok 17:11:17 thanks 17:11:24 keescook: this is true, but they are trying to get to group maintainership. 17:11:48 that leaves manpages, laptop-mode-tools, dh-make 17:12:14 cjwatson: IMO, it can be closed because a) it's lirc's fault, and b) we have lirc modules in lum now 17:12:15 cjwatson: I'm snagging dh-make (discussed above) 17:12:40 dh-make has dholbach's name on the bottom as a comment. 17:12:42 keescook: oh yes, thanks 17:12:55 manpages should have a Debian bug filed rather than deviating; I'll take care of that 17:13:07 BenC: thanks, please do whatever's appropriate then 17:13:15 cjwatson: done 17:13:16 iwj: manpages bug with the diff sent to the BTS 17:13:20 cjwatson: ^ 17:13:23 aha 17:13:45 I recall Matthew Garrett saying recently that laptop-mode wasn't really particularly desirable, so am not sure what to do with that bug 17:13:54