[01:04] <highvoltage> I have a package that used to use debconf, but it doesn't anymore.
[01:05] <highvoltage> It now uses the minimal rules file from dh7, but it still runs dh_installdebconf
[01:05] <highvoltage> how would I disable that?
[01:10] <highvoltage> ah, I still had a .templates file
[01:12] <maxwellian> highvoltage wins! :)
[01:12] <highvoltage> :)
[08:46] <and471> I am having trouble getting a pbuilder environment working
[08:46] <and471> I run sudo pbuilder create
[08:46] <and471> but it doesn't seem to finish correctly
[09:03] <geser> do you have an error message?
[09:14] <and471> geser, http://pastebin.ubuntu.com/471765/
[09:14] <and471> geser, sorry it took me so long, I didn't realise there was a response
[09:23] <and471> if an upstream has a .svn or .bzr directory, do I delete this before creating the orig.tar.gz or leave it there?
[09:27] <wgrant> and471: Why are you creating the orig.tar.gz? Does upstream not provide a tarball?
[09:36] <and471> wgrant, no I have to obtain it from a bzr branch
[09:39] <geser> and471: why not use "bzr export" to obtain a tar?
[09:40] <and471> geser, becuase I didn't know about that command :)
[09:40] <and471> geser, wgrant, thanks
[09:40] <and471> geser, did you have any luck with that log?
[09:41] <geser> and471: sorry no, I remember seeing that error in the past but don't remember the solution for it
[09:43] <and471> geser, no problem
[09:43] <and471> can anyone else help me? I am trying to create a pbuilder environment but I keep getting the error on the log http://pastebin.ubuntu.com/471765/
[09:44] <wgrant> and471: What is the host operating system?
[09:45] <and471> wgrant, ubuntu lucid
[09:45] <wgrant> and471: bzr export is pretty convenient. You can just say 'bzr export ../PROJECT-VERSION.tar.gz', and it will create the tarball for you.
[09:45] <wgrant> Not very well known :(
[09:45] <wgrant> and471: Hm. Using a stock Ubuntu kernel?
[09:45] <and471> wgrant, I think so, let me check...
[09:46] <and471> wgrant, 2.6.32-22-generic
[09:48] <wgrant> and471: Hmm. No idea, sorry.
[09:49] <and471> np
[15:15] <freeflyi1g> hi all, can we upload new package to universe directly now?
[15:22] <shadeslayer> freeflying: are you MOTU?
[15:22] <freeflying> shadeslayer: yes
[15:22] <shadeslayer> hmm well .. i would guess you need to go through revu
[15:23] <shadeslayer> freeflying: also can you sponsor a upload ? :D
[15:23] <shadeslayer> webkitkde from https://edge.launchpad.net/~rohangarg/+archive/experimental/+packages
[15:23] <shadeslayer> ( after its done building :P )
[15:24] <freeflying> shadeslayer: I'm not sure about the exact process now, so no idea
[15:25] <shadeslayer> freeflying: errr.. whut?
[15:25] <shadeslayer> regarding revu?
[15:26] <freeflying> shadeslayer: rearding with revu, we still need to adovates?
[15:26] <shadeslayer> yeah afaik
[15:26] <freeflying> shadeslayer: I remember we can do upload directly, right?
[15:26] <shadeslayer> well.. im not entirely sure...
[15:26] <shadeslayer> but id rather go through revu
[15:27] <shadeslayer> ( for a new package )
[15:27] <shadeslayer> always better to get more eyes looking at a package
[15:28] <freeflying> shadeslayer: what I'm trying to sponsor is a package made by a DD, and meanwhile he has contributed a lot to ubuntu
[15:28] <shadeslayer> ah
[15:28] <shadeslayer> freeflying: so the package is already in debian?
[15:28] <freeflying> shadeslayer: so he is familiar with both the policy of ubuntu and debian
[15:28] <freeflying> shadeslayer: not yet
[15:28] <shadeslayer> freeflying: then i would advise : upload to debian > sync/merge to ubuntu
[15:29] <shadeslayer> since he is a DD .. that should be easy
[15:29] <freeflying> shadeslayer: its kindly a ubuntu specific package
[15:29] <shadeslayer> oh.. hmm.. no idea then how to proceed :P
[15:29] <freeflying> shadeslayer: normally, we prefer to have it in debian firstly
[15:29] <shadeslayer> yep
[15:30] <shadeslayer> but we do have local packages as well
[15:30] <shadeslayer> ( local as in, only in ubuntu )
[15:30] <freeflying> ic
[15:30] <freeflying> shadeslayer: anyway, appreciate your suggestions
[15:31] <shadeslayer> :)
[15:31] <shadeslayer> not many people around since its a weekend
[15:32] <freeflying> shadeslayer: yes
[15:34] <shadeslayer> freeflying: will you sponsor my package? :)
[15:35] <freeflying> shadeslayer: depends on whether can I upload it directly :)
[15:35] <shadeslayer> brr... stupid thing will take 30 mins to build :S
[15:36] <shadeslayer> freeflying: yeah.. it already is in ubuntu
[15:36] <freeflying> shadeslayer: then I'd like :)
[15:47] <geser> freeflying: Given that REVU has almost no reviewers, a DD created the package and you also looked at it, you could probably upload it directly.
[16:01] <shadeslayer> freeflying: thanks :D
[16:12] <shadeslayer> freeflying: amd64 is building : https://edge.launchpad.net/~rohangarg/+archive/experimental/+build/1899551 : should finish in 20 mins :)
[16:37] <bdrung_> shadeslayer: the rule is that 2 MOTU have to review the package. if a MOTU creates a package, another MOTU has to check (1 + 1 = 2) before the upload
[16:51] <tumbleweed> bdrung_: oh, btw I gave grab-udd-merge some love today. How's your debdiff review tool coming along?
[16:52] <bdrung_> tumbleweed: it's on its way
[16:52] <bdrung_> tumbleweed: i already sponsored two SRU requests
[16:53] <bdrung_> tumbleweed: currently it supports only debdiffs - the normal diff support is the biggest part that is missing
[16:53] <tumbleweed> aah. That shouldn't be too hard to add, though
[16:53] <bdrung_> tumbleweed: btw, do you have time to sponsor bug #553328?
[16:55] <tumbleweed> bdrung_: not being a core dev, all I can do is review
[16:55] <bdrung_> tumbleweed: k, then i have to do it
[16:58] <bdrung_> tumbleweed: the biggest problem that needs to be fixed, before i can upload the script is the name of the script
[16:59] <bdrung_> some ideas: sponsor-patch, review-patch, review, sponsor
[16:59] <tumbleweed> I guess that depends how much scope it covers
[16:59] <bdrung_> the basic feature: take a patch or debdiff, create a package, and upload it somewhere
[17:00] <tumbleweed> sponsor-patch sounds good
[17:00] <tumbleweed> although sponsor-patch does sound patch-only rather than debdiff
[17:01] <bdrung_> some use cases: sponsor debdiffs (ubuntu-sponsors), upload patches to a PPA (ubuntu-reviewers)
[17:01] <micahg> bdrung_: how about sponsor-foo
[17:01] <micahg> bdrung_: or even sponsor-fu :)
[17:02] <bdrung_> micahg: that's a combination of foo and sponsor-patch :D
[17:02] <bdrung_> tumbleweed: a debdiff is technically a patch
[17:03] <bdrung_> mv foo sponsor-patch
[17:03] <shadeslayer> bdrung_: ah ok
[17:04] <bdrung_> micahg: sponsor-fu sounds nice, but sponsor-patch is more descriptive
[17:04] <shadeslayer> can someone sponsor my package tho?
[17:04] <tumbleweed> bdrung_: yes it is, although in Debian/Ubuntu when we say patch, we often mean an upstream-source patch without a new changelog entries
[17:05] <shadeslayer> webkitkde
[17:05] <shadeslayer> from https://edge.launchpad.net/~rohangarg/+archive/experimental
[17:05] <bdrung_> tumbleweed: that'll be supported, too
[17:06] <tumbleweed> yes, it works. Hell, grab-udd-merge doesn't sound like a reviewing tool, but that was my main aim for writing it :)
[17:07] <bdrung_> tumbleweed: 6 FIXME remaining
[17:07] <micahg> shadeslayer: already a package with that name in archive
[17:07] <shadeslayer> micahg: its a update to that
[17:08] <shadeslayer> the one in the archive is a svn checkout
[17:08] <bdrung_> shadeslayer: then prepare a debdiff
[17:08] <shadeslayer> whereas the one i have is a new upstream release
[17:08] <shadeslayer> bdrung_: itll be huge ;)
[17:08] <shadeslayer> so i have a diff of the old packaging vs new packaging
[17:09] <bdrung_> shadeslayer: in this case upload it somewhere
[17:09] <micahg> shadeslayer: why not get in debian first?
[17:09] <shadeslayer> bdrung_: its in my pap
[17:09] <shadeslayer> *ppa
[17:09] <bdrung_> REVU was designed for new packages
[17:09] <shadeslayer> micahg: hmm.. well i can.. but itll take time.. since i have to make a sbuilder first
[17:09] <bdrung_> shadeslayer: the 2 MOTU rule applies to new packages (not new upstream releases)
[17:09] <shadeslayer> bdrung_: i know
[17:09] <shadeslayer> its not a new package
[17:10] <micahg> which is why I mentioned existing source as well :)
[17:10] <shadeslayer> freeflying was asking about new packages
[17:10] <shadeslayer> not me :)
[17:10] <shadeslayer> oh this is a mess :P
[17:10] <shadeslayer> ok look... we have https://launchpad.net/ubuntu/+source/webkitkde
[17:11] <micahg> shadeslayer: a release was done last month in debian, so I think the maintainer is active, you might want to file an update request there with any patches for the packaging
[17:11] <shadeslayer> and i packaged  a update to that https://edge.launchpad.net/~rohangarg/+archive/experimental
[17:12] <shadeslayer> micahg: err.. i cant find webkitkde on p.d.o
[17:12] <shadeslayer> ah nvm
[17:12] <micahg> shadeslayer: http://packages.qa.debian.org/w/webkitkde.html
[17:12] <shadeslayer> google++
[17:13] <shadeslayer> hmm i need a sbuilder now...
[17:16] <shadeslayer> micahg: any idea how i can specify a certain release.gpg file to sbuilder?
[17:17] <micahg> shadeslayer: sorry, I use pbuilder
[17:17] <bdrung_> o/ pbuilder user
[17:18] <shadeslayer> well.... my sponsor asks for sbuild build logs :)
[17:26] <bdrung_> shadeslayer: there is no big difference between sbuild and pbuilder. your sponsor may be happy with a pbuilder log
[17:26] <shadeslayer> ok :)
[17:27] <bdrung_> tumbleweed: http://paste.debian.net/81976/
[17:27] <bdrung_> shadeslayer: he probably wants a log from a build in a safe environment
[17:28] <shadeslayer> bdrung_: im also poking cmot.. who is the original maintainer of the package
[17:28] <shadeslayer> this will take some time...i have to do some other work as well
[17:30] <bdrung_> tumbleweed: this is the current state
[17:31] <tumbleweed> bdrung_: thanks, will play with it
[17:33] <bdrung_> how can i compare if two patches are identical (the meta data may differ)?
[17:35] <tumbleweed> parse and normalise out the metadata? (i.e. strip timestamps, sort files and hunks)
[17:36] <tumbleweed> filterdiff can do some normalisation
[17:37] <tumbleweed> bdrung_: intending to support merges from debian?
[17:37] <bdrung_> tumbleweed: yes
[17:38] <bdrung_> tumbleweed: once i worked through the SRU list, i will add merge support
[17:38] <tumbleweed> cool
[17:39] <bdrung_> tumbleweed: in the end it should be able to sponsor everything except syncs (which ack-sync does)
[17:40] <tumbleweed> including bzr workflows?
[17:41] <bdrung_> tumbleweed: i didn't look into that, but it shouldn't be that hard to add it
[18:02] <ari-tczew> TheMuso: bug 612127 updated
[19:31] <vish> hmm , is it allowed to use  ’ instead of ' in debian/control?
[19:32] <micahg> vish: in what context?
[19:32] <vish> for "you’re"
[19:33] <micahg> vish: ?
[19:33] <tumbleweed> I'm imagining description
[19:33] <vish> micahg: oh , in the description of the package
[19:33] <micahg> vish: why not?
[19:34] <vish> micahg: yeah , i was just checking, not sure that why asked :)
[19:34] <tumbleweed> it should probably be ASCII, unless UTF-8 is actually needed, but it *is* allowed
[19:34] <micahg> vish: do you have the whole context?
[19:34] <vish> micahg: the debdiff > http://launchpadlibrarian.net/52831364/abuse-sdl_0.7.1-1ubuntu1.debdiff
[19:35] <vish> it showed up as "If youâ€™re one to get easily addicted"
[19:35] <micahg> vish: yeah, that should be an apostrophe
[19:35] <micahg> someone's editor might have made it something else
[19:36] <stalcup> vish: why not use "you are"?
[19:37] <micahg> vish: that should go through Debian though
[19:37] <vish> stalcup: well , we can use but it is usually shortened as you're , hence used it.
[19:37] <tumbleweed> that looks like it's correct UTF8, but it shows up incorrectly in a web-browser
[19:38] <vish> tumbleweed: micahg: cool! thanks , it didnt give any problems locally  , but it was weird seeing it in the browser :)
[19:38] <stalcup> okay, it is your choice afterall
[19:38] <stalcup> :)
[19:38] <tumbleweed> vish: if it were me, i'd change it to a '
[19:38] <Laney> Control files are *required* to be utf8
[19:39] <vish> hmm.. righto.. changing it.. :)
[19:39] <Laney> there's no reason to change it. Try running isutf8 from moreutils on the file and see if it's valid
[19:40] <micahg> vish: make sure to update the debdiff in debian :)
[19:41] <tumbleweed> Laney: there's no strong reason. But I live by the rule that source code should be ASCII unless it has a good reason not to be. i.e. not for a single character
[19:41] <vish> micahg: i wrote that.. not yet uploaded anywhere.  or did you mean send that to debian too , if so , yup sent it :)
[19:42] <micahg> vish: yeah, I saw it attached to a debian bug, just reminding you to update the debdiff for the apostrophe :0
[19:42] <jpds> ☺
[19:45] <Laney> That seems like a very bizarre requirement
[19:50] <stalcup> ohmy
[19:54] <crimsun> interesting: http://www.frogatto.com/about
[20:35] <micahg> archive builders are basically empty, good time to sponsor :)
[20:36] <crimsun> whittling away at the patch queue
[20:37] <Laney> I wonder why darcs FTBFS
[20:37] <Laney> builds just fine locally :(
[20:38] <crimsun> I've run into a lot of those lately on the i386 buildds
[20:39] <crimsun> a couple are scons-related (ugh), though
[20:39] <Laney> http://launchpadlibrarian.net/52801546/buildlog_ubuntu-maverick-i386.darcs_2.4.4-1_FAILEDTOBUILD.txt.gz
[20:39] <X3> scones with sugar on top
[20:39] <Laney> it just hangs at the test suite
[20:39] <Laney> seems fairly inexplicable to me
[20:42] <X3> seems I see lots of version errors
[20:42] <X3> src/Darcs/External.hs:37:36:
[20:42] <X3> Warning: In the use of `try'
[20:42] <X3> (imported from Control.Exception, but defined in base:Control.OldException):
[20:42] <X3> Deprecated: "Future versions of base will not support the old exceptions style. Please switch to extensible exceptions."
[20:42] <Laney> shouldn't matter
[20:42] <X3> idk
[20:42] <Laney> warnings, not errors
[20:43] <micahg> does anyone remember an ML post about .la files going away?
[20:43] <Laney> it worked on amd64, and locally on i386
[20:45] <Laney> and on Debian, of course
[20:46] <X3> Checking for already installed source dependencies...
[20:46] <X3> debhelper: missing
[20:46] <X3> etc etc
[20:46] <tumbleweed> micahg: debian policy 3.9.1
[20:47] <micahg> tumbleweed: is that where I saw it?
[20:47] <Laney> X3: I think you are misinterpreting the build log, I'm afraid
[20:47] <tumbleweed> well, I remember seeing it, and that's all I can find :)
[20:47] <X3> Build started at 20100731-2304 downfrom here seems bad
[20:47] <X3> darcs_2.4.4-1.dsc exists in cwd
[20:47] <X3> sh: gcc: not found
[20:48] <X3> and below is worst
[20:48] <micahg> tumbleweed: ah, thanks, so, is it a regression is a package stopped shipping those?
[20:49] <X3> though idk if that a reason for it to fail, just pointing at it
[20:49] <Laney> yeah that is interesting
[20:49] <X3> prolly
[20:50]  * X3 goes away
[20:50] <Laney> but gcc is in build-essential
[20:52] <tumbleweed> micahg: as I read it, only if another package needs them for it's own .la files. But I don't have any experience with that issue myself
[20:52] <micahg> tumbleweed: k, thansk
[20:57] <Laney> and it even does get installed
[20:57] <Laney> whatever could be going on here? :(
[20:58] <tumbleweed> there was a new gcc-4.5 last night, causing some dependancy issues in my pbuilders
[20:59] <Laney> happened before yesterday
[20:59] <tumbleweed> I assume it's sorted out (waiting for my mirror to sync)
[20:59] <Laney> even successful builds have this though: http://launchpadlibrarian.net/52685301/buildlog_ubuntu-maverick-i386.smuxi_0.7.2.2-1_FULLYBUILT.txt.gz
[21:40] <lucas> can we create teams on launchpad and automatically get an associated public mailing list?
[21:40] <lucas> or are mailing lists still managed separately?
[21:40] <lucas> (still *only* managed separately)
[21:40] <Laney> I don't know about automatically, but teams can have MLs now
[21:40] <lucas> ok, good
[21:40] <Laney> (→ #launchpad)
[21:40] <james_w> lucas: no, you can do that, but it requires that everyone that wants to subscribe join the team
[21:41] <lucas> that would be fine. it would be a "process sync requests for DDs" team.
[21:45] <lucas> is there a reason why --lp isn't the default for requestsync?
[21:45] <micahg> does it still require launchpadlib setup?
[21:45] <lucas> likely, but it's so much user-friendly
[21:46] <tumbleweed> yes, but the manpage tells you exactly what to do. (we assume ubuntu developers can read manpages)
[21:46] <geser> micahg: afaik yes as I don't remember any changes regarding this
[21:46] <micahg> lucas: my guess is that's why --lp isn't default then ^^
[21:47] <tumbleweed> micahg: the alternative is to have a mail set up, right?
[21:47] <geser> lucas: as the --lp option got introduced some persons mentioned that they preferred email as standard and as nobody proposed to changed that it didn't get changed yet
[21:48] <geser> tumbleweed: an open port 25 into the internet is enough
[21:48] <tumbleweed> lucas: where's the delay with sync requests for DDs? It's rare to see sync requests on the sponsor queue for more than a day or two. (but ACKed requests can take a while to be processed)
[21:48] <lucas> tumbleweed: well, it was to propose a solution for people who don't want to create an LP account
[21:48] <lucas> and also, to have a requestsync that does the right thing by default ;)
[21:49] <lucas> my proposal would be:
[21:49] <tumbleweed> geser: ok, I assumed it required a mailserver, so I used --lp from day 1
[21:49] <lucas> - document requestsync for people who have a LP account (preferably with --lp)
[21:49] <lucas> - have a team that can forward the requests for others
[21:57] <geser> lucas: do you know how much demand for such a team exists? (to forward sync requests from persons who don't want a LP account)
[21:58] <lucas> I don't know, I just want to have a fallback solution ready in case people complain about the requirement to create an account on LP
[21:58] <lucas> (which I could understand)
[22:01]  * tumbleweed handles sync requests from a debian sponsor of mine (who has an LP account but isn't interested in learning ubuntu procedures)
[22:16] <Rhonda> hmm.
[22:16] <Rhonda> I just uploaded pgadmin3 to Debian - how long should I wait for doing the syncrequest? It's a bugfix release, and it potential fixes some of the launchpad bugs.
[22:17] <crimsun> as soon as it appears in incoming, it's fair game ;)
[22:18] <Laney> even before that
[22:18] <Laney> as soon as you have the dsc :)
[22:18] <Rhonda> *blinks* :)
[22:19] <Rhonda> I have the dsc even before I uploaded it to Debian. :)
[22:19] <Laney> indeed
[22:19] <Laney> if you so wished, you could upload that
[22:19]  * hyperair dangles syncpackage in front of Rhonda 
[22:19] <Rhonda> syncpackage? Not requestsync?
[22:19] <Laney> but really I'd wait until rmadison knows about it and file a normal sync request
[22:19] <Laney> unless you can't wait for some reason
[22:20] <Laney> syncpackage is a script to upload syncs yourself
[22:20] <crimsun> why isn't syncpackage in lucid-* ? :/
[22:20] <Rhonda> I definitely can wait as long as maverick can wait (and it can AIUI). :)
[22:20] <Rhonda> syncpackage is in squeeze :P
[22:20] <Laney> crimsun: isn't it in ubuntu-dev-tools/lucid?
[22:21] <crimsun> Laney: not that I can find
[22:21] <Laney> it's reasonably new, could be post-lucid
[22:21] <Laney> bzr branch lp:ubuntu-dev-tools
[22:21] <geser> no, syncpackage was left out on purpose from u-d-t on lucid
[22:22] <hyperair> Laney: ubuntu-dev-tools in maverick has it.
[22:22] <Laney> I know
[22:22] <Laney> used it just today
[22:22] <crimsun> bah, I'm running lucid for hysterical raisins
 pgadmin3 1.10.5-1 uploaded by Gerfried Fuchs <rhonda@debian.at>
[22:22]  * hyperair has had it in ~/bin since before u-d-t had it
[22:22] <Rhonda> So incoming has it. :P
[22:22] <Laney> yeah I had pitti's version too
[22:23] <hyperair> Rhonda: so syncpackage and dput it. =D
[22:23] <Laney> Rhonda: requestsync won't let you do it until dinstall has grabbed it
[22:23] <Laney> urgh, why?
[22:23] <crimsun> as someone who has broken the archive before, I'm a bit hesitant to run stuff like it :p
[22:23] <Laney> I really think that should only be for the non-default urgent case
[22:23] <hyperair> hmm? break the archive how?
[22:23] <Rhonda> hyperair: Too much of a burden me thinks. ;)
[22:23] <hyperair> haha
[22:24] <crimsun> hyperair: I broke gcc for all 64-bit arches via an alsa-lib upload many releases ago.
[22:24] <geser> syncpackage is still in some "gray" area as the AA didn't say if it's okay to use it or not, there is a preference though to have it directly in LP
[22:24] <hyperair> crimsun: wait, how does gcc break on an alsa-lib upload?
[22:24] <crimsun> hyperair: a combination of lib32 hilarity on both packages
[22:25] <Laney> In general I wonder what the big rush is :)
[22:25] <hyperair> crimsun: eh, but how is that caused by syncpackage?
[22:25] <crimsun> hyperair: it isn't related at all. I'm referring to my hesitation to run syncpackage for that reason.
[22:26] <geser> Laney: I guess everybody is warming up for late uploads before FF on Aug 12th :)
[22:26] <hyperair> @_@
[22:30] <ari-tczew> what about sponsorship for patches attached before FF?
[22:31] <ari-tczew> I mean about situation when I'll prepare a patch and it will stay in sponsors-queue till FF and it won't be sponsored.
[22:31] <hyperair> you'll just have to get desperate and ping people.
[22:32] <ari-tczew> no, I won't prepare FFe. Patches atatched before Aug 12th should be sponsored without FFe.
[22:32] <hyperair> ari-tczew: the deadline is there for testing purposes. it has to enter the archive, with time for new bugs to be found and fixed before archive.
[22:32] <hyperair> i mean before release.
[22:33] <hyperair> i'm sorry, but i won't sponsor anything that is not a bugfix upload post-FF without FFe approval.
[22:34] <Laney> you should account for such delays when preparing uploads
[22:34] <ari-tczew> hyperair: so if I'll prepare a patch for merge Aug 11th and my patch won't be sponsored (late) do I have to prepare FFe?
[22:35] <hyperair> ari-tczew: if it requires it, yes.
[22:35] <ari-tczew> I mean about main component mainly.
[22:35] <hyperair> even more so.
[22:36] <ari-tczew> ok, 1-2 days before FF are too late, I could understand. But if I'll prepare a patch 5 days before FF and my patch won't be sponsored till FF, I won't prepare FF.
[22:36] <ari-tczew> ...prepare FFe
[22:37] <hyperair> then your patch won't get sponsored until the next release.
[22:37] <iulian> Why not?
[22:37] <hyperair> unless someone else prepares FFe for you.
[22:37] <iulian> ari-tczew: ^
[22:38] <hyperair> because he's missing the entire point of having a FF.
[22:38] <ari-tczew> iulian: sorry, I'll prepare a patch during before FF time.
[22:40] <iulian> ari-tczew: So when we enter Feature Freeze, you stop making patches?
[22:40] <iulian> Just because we're in FF?
[22:41] <ari-tczew> iulian: listen, now I prepare merges. Not every merge will fix any bug. I won't got time for looking merges which could fix bugs.
[22:42] <tumbleweed> my feeling is: your bugs awaiting sponnsorship are still. If Build-dependancies change incompatibly, or a newer version appears in debian, or Ubuntu enters FF, etc. you need to fix it. If you wait for a sponsor to tell you that and reject it, you are just wasting a sponsors time.
[22:42] <tumbleweed> "...are still your bugs"
[22:42] <ari-tczew> and FFe takes more time
[22:43] <tumbleweed> you can take that attitude, but it won't help get your requests approved
[22:44] <ari-tczew> tumbleweed: in my opinion should be following: all requests filled before FF should be sponsored even during FF, because they are prepared on time.
[22:45] <tumbleweed> ari-tczew: there are requests in the sponsorship queue that were filed before maverick development started
[22:45] <tumbleweed> we don't go merging those during feature freeze
[22:47] <tumbleweed> yeah, it's a pain when FF rolls around and you have things in the queue. If you want to be sure that you don't run into issues, start adding FFes. If you want to take the risk of them not being accepted, don't.
[22:49] <ari-tczew> tumbleweed: I see no reason for prepare FFe request if merge doesn't fix any important bug.
[22:51] <tumbleweed> fair enough
[22:52] <ari-tczew> iulian: even I stop making patches during FF, what does it matter?
[22:54] <iulian> ari-tczew: It's up to you.
[22:59] <ari-tczew> iulian: I don't understand. Please say directly what do you think.
[23:03] <iulian> I think that you should not stop making patches during FF.
[23:07] <ari-tczew> iulian: why?
[23:08] <iulian> Because they might be important for us.
[23:08] <pablohof> hi, i'm building a package where i need to restart apache after processing python-support triggers, but postinst is called before. any idea if this is possible and how to do it ?
[23:09] <micahg> ari-tczew: you might just want to get the FFe first, before doing teh work if one is required
[23:11] <ari-tczew> micahg: you mean about doing work 1-2 days before FF right?
[23:11] <micahg> ari-tczew: I was actually talking about after FF, but that might work too
[23:12] <ari-tczew> iulian: how does it compare to my motu application?
[23:22] <ari-tczew> iulian: do you think that if I don't make patches during FF, I'm useless member?
[23:23] <ari-tczew> come on, just say
[23:25] <hyperair> ari-tczew: patches are made as necessary. otherwise i'm a useless MOTU.
[23:26] <ari-tczew> hyperair: congrats
[23:26] <hyperair> why, thank you.
[23:26] <micahg> hyperair: so, do think that sqlite issue is sqlite based or banshee based?
[23:27] <hyperair> micahg: i'm tempted to say sqlite, but i haven't heard about any sqlite regression with any other application.
[23:27] <hyperair> micahg: so it could be just the way banshee uses sqlite.
[23:28] <hyperair> perhaps banshee uses sqlite in a way that wasn't intended. or perhaps banshee uses sqlite in a way that exposes a bug in sqlite.
[23:28]  * hyperair shrugs
[23:28] <hyperair> it's really hard to tell.
[23:28] <micahg> hyperair: right, I haven't seen anything else either, I'll keep an eye on sqlite, have you checked b.g.o for other issues?
[23:29] <hyperair> micahg: nope.
[23:29]  * hyperair checks
[23:30]  * Laney is generating comparative logs
[23:30] <hyperair> Laney: thanks, that would be useful.
[23:31] <Laney> whichever one it's on now is seriously lengthy
[23:31] <hyperair> micahg: nothing based on a search for sqlite.
[23:31] <Laney> 65507ms
[23:31] <hyperair> whoa, that's really bad.
[23:31] <hyperair> is it CPU or IO-bound?
[23:31] <Laney> clu
[23:31] <Laney> cpu
[23:31] <hyperair> hmm
[23:32] <hyperair> that makes it even worse.
[23:32] <Laney> It's the DELETE FROM CoreCache queries
[23:33] <hyperair> well, i'm off to go back to sleep. (shouldn't have stared at the computer after waking up for a drink of water)
[23:33] <Laney> seeya
[23:33] <hyperair> Laney: it might be a good idea to consult with people in #sqlite.
[23:33] <hyperair> and yeah, seeya =)
[23:33] <Laney> I'll be going to bed myself in a minute
[23:34] <Laney> will upload logs to the bgo bug, but yeah, tomorrow
[23:35] <micahg> I'll keep an eye on sqlite bugs in case anyone reports other issues
[23:48] <Laney> yeah that is a significant performance hit
[23:49] <micahg> Laney: well, there are already a few bugs scheduled for 3.7.1, so my geuss is it'll be released relatively soon, so if we find out if there's an issue with sqlite, we can get that in too
[23:50] <Laney> micahg: are you seeing it?
[23:50] <micahg> Laney: no, I'm not on maverick yet
[23:50] <micahg> I guess I can backport sqlite and check