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