[00:35] <ari-tczew> could anyone send to pastebin for me default .dput.cf file? I need a [ubuntu] field
[00:37] <micahg> ari-tczew: for PPA?
[00:37] <ari-tczew> micahg: nope, for oficial archive
[00:37] <micahg> ari-tczew: you don't need anything in .dput.cf for that AFAIK
[00:38] <ajmitch> it should be set already in /etc/dput.cf
[00:38] <ajmitch> tab-completion should even work for it if you've got that enabled
[00:38]  * micahg can just dput source_changes
[00:40]  * ari-tczew is waiting for ftp ACK
[00:41] <micahg> ari-tczew: archive is frozen, so any package needs a manual push
[00:41] <lfaraone> micahg: I didn't think that was true for Universe.
[00:41] <micahg> lfaraone: it's true, but you don't need a release team ACK AFAIK
[00:42] <ari-tczew> micahg, lfaraone: I uploaded lucid-proposed package. :)
[00:42] <ajmitch> archive can only be frozen as a whole
[00:42] <micahg> ari-tczew: ah, so that sits in unapproved until SRU ack
[00:44] <micahg> lfaraone: https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html
[00:51] <persia> lfaraone, Freeze isn't main/universe, really.  It's in-flavour-packageset/not-in-flavour-packageset
[00:51] <persia> Stuff in Xubuntu, Mythbuntu, or Ubuntu Studio usually still needs a wave from the respective teams.
[00:52] <persia> And some stuff in main gets waved through without significant consideration (not part any of the above *or* any of Ubuntu (GNOME) or Kubuntu or Server)
[00:57] <ari-tczew> persia: well, if I have a security patch for amsn (universe), can I upload it without freeze exception?
[00:57] <persia> ari-tczew, So, in which tasks are the binaries produced by that source?
[00:59] <ari-tczew> persia: tasks?
[00:59] <persia> Yes, tasks.
[01:00] <ari-tczew> persia: do you mean e.g. maverick?
[01:00] <persia> No.
[01:00] <persia> Try running `apt-cache show unity` and `apt-cache show quassel`  Look for the "Task" lines.
[01:01] <micahg> ah, cool, you said that last night, but wasn't sure what it meant
[01:02] <persia> Anyway, by looking at the Tasks for a binary, it is possible to tell if it belongs to an image.
[01:02] <persia> There's a few packages that end up on images without that, but they tend to be deep core, and most folk don't touch them.
[01:03] <persia> (You'll probably get a nervous feeling as you start to investigate the bug, and want to ask someone in -devel about it :) )
[01:04] <persia> But, essentially, if none of the produced binaries are in any Tasks, there's a very good chance you can just upload it (assuming it needs uploading because it's important)
[01:04] <persia> Generally that means stuff that would end up being security or sru bugs anyway if they weren't fixed first.
[01:04] <persia> If stuff is in a task, it's best to go chat with the folks that coordinate that task (usually easy to figure out from the name)
[01:04] <ajmitch> security bugs (like what you've said for amsn) tend to be fairly important to fix
[01:05] <ari-tczew> persia: $ apt-cache show amsn didn't show me "Task" field
[01:07] <persia> ari-tczew, OK.  try for *every* binary your package produces.  That means `apt-cache showsrc amsn | grep ^Binary` and then checking each of those.
[01:07] <ajmitch> not that it builds many :)
[01:07] <persia> There are one-liner shell reciepts for this, but I don't wish to contribute to any grimoires today (and it's usually not hard to check)
[01:08]  * ari-tczew sometimes thinks that policies were created against contributors.
[01:08] <persia> ajmitch, Well, no, but the point is to go through the process to check correctly, whether it's important or not, in case next time is important :)
[01:08] <micahg> persia: sounds like a good candidate for u-d-t
[01:08] <ajmitch> persia: I know, just saying that this time it'll be simple to check
[01:08] <persia> micahg, It's a one-liner (think grep, cut, sed, for)
[01:08] <micahg> persia: yes, but 'check-tasks source' is a lot shorter :)
[01:09] <persia> ari-tczew, How is this policy against contributors?  The idea is not to break the release candidates without communicating about it.
[01:09] <ajmitch> a way to avoid getting yelled at because you just broke something that's going onto a cd image to be tested
[01:09] <persia> micahg, write it if you like: using python-apt or similar, you can probably make it cleaner.  Might be interesting to add a --lp option that checked packagesets rather than tasks
[01:09] <ari-tczew> persia: I checked amsn and amsn-data. there are no task fields.
[01:10] <micahg> persia: I'm not familiar enough w/python
[01:10] <ajmitch> micahg: it's not too hard thankfully :)
[01:11] <micahg> persia: is it a requirement for scripts in u-d-t to be in python?
[01:12] <persia> ari-tczew, In that case, you don't have to worry about someone screaming at you about breaking their image.  Next, be sure you would upload this as -security or -updates.  Once you're sure, upload.
[01:12] <persia> micahg, Nope.  All mine are in bash.
[01:12] <kklimonda> -updates? not -proposed?
[01:12] <micahg> persia: k, I'll just write a bash script then and submit it, someone else can make it better
[01:13] <ari-tczew> persia: ekhm, I'm thinking about maverick right now.
[01:13] <persia> kklimonda, Targeted towards -updates.  Or -proposed.  Doesn't matter.  The point is to think for 2 minutes to make sure a bug is *really* worth fixing in final freeze.
[01:13] <persia> ari-tczew, Right: think about maverick, but because maverick is frozen, be sure enough that you want to upload this that you'd have to upload it next month if you didn't do it now.
[01:14] <kklimonda> which reminds me - can anyone take a look at bug 629495?
[01:16]  * micahg thought gnome packages had a standing exception
[01:16] <ari-tczew> persia: today I heard twice suggestion to working after final release. I'm going to think that work during feature freeze will be useless.
[01:16] <persia> kklimonda, You need to resubscribe the release team when it's ready for revirew.
[01:17] <persia> ari-tczew, the point is that you want to know that the work you are doing would have to be done after release anyway.  Once you make the decision that it has to be done, you can upload it today.
[01:17] <kklimonda> persia: gnome packages do have the standing exception but sure, I can do that
[01:17] <persia> If you're doing work that you wouldn't bother doing post-release, go find something else: there's plenty of stuff that's just plain broken and unreleasable in the current state.
[01:19] <persia> kklimonda, If there's a standing exception, a member of the release team will just rubber stamp it.  Have no fear, but if you follow procedures, you're more likely to have people sure about the next step/.
[01:19] <kklimonda> persia: mhm, makes sense :)
[01:19]  * micahg still had 2 merges from Debian and 1 bzr merge before looking at the RC bug list
[01:19] <micahg> *has
[07:15] <bilalakhtar> How do I make REVU recognise that I am MOTU?
[07:15] <bilalakhtar> It seems to consider me as a 'contributor'
[07:15] <bilalakhtar> wgrant: ping
[07:19] <wgrant> bilalakhtar: I've just promoted you to Reviewer.
[07:19] <bilalakhtar> Thanks wgrant !
[07:20] <bilalakhtar> though I have to tell everyone that the FF ha crossed so no more new packages can come into maverick
[07:22] <wgrant> Yep.
[07:27] <bilalakhtar> Garr, there are a few packages which are having merge bugs on which devs has commented and want to get the merge/sync fixed, but the bug reporter has become unresponsive, hence blocking others from working on the merge
[07:28] <bilalakhtar> These kind of bugs are reported way back in june/july
[07:28] <bilalakhtar> blocked since then
[07:35] <bilalakhtar> Moreover, I asked a merger to either work on the merge or cloe it so that others could work
[07:35] <bilalakhtar> I did that a week or two ago, still no reply
[07:36] <bilalakhtar> Any suggestion on what should be done in such a case?
[07:49] <poolie> cjwatson: hi?
[07:53] <borealis> Hello! Does anyone has any information about how packages that depends on Qt is built? Is some qt-dev package installed on the build machine prior to building? Or do one operate with a QTDIR setup?
[07:53] <tumbleweed> bilalakhtar: if the developer is being unresponsive, you might as well just take it over. However, this is the wrong time in the release cycle to be doing merging (unless it's necessary)
[07:53] <micahg> borealis: add a build-depends?
[07:54] <bilalakhtar> tumbleweed: I take merges which fix bugs
[07:54] <bilalakhtar> so that is acceptable after Final F
[07:54] <tumbleweed> bilalakhtar: yes
[07:55] <tumbleweed> wgrant: aha, a REVU admin. Can I also have reviewer status please?
[07:55] <micahg> tumbleweed: I have 2 merges still, 1 that just brings brings us up with Debian (we have -0, they have -1) and one that needs an FFe that should be granted
[07:56] <tumbleweed> micahg: I was just pointing out that there's no need for bilalakhtar to chase after unecessary merges (that have stalled)
[07:56] <micahg> tumbleweed: ah :)
[07:56] <micahg> tumbleweed: I updated my SRU
[07:56] <bilalakhtar> ari-tczew: well, thanks for looking at my memo, well, everythings over now! :)
[07:57] <micahg> tumbleweed: which local build engine do you use?
[07:57] <bilalakhtar> tumbleweed: got one SRU accepted in proposed, the other is awaiting approval into proposed
[07:57] <ari-tczew> bilalakhtar: I didn't know about memos.
[07:58] <tumbleweed> micahg: pbuilder
[07:58] <wgrant> tumbleweed: Done.
[07:58] <micahg> tumbleweed: does that do more checks than a standard chroot?
[07:58] <tumbleweed> wgrant: thanks
[07:59]  * micahg still hasn't logged into pbuilder to set up updates
[07:59] <tumbleweed> micahg: I have some pbuilder hooks
[07:59] <micahg> tumbleweed: ah
[08:01] <borealis> micahg: Excuse me, but I'm a bit new to this. A build-depends will see to that the appropriate package is installed to the build machine before the build of your package takes place, right?
[08:01] <micahg> borealis: correct
[08:55] <Tetsuo55> to confirm, my request is going in the right direction? https://bugs.edge.launchpad.net/ubuntu/+source/cppcheck/+bug/640655
[09:44] <cjwatson> poolie: pong
[11:59] <Wubbbi> Hey guys. I wanna change the default about:config of firefox in the source-code so when I build and install it, the about:config I did in the Source-Code is taking effekt now.
[12:00] <chrisccoulson> Wubbbi, this isn't really the right place to ask your question
[12:00] <chrisccoulson> but what are you trying to do anyway? i'm not sure if i follow....
[12:00] <Wubbbi> chrisccoulson: The #ubuntu-devel and #ubuntu+1 send me here.
[12:00] <chrisccoulson> hmmm :/
[12:03] <ari-tczew> #ubuntu-mozillateam ?
[12:06] <gnomefreak> chrisccoulson: i sent him here as #ubuntu+1 does do packaging. there used to be -packaging i thought but eh.
[12:07] <gnomefreak> Wubbbi: you need to know what you want to change since there is no "file" but a few files
[12:08] <Wubbbi> gnomefreak: well after a while I found it now. I'm gonna change it. This will add by default the option to go back by pressing the Backspace key. I think this is more confortable. Do you wanna have that in Ubuntu too?
[12:09] <chrisccoulson> we generally don't deviate from upstream defaults, especially those that modify fundamental behaviour like that
[12:09] <gnomefreak> Wubbbi: we are keeping it this way for now
[12:09] <gnomefreak> ^^ for your changes
[12:09] <chrisccoulson> Wubbbi - what are you going to do with the package anyway? is this just for your own install?
[12:11] <Wubbbi> chrisccoulson: first its only for me. But I only change a default about:config setting. If you want to you can have it to. It will just change a Value in the default about:config nothing more. It is more confortable then and it is the default way as in windows. Well only if you want. Just 1 changed Value
[12:12] <gnomefreak> why do i get this feeling it is altering upstream source
[12:13] <gnomefreak> Wubbbi: where did you get the source from?
[12:14] <chrisccoulson> Wubbbi, please take a look at http://www.mozilla.org/foundation/trademarks/policy.html before you consider re-distributing your package
[12:14] <Wubbbi> gnomefreak: Maverick - apt-get source firefox
[12:14] <gnomefreak> Wubbbi: k
[12:14] <Wubbbi> chrisccoulson: I wont change firefox code. I will add a patch to change the Value from "2" to "0" ... not more. Its just a setting changed. I wont change any programm code!
[12:15] <chrisccoulson> it's a fundamental change to browser behaviour which deviates from what mozilla distribute on linux
[12:15] <chrisccoulson> so it doesn't matter
[12:16] <chrisccoulson> (ie, it doesn't matter if it's a code change or not)
[12:17] <Wubbbi> chrisccoulson: ok ... So do you wanna have it? I can send you the patch and if you want to you can test your self. its realy better than always clicking on the "Back" buttom. Also its the default setting on Windows firefox
[12:17] <chrisccoulson> no, we don't want to change that, but thanks anyway
[12:17] <Wubbbi> hmmm ok
[12:17] <Wubbbi> what ever you want
[12:18] <chrisccoulson> i couldn't think of anything more confusing. backspace is for removing characters in text boxes
[12:18] <chrisccoulson> alt+left arrow are for going back, which users can already use if they want to use the keyboard
[12:19] <Wubbbi> well ok. I use firefox on windows and there it is with backspace. Well I dont care. I have my own settings now and I'm happy
[12:19] <Wubbbi> M)
[12:19] <Wubbbi> ;)
[12:31] <playya__> even on windows both should work
[15:05] <bilalakhtar> Amaranth: there?
[15:06] <Amaranth> bilalakhtar: A bit
[15:06] <bilalakhtar> Amaranth: :) What would you say about bug #111896 ?
[15:07] <bilalakhtar> For some reason, that bug doesn't have useful info and no good user cases, yet its triaged
[15:08] <Amaranth> bilalakhtar: Yeah, that's goofy
[15:09] <Amaranth> But it doesn't really matter, alacarte will be kaput in GNOME 3.0 and hasn't been worked on in like 2 years
[15:09] <bilalakhtar> well, alacarte was never slow for me
[15:10] <Amaranth> bilalakhtar: It doesn't pop up instantly but it looks like an incredibly simple problem, thus it must be slow
[15:11] <Amaranth> Even a rewrite C with the most efficient lazy loading of menus I could manage it takes just under a second on my computer
[15:12] <bilalakhtar> well, as you said it will be done for in GNOME 3 then, we are only one more release away from it
[15:12] <bilalakhtar> it shall come by natty
[15:13] <bilalakhtar> brb
[21:07] <ScottK> fabrice_sp: Why is disabling tests on creolparser a good idea?
[21:08] <fabrice_sp> ScottK, to fix the FTBFS
[21:08] <ScottK> fabrice_sp: But does it produce a working package (i.e. are the test failures real)?
[21:08] <fabrice_sp> the other fix does not seem to be the right way (changing the installation directory)
[21:08] <ScottK> Does the updated package work?
[21:09] <fabrice_sp> yes
[21:09] <fabrice_sp> the package should be change to make the test later during the build
[21:10] <fabrice_sp> (when the python executable is in a non arch dependent directory)
[21:11] <fabrice_sp> ScottK, http://paste.ubuntu.com/495513/ )(with the instalation and importO)
[21:12] <ScottK> fabrice_sp: OK.  I can accept this for now, but would you please figure out the proper fix and send it back to Debian?
[21:12] <fabrice_sp> ScottK, sure: I was going to ping someone in python channels, as they rejected the previous fix. It builds fine in Debian
[21:12] <fabrice_sp> (tests are not executed there)
[21:12] <ScottK> OK.
[22:47] <sistpoty> ari-tczew: congrats to your motu-ship :)
[22:47] <ari-tczew> sistpoty: thanks :) your comment was useful.
[22:48] <sistpoty> :)
[22:49] <micahg> is MoM broke again?  It's not updating
[22:51] <sistpoty> no idea, but it *shouldn't* be too useful at this state of the release :P
[22:51] <ari-tczew> +1 ^^
[22:51] <ari-tczew> micahg: maybe lucas merges will be useful for you
[22:52] <micahg> ari-tczew: lucas merges?
[22:52] <micahg> sistpoty: only 1 new version that I need, the rest is just merging a -0 to a -1
[22:52] <ari-tczew> micahg: http://people.ubuntuwire.org/~lucas/merges.html
[22:53]  * micahg wonders why that isn't bookmarked yet :)
[22:53] <micahg> thanks ari-tczew
[22:53] <ari-tczew> np
[22:53] <micahg> the important one is on there at least :)