[00:00] <lifeless> so, I'm upstream; I rolled release of what was already in Ubuntu as ~68 or so; tested that in a PPA, pushed it to Debian
[00:00] <lifeless> let it settle there
[00:00] <lifeless> and now want it it Ubuntu, because it includes the perl modules, .pc file etc
[00:01] <james_w> so it does have new features?
[00:01] <lifeless> from the upstream perspective, no. Some things that weren't installed by the package are now [the perl module]
[00:02] <james_w> ok, so motu-release will want to review
[00:02] <sistpoty> lifeless: are you subscribed as bug contact and promise to fix things if they are broken?
[00:03] <lifeless> sistpoty: is the moon in orbit?
[00:03] <sistpoty> lifeless: good, than declare it as bug fix only, and go straight to ubuntu-archive ;)
[00:03] <lifeless> sistpoty: I'm upstream; package it in Ubuntu, package it with Jelmer in Debian
[00:04] <lifeless> mm
[00:05] <lifeless> I'd rather err on caution here and use that card when I really have to :)
[00:05] <christoph_debian> sistpoty: hm I'm looking at the doc currently
[00:05] <sistpoty> haha
[00:05] <sistpoty> christoph_debian: for new packages it basically calms down to why we want it and where to get from
[00:06] <sistpoty> christoph_debian: bonus points for mentioning that you're packaging it in debian and will take care for ubuntu bugs as well ;)
[00:07] <lifeless> urgh, autotools, sometimes, I hates you
[00:07]  * JontheEchidna always hates autotools. cmake ftw
[00:08] <lifeless> well, I just found that the .pc file generated contains
[00:08] <lifeless> exec_prefix=${prefix}
[00:08]  * sistpoty learnt to love autotools and hopes that now autotool will love him as well
[00:08] <sistpoty> (which sadly isn't always the case)
[00:08] <lifeless> which I'm now going to have to check works
[00:09] <sistpoty> christoph_debian: of course mentioning some kind of testing would also be good (well, I've done that, so... ;))
[00:12] <thiagocrepaldi> has anyone here able to ENABLE LdapAuthentication mediawiki-extension plugin ?
[00:12] <thiagocrepaldi> "mediawiki-extension" package looks like debian/ubuntu specific, so i can't find help to configure it
[00:21] <ari-tczew> is here? anyone
[00:23] <ari-tczew> please check this bug: 421684 have someone got this bug?
[00:38] <ScottK> ari-tczew: Try it without the colon
[00:38] <ScottK> thiagocrepaldi: You might get help in #ubuntu-server.  Not sure
[00:39] <thiagocrepaldi> ScottK, for ow, no success =/
[00:39] <thiagocrepaldi> now*
[00:41] <thiagocrepaldi> and i checked that ubuntu-mot are the mediawiki-extensions's maintainer
[00:46] <ari-tczew> ScottK: what is colon?
[00:50] <ScottK> ari-tczew: Instead of bug: 421684, bug 421684
[00:50] <ScottK> Then people have a better idea what you're asking about.
[00:53] <ari-tczew> bug 421684
[00:53] <ari-tczew> OK
[00:54] <ari-tczew> sorry for mistaking, it's my first day on irc
[00:54] <ari-tczew> what is colon, ScottK ?
[00:55] <ScottK> ari-tczew: colon is ";"
[00:55] <ScottK> oops
[00:55] <ScottK> That's semi-colon
[00:55] <ScottK> colon is ":"
[00:55] <ari-tczew> ah, OK
[00:56] <sistpoty> lifeless: haha, regarding ScottK's comment :P
[00:57] <lifeless> sistpoty: :P
[00:57] <ari-tczew> english isn't my language
[00:57] <ari-tczew> my fail :P
[00:57] <lifeless> ScottK: so, I still need -archive to flip the bit.  Thats you isn't it?
[00:57] <ScottK> lifeless: Needs someone with shell access.
[00:59] <ScottK> ari-tczew: You are doing great.
[01:00] <sistpoty> vorian: (| ScottK): bug #419465 looks kde-specific
[01:00] <sistpoty> (/me is just going through the list, trying to get long-standing ones updated)
[02:06] <lamont> sistpoty: I'll be bootstrapping it this weekend
[02:06] <lamont> tonight is with family in a bit though
[02:06] <sistpoty> \o/
[02:07] <sistpoty> lamont: excellent, thanks a lot!
[03:02]  * sistpoty goes to bed. gn8 everyone
[05:46] <Laibsch1> can somebody please take the fix from 414537 from karmic and release it in jaunty?
[05:47] <Laibsch> The fix for that bug is the only difference between the karmic and jaunty package
[05:47] <Laibsch> bug 414537
[05:49] <Laibsch> bdrung_: ping.  Kannst Du das vielleicht noch machen?
[06:02] <jdong> Laibsch: an excellent candidate for a StableReleaseUpdate
[06:02] <jdong> !sru
[06:03] <jdong> if you can prep the writeup and debdiffs according to the instructions there, I'll take a look at it right away
[06:03] <Laibsch> I'm sorry
[06:03] <Laibsch> I'm taking an extended overseas trip on Monday
[06:03] <Laibsch> I'm very short on time
[06:03] <Laibsch> But the SRU should be more than straight-forward
[06:04] <jdong> absolutely
[06:04] <Laibsch> s/karmic/jaunty/ in the first line of the changelog is all that should be necessary
[06:05] <Laibsch> And maybe not even that
[06:05] <Laibsch> And regression potential is obviously 0
[06:05] <jdong> indeed
[07:59] <fabrice_sp__> jtimberman, about bug #420674. It's just a matter of waiting for an archive admin to perform the sync. Don't worry: it's on his way.
[08:12] <randomaction> fabrice_sp: I redid the debdiff for ufraw
[08:18] <fabrice_sp_> randomaction, ok. I'll have a look now
[08:18] <fabrice_sp_> (waiting for a build to end :-) )
[08:19] <AnAnt> Hello, do I need to file FFe for a new branding package ?
[08:19] <AnAnt> it's an xsplash theme
[08:21] <fabrice_sp_> randomaction, sounds good. I'll build, and if it installs, I'll upload. Thanks for your contrib! :-)
[08:22] <fabrice_sp_> AnAnt, I think so (new package = new features)
[08:24] <AnAnt> ok
[08:37] <fabrice_sp_> randomaction, uploaded. Thanks!
[08:37] <fabrice_sp_> no more fix to FTBFS to sponsor? :-D
[08:37] <randomaction> good to have helpful upstreams :)
[08:38] <fabrice_sp_> yep :-)
[08:40] <fabrice_sp_> in general, it's good to have a look at upstream svn, to check if the bug is already fixed (others distros are using the latest c libs)
[08:51] <randomaction> oh, in this case it was even imported into LP
[09:01] <ripps> can someone help me use patches with a pacakge that doesn't use cdbs?
[09:02] <lifeless> have you read the wiki page on patch systems?
[09:04] <ripps> lifeless: I'm trying to implement a quilt patchsystem, and the wiki only explains how to do a simple patchsys. I know quilt includes a quilt.make, but I don't think it's working.
[09:05] <lifeless> there are plenty of packages using quilt already
[09:05] <lifeless> I'd cargo cult one of them
[09:05] <lifeless> but not fakeraid, cause it does two builds and it a bit heinous
[09:06] <RAOF> IIRC quilt.make basically gives you a patch: and unpatch: targets that DTRT.
[09:06] <ripps> lifeless: you know a cdbs-less package using quilt?
[09:08] <ripps> and then I keep reading something about usein --with-quilt with debhelper, but I don't know specifically where to put it or how
[09:14] <ripps> ah, I think I know, I had to add something to build-stamp and clean
[09:16] <lifeless> if you have time, see if there is a FAQ on quilt as patchsys, and if not, perhaps write onee up?
[09:16] <lifeless> [e.g. on the patch systems page on the wiki]
[09:18] <ripps> Okay, I added dh_quilt_patch and dh_quilt_unpatch to the rules. I had assumed that quilt.make would take care of everything, but I was wrong
[09:20] <sebner> ripps: post your rules file somewhere
[09:22] <ripps> sebner: I'm not certain it will work yet, but you just add one dh_quilt_patch before configure and dh_quilt_unpatch before dh_clean, whereever those are in your rules
[09:23] <ripps> I put my dh_quilt_patch at the beginning of build-stamp: and dh_quilt_unpatch near the end of clean:
[09:25] <sebner> ripps: not really needed. dh --with quilt $@
[09:29] <ripps> sebner: that's if your using the super simple dh7 layout, the package I'm trying to modify already has a pretty complicated setup and I don't want to alter it too much.
[09:30] <sebner> ripps: I personally also use --with quilt with big and not simple rules layouts ... paste you rules file somewhere ;)
[11:06] <joaopinto> shouldn't all universe packages be maintained by MOTU ?
[11:06] <joaopinto> I am looking at apparmor-profiles, it's universe by maintained by UCD
[13:12] <directhex> bah, mysql won't start on my server after karmic upgrade
[13:25] <directhex> found it. skip-bdb line in my.cnf kills mysql-server-5.1
[13:33] <jdstrand> joaopinto: the source package for apparmor-profiles is 'apparmor'. 'apparmor' is one of those cases where it has packages in both universe and main
[13:33] <jdstrand> joaopinto: if you want to make changes, file a bug against apparmor, attach a debdiff or link to a branch and we can get it merged
[14:05] <mok0> Who has tried an update-manager upgrade jaunty -> karmc?
[14:07] <mok0> Considering an upgrade of my production box but... you know
[14:56] <bdrung> DktrKranz: your main email is  dktrkranz@ubuntu.com ?
[14:58] <DktrKranz> bdrung: for ubuntu stuff yes
[14:58] <bdrung> k
[14:58] <bdrung> thx
[14:58] <DktrKranz> np :)
[15:01] <ScottK> mok0: I've upgraded from Jaunty to Karmic during the beta freeze.  My only problem was I upgraded off of a stale mirror and got a dead box due to an old KDM.  Once I coaxed it into life and got the updated one it was fine.
[15:11] <jbernard_> mok0: I tried it 4 days ago and all went smooth
[16:13] <soc1> hi
[16:13] <soc1> can someone help me with a gnome app?
[16:13] <soc1> i can't find that http://blogs.gnome.org/thos/2009/07/26/re-adding-fonts-in-gnome/ app in the gnome source tree
[16:14] <soc1> it _should_ be in gnome-control-center, but the changes there a at least 7 monts old ...
[16:21] <soc1> btw, *.ttf-fonts get a thumbnail, *.otf-fonts don't get one, that's a bug, right?
[16:21] <soc1> additionaly
[16:21] <soc1> s/additionaly/additionally
[16:21] <soc1> ttf is opened by gnome-font-viewer, otf not
[16:22] <soc1> any ideas?
[16:52] <wrapster> http://pastie.org/640490 thats the change log and line actually starts with a red highlight..
[16:52] <wrapster> what does that mean?
[16:53] <Amaranth> wrapster: if you mean the first line it could be because "unstable" isn't an Ubuntu release
[16:54] <wrapster> no its not the first line its "* Added a return(0) to myk_mhz in myk_gem.c "
[16:54] <wrapster> that line.. btw is the format im specifying matching to the standard?
[16:54] <wrapster> or should i write in a different way?
[16:55] <ScottK> wrapster: Did you use spaces or a tab?
[16:55] <wrapster> tab
[16:55] <ScottK> If you used a tab, that's the problem
[16:55] <wrapster> which was set to 2
[16:55] <wrapster> eiks!!
[16:55] <ScottK> Needs to be spaces
[16:55] <wrapster> ok
[16:55] <ScottK> Gotta run
[16:56] <wrapster> working now...
[16:56] <wrapster> thanks
[16:56] <wrapster> but i would like to know if the format i've followed is right?
[17:03] <wrapster> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends};;;;;  dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends} ---> while make this is a warning from the control file that im getting..is it a serious one? seconldy there are no dependency so should i yank that line out completely or can i specify something line NULL or null in Depends:
[17:21] <maxb> wrapster: They are not serious, you should probably leave in misc:Depends ... and I thought newer debhelper tried to avoid that warning.
[17:22] <maxb> It's reasonable to remove shlibs:Depends if your package contains no compiled code such that it's impossible for it to have a .so dependency
[17:22] <wrapster> well nope.. for now i'll leave both in peace.
[17:23] <wrapster> im building pkg out of tarballs for pkgs that are non exisitant so this is what i have in the chagnelog... "  * Initial release (Closes: #nnnn)  <nnnn is the bug number of your ITP>" what do i write here? or should it be left the way it is?
[17:25] <wrapster> i can take that line out right?
[17:26] <maxb> wrapster: Hm. I'm seeing code that claims to avoid the misc:Depends warning in the karmic version of debhelper
[17:27] <wrapster> im not using karmic i guess then!!
[17:27] <maxb> heh
[17:27] <maxb> On the subject of changelogs - write anything you like, just make it meaningful.
[19:29] <ari-tczew> hello all
[19:29] <hyperair> hello
[19:55] <fabrice_sp_> hello ari-tczew
[19:55] <fabrice_sp_> do you have 5 minutes to speak about maven2?
[19:56] <ari-tczew> yes
[19:57] <fabrice_sp_> I tried earlier in the cycle to have the maven/plexus packages to work, and I had to stop, because it required some non maven2 package to be updated, and ttx didn't wanted to impact non maven packages because of maven
[19:58] <fabrice_sp_> so, basically, if at some points you needs a non maven package, don't try to go further, and the sync won't be accepted
[19:58] <fabrice_sp_> just wanted to warn you :-)
[20:00] <fabrice_sp_> s/and/as/
[20:02] <fabrice_sp_> one of them was google-collections-java, I think
[20:17] <ari-tczew> sorry fabrice for non response
[20:17] <ari-tczew> so it's not eay work
[20:17] <ari-tczew> easy *
[20:19] <wrapster> ive developed pkgs out of a few tarballs and all of them after installaion require a reboot.. is it safe to install em all first then reboot at once? or should i do it one by one?
[20:20] <fabrice_sp_> ari-tczew, no, but the Debian packages has changed, so it may be possible now
[20:24] <ari-tczew> fabrice_sp_: what do you think, is it sense to work on maven?
[20:25] <ari-tczew> from some comments is info, that maven from karmic is broken
[20:25] <fabrice_sp_> ari-tczew, you could do a quick check on the required packages, and see if you would need a non maven package, because of a FTBFS. If it's the case, it's not worth trying to go further
[20:26] <fabrice_sp_> yes: it's totally broken, but as I was saying before, it's known, and accepted by core-dev....
[20:26] <fabrice_sp_> I mean: the risk of getting something other broken because of a bad sync is not worth the risk
[20:27] <sistpoty> ?
[20:27] <ari-tczew> ehh, now I'm busy and for the moment someone else can works on maven2
[20:28] <sistpoty> imho we should fix maven, but we need to get a plan of what we need to sync, what needs to get through new (at least the split off core package) etc.
[20:29] <ari-tczew> btw. Please MOTU review sync hugin request, now is complete informations: bug 439396
[20:29] <ari-tczew> ack needed
[20:31] <fabrice_sp_> sistpoty, I've exchanged some emails with ttx, and this what I've been told 2 times (I tried it 2 times :-) )
[20:32] <fabrice_sp_> when I tried to fix them, I required at least 4 non maven packages
[20:32] <sistpoty> fabrice_sp_: so you do have some overview of what's needed for maven already?
[20:32] <sistpoty> fabrice_sp_: can you add that to the FFe bug please
[20:35] <fabrice_sp_> sistpoty, I had all packages in my ppa, but deleted everything ... I only have the emails with ttx, that I will paste in the sync request, if it makes sense
[20:36] <sistpoty> fabrice_sp_: that would be great, thanks!
[20:36] <fabrice_sp_> ok. Thanks to you ;-)
[20:38] <ari-tczew> fabrice_sp_: hugin tested, works fine ;)
[20:38] <ari-tczew> libpano needed
[20:39] <fabrice_sp_> ari-tczew, you still need to convince 2 motu-release team member :-)
[20:39] <ari-tczew> ACK right?
[20:39] <fabrice_sp_> yes
[20:40] <ari-tczew> status changed from Imcomplete to New, is this OK?
[20:40] <fabrice_sp_> yes
[20:40] <fabrice_sp_> do you have the maven2 sync bug request at hand?
[20:40] <fabrice_sp_> I'll update it with the answer of ttx
[20:40] <ari-tczew> yes, but it's made for all maven packages
[20:41] <ari-tczew> bug 427539
[20:41] <fabrice_sp_> perfect :-) Thanks
[20:42] <ari-tczew> np
[20:43] <fabrice_sp_> ari-tczew, for Hugin, did you keep the patch I made to update default parameters?
[20:43] <fabrice_sp_> it seems not, as I'm seen the bug as sync request
[20:44] <fabrice_sp_> s/seen/seeing/
[20:45] <ari-tczew> I did nothing on hugin! only send to ppa from unstable (debian/changelog changed)
[20:45] <ari-tczew> Darxus tested it
[20:46] <ScottK> sistpoty: hugin is probably something we want.
[20:46] <fabrice_sp_> you need to perform the merge, then
[20:47] <sistpoty> ScottK: *nod*, though I haven't looked in detail yet. libpano1 seems a non-brainer *if* we want hugin (only hugin as rdepends)
[20:48] <ScottK> fabrice_sp_: Is it a merge or a sync?
[20:49] <fabrice_sp_> it has to be a merge: the default pano software is not the same in Ubuntu than in Debian
[20:49] <fabrice_sp_> libpano can be synced AFAIR
[20:54] <ari-tczew> btw. it's nice that we can talk directly about bugs instead on LP
[20:55] <fabrice_sp_> ari-tczew, it's quicker :-)
[20:55] <fabrice_sp_> do you take the merge?
[20:57] <ari-tczew> I can take this, but tell me what I need to do?
[20:57] <ari-tczew> include patch, remove patch... ?
[20:59] <fabrice_sp_> It seems that 2 motu-release agree that hugin 0.8.0 is a must-have :-)
[20:59] <ari-tczew> yhym
[20:59] <fabrice_sp_> !merge
[21:05] <Darxus> Hi.
[21:05] <fabrice_sp_> Hi Darxus
[21:08] <Darxus> Wow, hugin 0.8.0 is actually going to make karmic?  Excellent.
[21:08] <Darxus> Then it'll only be one major release behind :)
[21:10] <Darxus> Let me know if I can help further.
[21:10] <fabrice_sp_> Darxus, more testing after the merge :-)
[21:10] <Darxus> Sure.
[21:11] <Darxus> So Ari is doing the merge?
[21:11] <fabrice_sp_> actually, the Debian version can't go as-is into Ubuntu
[21:11] <fabrice_sp_> I think so: he is reading the merge guide now :-)
[21:11] <fabrice_sp_> ari-tczew, do you confirm?
[21:11] <Darxus> fabrice_sp_: Yeah I was testing the ubuntu 2009.2.0 version and its lack of automatic stitching is a real pain.
[21:12] <fabrice_sp_> this was one of my first fix for Ubuntu :-D
[21:12] <Darxus> fabrice_sp_: Making autopano work by default?
[21:12] <fabrice_sp_> yes
[21:12] <Darxus> fabrice_sp_: Nice, thanks :)
[21:12] <fabrice_sp_> ;-)
[21:13] <Darxus> I couldn't even figure out how to get any of those to work with the debian experimental package :(
[21:14] <fabrice_sp_> I don't know for the 2009.2.0 version, but the other one has to be patched, and the patch has to be adapted for version 0.8.0
[21:14] <fabrice_sp_> will have a look in the next dev. cycle
[21:14] <Darxus> Right.
[21:14]  * fabrice_sp_ is busy fixing FTBFS and sponsoring fixes
[21:15] <Darxus> Cool.
[21:15] <Darxus> Makes me a little nervous that so many such things are still open at this stage.
[21:16] <Darxus> Hell, it makes me nervous that hugin 0.8.0 can be accepted after beta freeze without some kind of massive coordinated testing.
[21:18] <fabrice_sp_> it has been some time in Testing, and no blocking bugs has been found
[21:19] <ScottK> Darxus: It's a judgement call.  If we can get some reasonable testing, then we ought to have it.
[21:19] <ScottK> If not, we won't.
[21:20] <Darxus> Wow, Merge-O-Matic actually has hugin 0.8.0.
[21:22] <fabrice_sp_> MoM has everything :-)
[21:23] <ari-tczew> I didn't read megre docs, now I'm working on something for my daily-work, not for Ubuntu
[21:23] <ari-tczew> give me time for this
[21:23] <ari-tczew> fabrice_sp_: So I must include patch from debian experimental to hugin 0.8.0, right?
[21:24] <ari-tczew> wait... what about libpano? It needed first, before getting hugin
[21:25] <fabrice_sp_> no: include the changes done on hugin 0.7.0 to 0.8.0, or at leas review them
[21:25] <Darxus> # wc -l hugin_0.8.0.dfsg-2.patch
[21:25] <Darxus> 238872 hugin_0.8.0.dfsg-2.patch
[21:25] <Darxus> :(
[21:25] <fabrice_sp_> include both in your ppa, and if testing is ok, the ack will go for both
[21:25] <fabrice_sp_> Darxus, my changes can't be applied as-is to 0.8.0: the source patched has changed
[21:26] <fabrice_sp_> I don't remember it to be as big as that :-/
[21:27] <ari-tczew> heh, I'll review this later.
[21:27] <ari-tczew> now I must go away, cya
[21:27] <fabrice_sp_> bye
[21:31] <Darxus> Why isn't hugin on https://merges.ubuntu.com/universe.html ?
[21:36] <Darxus> Ohh, looks like the only merge conflict is in debian/control.
[21:37] <sistpoty> Darxus: it was uploaded to unstable after the last run of MoM
[21:37] <Darxus> sistpoty: Ah, thanks.
[21:37] <fabrice_sp_> Darxus, could, but the patch won't apply
[21:39] <fabrice_sp_> otherwise, it's a quite easy merge
[21:39] <Darxus> And the only changes in debian/control are Build-Depends and Standards-Version.
[21:40] <ScottK> What's the build-depends change?
[21:41] <Darxus> "libpano13-dev" to "libpano13-dev (>= 2.9.14~0)", wx-common was removed, and libglew1.5-dev was added.
[21:41] <Darxus> http://packages.ubuntu.com/karmic/libglew1.5-dev  exists.
[21:42] <Darxus> So it looks like the only conflict can be resolved by just accepting the new stuff from debian?
[21:42] <Darxus> Standards-Version: 3.8.0
[21:42] <Darxus> Standards-Version: 3.8.3
[21:43] <ScottK> Standards version we don't care about
[21:43] <Darxus> I don't know what that means, but I'm going to guess, since these are the only changes, that it'll work :)
[21:43] <ScottK> What that means is we need the newer libpano
[21:44] <Darxus> Didn't we know that?
[21:44] <ScottK> So if those are the only changes, we should be able to update libpano and then sync hugin.
[21:44] <fabrice_sp_> yes: it won't build with the actual one
[21:44] <ScottK> Yes, but that's what that means.
[21:44] <Darxus> Right.  Cool.
[21:45] <fabrice_sp_> no: there is still a patch to apply to hugin for Ubuntu
[21:45] <fabrice_sp_> so sync for libpano and merge for Hugin
[21:45] <fabrice_sp_> Darkus was jsut speaking about the conflict in the merge
[21:48] <fabrice_sp_> 51_ubuntu-autopano-sift is the patch to keep. IIRC, 52_ubuntu_gcc44_ftbfs can be dropped
[21:49] <fabrice_sp_> Darxus, ^
[21:49] <Darxus> fabrice_sp_: Looking.
[21:49] <Darxus> How sure are you?  :)
[21:50] <fabrice_sp_> about keeping 51_ubuntu-autopano-sift ?
[21:50] <fabrice_sp_> 100% :-)
[21:50] <fabrice_sp_> I began to work on the merge some time ago, and got then distracted .-)
[21:50] <Darxus> Man that's a small patch :)
[21:50] <fabrice_sp_> yep: but the lines don't fit now
[21:50] <Darxus> fabrice_sp_: How sure are you about dropping 52_ubuntu_gcc44_ftbfs?
[21:51] <fabrice_sp_> hmm, 50% :-)
[21:51] <Darxus> Oh.  I expected that to show up in MoM's report.
[21:51] <Darxus> Hah.
[21:51] <fabrice_sp_> I think all lines where fixed....
[21:51] <fabrice_sp_> you can try, if you want, without the gcc 4.4 patch, and see if it compile
[21:51] <Darxus> Ah, that makes sense.
[21:52] <ScottK> Generally you can look at the source that the patch was touching and see.
[21:53] <ScottK> Particularly in the case of GCC 4.4 compatibilty changes, it's usually pretty obvious.
[21:55] <Darxus> #define HUGIN_APSIFT_EXE                      "autopano-sift-c.exe"
[21:55] <Darxus> There's the problem.  In the upstream.
[21:55] <fabrice_sp_> this one if for Windows
[21:55] <Darxus> Ohh..
[21:55] <fabrice_sp_> there is 3 blocks of parameters, and I patched only the unix one
[21:56] <Darxus> Right.
[21:56] <fabrice_sp_> :-)
[21:58] <Darxus> Okay.  New debian patch:
[21:58] <Darxus> -#define HUGIN_APSIFT_EXE                      "autopano-sift-c"
[21:58] <Darxus> +#define HUGIN_APSIFT_EXE                      "autopano"
[21:58] <fabrice_sp_> in my work in progress merge directory, I don't have the gcc patch, and I remember looking at the source one by one, so it should be safe to remove it. Anyway, new errors could come
[21:58] <Darxus> Which makes your ubuntu patch not match:
[21:58] <Darxus> -#define HUGIN_APSIFT_EXE                      "autopano-sift-c"
[21:58] <fabrice_sp_> it should be autopano-complete
[21:58] <fabrice_sp_> yes:
[22:00] <fabrice_sp_> new parameters has been inserted
[22:04] <Darxus> $ mv hugin-0.8.0.dfsg-2ubuntu1 ..
[22:04] <Darxus> mv: cannot move `hugin-0.8.0.dfsg-2ubuntu1' to `../hugin-0.8.0.dfsg-2ubuntu1': Directory not empty
[22:05] <Darxus> Since when?
[22:05] <Darxus> Oh, nevermind.
[22:05]  * fabrice_sp_ never moves directories :-)
[22:06] <fabrice_sp_> have to go now
[22:07] <Darxus> Okay, thanks.
[22:07] <fabrice_sp_> Darxus, if you comes to some debdiff, post it in the bug report. Anyway, still miss one motu-release ack to be able to upload it. You should perhaps upload it to a ppa
[22:08] <fabrice_sp_> so that more people can perform tests
[22:08] <fabrice_sp_> bye :-)
[22:19] <Darxus> "Generate a new merged source package using the merge-buildpackage script." doesn't appear to exist.
[22:21] <Darxus> "It looks like this package is maintained in revision control:...You almost certainly don't want to continue without investigating."
[22:21] <Darxus> Found merge-buildpackage :P
[22:55] <Darxus> Wow, it built.
[23:30] <Darxus> dput said it successfully uploaded to my ppa, but launchpad says there's nothing there.
[23:30] <Darxus> $ dput ppa:darxus/hugin-0.8.0 hugin_0.8.0.dfsg-2ubuntu1_i386.changes
[23:30] <Darxus> Successfully uploaded packages.
[23:30] <ScottK> Darxus: Patience.
[23:31] <Darxus> ScottK: Oh, it's doing something with them and they'll show up at some point in the future?
[23:31] <Darxus> And there's no way I can check evidence of that?
[23:31] <ScottK> Generally.
[23:31] <ScottK> Every now and then, it loses packages, but not often
[23:32] <Darxus> Hah.
[23:32] <Darxus> Hah, upload rejected because it contains binary packages.
[23:50] <Darxus> Rejected:
[23:50] <Darxus> PPA uploads must be signed by an Ubuntu Code of Conduct signer.
[23:50] <Darxus> So I signed the code of conduct.
[23:50] <Darxus> And now dput won't let me upload it again.
[23:51] <Darxus> "Already uploaded to ppa on ppa.launchpad.net"
[23:51] <Darxus> Oh, I love force flags.
[23:51] <sistpoty> Darxus: there should be a .upload file, remove that (or use dput -f)