[02:32] <ESphynx> Sync sync sync https://bugs.launchpad.net/ecere/+bug/394998 pretty please =) Quantal! :)
[02:39] <jbicha> ESphynx: you'll need to apply for a feature freeze exception since it's late in the release cycle
[02:39] <jbicha> https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
[03:00] <xnox> hmm...
[03:02] <xnox> it will need a sync in either case cause it's in the experimental and since the archive is frozen I can sponsor this into ubuntu as I did into debian and then let the release team decide =)
[03:30] <ESphynx> jbicha: Should I still apply for a feature freeze exception? :)
[03:31] <ESphynx> thanks again xnox :)
[03:31] <jbicha> ESphynx: I don't know, it got accepted from the unapproved queue, but not the new queue
[03:32] <ESphynx> what should I do then :P
[03:32] <xnox> ESphynx: you should state the FFe reasons in the bug report.
[03:32] <xnox> as it is an FFe.
[03:33] <xnox> regardless of which queues it's stuck in.....
[03:33] <ESphynx> so I should just post a comment saying 'Ecere is Awesome, please sync into Quantal?' ?
[03:36] <xnox> ESphynx: sure, why not =)
[03:37] <ESphynx> xnox: seriously, what's your recommendatino? :)
[03:37] <ESphynx> tumbleweed: hey man you around? :) You got that FFe magic with you? :)
[03:46] <ESphynx> there :)
[04:07] <micahg> jbicha: new sources don't hit unapproved, they hit NEW regardless of freeze AIUI
[04:11] <micahg> xnox: usually, we don't sync stuff into NEW without the FFe to avoid wasting the AAs tim
[04:11] <micahg> *time
[04:11] <ESphynx> how do we get that FFe? :P
[04:12] <micahg> and there's always backports (which would show up in software center just the same AIUI)
[04:13] <micahg> TBH, I'd rather have it in backports than in the release pocket with 3 weeks to go, but I think I'm alone in this opinion (and IANA release team member)
[04:14] <ESphynx> but backport doesn't have the Gold feeling as much as making it into Quantal :P
[04:14] <ESphynx> The SDK is so small it might just fill the annoying free 5mb onto CD1 :P
[04:15] <micahg> with the backport, you can also keep updating it (as long as you install/run test it)
[04:15] <ESphynx> (Ok I'm pushing it :P)
[04:16] <ESphynx> Is that different from the regular Updates?
[04:16] <micahg> you can do the backport afterwards anyways, but then people have to choose the initial jump to backports if they have the release version installed
[04:16] <micahg> ESphynx: well, backports allow feature updates, regular updates pocket usually doesn't
[04:16] <micahg> regardless, it would go into the release pocket for R
[04:16] <ESphynx> right
[04:41] <jbicha> micahg: quantal-backports isn't open yet, is it?
[11:18] <Rhonda> hmm, how to block wesnoth-1.11 from getting synced?  File a bugreport against what specific?
[11:23] <jtaylor> Rhonda: you want no autosync?
[11:23] <jtaylor> that is off until R opens
[11:23] <Rhonda> I don't want any sync at all, it's not a package targetted for a release.
[11:24] <jtaylor> there is a sync blacklist maintained by archive admins
[11:24] <geser> trying to remember how the sync blacklist now works
[11:24] <Rhonda> Right, but it shouldn't get synced after R opens neither. :)
[11:25] <geser> if it's on that sync blacklist it won't get synced before the entry gets removed first
[11:25] <Rhonda> It just got accepted into Debian unstable, so it can't be on that list yet. ;)
[11:25] <jtaylor> if its not suitable for release why is it in unstable and not experimental?
[11:26] <Rhonda> Because it gets more testing that way.
[11:26] <jtaylor> well R will be only for the brave too
[11:26] <Rhonda> It will eventually turn into wesnoth-1.12.
[11:27] <jtaylor> will it not stabilize in 6 month?
[11:27] <Rhonda> Right, but 1.12 won't be out before R gets into release. :)
[11:27] <jtaylor> k
[11:28] <geser> Rhonda: https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist; branch, patch, propose-merge
[11:28] <Rhonda> yay, working on my rusty bizarre knowledge ;)
[11:28] <geser> (I hope that the right process to get entries into that file)
[11:33] <jtaylor> does someone know why we have two glades in quantal?
[11:33] <jtaylor> 3.14 and 3.8?
[11:33] <jtaylor> can we remove 3.8? it ftbs (with a simple fix)
[11:35] <geser> what are the source package names?
[11:35] <jtaylor> glade and glade-3
[11:35] <jtaylor> the latter is old and in universe
[11:35] <jtaylor> the former main
[11:36] <jtaylor> looks to my like it was forgotten to remove glade-3 when glade3 went in main
[11:37] <jtaylor> or do you need 3.8 for gtk2?
[11:37] <geser> both packages are also in Debian
[11:38] <geser> is there something depending/build-depeding on it?
[11:39] <jtaylor> yes
[11:39] <jtaylor> xfce
[11:39] <jtaylor> I'll then just fix the ftbs
[11:44] <jtaylor> Rhonda: the next wesnoth will get a new source package?
[11:45] <Rhonda> Yes, the reason being that people can install 1.10 side-by-side with 1.12.
[11:46] <Rhonda> Users complained that they can't finish their started campaigns after the upgrade.  The savegames are compatible, but the campaigns change between stable releases, mainly for balancing factors, and even units might change.
[11:46] <geser> Rhonda: just got told by cjwatson in #ubuntu-devel that you should file a bug to get wesnoth-1.11 added to the sync-blacklist and subscribe ubuntu-archive
[11:46] <Rhonda> So the approach was to be able to install the different stable versions side-by-side, and thus also the development release for those who want to give it a test early on.
[11:47] <Rhonda> geser: bug against what?  :)
[11:47] <cjwatson> doesn't matter
[11:47] <cjwatson> wesnoth-1.11, conventionally
[11:47] <cjwatson> but we work off our +subscribedbugs list so the target is irrelevant
[11:48] <cjwatson> don't bother proposing a branch for the sync-blacklist or whatever; that's a waste of effort
[11:48] <cjwatson> and merge proposals won't work there anyway because it's a +junk branch
[11:53] <Rhonda> done. :)
[14:10] <jtaylor> someone familiar with the tiff transition?
[14:10] <jtaylor> tiff-dev is gone, now we should use libtiff5-dev?
[14:10] <jtaylor> why is that? I though the recommendation is the opposite
[14:24] <tumbleweed> jtaylor: libtiff5-dev provides libtiff-dev
[14:26] <jtaylor> I don't understand this failure https://launchpadlibrarian.net/117813129/buildlog_ubuntu-quantal-i386.love_0.8.0-1_FAILEDTOBUILD.txt.gz
[14:52] <cjwatson> jtaylor: In general you should just use libtiff-dev - it only has one provider
[14:53] <cjwatson> jtaylor: That kind of failure generally means that something in the (build-)dependency set conflicts
[14:54] <cjwatson> jtaylor: love has an explicit build-dep on libtiff4-dev, which won't work.  Try s/libtiff4-dev/libtiff-dev/ there
[14:54] <jtaylor> makes sense, thanks
[16:00] <bobweaver> Hello there I have been trying to package up some C++ work for the last day and can not get it to package correctly. all dependency's are fine debian file is good. It is cmake that I am having trouble with
[16:02] <JontheEchidna> bobweaver: anything in particular?
[16:02] <bobweaver> do I do  cmake . -DCMAKE_INSTALL_PREFIX:PATH=/usr
[16:02] <JontheEchidna> what does your rules file look like?
[16:02] <bobweaver> JontheEchidna,  yeah It says that (on LP) that it can not change dir's to /home/joseph   and I can understand why
[16:03] <bobweaver> JontheEchidna,  one sec
[16:03] <bobweaver> slow neytwork today
[16:03] <JontheEchidna> no rush :)
[16:04] <bobweaver> https://launchpad.net/~josephjamesmills/+archive/beta/+packages   it is the package Unity-2d-nudity1
[16:05] <bobweaver> http://paste.ubuntu.com/1252077/    << debian/rules
[16:06] <jtaylor> bobweaver: you can pass arguments to cmake by running dh_auto_configure -- cmake-args
[16:06] <bobweaver> I have a feeling that I need to tell cmake to install to $(DESTDIR) but I am not sure how to do this ?
[16:06] <JontheEchidna> it looks like the packaging has cmake generated files local to your machine...
[16:06] <jtaylor> dh_auto_configure should set the install prefix to destdir already
[16:06] <bobweaver> correct should I get ride of all the cache ?
[16:07] <bobweaver> cool
[16:07] <JontheEchidna> yes, it is the cmake files that are confusing the build daemon
[16:07] <bobweaver> maybe try presitine package ?
[16:07] <bobweaver> meaning do not run cmake at all on local
[16:07] <JontheEchidna> yes, you will not need to run cmake locally
[16:08] <bobweaver> there is the troubles very cool and thanks JontheEchidna
[16:08] <JontheEchidna> no problem. :)
[16:09] <bobweaver> yeah I just ran cmake  before so that I could test package on 12.10 (fakeroot dpkg-buildpackage -F)
[16:10] <bobweaver> package build and compile and I have unity 2d on 12.10 now
[16:10] <bobweaver> now just to get it into repo's
[16:10] <bobweaver> well my repo thanks again
[16:10] <JontheEchidna> here's an easy way to clean stuff up: mkdir build; cd build; cmake ../ -DCMAKE_INSTALL_PREFIX=/usr; make; make install
[16:10] <JontheEchidna> then when you're done: rm -rf build/
[16:11] <jtaylor> I think dh already does out of source builds for you
[16:11] <jtaylor> but its been a while sinece I dealt with cmake packages :/
[16:11] <JontheEchidna> I think he was just trying to do a local build, without any packaging involved
[16:12] <bobweaver> yeah local build works great
[16:12] <JontheEchidna> but yeah, debhelper will create its own build directory and instruct cmake to use that when building the package
[16:12] <bobweaver> had to remange libs but works (little buggy but not that bad )    to clean I can run  find -iname '*cmake*' -not -name CMakeLists.txt -exec rm -rf {} \+      ?
[16:12] <bobweaver> nm I see what you said above ^^
[16:16] <bobweaver> Is there a way to tell dh_automake  to run with -j4 ?
[16:16] <bobweaver> like for make -j4  (because I have 4 threads )
[16:17] <jtaylor> --with parallel
[16:17] <bobweaver> but with-in the build (just to make faster )
[16:17] <jtaylor> then uses DEB_BUILD_OPTIONS
[16:17] <bobweaver> sweet thanks jtaylor
[16:32] <bobweaver> sorry about all the questions but this should be the last of the day (I hope) When building a package what do I do with the .bzr stuff remove it ?
[16:32] <bobweaver> litian warning me
[16:33] <tumbleweed> it shouldn't be in the source package
[16:33] <bobweaver> lintian *
[16:33] <tumbleweed> if you bulid with bzr bd, it shouldn't be there
[16:34] <bobweaver> thanks tumbleweed . never used bzr to build, Looks like I got more cool stuff to learn about :)
[16:37] <bobweaver> you all are straight up AWESOME in this channel !  thanks again for the help. If you all ever need any qml QT or C++ javascript stuff done. dont be shy to call me out. (it is the least that I could do (not sure that I could be the best help but hey I have to offer ))
[16:37] <bobweaver> thanks again !
[16:40] <tumbleweed> btw, debuild -i will also ignore that stuff (I have -i as a default debuild argument)
[16:49] <bobweaver> Cool tumbleweed  !!
[18:17] <micahg> jbicha_: yes, quantal-backports is open
[21:10] <MohamedAlaa98> raof: hello :) I've branch merging propose https://code.launchpad.net/~m-alaa8/ubuntu/quantal/gtk-nodoka-engine/fix-for-803007/+merge/127177 so can you please merge it after the ubuntu 12.10 release? thank you ;)
[21:12] <MohamedAlaa98> * :)