=== jalcine is now known as JackyAlcine_ === JuN1x_ is now known as JuN1x === webjadmin_ is now known as JackyAlcine_ [01:44] slangasek: your merges seem to be lacking teh Debian changelogs [02:21] micahg: sigh [02:21] micahg: sorry [02:26] We should probably get some tooling to detect and reject that. [02:26] It's *way* too easy to neglect. [02:28] what's that, missing -v? [02:29] missing --package-merge [02:54] RAOF: Rejecting just because the .changes is lacking entries seems a bit harsh. We certainly allow much buggier uploads than that. :P [02:54] Only because we can't catch them :)\ [02:54] Well, but a truncated .changes isn't a package bug at all. [02:55] (Not saying we shouldn't continue to promote a best-practice of -v(last_upload), just that I don't see the point in rejecting if someone forgets) [02:56] It doesn't affect the quality of the package at all, nor even the contents of the real changelog, just the mail to -changes, and the upload record in LP. [02:57] (And if we're "checking" that it's correct by tearing apart the package and reading the real changelog, then LP could correct both those issues instead of rejecting) [02:57] It'll sometimes cause launchpad bugs that would be closed by a proper changes file to go un-closed. [02:57] Well, making launchpad do the right thing would be nice, too :) [02:58] Yes, it can leave bugs unclosed. And the upload can and should fix that. :P [02:58] But I still don't see rejecting non-buggy packages as the answer. [02:58] I find it about as distasteful as the people who spend hours arguing over someone submitting a patch in the "wrong" format instead of just applying it. [02:59] Not that the two things relate at all, but in both cases, it's a question of process, not function. [02:59] s/the upload can/the uploader can/ === stokachu is now known as battlemidget [03:43] broder: stgraber: to be clear, on that bluez patch, that didn't originate with me [03:43] maybe i didn't do the right thing there, but i wanted to keep the guys' patch going, but didnt' have the rights to do anything but make a new merge proposal myself === webjadmin is now known as JackyAlcine_ === emma_ is now known as emma === battlemidget is now known as stokachu [05:03] can i ask a packaging question here or does that fall under ubuntu-app-devel? [05:05] It depends; is it to do with the development of ubuntu? [05:05] (#ubuntu-motu can also be reasonable for packaging questions) [05:05] ah ok ill try there [05:05] thanks [05:06] Basically - if the objective is to work on a package in the main archive, then either here or #ubuntu-motu is entirely appropriate. [05:42] Good morning [05:59] bdfhjk: Hi [06:32] the binary packages from the latest linux-meta upload in precise (3.2.0.18.18) seem to be MIA, can't find them anywhere [06:35] apw: I binNEWed them an hour ago [06:35] they should appear RSN [06:35] they should be there now, actually [06:35] pitti, hmmm, ahh, compat-wireless was added ... didn't spot that [06:35] * pitti cleans up http://people.canonical.com/~ubuntu-archive/nbs.html [06:35] thanks [06:38] apw: any chance to get a bumped linux-meta-ti-omap4, too? [06:38] pitti, will do [06:38] cheers [06:48] apw: linux-meta added a modules-cw package which depends on a non-existing linux-backports-modules-cw-3.3-3.2.0-18-server [06:48] apw: is that binary package going to exist, or does -meta need to drop that? [06:49] pitti, i believe it will ... /me checks [06:51] pitti, oh is that in amd64 ? [06:51] yes [06:51] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [06:51] pitti, ok leave that with me, i think thats a thinko [06:52] apw: It won't exist, -server was replaced with generic... [06:52] apw: (And you just dropped the cw-server stuff in the last lbm upload) [06:52] yeah, i'll fix that and get it updated [06:54] * infinity wonders how deeply he cares about fixing -tools-armadaxp. [07:00] infinity: we could just drop the package temporarily instead, to get rid of the uninstallability? [07:00] pitti: If it bugs you terribly, I can just drop it from the meta for now, sure. [07:02] it's the one step away from beer :) [07:03] well, now two steps since yesterday, but apw is sorting this out [07:04] Fine. I'll fix the meta JUST FOR YOU. [07:05] Oh man, I'd gotten so used to the syntax hilighting in vim with the incorrect background=, that the new and correct setting just looks weird. [07:05] Figures. [07:06] infinity: thanks! [07:06] infinity: yeah, the new default totally broke here as well; I added "set bg=light" to my .vimrc now [07:06] bright text on dark background is just plain wrong [07:07] Well, it makes some sense this way. And that bright text definitely would have been unreadable on white backgrounds. [07:07] Still. [07:07] Weird. [07:07] I might flip it back locally too. :P [07:11] pitti: I think I stand by my belief that the new default is "correct", and old nerds like us just hate change. [07:12] infinity: no, it's a matter of ergonomy [07:12] at least for people who work in a bright environment [07:12] infinity: which might not apply to night-time workers like you of course :) [07:12] pitti: Perhaps, but edit a changelog with bg=dark, and tell me that package name field in incredibly dark blue is actually readable without eye strain. [07:13] infinity: oh, it's certainly matching our default terminal colors better [07:13] (I'm used to it, and I pretend it's readable, but I'm not sure it actually is) [07:13] infinity: but I never said that _those_ were correct either [07:13] ;) [07:13] pitti: Oh, wait. Do you use white terminals? [07:14] yes, of course [07:14] well, white-ish [07:14] pitti: Oh, kay, then I misunderstood your complaint. [07:14] pitti: And I choose to just pretend people like you don't exist. Terminals should be black. ;) [07:15] pitti: (But as I noted when the change was being discussed, it shouldn't be hard to make vim smart enough to actually detect the bg hue and DTRT... termcap makes that available) [07:15] yeah, and many centuries of experience in book printing just got it all wrong [07:15] pitti: So, yeah, someone really should do that. [07:15] infinity: indeed I actually thought that vim did that already [07:15] until it got that explicit default [07:15] pitti: You'd think, but apparently not. :/ [07:15] pitti: No, before that default change, I was getting your "light" colours in my black terminals. [07:16] pitti: It would be stellar if someone sorted out making it smart. [07:16] pitti, ok linux-meta is building ... [07:16] (And maybe the smart is already there and the Debian package just fails to turn it on or something silly?) === tkamppeter_ is now known as tkamppeter [07:20] pitti: meta-armadaxp uploaded mit fixen. [07:20] infinity: cheers! [07:24] ScottK: ~email to u-devel -- I see priority: required on apt-cache show libncurses5, which is the same as dpkg... [07:24] YokoZar: dpkg is Essential: yes [07:25] micahg: Ahh I see my source of confusion. I'm not talking about the essential field then, I'm talking about the priority field. Is it not the case that all priority: required packages are installed on a system? [07:25] (of the system native arch, that is) [07:25] YokoZar: no [07:25] only Essential: yes [07:26] so, uh, what's the point? [07:27] The point of the Priority: Required category, rather [07:27] YokoZar: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies [07:28] YokoZar: they're generall installed, but you can't depend on them being there unless they're Essential: yes or (usually transitively Essential: yes) [07:35] micahg: See, I was confused by http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities which seems to indicate that removing a required package is something that can totally break things (dpkg included), and (perhaps wrongly) interpreted that as being safe to assume they're there [07:37] YokoZar: they usually are, also, I'm curious why ${shlibs:Depends} isn't adding the dependency for you [07:38] micahg: I was wondering that myself. It seems Wine likes to dlopen libraries at runtime and fail gracefully if they're not there by disabling components [07:38] Which makes me think I have potentially a lot of missing dependencies that are only now coming out. [07:39] well, normally that's called friendly :) [07:39] meh, if the program quits on startup because it can't dlopen a particular library, it might as well be flat out linked against it [07:39] (as was the case with libncurses) [07:39] yes, I'd suggest that's an upstream bug then [07:41] pitti, how often does the problems page update? hopefully everything is published [07:55] good morning [08:09] apw: every half an hour after the publisher [08:10] pitti, with luck things should be good by :30 then === smb` is now known as smb === webjadmin is now known as JackyAlcine_ === webjadmin is now known as jalcine [08:48] I have a suggestion for a keyboard layout, where should I send it? [08:48] (it's a modification on the Spanish layout; it adds n- and m-dash, 1/4 and 3/4 fractions, and dead caron) [08:50] I made an xkb file for it; I don't have it here but it's on my PC at home [08:51] (now it's when someone will tell me that xkb isn't used anymore or something like that...) [08:51] cousteau`uni: Upstream is a good place for that - bugzilla.freedesktop.org. [08:51] ok [08:55] Ok, I think I have an account on that site; however I forgot the user and password. Any clue? [08:55] (i.e. user is a name or an e-mail address? and were there any restrictions on the password?) [08:55] email address, no restrictions. [08:55] Reset? [08:56] jalcine: would need the user for that [08:56] RAOF: ok [08:57] I'm starting to think I don't have an account there... === doko_ is now known as doko [09:24] is there a master bug for '..foo/changelog.Debian.gz is different from the same file on the system' install errors? [09:27] tjaalton: idk, there's Bug #871083 [09:27] Launchpad bug 871083 in libtasn1-3 (Ubuntu Precise) "gzip -9n sometimes generates a different output file on different architectures" [Medium,Triaged] https://launchpad.net/bugs/871083 [09:29] micahg: thanks, would that mean a rebuild of the affected packages is needed? [09:29] tjaalton: I think so [09:30] alrighty [09:32] dholbach: did you get an FFe for mdbtools, looks like it needed one [09:32] micahg, really? why? [09:33] * Added support for REPID (UUID) fields. Thanks Will Daniels from Ubuntu. [09:33] hmm, though looks like this time the fault was in not having a i386 version update available and the amd64 update failed with that error [09:35] micahg, it's a small patch which makes the exported data a bit more useful by adding another piece of data [09:35] micahg, I didn't read that as a new feature [09:36] well, IANA release team member, maybe one can chime in :) [09:36] sure you can :) [09:37] dholbach: loved your post about the Ubuntu weekend :) [09:37] micahg, but in general the update looked like a good idea, as it fixed a crash and it was requested by the debian maintainer who seems to have a look over things, so I felt additionally encouraged :) [09:37] jalcine, thanks a lot [09:38] jalcine, I'm going to write a summary of the activity in a bit [09:38] dholbach: oh, I agree it was a good idea, just thought it needed an FFe, that's all :) [09:38] jalcine, and I'm already looking forward to the next Friday :) [09:38] Same here! [09:38] micahg, thanks a bunch for keeping an eye on things :) [09:42] cjwatson, would we expect an external esata connected drive to be handled sensibly ? ie mounted when connected etc? [09:43] don't see why not [09:44] cjwatson, it seems to behave like its an internal drive, it detects it ok as it appears etc, but i have to open 'disk utility' and hit mount to get it moutned [09:45] I tend to prefer them to behave like internal ones. [09:45] But I'm not sure what the "normal usecase" is. [09:46] i thought you couldn't tell from udev whether or not a sata drive was esata or internal [09:46] infinity, yeah not clear cut, but i'd say that could apply to any external drive [09:46] so udisks treats them all as internal [09:46] . [09:46] oops [09:47] broder, then our handling of new internal drives is also poor, as i added this 'internal drive' and there is no interface i can find to make it mount by default [09:47] yeah i can edit /etc/fstab cause i is smart, but ... [09:47] Well, and I use eSATA drives as "normal system" drives. I'm not sure I'd want to deal with the strange races involved in, say, my system trying to simultaenously mount it on my desktop and rebuild a raid array from the cold-swap. [09:48] infinity, indeed, but i have wanted that in that past with USB drives, an option to say "this is a key drive, the world is over without it" seems reasonable either way [09:58] pitti, ahhh frothy beer [09:59] woah [09:59] ogra@horus:~$ mkdir bin [09:59] ogra@horus:~$ cp /bin/ls bin/foo [09:59] ogra@horus:~$ foo [09:59] Segmentation fault [09:59] evil [10:00] ogra_, arm ? [10:01] apw, yes, works fine if i re-loagin to do a "sudo -i -u ogra" [10:01] *login [10:01] ogra_, worked for me not on arm [10:02] did you have ~/bin in your PATH already ? [10:02] it only happens for me if it isnt in PATH and i newly create the dir without re-login [10:04] nope bin not in my path [10:05] * ogra_ will try on armhf to verify it happens there too [10:05] still running el here [10:31] is this the right place to discuss kernel issues with the latest beta? [10:31] try #ubuntu-kernel [10:32] cheers. === jodh` is now known as jodh [11:01] * micahg wonders if anyone's interested in processing a round of removals [11:06] stgraber: Have you seen, bug 946754? [11:06] Launchpad bug 946754 in dnsmasq (Ubuntu) "dnsmasq does not respect/watch '/etc/hosts' updates" [Undecided,New] https://launchpad.net/bugs/946754 [11:54] could somebody have a look at https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 [11:54] Launchpad bug 776264 in cryptsetup (Ubuntu) "Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,New] [12:01] dupondje: have you checked if any packages depending libcryptsetup1 build with the new libcryptsetup-dev? as there was a API change [12:10] dupondje: you should subscribe ubuntu-release to the bug, it needs a FFe === _salem is now known as salem_ === sunwc_ is now known as sunwc === MacSlow is now known as MacSlow|lunch === dholbach_ is now known as dholbach === MacSlow|lunch is now known as MacSlow === kenvandine is now known as ken[out] [14:28] Daviey: the latest NetworkManager upload actually turned off /etc/hosts parsing entirely giving that job back to the libc/nss [14:39] jelmer, mvo: mhall119 and I ran into a small problem with UDD work-flows - basically it was just about this use-case: branch ubuntu:geany, use edit-patch to change a .desktop file - the resulting diff is HUGE because of applied quilt patches [14:39] do you think we should add a quilt pop -af; bzr commit -m "unapply quilt patches" step somewhere? [14:39] and where might be a good place for this? [14:39] it's certainly confusing contributors and reviewers alike [14:41] dholbach, that commit idea seems a workaround, it mean you couldn't bzr merge without getting that "buggy commit" in the middle [14:42] seb128, yes it is a workaround [14:42] but it makes things a bit less confusing [14:42] seb128: right now, making a 1-line change to geany.desktop.in results in a 4745 line diff [14:45] mhall119, dholbach: I'm not saying "right now" is not buggy ;-) [14:46] yeah, it'd be nice to get some advice on what might be a good way of solving it or in the meantime workaround it, so we can let new contributors know what to do [14:46] * seb128 puts debian dir only desktop vcs use [14:46] ups, "pets" [14:47] seb128: I'm going to try and get the quicklist and keywords contributors making proper patches, as requested, but I need an easy-to-follow process that "just works" [14:48] mhall119, yeah, anyway I'm not the one working on that, I was just doing a side comment so I'm stepping out [14:49] dholbach: it looks like edit-patch *should* be quilt pop'ing all the patches before it commits [14:49] mhall119, the question is: should it commit the unapplied patches into history? [14:50] so the question is, when there are applied patches on the branch, should they be unapplied in a separate revision from the actual change, or as part of the same revision [14:50] :) [14:50] not so much "if" as "when" [14:50] absolutely not in a separate revision [14:50] cjwatson: why? [14:50] because each revision should be self-contained [14:50] if there are applied patches on the branch, then you should leave the branch that way [14:50] if there are unapplied patches on the branch, then you should leave the branch that way [14:51] cjwatson: ok, but edit-patch unapplies all patches [14:51] edit-patch shouldn't be changing the branch handling policy [14:51] so should edit-patch not be used? [14:51] surely it should be fixed [14:53] so that's a bug in edit-patch? If so, I'll file a bug report [14:54] sounds like it; it should try as hard as possible to leave stuff the way it found it ... === yofel_ is now known as yofel === cmagina_ is now known as cmagina [14:56] ogra_, were you going to upload https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618? [14:58] cjwatson: filed bug #947180 [14:58] Launchpad bug 947180 in devscripts (Ubuntu) "edit-patch should not unapply quilt patches" [Undecided,New] https://launchpad.net/bugs/947180 [14:59] dholbach, see -changes, already done [14:59] aha [14:59] (it needed some changes, i didnt bother to ask GrueMaster to change it again but made them on the go) [15:00] ogra_, should it be marked as merged then? [15:01] hey thanks dholbach ! [15:01] ogra_, or maybe rejected as it wasn't merged as is [15:01] dholbach, oh, indeed, will do, thanks for the pointer [15:02] (not intended to be completely random, but was just too excited) [15:03] ogra_, it's possible you can't reject it yourself, but somebody else in here should be able to do it [15:04] i dont want to reject it ... but mark it merged with the comment that i dropped a misaligned chnage from a former iteration [15:04] and i think i can mark it as i used to own the branch it wants to be merged in (at least in the past) [15:07] or did you file one already? [15:08] oops :) [15:18] can somebody reject https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618 please? (fixed in a different way) [15:19] I think ogra_ has to do it. === dendro-afk is now known as dendrobates [15:21] Question about packaging, if I wanted to say that package B is an upgrade for B but also obsoletes package A just adding in the control file Replaces: A would be enough? [15:23] dholbach, so why the heck do i have to do all this crap, it now took me 20min of paperwork for a less than 5 min package fix (incl. upload)... i though UDD would nowadays just take care of it [15:23] lynxman: if it replaces some of the files in A, but not the entire package. If it entirely supercedes it, you need both Replaces and Breaks. [15:24] ogra_, I guess if it's fixed in a different way, the machinery can't figure out which fix it originally was and how it was applied [15:24] ScottK: it entirely supercedes, so Replaces and Breaks then? [15:24] ogra_, I don't know all the internals [15:24] Yes. [15:24] well, why cant i just mark it merged with a comment that a part of the merge was omitted [15:24] ScottK: cool, thank you :) [15:25] You're welcome. [15:25] ogra_, I'm sure there's a bug open about it - I don't know - I mostly just asked in here and somebody with more powers in LP did it for me [15:26] ah, seems i can, i just tried it with the wrong button [15:27] aha! [15:27] * ogra_ was expecting it in the review pulldown at the bottom [15:40] dpm: hey there, any idea when I can expect a go/no-go from the translations team on bug 926493? [15:40] Launchpad bug 926493 in ubiquity (Ubuntu) "[UIFe] The installer still says your picture will be used on the login screen" [Low,Triaged] https://launchpad.net/bugs/926493 [15:41] * dpm looks [15:44] when running 'quilt' commands, should I be in the ./debian/ directory, or in ./? [15:44] in ./ it thinks everything is applied but can't find a series file, in ./debian/ it thinks none are applied but it sees the series [15:45] mhall119: do you have a ~/.quiltrc file? [15:45] you should not be in the debian/ directory [15:45] mhall119: sounds like QUILT_PATCHES isn't set [15:45] cyphermox: no [15:45] stgraber, +1'd it with a suggestion [15:45] http://paste.ubuntu.com/870039/ <- my .quiltrc [15:46] (though 'export QUILT_PATCHES=debian/patches' is sufficient for a one-off) [15:48] ok, that got it working [15:48] it that needed for edit-patch to run? [15:49] dpm: any suggestion on who to poke to get a nice proper english sentence that sounds right? :) [15:49] ah, nvm, I see it's being set in edit-patch [15:49] stgraber, try with mattprice [15:51] ogra_: dholbach, what was wrong with my patch (other than maybe no changelog entry (which I thought was autogenerated)). [15:51] GrueMaster, I was just wondering why it was still on the list [15:51] I had no specific comment about the patch itself [15:51] can somebody please reject https://code.launchpad.net/~nik90/ubuntu/precise/software-center/add_quicklist/+merge/94178 from the list? [15:51] err, reject the MP :) [15:52] dpm: ok, poked him [15:52] I pushed it Friday, and ogra said he would pull it in today. [15:52] dpm: thanks [15:52] stgraber, no worries ;) [15:52] stgraber: I prefer the proposed string with s/some/certain/ [15:53] GrueMaster, likely a problem in the machinery - it didn't get the memo [15:53] ah. === ken[out] is now known as kenvandine [16:13] mvo: dholbach: cjwatson: https://code.launchpad.net/~mhall119/devscripts/fixes-947180/+merge/95929 [16:14] that should fix the problem I was having [16:15] mhall119: in a call right now, but from looking at it for 3s it looks fine [16:17] GrueMaster, your patch had changes in the mx5/imx51 section that were bogus, i just omitted them and merged the rest (as i said in the merge comment on LP) [16:19] Oh. Actually, they weren't bogus as they actually fixed a potential problem I noticed when editing the code, but I can easily re-add them and push them. I had just forgotten about them when I made the initial no-mtd fix. [16:19] they wre between two case statements [16:19] that would have choked heavily :) [16:21] i thought it was just an accidential paste, the code surely didnt belong where it was [16:21] slangasek: hmmm, don't suppose gconf 3.2.3-2 will make precise? it had some multi-arch fixes [16:21] Looking at my actual code, it looks like somehow the ;; got pasted in at the beginning of the if statement. Not sure how that happened. [16:22] right, thats what gave me the impression there was something wrong with the first bit of the patch [16:22] but since i had promised you i would merge it asap i took the working part of it :) [16:23] Ok. Well, it isn't critical, but it does fix a potential issue of no-mtd on Freescale platforms. I'll fix and repush. [16:23] Or push as separate I should say. [16:24] just give me a pastebin with the patch and i'll upload immediately === Ursinha is now known as Ursinha-lunch [16:32] is there a command which will grab bug info from launchpad? [16:33] hrw, there should be [16:33] don't know if there is though [16:34] someone could surely whip one up in launchpadlib in a few moments [16:43] seb128: updated https://code.launchpad.net/~mhall119/ubuntu/precise/geany/add_keywords/+merge/94825 after fixing edit-patch, does it look good now? [16:44] mhall119, if you actually file the "## Description: add some description" "## Origin/Author: add some origin or author" "## Bug: bug URL" yes [16:45] mhall119, that and lp: #.... in the changelog so the bug gets closed on upload [16:46] seb128: ah, didn't know I had to further edit the patches [16:46] mhall119, well it's clearly written ;-) [16:47] seb128: written where? edit-patch made it and committed it for me without prompting me to change those parts [16:47] mhall119, at the top of the patches [16:47] mhall119, hum, edit-patch shouldn't commit for you... [16:47] it should create the patch so you can bzr diff [16:47] review your change [16:47] edit if needed, then commit [16:49] seb128: (LP: 942154) or (Closes: 942154) [16:49] mhall119, lp: #nnnn [16:50] pushing changes [16:52] mhall119: (Closes: #nnnnnn) is for Debian. === Ursinha-lunch is now known as Ursinha [17:02] brendand: lptools pkg, wget -O /tmp/${bug}.txt https://bugs.launchpad.net/bugs/$bug/%2Btext, http://people.canonical.com/~jhunt/scripts/lp-show-bug.py (caveat - hideous code). [17:03] jodh, would be nice to have something in universe that does it [17:21] Will precise-backports open early this cycle? [17:22] * ScottK doesn't think the tech board has approved it yet and there are some LP changes needed in any case. [17:22] broder: ^^^? [17:22] pretty sure they did approve it, but at any rate the implementation isn't ready AFAIK [17:22] not sure what the blockers are though [17:23] at least n+1 initialisation [17:23] Ah ok [17:23] Since we're being conservative and not shipping PHP 5.4.0 , I want to get it into precise-backports early. [17:24] We've never had a PHP version in backports, but in this case, I think its going to be key given the unfortunate timing of their release. [17:30] SpamapS: it will require a install/run test of all the reverse dependencies [17:31] micahg: I think its time we re-evaluate what "test" means. :) [17:32] test already is the loosest it can be === deryck is now known as deryck[lunch] [17:32] SpamapS: and PHP being what it is, I think we'd have to ask for some type of commitment to keep the backport updated for security patches [17:33] Yeah, I don't like the idea of shipping a backport that we think many/most people will end up installing. [17:33] At that point, it's worth re-examining the possibility of a freeze exception, with perhaps a loose "and make it 5.4.1 ASAFP". [17:34] infinity: would you argue instead for just shipping 5.4.0? I've closed that door a few times only to have a few people try and kick it down again. [17:34] Cause well all knw dot-zero from php.net is lollerskates pretty much every time. [17:34] SpamapS: Well, I really don't want to see 5.3.x not being used in favour of an unsupported backport. [17:34] infinity: the release process is light years different.. I think this one may be at least better. [17:34] SpamapS: And that's what's likely to happen in your scenario. [17:35] SpamapS: Unfortunately, many webapps will break horribly with the pass-by-reference changes. [17:35] infinity: 5.3.x is just as likely to be used by stubborn organizations. [17:35] SpamapS: Which is a non-issue for 3rd party stuff, but sucks for anything we ship. [17:35] 5.4 has a pass by reference change? [17:35] Uhm. Yeah. [17:35] I thought that was 5.3's big suckage [17:36] infinity: oh, that has been spitting E_WARNING since 5.3 was released 3 years ago. I have almost no sympathy for those people who ignored that change. [17:37] I think even 5.2 had it as an E_DEPRECATED [17:37] SpamapS: As long as nothing in the archive breaks, I don't care. 3rd party upstreams will fix their shit. [17:37] SpamapS: But yeah, with my release hat on, if our options are "split the userbase between 5.3.x and an unsupported 5.4.x backport" or "just effin' make 5.4.0 work", I'm for the latter. [17:38] infinity: Yeah, thats why we're not shipping 5.4.. because *ZERO* people stepped up to test anything in the archive. [17:38] SpamapS: That needs some commitment from the server team of making sure it kinda works. [17:38] SpamapS: And I care less about webapps here than making sure extensions DTRT, etc. Which should be trivial. [17:38] SpamapS: But some few "important" webapps we ship should be tested... [17:38] I believe I found only 2 php dependencies in main, and they both work fine w/ 5.4 [17:39] backports doesn't particularly care about the main/universe split :) [17:39] but the 107 other reverse deps .. no clue if they work [17:39] SpamapS: Putting it in the inverse, I'd be inclined to forbid 5.4.x backports if we ship 5.3.x. :P [17:39] SpamapS: So, given all those options, shipping 5.4.x seems the least nasty. [17:40] But *some* testing needs to be done. [17:40] Really. [17:40] At this point in the game, we can't guess. [17:40] infinity: so, if we went the 5.4.0 route.. we are ignoring the fact that MANY users are only just now migrating to 5.3.x .. so *they* will be even less likely to upgrade to precise. [17:40] Or they'll go on some wonky unsupported 5.3.x package.. or upstream [17:40] I don't see that as an issue. New releases have new software. They'll learn to cope. [17:40] SpamapS: that means they skipped lucid as well or so it would seem [17:41] micahg: there are quite a few questions out there on the forums and askubuntu about how to run 5.2.x on lucid [17:41] And yes, lucid was 5.3.x [17:41] I really want to ship 5.4.0 [17:41] People running old releases are more rare than people wanting the new shiny. [17:41] Ondrej from the Debian PHP team suggested I should do it. [17:41] Hi all! [17:42] infinity: hrm.. not sure I agree with that from my experience w/ PHP. Its bass-ackwards from most of the other languages. [17:42] infinity: thats part of the reason the PHP devs adopted their new stricter release process.. because people were almost completely unable to upgrade due to the insanity of the past 5.1.x -> 5.2.x and 5.2.x -> 5.3.x [17:43] From my experience maintaining it in the past, there was always a small set of corporate holdouts that hated rewriting that stayed on old versions for "too long", and everyone else upgraded to CVS versions before they were even released. :P [17:43] But that was then. [17:44] I'm not sure how things work now, to be fair. [17:44] Every PHP meetup I go to is full of sad developers who are forced to stay on ridiculously old versions because they have no test suite and tens of thousands of lines of code. [17:44] Still, I think shipping a new language version in backports is the wrong answer to any of these questions. [17:44] I think we should kick them in the shins w/ 5.4 actually [17:44] lucid is still supported for 3 more years if people need 5.3 [17:44] And heck, hardy is supported for another year, if they need 5.2 [17:45] ok, since this issue has been raised from the dead I think 5 times now.. it warrants a re-evaluation of my priorities. [17:47] To be honest, I'd like to go back in time and spend a couple of weeks on evaluating apache2.4 as well, but at least that one's not "necessary" for anyone, just nice-to-have. [17:47] SpamapS: well, that's why I'm shocked by the new PHP roadmap in general, things would seem to be moving too fast for most PHP devs [17:47] I wouldn't mind shipping 5.4.* in Precise, but breaking half the Universe package would be uncool, so some evaluation is needed. I also don't think I would forbid a backport on principle if there is a maintenance commitment (aside: we should extend tools like the CVE tracker to cover backports). [17:47] And, well, every bit of software has an "I wish it was newer" version. [17:47] Laney: If there was a maint commitment, sure, but I don't honestly see that happening. [17:48] Laney: I didn't say anything about forbidding on principle, that was infinity :) [17:48] I didn't say I was addressing you micahg :P [17:48] maybe I was with the CVE comment though ... [17:48] * Laney runs [17:48] Laney: oh, silly me with my backport highlight :) [17:48] backport backport backport [17:48] This could be fun. [17:49] backwards rolling releases ? [17:49] * Laney eyes the universe page on the CVE tracker [17:49] bad community [17:49] No biscuit? [17:50] Laney: people in glass houses :) [17:50] ... shouldn't walk around naked? [17:50] depends [17:50] ogras in glass houses shouldn't walk around naked? [17:51] Anyhow. Back to work with me. [17:51] SpamapS: Ping me and keep me in some sort of loop about whatever's going down. [17:51] SpamapS: As Laney says, a backport with a firm support commitment would probably be fine, but I don't see the security team agreeing to it, and I suspect your team doesn't want to maintain a precise backport for five years. [17:52] infinity: I'm going to put 5.4.0 in a PPA and make a call for testing.. and test whatever I can myself. [17:52] SpamapS: But. I could be wrong on the latter (I suspect I'm not wrong on the former) [17:52] the security team will not be supporting the backport :) [17:52] infinity: one thing thats going to suck is how many upstreams are not ready for it because it only came out 2 weeks ago. [17:52] Most of the "important" ones move pretty fast. [17:52] seb128: ping [17:52] * SpamapS is convinced the backport is a bad idea. [17:53] And, as you point out, the one really nasty change has been a deprecated/warning for years. [17:53] mhall119, hey [17:53]