[00:23] ebroder: I'm pretty sure that multiple fixes in the same SRU are NOT acceptable. the exact opposite of what you said :) [00:23] ebroder: at least that makes a lot more sense than what you said [00:23] you could have patch a fix one thing and patch b break another; which is exactly what we don't want in SRU's [00:24] Chipzz: What? Multiple fixes in the same SRU are *clearly* acceptable, and have always been. The question was whether you needed an explicit ACK from ubuntu-sru before uploading it, or whether you could use the same process as for a single fix (i.e. upload, then get ubuntu-sru's ACK) [00:24] Chipzz: a release team member said it was fine shortly afterwards as long as each bug has the proper SRU precedures [00:26] ebroder: is this documented somewhere? because like I said, trying to fix multiple issues at once sounds to me like it greatly increases the chance for regressions [00:26] Chipzz: I'm pretty sure there's documentation of multiple fixes on the SRU wiki page [00:27] !sru [00:27] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [00:28] "Fixing several bugs in one upload" [00:29] Chipzz: no more than having 3 uploads in one week... [00:29] maco: you upload 3 SRU's for the same package every week? ^^ :) [00:30] Chipzz: if there are 3 patches available for it and you've got debdiffs for all 3 and SRU stuff filled out for all 3 and ACKs for all 3... no point in doing 3 separate uploads [00:30] Especially when you consider the 1 week minimum time in -proposed [00:30] maco: IMHO there is [00:30] "ok did it start happening with tuesday's version or wednesday's?" [00:30] user: "like hell i know" [00:30] maco: if there's a regression in 1 of thsoe 3 patches, you can see which SRU caused the regression [00:31] maco: launchpad. archive of old debs. point user to them. :) [00:31] heh i remember writing directions for someone once of how to find old debs on lp... [00:31] those were long directions [00:31] user: "oh it happened with tuesday's version" [00:32] Chipzz: If that sort of thing happens, then a developer can do PPA builds of each patch [00:32] But in the common case, I think it's much easier to track regressed behavior back to a particular patch than suggesting [00:32] *you're suggesting [00:32] its not like theyre going to be huge invasive patches [00:33] if they got an ACK to start with they're fairly minor [00:33] ebroder: btw, the text you quoted only says what to do if there are multiple patches attached. It doesn't encourage or discourage uploading multiple patches at once eiter way [00:33] so figuring out which bit did it should be fairly trivial [00:33] *either [00:33] Chipzz: It establishes that doing so is acceptable [00:33] but I guess it being allowed is implied in some way [00:33] no [00:33] In order to make it easier for the SRU team to review your patch, you can additionally: ... Attach individual patches to the corresponding bug reports. If you have the fixes in bzr, it is even easier and more convenient to give a pointer to the fix ("fixed in http://bazaar.launchpad.net/.../revision/12") when fixing the bug in trunk. [00:34] where does it state it's acceptable? [00:34] it's implied, but not stated [00:34] "Just prepare all fixed bugs as described above and attach the patch/debdiff to one of them." [00:35] It gives a procedure for SRU'ing multiple patches at once, which makes it acceptable. If it wasn't acceptable, there wouldn't be a procedure [00:36] ebroder: but it doesn't establish when it is acceptable. for example, it could be considered acceptable to SRU 2 patches for things which are very closely related (ie code- or functionality-wise) [00:36] but SRU'ing 2 patches which touch totally different parts or fix totally unrelated bugs may not be [00:36] anyway [00:37] matter of opinion I guess, but I wouldn't advise on it [00:37] but then again I don't know the workflow of the SRU team [00:37] Chipzz, ebroder: http://irclogs.ubuntu.com/2010/08/22/%23ubuntu-devel.html#t06:10 [00:39] well, ebroder, you were present for it... [00:39] Chipzz: we got clarification on this from SRU team member less than 24h ago [00:41] grr...I need to get added back to ~ubuntu-sponsors [00:41] ebroder: poke persia [00:43] maco: right, I just read that. don't personally agree, but who am I? :) [01:01] maco: Can you do me a favor and unsub ubuntu-sponsors from bug #622196? [01:01] Launchpad bug 622196 in epdfview (Ubuntu) "Please sync epdfview 0.1.7-4 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/622196 [06:26] anyone been able to link against xmlrpc-dev in the repo? [07:19] Good morning [07:19] morning pitti [07:19] hi [07:21] Good morning ! [07:23] morning all! [08:24] pitti, good morning [08:25] hey ara, how are you? [08:25] pitti, good, thanks :-) slowly starting the week. yourself? [08:25] pretty well, thanks! had a nice weekend? [08:26] yes, relaxed weekend, after a sprint week [08:28] pitti, I have a couple of questions more about apport [08:29] pitti, 1) I have a virtual package that installs a bunch of packages. The hook will be the same for all those packages but, if I want apport to know, I have to install one hook per package? or is there a way to do it differently? [08:30] pitti, 2) Adding hooks at this time of the cycle, does require a FF exception? [08:32] ara: (1) xorg is similar; the x11-common package ships the hook, and all other packages just ship a symlink [08:32] ara: if the packages mutually exclude each other, you have to install it to every package, I'm afraid [08:33] ara: (2) No, apport hooks are fine; asking for FFEs for better debugging tools would be very .. bureaucratic and against the spirit of FF, I think [08:33] pitti, OK, perfect. Thanks! [08:35] good morning === jelmer is now known as Guest73756 === almaisan-away is now known as al-maisan === Guest73756 is now known as jelmer === jelmer is now known as Guest76162 === Guest76162 is now known as jelmer [10:13] slangasek, cjwatson: could one of you please review my udev lucid SRU? it's a keymap update according to the SRU exceptions, but I guess it should still be reviewed [10:23] I'm researching a sound-card problem that has been introduced in Lucid through an SRU last week. Do you know what packages were released to lucid-updates last week? [10:28] diwic: I don't remember anythign sound related; we were in SRU freeze, so there was very little change in -updates [10:28] diwic: do you have an affected system? check /var/log/dpkg.log perhaps? [10:29] pitti, unfortunately I can't reproduce it here. It could have been two weeks ago as well, and it could have been permissions related [10:29] pitti: could you please reject the compiz upload from lucid-proposed (I uploaded ~5min ago or so). it does not contain the merged bits from 15.1 [10:30] diwic: https://edge.launchpad.net/ubuntu/+source/linux/2.6.32-24.41 perhaps? [10:30] but it doesn't look sound related as well [10:31] mvo: done [10:32] pitti: thanks [10:33] pitti, is there a complete list somewhere of lucid-updates packages, sorted in "latest release date" order somewhere? [10:34] diwic: not by that sort order; it's done by copy-packages.py in LP, which doesn't log that well, I think [10:35] diwic: the proposed uploads are on https://lists.ubuntu.com/archives/lucid-changes/2010-August/thread.html [10:35] diwic: I'd start with trying the previous kernel; there were no alsa/pulse updates recently [10:35] or gstreamer, etc. === amitk is now known as amitk-afk [10:37] pitti, thanks for the thread, I'll go through it, it seems to have a post date of when they were moved from lucid-proposed to lucid-updates, right? [10:39] diwic: no, it's the acceptance date of entering -proposed === yofel_ is now known as yofel === doko_ is now known as doko [11:09] pitti: ok [11:10] maxb: could you have a look at lp:~cjwatson/bzr-rewrite/rebase-foreign-merges? it's based on your work in lp:~maxb/bzr-rewrite/hg-papt-rebase-foreign, but I found I needed an additional tweak [11:10] I don't know if it's exactly the right way to do it [11:11] (I also forget the exact set of circumstances that led up to it ... I was working on rebasing tasksel) [11:14] diwic, for a specific package you can find when it has been pushed to -updates from the LP +publishinghistory page e.g for alsa https://launchpad.net/ubuntu/+source/alsa-driver/+publishinghistory [11:23] pitti: accepted [11:24] cjwatson: cheers === amitk-afk is now known as amitk [11:50] hmmmm, why is gnome-power-manager no longer in the ubuntu-desktop package-set in maverick? [11:58] chrisccoulson, it's in core, maybe because ubuntu-netbook, ubuntu-desktop and ubuntustudio-desktop want it [11:58] hmmmm, that sucks. it seems that every desktop component i'm interested in is in core now :/ [11:59] chrisccoulson: take the hint and apply for core dev ;) [11:59] heh ;) [11:59] chrisccoulson: I'll add an exception shortly [12:00] cjwatson, thanks [12:00] dholbach's analysis would put it in desktop-core, not core, so I expect it's more complicated than that [12:00] it's probably buried in the huge gnome build-dependency web at the centre of everything [12:00] cjwatson: um, I pinged you about a bug last night, were able to look at it? [12:01] nigelb: not yet (it was a Sunday night!) but it's not an urgent bug [12:01] cjwatson, you're right - I didn't check build-depends [12:01] nigelb: I'd rather leave it the way it is than rush it [12:01] that sort of change can have serious effects on the installer [12:01] cjwatson: clearing up the patches... [12:01] I know, but still [12:03] cjwatson: oh, I didn't think of the side effects. I'll skip that one for now. There are some really old ones that we seem to have forgotten about. === MacSlow is now known as MacSlow|lunch [12:08] nigelb: (also, the semantics of debootstrap at that level need to stay the same between Debian and Ubuntu or everyone's head will explode in confusion, so I'll have to think about it with my Debian hat on) [12:08] cjwatson: ack, no problem. === bilalakhtar is now known as bilalakhtar_ === bilalakhtar_ is now known as bilalakhtar [12:15] cjwatson: noted. Thanks for reminding me to get back to polishing that branch for submission === bilalakhtar is now known as bilalakhtar_ === oubiwann is now known as oubiwann-away [12:16] maxb: feel free to merge from me or whatever - I'm not going to propose that branch for merging since I'm not confident I understand all of it :) [12:17] maxb: (I proposed three other bzr-rewrite branches for merging today, though) === oubiwann-away is now known as oubiwann [12:32] james_w: hey -- I cannot change status on https://code.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/+merge/32036, probably because it was proposed for merging into "lucid" instead of lucid-proposed... Can you mark it merged or abandoned so that it doesn't show up in the sponsorship list anymore ? [12:33] nigelb: I assume you guys have a state for "patch forwarded upstream" which takes it off the "needs action" list? [12:34] cjwatson: yep, patch-forward-upstream or patch-forwarded-debian (which might be appropriate here) [12:49] lamont: Hey, would you mind bumping up the libnih buildd timeout on armel? It swaps when building libnih's testsuite with -fPIE and that takes a long while to build [12:50] sigh [12:50] we need a webUI with a slider :) [12:51] lamont: If that makes you any happier, there is probably a similar bump on upstart which you can now remove since the code moved from upstart to libnih [12:54] lool: there are currently no timeout overrides [12:55] :q [12:55] heh. that almost makes sense as an emoticon [12:56] nigelb: OK, off your list now then [12:56] cjwatson: thank you! [12:57] cjwatson: Thank you! [13:01] lamont: Do you have the timeout overrides deployed already? I wonder when to kick a retry of libnih/armel [13:02] lool: it's a highly manual process... and there wasn't one on upstart... how long does libnih need [13:02] ? [13:05] lamont: I have no idea; michaelh built it locally yesterday [13:06] I gave it, um, long. [13:06] lamont: Let's shoot for 6 hours? [13:06] 10 [13:06] lamont: thanks; giving it back [13:06] as long as gourd doesn't get it, that is.. [13:06] satinash [13:06] well maybe, sometimes this changes when the build "started" but didn't actually start === dholbach_ is now known as dholbach === al-maisan is now known as almaisan-away === mathiaz_ is now known as mathiaz === MacSlow|lunch is now known as MacSlow [14:29] chrisccoulson: fixed [14:40] cjwatson - thanks === bjf[afk] is now known as bjf === bilalakhtar is now known as bilalakhtar__ === bilalakhtar__ is now known as bilalakhtar === bilalakhtar is now known as bilalakhtar_ === bilalakhtar_ is now known as bilalakhtar [15:20] james_w: thanks :) [15:20] np === achiang` is now known as achiang === almaisan-away is now known as al-maisan [15:38] is Mathieu Trudel-Lapierre around by any chance? [15:41] dagger, he's cyphermox [15:41] seb128: thanks [15:41] dagger, yup === ogasawara_ is now known as ogasawara === quadrispro is now known as alessio === zyga is now known as zyga-afk === alessio is now known as quadrispro [16:33] am i correct to assume that switching default window manager requires only changing "/desktop/gnome/session/required_components/windowmanager" string ? [16:59] emacs_noob: System->Adminstration->Login Screen === fta_ is now known as fta === _martin is now known as m4rtin [17:20] dyfet: I don't suppose you got anywhere with python-qt4? [17:21] no, ncommander promised a related patch, I was not able to get it from him yet though [17:21] * Riddell looks with pleading eyes at NCommander [17:21] isn't he in China? === doko_ is now known as doko === MacSlow is now known as MacSlow|afk === zyga-afk is now known as zyga === beuno is now known as beuno-lunch === ivoks_away is now known as ivoks === dendrobates is now known as dendro-afk === MacSlow|afk is now known as MacSlow === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === beuno-lunch is now known as beuno === sconklin is now known as sconklin-lunch === dendrobates is now known as dendro-afk [18:38] hey all, just an FYI, UDS is now announced: http://uds.ubuntu.com/ [18:38] do go and apply for sponsorship === al-maisan is now known as almaisan-away === dendro-afk is now known as dendrobates === jelmer_ is now known as Guest39999 [18:56] can I submit a sync request if Debian's madison cache is out of date (i.e. can the AAs still do it) [19:07] siretart: can you 'Won't Fix' this bug as with upstream debian one? bug 72054 [19:07] Launchpad bug 72054 in zsh (Ubuntu) "package defaults are unfriendly for users that use the 'viins' editing mode" [Wishlist,Incomplete] https://launchpad.net/bugs/72054 [19:08] (or can you ack, so I can Won't Fix it :)) [19:08] cjwatson: hi! do you have less than 5 minutes to help me with something regarding dpkg triggers? [19:10] cjwatson: either something changed with dpkg triggers or there is a bug in dpkg/debconf/triggers [19:10] micahg: yes [19:11] jdstrand: maybe :) not at my laptop right now [19:11] cjwatson: well, let's give it a shot. a 'not right now' or 'I don't know' is totally fine :) [19:11] cjwatson: k, thanks [19:11] cjwatson: so in ufw.config I have: [19:12] if dpkg --compare-versions "$2" lt 0.28-1 ; then [19:12] ... [19:12] in maverick at certain times, ufw.config gets called with: [19:12] ufw.config configure /etc/ufw/applications.d [19:13] /etc/ufw/applications.d is the directory that ufw is interested in [19:13] the debconf-devel manpage doesn't mantion anything about triggers, and says it is legal to use dpkg --compare-versions in this manner [19:14] cjwatson: so, I wonder if I found a bug or am doing it wrong [19:15] cjwatson: oh, context is bug #618410 === DrKranz is now known as DktrKranz [19:15] Launchpad bug 618410 in ufw (Ubuntu) "/etc/ufw/applications.d has wrong syntax" [Undecided,In progress] https://launchpad.net/bugs/618410 [19:15] you need to avoid sourcing debconf/confmodule when the postinst is called with [ "$1" = triggered ] [19:15] ah [19:15] I wonder why I never saw this before === deryck is now known as deryck[lunch] [19:15] cool, that is a super easy fix [19:15] cjwatson: thanks! :) [19:16] however what you do in that case does need to be sufficient to noninteractively configure the package, iirc [19:16] so you might need to be a little careful [19:16] this is implied by triggers.txt in the dpkg docs plus a knowledge of how the confmodule works, but it isn't spelled out [19:16] cjwatson: you mean I need to be careful when [ "$1" = triggered ]? [19:16] yes [19:17] right. yes, I am quite careful there to not hang or anything [19:17] (or error out, etc) [19:17] triggering involves calling postinst triggered "

