[00:00] gotto sleep, thx for the help crimsun [00:01] jmarsden: there? [00:02] ok if the builder says dependency wait on some-dev file,is problem at my end? [00:02] oh its accepted :) thx :D [00:03] any ideas? [00:03] shadeslayer: which source package? [00:03] shadeslayer: depends on the case ;) ... if you are wondering about this, it probably means the problem is on your end, yes. [00:03] shadeslayer: That depends on whether some-dev is meant to be available in the archive. [00:04] https://launchpad.net/~rohangarg/+archive/kde-extra/+packages << choqok karmic package [00:05] i just sent it for a rebuild about 2 mins ago [00:05] That doesn't look like it's in dep-wait? [00:05] It's built successfully on lpia. [00:06] RAOF: yeah but for amd 64 it said dep-wait on libqt4-dev [00:06] RAOF: and btw are PPA archives expanded on requests? [00:07] it doesn't say anything of that sort for the amd64 karmic build [00:07] crimsun: yeah i sent it for a rebuild 2 mins ago [00:07] and what about : 1 failed [00:07] in completed builds [00:07] I think he might mean kopete-facebook? That's dep-wait for libqt4-dev, which has a versioned dependency against a version that's not in Karmic. [00:08] RAOF: had the same error for choqok too [00:08] RAOF: can you explain the error? [00:08] shadeslayer: Does it really require libqt4-dev >= 4.6.0~rc1? Because Karmic has 4.5.2 [00:08] RAOF: 4:4.6.0-1ubuntu3~karmic1~ppa1 [00:09] RAOF: in : 500 http://ppa.launchpad.net karmic/main Packages [00:09] RAOF: does this mean itll not build? or its just searching for that package? [00:09] shadeslayer: Yeah, but your PPA isn't building against that other random PPA; It's grabbing the libqt4-dev from the official archives, which have 4.5.2. [00:10] RAOF: so,will it build eventually? [00:10] No, it won't. [00:10] i.e., local repos have no bearing on repos available to your PPA [00:10] RAOF: ok so how do i get the required dep? [00:10] (could you imagine the chaos otherwise?) [00:10] If you add the PPA which contains 4.6.0 as a dependency of your PPA then it will build. [00:11] (And people who don't have that PPA in their sources.list won't be able to install your packages) [00:11] RAOF: where do i add this? im new to building stuff :P [00:11] RAOF: ok ill mention it in the PPA description [00:11] It's somewhere in the PPA setup page; I forget quite where. [00:12] ok [00:12] found it :) [00:21] and on what basis are PPA sizes increased? [02:05] Uploaders.gz, nice. [02:08] crimsun: hm? [02:08] ajmitch: just musing over bits from planet.debian, 'tis all [02:09] ah, I probably glanced at that post at some point [02:09] or the rss client has yet to catch up :) [02:11] now to convince wgrant to add it to soyuz... [02:18] * wgrant is home now. [02:19] wgrant: a nice quiet flight back? [02:23] ajmitch: The first was quite full, but the second not so much. [02:25] * ajmitch went along to the open day on saturday for a bit, which was sort of interesting [02:26] Wellington seems to like pouring during the weekends. [02:28] yeah, the weekend wasn't exactly useful for exploring wellington [02:29] We did wander around quite a bit on Saturday, while it wasn't raining. [02:30] ajmitch: Sort of useful? [02:30] for about 5 minutes then? [02:30] * StevenK had to leave the hotel at 4am for his flight [02:31] ajmitch: More like 5 hours. [02:31] * ajmitch is glad he had a 7pm flight yesterday [02:31] much easier to be awake then, and not have to stay up all night [02:31] * wgrant was on the wonderful 6am flight too. [02:33] now it's back to work, with a large pile of stuff to catch up on [02:38] ajmitch: Ditto. [02:38] wgrant: Ouch [02:47] StevenK: since you hassled me about not doing much ubuntu work, got anything in mind that I should look at? :) [02:55] ajmitch: FTBFS? :-) [02:56] ah, the rusty spoon option [02:57] speaking of which, why was libglade2.0-cil-dev demoted to universe? [02:57] some mono packages in main now FTBFS [02:58] even stranger, it only appears to have been demoted on i386? ... [02:58] Maybe an accept accident? [02:59] well, I haven't updated in a couple hours, so I could be outdated [02:59] ajmitch: If you want something simpler than FTBFS, NBS is always a good way to pass a few hours. [03:01] * ajmitch sees a lot of zope.* packages in depwait [03:01] That would be the python-van merge. [03:01] it requires a merge now? I'm seeing 1.3.0-3 on my lucid VM [03:02] * persia gets confused and looks again [03:02] * ajmitch doesn't know how often the autosync is still running [03:02] https://edge.launchpad.net/ubuntu/+source/van.pydeb claims it was updated 38 hours ago, but the zope.* packages already want something newer [03:03] Indeed, it needs a sync. I wonder how that worked, as it should have been caught in sid -> testing. [03:04] I won't bother filing sync bugs for those ones just yet [03:04] Somehow the zope stuff migrated 17th Jan, and python-van.pydeb not until Saturday. [03:05] odd [03:05] So probably just needs the archive-admin of the day to run a script (which shouldn't happen for many hours, given the identity of the AAotD, and their local timezone) [03:05] * ajmitch doesn't know the archive admin rotation [03:06] Indeed. Maybe it identifies some issue with sid->testing, because it's based on binary promotion, and doesn't guarantee buildability. [03:06] https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days [03:06] thanks [03:07] * ajmitch wonders if james_w is even back home yet [03:07] I lot of Zope stuff is in churn right now due to python2.4 removal in Debian. [03:07] I/A [03:07] NCommander: Are you up for some bootstrapping today? [03:07] crimsun: libglade2.0-cil-dev is new, and arch:all (as are the rest of the -cil-dev packages). We in the debian-cli team probably need to pay a bit more attention to what's happening in Lucid. [03:08] python-stdlib-extensions finally built on mips, so we should see python2.6 in Testing tomorrow. [03:08] RAOF: yeah, the rmadison output threw me [03:10] ScottK: so the binNMU list will get processed sometime soon in debian, and things will settle down? [03:10] * ajmitch has been following debian-python a bit [03:10] ajmitch: For a fairly wild definition of settle down, I imagine. [03:10] but not -release [03:11] I'm sure it'll be smooth & ponies will rejoice, etc [03:11] The binNMU list for dropping 2.4 was ~40 packages. The binNMU list for adding 2.6 is over 300. [03:21] * james_w is not here, but can run an auto-sync [03:22] james_w: sorry, wasn't meaning to wake you from your jetlag or holiday :) [03:22] no problem :- [03:22] ) [03:23] As long are you aren't breaking any of your rules about logging into the server holding the actual Ubuntu archive... [03:24] heh, I think that rule has to be based on local timezone, or it would be too confusing :-) [03:25] The one I was thinking of was based on blood alcohol content. [03:26] oh yeah, it's a little too early in the day for that to be a worry [03:26] if you're still in NZ, then surely it's not too early? [03:27] Somehow that says more about NZ than about the time of day [03:27] persia: true :) [03:27] It's always after 5PM somewhere. [03:30] Maybe I'm missing somewhere, but I don't think it's after 5PM Monday anywhere right now. [03:31] (should be about 16:45 furthest east) [03:31] * ScottK didn't specify a day. [03:31] persia: currently 17:15 in the chatham islands [03:31] ajmitch: I keep forgetting about them, and their special summer timezone. [03:33] most people would forget about them [03:33] Well, it's only in the summer that it matters. In the winter they have a more westerly timezone, and fall behind other places. [04:32] good morning :) [04:50] persia, of what? [04:50] fp-compiler on powerpc [04:52] NCommander: Essentially, it means stripping down the fpc source, building just fp-compiler, and then installing that result to be able to build fpc (which includes all the libraries). [04:52] persia, *cries* [04:52] persia, my PPC is semidead though :-/ [04:53] NCommander: I thought that bootstrapping had to be done on the buildds. If I give you some signed .debs, would that work? [04:55] persia, I can give lamont done debs, then he does a rebuild, but I can't do binary uploads [04:55] unless I have powers of which I'm thus unaware of [04:55] NCommander: Ah. I picked on you because you're listed as in the assigned team for the bug :) [04:56] But if you could pass on bug #67544 that would be lovely. I'm happy to generate a .deb if it helps, but I'm not convinced the buildds *should* trust me. [04:56] Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544 [05:15] * james_w would like to remind everyone that we are still in the autosync time, and so don't need bug reports for syncs of unmodified packages [05:17] oh, I see what's going on [05:18] unstable? [05:18] yeah [05:19] While it's tempting to call it impatience, I know that we've seen a few things that FTBFS or DEPWAIT because sid->testing doesn't seem to check build-deps. [05:25] I'm happy that it now takes longer for the automated parts of sync processing than the manual parts though [05:26] \o/ [05:26] * StevenK fixed that bit [05:29] Adding several "sleep 300" calls to the automated part? [05:30] persia: No, I wrote a script that automated large parts of the manual syncs [05:30] Oh, cool. [05:31] persia: Which james_w fixed to be even cooler [05:32] So, last I remember one just fed a bug number, and it did stuff. Does it now automatically grab the bugs from LP rather than requiring one to type the numbers? [05:33] persia: That's the first script. I wrote a script that grabbed the bugs from LP and spat out lines suitable to be fed to the first script. [05:34] And it somehow detects when they are requests from unstable/experimental/testing? [05:34] * persia remembers pain on this point previously [05:34] No, you can switch it, and it changes the output [05:35] Oh, so the script only pulls bugs from LP that match some specific debian pocket? [05:35] persia: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/sync-helper.py [05:36] am i allowed to call apt-get source within debian/rules? [05:36] hyperair: No [05:36] =( [05:36] hmm this makes it a tad bit harder.. [05:36] hyperair: Well, explain why you want to? [05:36] Um, why not? It should be fine as long as something has been arranged so it doesn't need network access. [05:36] StevenK: i'm working on packaging poppler-sharp [05:37] StevenK: poppler-sharp generates bindings based on the poppler code. [05:37] persia: You can't expect that it has on the buildds, for example [05:37] That's what build-dependencies are for :) [05:38] StevenK: i'm thinking it might be nice to use apt-get source to get the most current poppler source code so rebuilds are easy if poppler gets updated. [05:38] But the better way to solve it is to either build-dep on some poppler binary (generating a poppler-source binary is the least good way: doing it from header analysis probably easiest). [05:38] header analysis? [05:38] OR to have poppler-sharp be a patch against the poppler source and build as part of that. [05:39] hmm [05:39] that's an interesting idea. [05:39] i hadn't thought of that [05:39] Sure. Presumably poppler exports some headers so stuff can build against it's C API. Those should describe everything you need for bindings. [05:39] good point, i'll try looking into that [05:39] Investigating the other code is just asking to end up exposing a private interface that changes without warning. [05:39] what does gapi2-parser look at? [05:40] The headers. [05:40] alright. i'll see if i can force it to make do without the source then [05:41] StevenK: That is nifty. I can think of ways to abuse it ("Please never, never sync this"), but it must save heaps of time. [05:41] persia: The script has a "Skip" for that [05:41] hyperair: Actually, poppler-sharp does that analysis at build-time? [05:42] RAOF: yes [05:42] http://github.com/jacintos/poppler-sharp [05:42] there isn't a tarball release [05:42] StevenK: That's not what I'm talking about (although, yet), but I'm not going into details here (plus I'll stop distracting you). [05:43] hyperair: Ah. Generally, gapi users ship the pre-extracted raw symbols; that's how gtk#, gnome#, etc do it. [05:43] i see. [05:44] RAOF: should i convince the author to do that, or generate a tarball with pre-extracted raw symbols? [05:44] It's entirely possible that you want to generate the raw xml as a part of constructing the original tarball, given that you'll need to generate the tarball anyway. [05:45] Heh. Too slow. Yes, I'd generate the raw xml and shove it in the original tarball. Convincing upstream to ship the raw xml is probably a good idea, too. [05:45] Um... they already *do* [05:45] http://github.com/jacintos/poppler-sharp/blob/master/poppler-sharp/poppler-api.raw [05:46] I don't think you actually need to have the poppler source available at build time. [05:46] RAOF: oh yeah, you're right! [05:46] * hyperair facepalms [05:47] i was reading too much into the README [05:48] You may need to do steps (2) & (3) when generating the tarball, depending on how rapidly poppler's API changes. [05:49] hmm [06:49] good morning [06:55] dholbach: mornin [06:55] hi shadeslayer [08:15] hm, how long does it usually take before a package is synced from debian to ubuntu? Or is this something I need to file a bug for? :) [08:18] dholbach: whats : https://wiki.ubuntu.com/MeetingLogs/devweek1001/AdoptUpstream [08:19] shadeslayer: Jorge and I will talk about https://wiki.ubuntu.com/Upstream/Adopt [08:19] brb [08:20] ok [08:26] runasand: if the package is in testing and Ubuntu version has no Ubuntu-specific changes, it usually takes 1-2 days [08:26] randomaction: ok, thanks :) [09:02] how long does it take to be a MOTU? [09:03] *become a [09:16] shadeslayer: There's no time rule, but there is a typical expectation of having been involved in Ubuntu Development for a complete development cycle (although there have been exceptions). [09:35] I personally like the question "how long until I can start contributing?" better :-) [09:38] But that has the simple answer "No time at all, you can do it today" :) Plus, shadeslayer was already working on the kopete-facebook update and backport [09:38] (and maybe other stuff I didn't see) [11:50] mok0: could i bother you with bug #511375? =) [11:50] Launchpad bug 511375 in codelite "codelite high cpu usage from ubuntu package" [Undecided,Confirmed] https://launchpad.net/bugs/511375 [12:03] hyperair: 2 secs [12:20] hi there, i was looking to merge gstreamer0.10-plugins-bad from debian unstable but the lv2 plugin fails all its tests. is it better to leave it in even though its probably broken or disable it? http://paste.ubuntu.com/362562/ [12:21] SevenMachines: You may have identified why it FTBFS on all arches (see http://qa.ubuntuwire.com/ftbfs/) [12:22] Does lv2 work even though it fails the tests? Maybe we need newer lv2 libs? [12:22] ScottL: Do you know anything about gstreamer & LV2 ? [12:24] i fixed the FTBFS with 0.10.17-1ubuntu2 but it was recommended to merge with sid since it essentially contains the same patches but also fixes a crash they introduce [12:26] ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549189. i guess it shopuld be disabled then [12:26] Debian bug 549189 in gstreamer0.10-plugins-bad "gstreamer0.10-plugins-bad: Crashes every gstreamer-aware app" [Critical,Fixed] [12:28] heh. So if you merge 0.10.14-4, you disable with no crash :) [12:29] And if ScottL (or someone) can figure it out, it can be re-enabled (I pick on ScottL because I know he was working on lv2 stuff) [12:30] 0.10.14-4 isnt even in sid yet for whatever reason, 0.10.14-3 with lv2 disabled should be ok though? [12:31] Erm, we've both missed something critical :) [12:31] 0.10.14-4 << 0.10.17-3 [12:31] :) [12:32] i'll give it a test with lv2 enabled and see what happens, i'll probably disable it though unless someone who knows about these things thinks different [12:33] Really, I think you need to connect with ScottL, if you can. [12:33] There may be someone else, but that's the name that shows up with LV2 the most in my logs. [12:33] You might need a newer LV2 or something, but I'm not sure. [12:36] Hi , I Have A Lot Of Deb Files And I Have Created Packages.gz file now i want to create Release File What Should I do ? [12:36] Capitalise less? [12:36] Aside from that, apt-ftparchive is a quick'n'dirty way to do things. [12:37] hyperair: you need sponsorship I guess... [12:37] mok0: yeah i do. [12:37] persia : could you plarese help me what should i exactly Enter . i am a beginner [12:38] hyperair: great, I'll take a look after lunch [12:38] thanks =) [12:38] MohammadRRR: I don't remember precisely. `man apt-ftparchive` may be useful. You may also want to try the support channel (#ubuntu) [12:39] persia : First i have gone there but they said I sould come here . i have read the manual but i have not learn anything please help [12:41] Hrm. Well, I don't remember precisely, so I'm not the best person. We don't generally create archives here (we use Soyuz), but maybe someone else can help you. [12:42] MohammadRRR: usually the tools create the Packages.gz etc files [12:53] looks like libgstlv2 really does segfault gstreamer, its not just failing tests [12:54] Can you get a stacktrace? Is it just unsafe coding and easy to fix? [12:54] persia: hey [12:55] shadeslayer: Hey. [12:55] persia: ive built packages for lucid and need sponsors for updating the packages there... where do i find motu sponsors? [12:55] persia: file a bug in launchpad? [12:55] !sponsorship [12:55] !sponsor [12:55] Grr. [12:55] https://wiki.ubuntu.com/SponsorshipProcess [12:56] Right. [12:56] yeah as it says.. file a bug,against what? [12:57] shadeslayer: The package that has the "problem" [12:58] persia: ah ok [12:58] was reading https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue [12:58] persia: do i give them a link to my PPA too where the package is being held? [12:58] or do i attach the files.. [12:59] I usually prefer a debdiff against the current source, or an attached diff.gz for an update. [12:59] hmm [13:01] persia: i'll try and get a trace, i can see why debian never actually put it in the .install though, although they do build it [13:01] SevenMachines: If you install pkg-create-dbgsym in your local builder, it gives you ddebs, which can be handy for that. [13:02] Do you know how to track down the crash once you get the trace? [13:02] probably not [13:03] Well, if you can get a trace (with symbols) within the next hour, ask me, and I'll debug it with you. [13:03] * geser sees persia giving an ad-hoc "Interpreting stack trace" session :) [13:03] If it takes longer, ask here and maybe someone else will. [13:03] geser: That's the way I prefer them, really. Nobody asks enough questions in formal sessions. [13:04] yes, it's often easier to learn from own cases (you're more interested) [13:05] i've seen enough stack traces in my own c++ stuff but i know literally nothing about gstreamer [13:06] Doesn't matter. Code is code. I remember foolishly picking an ObjC crash for a session once, and it ended up that the attendees (largely geser, IIRC) helped me understand it :) [13:06] At the final stage, when you find the problem function, then you need to know, but at that point the entire framework doesn't much matter anyway. [13:25] hyperair: "patch unexpectedly ends in middle of line" [13:25] huh? [13:25] O_o [13:25] how are you getting that? [13:26] hyperair: patch -p1 < ../codelite-debdiff [13:26] weird.. [13:26] hyperair: it successfully patched 3 files [13:27] hyperair: "Hunk #3 succeeded at 40 with fuzz 1." [13:28] hmm [13:28] maybe the uploaded package to the archive does not match my local git tree [13:28] hyperair: I'm concerned that debian/patches/03_move-helper-binaries.patch might be screwed up [13:28] it was screwed up [13:28] that's the cause of the bug. [13:28] hyperair: can you send me the proper one? [13:29] http://paste.ubuntu.com/362595/ [13:29] gimme a moment to dget codelite [13:35] mok0: the patch uploaded seems to be screwed up for some reason or other. weird. [13:36] hyperair: I think it's a missing newline at the end [13:36] http://paste.ubuntu.com/362600/ [13:36] use this instead [13:36] i generated it the same way [13:36] i'm thinking something happened while i was uploading the attachment [13:36] hyperair: ok [13:37] yeah it seems to be missing a newline. [13:37] * mok0 tries again [13:37] weird. i wonder if thunderbird's whacking up my patches.. [13:39] hyperair: patch works now w/o problems [13:40] mok0: that's good =) [13:40] hyperair: doing a test build now... [13:40] that can take a while, depending on the machine =p [13:41] hyperair: I know, I've compiled codelite several times :-) [13:41] figures =p [13:41] hyperair: my machine is pretty fast though [13:41] that's good [13:41] * hyperair uses ccache to compensate [13:41] hyperair: it's a quad6600 [13:41] that is fast [13:41] i had to undervolt my CPU to get codelite to testbuild on my notebook [13:42] there are only two compilations that can drive my CPU that mad -- codelite, and the kernel. [13:42] hyperair: I've had it a couple of years now, I'm still very happy with it [13:42] heheh [13:42] * hyperair still runs a dual core.. [13:43] the q6600 was the best price/performance cpu you could buy for a long whle [13:43] Haven't checked TomsHardware for a while now [13:43] hmm [13:43] * hyperair didn't go shopping for desktops [13:44] live in a dorm overseas, can't drag that many things along with me [13:45] hyperair: you don't have to. Have you ever heard about something called "Internet" :-D [13:45] mok0: mm yeah. it's a very familiar sounding word. i wonder what it was again.. [13:45] =p [13:45] :) [13:45] my desktop's still going strong [13:45] my single-core P4 [13:45] ;-) [13:46] hyperair: nice and CO2-friendly [13:46] well everything about it except the CMOS battery holder which doesn't seem to want to connect my CMOS battery to the motherboard (so when it's unplugged, the clock resets), and the stupid nvidia GPU flickering away.. [13:46] CO2-friendly? [13:47] but i'm sure the nvidia GPU flickering is a fault of the stupid legacy driver. [13:47] persia: uhm, older CPUs tend to use a lot less energy [13:47] mok0: do they? [13:47] Yeah [13:47] mok0: iirc multicores use less.. [13:48] because they can run at lower frequencies, yada yada [13:48] It really depends on the CPU. [13:48] oh it doesn't help that acpi-cpufreq conveniently removed support for my CPU. [13:48] I thought P4s weren't so good on energy consumption [13:48] hyperair: yes that's true. Hmm, I guess you have to go back to P3's to get a lot lower power consumption [13:48] * persia has single-cores that run <1W and multicores that run >70W and vice-versa [13:48] O_o [13:48] 70W? [13:48] i can power several notebooks with that you know? [13:49] like three notebooks. [13:49] 70W is what I've read [13:49] three notebooks playing music and compiling kernels at the same time [13:49] hyperair: indeed [13:49] hyperair: There are >100W processors available, if you have the cooling. [13:49] with maximum panel brightness [13:49] Lowest number I've ever seen is 0.2W [13:49] 0.2 is tiny [13:49] seriously tiny. [13:49] persia: for what....? [13:49] persia: ARM? [13:50] that'd explain why our ARM buildds are so slow =p [13:50] ARM & SH both get that low. [13:50] (at least, i think it was arm that was slow) [13:50] The ARM buildds aren't anything so low :) [13:50] I think the marvell wall-plug server uses a couple of watts [13:50] sparc seems slowest from my "rebuild foo on all arches" tests. [13:50] SheevaPlug? I think that's 5-10 or so. [13:51] persia: OK, I stand corrected [13:51] Unfortunately, dist-upgrade to karmic on that crashes hard. [13:51] ouch. [13:51] persia: is that a kernel related issue? [13:51] speaking of dist-upgrade, i should probably dist-upgrade to lucid one of these days. [13:51] hyperair: ugh [13:52] mok0: is lucid in a bad state at the moment? [13:52] hyperair: I dont know.... karmic was in a pretty poor shape even at release time [13:52] mok0: ISA issue The processor doesn't support the ISA used for armel in karmic. Like trying to run Karmic on an i386 [13:52] mok0: but karmic now is splendid! [13:52] mok0: and i was pretty happy with karmic from the betas all the way up [13:52] make that alphas [13:53] hyperair: it's fine now [13:53] I've become very sceptical about the fixed release schedule [13:53] i'd say karmic's the best ubuntu release since intrepid. [13:53] but yeah, the fixed release schedule is a little annoying sometimes. [13:53] perhaps we need to push freezes earlier? [13:53] kernel doesn't work either, but due to the annoyances of ARM kernels, you basically need a separate kernel for *every* board, and there's only a couple supported in the archives. [13:54] We need to push testing harder. [13:54] Yes [13:54] Way back when, we used to close lots of the bugs. [13:54] Now it doesn't matter how many bugs are open [13:55] Release before all [13:55] Now, we have lots and lots of bugs, and lots of people don't even bother to try to get all the merges done immediately or fix all the NBS / FTBFS right away. [13:55] No, it was Release-on-Release-Day back then too. [13:55] We just tried harder. [13:55] persia: "well, we can always fix those bugs in the next release" [13:55] afaik 6.06 was pushed back [13:55] i mean why wasn't it 6.04? [13:56] maybe we should do the same for lucid. [13:56] I don't think it's worth it. it didn't help much for Dapper. [13:56] There should be 1 year of development for the LTS [13:56] Things age too quickly for that. [13:56] agreed [13:56] Essentially, there's 2 years of development for an LTS. [13:56] But it's a mindset thing. [13:57] persia: how's that? [13:57] Well, right now FTBFS and NBS are full of stuff. Those need clearing. [13:57] i can't seem to bring myself to spend the effort backporting things all the way down to hardy in my PPA despite it being a LTS [13:57] Once clear, we should chase UEHS. [13:57] what's NBS? [13:57] and UEHS? [13:57] If that's clear, then it becomes worth doing things like piuparts testing or autopkgtest. [13:58] But if we're not even keeping up with NBS and FTBFS, it's hard to suggest doing more QA stuff to make sure the release is clean. [13:58] hyperair: NBS is stuff no longer built from source. Transitions. [13:58] i see. [13:58] So if Package A used to build libfoo1 and now it builds libfoo2, we need to migrate everthing. The NBS page lists everything needing work. [13:59] UEHS is the Ubuntu External Health System. For all the packages that aren't maintained in Debian, it checks what has watch files, and tells us what we need to merge directly with upstream (as opposed to just what we need to merge from Debian). [14:00] i see. [14:00] In my opinion, if we manage a release with clean FTBFS, NBS, UEHS, and rcbugs, we'll be in very good shape. [14:00] But it's been a while since we managed that. [14:00] persia: I agree, but there's no concerted effort [14:00] hyperair: If you want more info: read https://wiki.ubuntu.com/UbuntuDevelopment/NBS [14:01] i should spend some time looking at these lists. i admit i haven't actually looked much [14:01] mok0: How do you think it should be concerted? In the past, we used to just put QA tools in the /topic, and people did them. [14:01] persia: I don't see the MOTU working as a team anymore [14:01] How can we improve that? [14:02] persia: I don't know... but now the MOTU team seems to be disbanded anyways [14:02] aren't the MOTU disappearing? [14:02] No [14:02] yeah like that [14:02] yep [14:02] disbanding. [14:02]