=== TheMuso` is now known as TheMuso [03:03] was launchpad ever called "Malone"? [03:03] I found some old changelog entries that say "closed Malone: #xxxxx" and it's an LP bug # [03:04] mfisch: The Bugs component of Launchpad is Malone, but nowdays that's really only an internal name. [03:05] interesting, thanks === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine === jalcine is now known as jalcine_ [08:50] mfisch: I think that old name was my fault. (See "Bugsy Malone") [08:54] * ogra_ wasnt aware we still use it [08:55] See scrollback [08:55] It's in old changelogs [08:55] well, StevenK claims its an "internal name" :) [08:56] Well, yes, that too [08:56] But no reason you should be aware if you don't hack on LP :) [08:56] heh, indeed [09:25] Totally missed the release. %-/ [09:34] Hmm, the saucy release didn't obsolete any older release? [09:34] Was the lifetime of precise extended with respect to former releases? [09:35] oneiric was obsoleted by raring, why doesn't saucy obsolete precise … [09:36] 5 year LTS. [09:36] bleh [09:36] of course, totally overlooked the LTS part. [09:36] Unit193: Thanks for helping me think. :) [09:36] Sure. :) [09:40] Rhonda: according to https://wiki.ubuntu.com/Releases the next EOL are Jan 2014 (raring), April 2014 (quantal) and July 2014 (saucy) [09:46] geser: Right, that's the information I looked at. :) [09:46] Wait a moment. Is july 2014 for saucy really proper? [09:47] I would expect April 2015? [09:47] Normal releases are 9 months now. [09:48] Since saucy [09:48] Interesting. [09:52] Which leads to the oddity of raring EOLing before quantal === emma is now known as em [10:54] maxb: Ah, so since raring, indeed. === freeflying_away is now known as freeflying [13:16] cjohnston: thanks for that info. I was wondering if there was really a bug tracker called Malone but the bug number matched LP so a rename made sense [13:16] five digit bug # too [13:17] YM cjwatson [13:28] We need to prepare a saucy update for ejabberd. Current version in saucy is 2.1.10-5ubuntu1 [13:29] What version shall we choose? trusty-proposed has 2.1.11-1 [13:29] Ah, wait, it's stuck in trusty-proposed because it doesn't carry the -ubuntu changes *checking* [13:36] Rhonda: it still needs building on powerpc before it can transtion to trusty [13:37] So it would automatically transition to trusty? [13:37] I just checked, the ubuntu diff isn't needed anymore. [13:38] yes [13:39] it's like in unstable -> testing but without the waiting time and RC bug check [13:39] https://wiki.ubuntu.com/ProposedMigration for the rules [13:40] ejabberd will probably be fine, the powerpc builders are just a bit behind [13:42] Rhonda: I'd say the saucy SRU should be 2.1.10-5ubuntu1.1 (the usual SRU scheme) [13:42] geser: Thanks. :) [14:12] Good morning all, Is there anything I can do to help resolve bug 1243310 ? [14:12] bug 1243310 in saucy-backports "Please backport libaria 2.8.0 from trusty to saucy, raring, quantal and precise" [Undecided,New] https://launchpad.net/bugs/1243310 === elopio_ is now known as elopio === Vivek is now known as Guest6309 [17:09] Good afternoon all, Is there anything I can do to help resolve bug 1243310 ? [17:09] bug 1243310 in saucy-backports "Please backport libaria 2.8.0 from trusty to saucy, raring, quantal and precise" [Undecided,New] https://launchpad.net/bugs/1243310 [17:14] dereck: I or someone will get to it in the next few days [17:14] no need to remind :-) [17:49] Laney: Alright, I just wanted to make sure I was done with my end of the work. :) Thanks [18:42] Hey there! I'm a contributor to the Gambas(gambas.sf.net) project. I'm looking for a MOTU sponsor to update the gambas3-* packages avalable in the official repositories. Those where imported from debian, and although the maintainers where contacted, we received no response from them. [18:44] There is a PPA with the latest version, so the packages are already available. I'm looking at updating those older packages as they are broken and badly packaged. [18:46] How should i proceed? [18:47] sebikul, if it exists in Debian have Debian update the packages, then they can be synced to Trusty whenever debian syncs are opened, i think. [18:47] (I'm not MOTU, i'm just making an observation) [18:48] typically getting the package updated in Debian is best... not sure if MOTU will approve a delta from Debian for this package though. (since it's MOTU's call) [18:49] I know updating the debian packages is the best course of action, but we have already tried to contact them and received no response. We get a lot of bug reports from people using Ubuntu with these older packages, which are almost a year old and several milestones behind [18:49] At least as a temporary fix.... [18:50] sebikul, Where have you contacted debian guys? pkg-gambas-devel@lists.alioth.debian.org ? [18:50] TheLordOfTime, We have a fairly large diff already [18:52] Noskcaj, REALLY? [18:52] whoops caps [18:52] * TheLordOfTime looks at changelogs [18:52] well it's ubuntu8 [18:52] I didn't check the logs [18:52] So i don't think debian are too ctive [18:52] Noskcaj, ignoring the package delta, i was focusing on the major version [18:53] not the package revision thing [18:53] ok [18:53] either way, AIUI, the updated version would hit Trusty, and not the older releases, right? [18:55] We have contacted one of the mantainers directly, as he is a member of the gambas-users list. I'm not sure if someone else made contact with another maintainer. I will send an email now and wait for an answer, but i'm not expecting one [18:55] Since I have been working on something similar recently: The workflow is to land the latest code in debian -> merge/sync from debian to Trusty -> backport to previous versions of ubuntu if desired. [18:55] dereck, if desired / if possible. not all software cleanly backports [18:56] sebikul: you may be able to contact any debian maintainer and help keep the package up to date IIRC [18:56] you don't nessiarally need the original maintainer, although that's the best way. :) [18:56] TheLordOfTime: true dat. [18:58] (case in point, come next debian sync to trusty, nginx won't cleanly backport because build-deps) [18:58] Well that's great! Just to make sure; if packages are updated in debian unstable. Can they be backported to older Ubuntu releases? [18:58] oop lag, missed you saying "true dat" :) [18:58] sebikul, it can be requested [18:58] sebikul, if you ping me i'll take a look and see if it builds on older releases [18:58] as build-deps and such are sometimes a problem [18:59] (i'm not MOTU, but I volunteer my sbuild setup to test building) [18:59] from there, the backports procedures are relevant. [19:00] TheLordOfTime, That's great. Thanks a lot for your help. I will come here once everything is fixed on the Debian side, hopefully. Thanks again! [19:01] sebikul, i do suggest you read up on the backports process here though [19:01] because building is only part of the confirmation it'll work :P [19:02] i think that's all at this page... https://wiki.ubuntu.com/UbuntuBackports [19:02] but i dunno since my links were lost with my old system :/ [19:02] either way i'll volunteer to test-build the package. [19:05] TheLordOfTime: Thanks again ;) [19:07] yep [19:07] * TheLordOfTime goes to testbuild nginx builds before pushing them to the staging PPA for the nginx team [20:00] Noskcaj: don't go by the number alone. most of those revisions are rebuilds. [20:00] cjwatson, exactly the point i was making, a version delta outside of rebuilds/package patching might be more significant [20:01] yep [20:03] hence how we said "Fix it in Debina first" [20:03] Debian* [20:04] I entirely agree [20:04] just wanted to say that I had actually *looked* at most of those 8 Ubuntu uploads and the bulk were rebuilds [20:04] And then there are things like debian-installer, where some revs may be the exact same fix. So the date on the bin may not mean anything, and the current one may be close to the one in Ubuntu. Another reason to get it in Debian, you won't hold up auto-syncs that way. [20:05] I agree [20:09] speaking of autosyncs when's the next autosync with Debian for universe packages? [20:15] Heh, what I'm wondering is when cryptsetup can be sync'd. :P [20:15] i'm curious because i want to make sure the nginx 1.4.3 gets in from unstable, with its build-dep (although its build dep is sufficient for Saucy and later so far) [20:16] and unless i'm mistaken there's an autosync from Debian normally [20:17] TheLordOfTime: It won't technically autosync since it has the Ubuntu branding. [20:17] Unit193, ehhh, it should be synced and then a patch applied to reapply the branding, 1.4.3 > 1.4.1 [20:17] and honestly i think that delta solely for the Ubuntu branding isnt' needed... [20:18] somewhat good idea, yes. blocking for sync, not really. [20:18] Not automatically. [20:18] i don't know of any Ubuntu specific delta in that... :/ [20:18] ehhh, maybe i'll do what i normally do, post a sync request [20:29] TheLordOfTime: Err ... every six hours [20:29] TheLordOfTime: And nginx 1.4.3 is *already* in, manually merged by me [20:29] cjwatson, ah, i missed the merge information then. ^.^ [20:29] cjwatson, thanks for that btw :P [20:30] The Ubuntu branding shouldn't be dropped, but should be forwarded to Debian in such a way that it's applied conditionally [20:30] cjwatson, agreed, but Debian's maintainers don't really care about the Ubuntu branding, but if you want to give me details to give them i'll do that in the next bug i send their way [20:30] i.e. ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes)) [20:30] since i'll be on the debian BTS later [20:31] would need a bit of work to adjust NGINX_VER of course; you could look at what I do in openssh [20:31] (I don't care that much, the merge effort is trivial for me) [21:28] TheLordOfTime: autosync is running non-stop. [21:29] Unit193: cryptsetup needs manual merging, since we do it quite differently on ubuntu (the initramfs / boot steps) [21:29] He's stalking me. >_> [21:29] Yep, read the changelog. [21:29] Unit193, heh [21:30] xnox, cool, didn't know, although cjwatson manually merged it because of the ubuntu branding delta, apparently [21:34] xnox, out of curiosity, do you know if that "Backports can't build-depend on other backports" thing was fixed? Back in 10.* it was an issue for a few backports i requested... curious if it was ever resolved. [21:37] TheLordOfTime: find the bug report on launchpad and check. I think it was fixed. [21:37] but I don't usually do backports =) [21:37] xnox, true, but it was a general repo builder thing i think [21:38] TheLordOfTime: no, it was not. [21:38] TheLordOfTime: and when i say check launchpad I mean launchpad.net/launchpad bugs in launchpad itself =) [21:39] wait it was a launchpad specific bug? o.O [23:00] TheLordOfTime: That's https://bugs.launchpad.net/launchpad/+bug/888665; IIRC it winds up being closely related to upgrading launchpad-buildd to use a modern sbuild [23:00] Ubuntu bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] [23:05] cjwatson, looks like that bug was deescalated in favor of another bug... [23:06] That's fairly irrelevant [23:06] but was this fixed was the question [23:06] You can tell it wasn't because the bug is still open [23:06] (doesn't look it) [23:07] Escalation was for back when Launchpad had ~25 developers rather than ~2 [23:07] heh [23:07] That said, we've been getting a fair bit of buildd work done of late, and that one is relatively high on the list [23:08] If only because running with a nine-year-old sbuild fork is boring [23:08] so, fixed in the relatively near future? [23:08] Can't promise but I still hope so [23:08] i hope so too, this one person emailed me asking if nginx is easily backportable and it's not because 888665 [23:08] (has another runtime and build-dep dependency that needs to be backported) [23:08] only place older releases can have newest nginx is in the nginx team PPAs :/ [23:08] newest stable*