..." [19:17] * jdstrand nods [19:17] it all makes sense now [19:18] I was scratching my head a bit before I asked. this is super helpful [19:18] let me just check something though [19:18] Hi! I'm wondering, how can I use gdb for core file analysis? [19:19] jdstrand: do that for now - I might get back to you, it's possible this is a bug in debconf [19:20] cjwatson: thanks [19:22] slangasek: In these post-FF days, do you need a poke to get source NEW stuff done? It's only been in the queue for 11 hours, so it's perfectly cool if it's just not been done yet, I just want to be sure there's nothing more I need to do. === ivanka is now known as ivanka-train [19:22] slangasek: (Asking you specifically because you're listed as today's AA) [19:23] heh i dont think ive ever needed a FFe before, so i'm wondering whether this process has an undocumented "poke someone on irc" step like many others [19:24] maco: I don't think it's really needed, someone just suggested it might be. [19:24] maco: I know at least jdstrand, being his usual awesome self, did a source NEW review without a poke. :) === fta_ is now known as fta [19:28] soren: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20packages [19:29] soren: my listing as the day's AA is somewhat optimistic at this point, I'm afraid; though I should at least be able to get through binary NEW today and may have a look at source NEW as time allows [19:29] slangasek: Is that the rtfm-y sort of way of telling me that if I've done that, everything is cool, or are yo utrying to tell me I'm missing a step? [19:30] soren: you asked about needing an FFe; the documented process is that yes, you do, though it's generally very light [19:30] slangasek: Er.. That's not what I intended to ask, at least. [19:30] slangasek: I see that I might have been unclear. [19:31] slangasek: I filed an FFe, got it approved, and have uploaded accordingly. [19:31] oh :) [19:31] then ack :-) [19:31] slangasek: The person who approved it said it might need extra work to actually get it reviewed. [19:31] to answer your question: yes, if you want me to do NEW review, *I* need to be poked ;) [19:32] slangasek: Alright. Consider yourself poked. :) [19:35] any suggestions as to what should be done with this bug? how do I know if it ever built sucessfully bug 219280 [19:35] Launchpad bug 219280 in xen-3.2 (Ubuntu) "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/219280 [19:49] jono: Re UDS-N, I'm getting back into school on the 7th, and won't probably know till the end of that week whether or not I'll be able to come, (ie whether my teachers have loads of plans that week, etc) and for how long. Can I apply for sponsorship late after I determine that? (It'll be no more than 5 days post-deadline) === sconklin-lunch is now known as sconklin [19:51] lfaraone, sure! [19:56] jono: cool, thanks! [19:57] nigelb: I don't use viins mode myself, and I'd rather follow debian on this package. AFAIUI it's a classical "doomed if we do, doomed if we don't" issue [19:58] siretart: Debian closed as Won't Fix, hence I asked if you could do the same in Ubuntu. [20:25] mathiaz: what is the intent of this php5-sybase-dbg package? [20:25] mathiaz: it's not going to result in freetds being moved to universe, so if that's the only purpose, I think you should revert this [20:26] seb128, are you up for reviewing and uploading the latest utouch-grail, utouch-geis, and utouch meta package to ubuntu? [20:29] cnd, hi, open bugs and subscribe ubuntu-sponsors [20:30] cnd, you have api changes there right? [20:30] seb128, ok [20:30] seb128, yeah, we do [20:30] cnd, it's late for those we are 10 days over the freeze for such changes [20:30] we need at least bugs to track the exceptions [20:30] seb128, we know... [20:30] ok [20:30] cnd, thanks [20:31] cnd, you have changes to the dummy package as well? which one? === almaisan-away is now known as al-maisan [20:31] seb128, utouch is the package [20:32] seb128, and I forgot that mtdev needs a bug fix update too [20:32] cnd, ok, just open bugs with the changes or the vcs to sponsor [20:32] cnd, what changes do you have to utouch? you have new sources to add to it? [20:33] cnd, not sure why we need that one, the others one should be installed by what depends or recommends the binaries [20:33] seb128, removal of dependency on xserver-xorg-input-gevdev in place of xserver-xorg-input-evdev [20:33] ok [20:33] and the addition of the geis doc package [20:34] cnd, thanks for the work on those [20:34] cnd, you are done with the api changes now right? ;-) === deryck[lunch] is now known as deryck [20:35] seb128, umm, very close [20:35] bregma was working on some last changes to geis [20:35] but realized they wouldn't work [20:35] so we had to stick with the current geis api for this upload [20:35] so we can get unity with MT in [20:35] well if you are other api change let's wait for those to sponsor updates [20:35] seb128, the issue is that unity is ready to go with geis stuff [20:35] if you have [20:35] cnd, no it's not [20:36] seb128, well, what are we considering api changes, do strict additions count? [20:36] we are not going 2 rounds of updates [20:36] cnd, now is over time to add pis [20:36] to add apis [20:36] seb128, I know, I really do [20:36] I really don't like this either :) [20:36] well so... ;-) [20:36] cnd: what is bregma wanting to add? [20:37] cnd: things that Neil absolutely has to have? [20:37] cnd, oubiwann: you guys need to stop doing api changes really [20:37] it's weeks late [20:37] seb128: yeah, no kidding... I'm actually surprised by this info [20:37] seb128, oubiwann, mind if we chat with bregma in #ubuntu-touch? [20:37] ... [20:37] cnd: okay, let's [20:37] it may be that we just have to forgo some functionality in maverick [20:38] I will let you guys deal with the changes you have to do [20:38] I've other things to finish today as well [20:38] let me know what you decide [20:38] seb128, sounds good [20:38] thanks! [20:39] yw === fta_ is now known as fta [21:29] slangasek: the intent is to move php5-sybase out of main [21:29] mathiaz: what's the benefit of moving a single binary package out of main like that? [21:30] slangasek: to not support the sybase functions in main anymore [21:30] mathiaz: from the changelog, I assumed you were trying to get freetds out of main, which this change doesn't help with [21:30] ah [21:30] slangasek: nope - the goal was to move php5-sybase to universe [21:30] supporting them is a problem? [21:30] slangasek: hm - I guess we're trying to decrease our support burden [21:30] slangasek: I don't remember the exact reasons [21:31] SpamapS: ^^ ? [21:31] didn't they have troublesome aliases in that package? [21:31] slangasek: SpamapS may have more clue on the reason for demoting php5-sybase [21:31] ajmitch: yeah - there is something like as well [21:31] I'm surprised that php5-sybase involves any effort on the part of the server team at all, though - above and beyond php5 itself, that is [21:31] ajmitch: "troublesome"? [21:32] slangasek: aliases of sybase functions to mssql, there were a few bugs about it that I saw [21:32] er, why are those troublesome? [21:32] I think it was because they weren't all aliased, I'd need to look up the bugs to know [21:33] right; but the aliases themselves weren't troublesome, they're meant to be there because you really should only have one module to support both sybase and ms-sql (since they use the same libraries on the backend) [21:33] anyway [21:34] I can certainly accept this if the point is to demote php5-sybase itself, I just don't understand how that actually helps anyone === dendrobates is now known as dendro-afk === glick is now known as glickster [22:03] hi kees, you there? === al-maisan is now known as almaisan-away === Guest39999 is now known as jelmer === dendro-afk is now known as dendrobates === fta_ is now known as fta [22:32] lamont: FYI libnih built fine; thanks === bjf is now known as bjf[afk] [22:34] lool: cool [22:37] chrisccoulson: yup, what's up? [22:38] hi kees, did you say you knew how to fix crash handlers that relied on ptrace? [22:38] the mozilla handler is actually relying on that ;) [22:38] i've just been trying to figure out why we send empty crash reports [22:39] chrisccoulson: yes. you'll want to use prctl(), let me find the example. [22:39] chrisccoulson: the crashing program must call prctl with the pid of the debugger. [22:39] kees - this one? http://bazaar.launchpad.net/~kubuntu-members/kdelibs/ubuntu/annotate/head:/debian/patches/kubuntu_69_declare_debugger_pid.diff [22:40] chrisccoulson: https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030973.html yup [22:40] cool, i'll try and get this working with breakpad as well then [22:40] thanks [22:40] cool === fta_ is now known as fta === kentb is now known as kentb-afk === kentb-afk is now known as kentb-saftey-tra === kentb-saftey-tra is now known as kentb [23:42] mathiaz: in response to php5-sybase, its just less code to cover under security and bug fixes, and especially difficult to support because we do not have any access to sybase/mssql servers [23:42] slangasek: ^^ [23:42] SpamapS: OTOH it introduces a new binary package in the archive [23:42] SpamapS: and we slip a bit further away from Debian [23:43] mathiaz: why can't we just manually put that binary in universe? [23:44] SpamapS: so I don't see that this is actually true wrt "less code to cover under security" [23:44] is the security team actually intending to leave security bugs in the php5 source, which is in main, unfixed because they affect php5-sybase? [23:46] Right, I can't say they'd be happy about doing something like that. [23:47] where should the TERM variable be set from ? After a karmic->maverick upgrade I get a "dumb" value [23:47] I just don't know that we can give the same assurances that a security fix works... [23:47] "When you install software from the main component, you are assured that the software will come with security updates and that commercial technical support is available from Canonical." [23:48] http://www.ubuntu.com/project/about-ubuntu/components [23:48] Maybe we do have some access to sybase/mssql servers. If we do, then I'd say its fine to keep php5-sybase in main. [23:48] SpamapS: we can't manually put the binary in universe because main is defined as a closure over build and runtime dependencies. FWIW you could just have php5-dbg not depend on php5-sybase; any reason that doesn't do what you're trying to achieve? (it would certainly be less delta from Debian) [23:49] we could drop php :P [23:49] SpamapS: "commercial technical support" - but not guaranteed to be as affordable if the support involves someone having to go set up MS SQL first ;) [23:49] do the world a favour! [23:50] lifeless: no haters please. ;) [23:50] lifeless: this was my thought! But some people seem to be attached to it [23:50] lifeless: don't tempt him [23:50] slangasek: Agreed, its actually probably cheaper for us to simply maintain a mssql server than to maintain a large delta for this. [23:50] SpamapS: no emotion involved; sheer dispassionate technical assessment :P [23:51] Being just 4 months out of a PHP shop.. and having recently seen the *circus* around PHP 5.4alpha, aka "the release that may never be" .. I'm less inclined to ever write another line of PHP. ;) [23:51] SpamapS: did the concern about support originate with the support team itself? [23:52] slangasek: no, its purely something that mathiaz suggested as a possibility, and I looked into and agreed it seems like something fairly difficult to support. [23:52] if it did, then it's pretty clear we should move php5-sybase out of main as a matter of documentation [23:52] ok [23:53] I'm a big fan of contraction of responsibility whenever possible, so I may have seemed over-eager at the prospect. [23:54] SpamapS, mathiaz: so my preferences would be: 1) revert and just accept this package in main unless one of the teams that actually get stuck with the work post-release requests its removal; 2) ship the same php5-dbg package as in Debian, but Suggest: php5-sybase instead of Depends: on it; 3) the currently proposed upload [23:54] SpamapS: you're not contracting others' responsibility much, and you're increasing your own maintenance burden with the added delta ;) [23:55] slangasek: indeed, I think its clear now that we'd be doing a lot more than just changing a seed. === fta_ is now known as fta [23:58] any python gurus know how to fix this? python -c 'print u"\xc2\xb0"' | cat [23:59] SpamapS: btw, if you didn't notice, I am the maintainer of the freetds package in Debian - so if you disagree at all, I'm happy to recuse myself and refer this to another archive admin :)