[02:45] lfaraone: I understand that precise has to be what it is, but oneiric and quantal do not [02:46] (speaking of the versions) [02:46] also, ScottK mentioned the bit about -proposed [02:46] and I saw the bug, so I wouldn't be able to push that today [02:46] but the big issue was the patching [02:47] mdeslaur: ^ === altair is now known as Guest59016 [02:49] hello. i could need some help here [02:50] I did a "bzr branch ubuntu:update-notifier" but it replied me with "Packaging branch status: OUT-OF-DATE" ... so how can I get the current version? [02:52] Why not lp:update-notifier ? [02:56] what is lp? [02:57] i have no idea. i just wanted to provide a quick fix there (never done that before) and I found somewhere in the internet, that this is the way to get the code. I dont wqant to apply my fix to an outdated version of the update notifier [03:07] Guest59016: lp is launchpad, it is a "shortcut" name in bazaar. [03:08] jdstrand: No, really, the + is there for an actually good reason. [03:08] jdstrand: if you use openafs-modules-source with m-a, upgrades won't work correctly. [03:09] that is weird [03:09] well, if you didn't already, can you mention it in the bug? [03:10] that way the person sponsoring next week won't get tripped up [03:10] jdstrand: I linked to a comment explaining the rationale, https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/356861/comments/1 [03:10] Launchpad bug 356861 in openafs (Ubuntu Jaunty) "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,Fix released] [03:10] oh I see now [03:10] ok, thanks [03:11] that seems like a bug in the packaging, but it isn't all that important [03:12] jdstrand: well, its a module-assistant thing. [03:12] AIUI. [03:14] thanks mate [03:14] Sure. [03:15] sure, whether it is m-a or openafs, that just seems to not be right, but it doesn't matter. if it needs to be that, it needs to be that [03:15] we wouldn't fix that in an SRU [11:17] I'm guessing that fixing new versions hanging in proposed does not need a ffe? [11:36] jtaylor: They dont add new features, so *probably* not [11:36] they do [11:36] jtaylor: ah wait, I read it wrong [11:36] * vibhav needs spectacles [11:37] jtaylor: Actually, which fix are you talking about [11:37] general case [11:37] we have many new upstream versions hanging in proposed [11:39] probably, yes then [11:43] jtaylor: But AFAIK, aren't packages in raring-proposed copied raring after their autopkgtest test is succesfull (if they have one) [11:43] they are copied when they build and don't degrade installability [11:43] or is this only before Feature Freeze? [11:44] jtaylor: I think both factors are checked [11:46] jtaylor: The copying probably halts after FF [18:17] No. The copying doesn't halt. [18:17] How else would we upload new stuff. [18:17] I assumed so much [18:17] so do we need ffe? [18:17] or leave it broken so it won't migrate [18:17] jtaylor: If you're adding new features, it needs an FFe. "It's broken and stuck in proposed if we don't ..." makes it an easier decision. [18:18] say the ffe is denied, and we need to fix a bug [18:18] We'll need to decide if it's better to remove it from proposed or take the new feature so it migrates. [18:18] how can that be handled? [18:19] We can remove from proposed, although there will be some potential versioning issues. [18:19] A handful of days after FF, it's somewhat unlikely a well thought out FFe to fix stuff will get denied. [18:20] e.g. libmatio [18:20] its in proposed and needs a migration [18:20] blocks bugfixes of other packages (dynare) [18:20] What's blocking it? [18:21] I can't rebuild dynare against libmatio from raring [18:21] only against proposed [18:21] so it won't migrate [18:21] Right, but what's blocking libmatio? [18:21] probably an ffe [18:21] Paperwork isn't stopping anything [18:22] * ScottK looks [18:22] its certainly all fixable [18:22] but kind of a mess [18:22] I have no idea how invasive the matio change is [18:23] The first step would be to take the packages that need rebuilding and see if they just build. [18:23] libscilab2-java, libvips-dev, libvips-tools, libvips15, nip2, python-sciscipy, python-vipscc, scilab, scilab-ann, scilab-celestlab, scilab-cli, scilab-full-bin, scilab-full-bin-dbg, scilab-getfem++, scilab-jims, scilab-minimal-bin, scilab-minimal-bin-dbg, scilab-overload, scilab-plotlib, scilab-scimax, scilab-scimax-doc, scilab-scimysql, scilab-sivp, scilab-swt, scilab-test [18:23] Those are the binaries. [18:23] It's rather fewer sources. [18:24] Iwas just in the process of checking why its not completed yet [18:24] OK. [18:24] but I do need to file a ffe for matio? [18:24] No. [18:24] Not for the version in proposed' [18:24] while I like that, why? its a new upstream version [18:24] Stuff in proposed is already in raring. [18:24] so no ffe for stuff hanging in proposed ? [18:24] Yes. [18:24] ScottK: yeah, I had realised that too. Anyway, thanks! [18:25] 19:17 jtaylor: If you're adding new features, it needs an FFe. "It's broken and stuck in proposed if we don't ..." makes it an easier decision. [18:25] Getting stuff to migrate is bug fixing. [18:25] jtaylor: I thought you needed a newer version with new features than was in proposed already. [18:25] sorry if I'm dense I'm just trying to learn the new rules [18:25] I misunderstood the question. [18:25] ah ok so just a misunderstanding [18:25] No problem. It's the first time around. [18:25] Yes. [18:26] thx, lets see whats wrong with matio [18:26] scilab does not fill me with confidence :( [18:26] An example of what I was talking about is if scilab didn't build with the libmatio in raring, but a newer version would. The new scilab (if it had feature changes) would need an FFe. [18:27] scilab never does. [18:28] ScottK: from what I can deduce, you dont need FFEs to have packages in proposed copied to raring, right? [18:29] vibhav: Packages moving to the release pocket from proposed is fully automatic. No paperwork required. [18:51] big surprise scilab fails ._. [18:53] * jtaylor wishes people would test build transitions before syncing ._. [18:53] Was that one a manual sync or an automatic one? [18:54] If it was a manual one, feel free to apply your LART liberally. [18:54] manual from experimental [18:54] Hmmm. [18:56] hm at least it looks like an easy fix, if scilab would autoreconf... [18:57] Great. [19:02] jtaylor: \o/ for looking at it (I had a look last night, and it scared me) [19:02] it scares me too :/ [19:03] my build hasn't reached the testsuite yet, thats were it gets ugly [19:03] If it's too hard, ask the syncer to help you out and failing that we can remove it from proposed (future versioning pain notwithstanding) [19:03] we should grumble at him anyway [19:04] I suspect we still people out there with upload rights who aren't aware of britney [19:04] and many more who never check to see if their uploads migrated [19:04] hopefully it was not me why synced it in the end ;) [19:05] even so, you should be aware of transitions [19:05] Uploading a new library and not doing the transition is poor form britney or not. [19:05] there's that too :P [19:05] a bunch of stuff stuck in -proposed is due to other installability problems, though [19:06] noo scilab needs patches to build with the new matio [19:06] yeah, I got that far [19:07] did you start patching? [19:07] no, exactly that far :P [19:07] and now I need to find something to eat :) [19:07] looks like similar to png, move stuff from a public struct to accessors [19:07] hopefully not more :/ [19:30] well it compiles [19:30] hopefully the stuff is tested well :/ [19:33] * ScottK is fixing the fritzing FTBFS on armhf. [19:54] ScottK: thanks :) [19:54] for? [19:56] fritzing in advance [19:58] 5.4.1~git20130308-b7ffdce-1~exp1ubuntu1 what a version number ._. [20:00] that's just silly [20:00] jtaylor: does that build on i386? it looked like it had trouble on Debian [20:01] according to the changelog the git snapshot should fix that [20:01] but I didn't try it yet [20:15] Ah. [20:26] hm -msse in the buildlog of i386 [20:26] hopefully its runtime checked