[02:07]  * hyperair kicks lightdm
[02:08] <hyperair> it refuses to log me in, and i don't see *ANYTHING* in the logs.
[03:20] <hyperair> okay, so removing ~/.Xauthority did the trick.
[03:20]  * hyperair sighs
[03:20] <hyperair> it would be nice if lightdm actually said something somewhere about this
[03:21] <micahg> hyperair: sounds like a bug somewhere unless you were tinkering with the file manually
[03:21] <hyperair> micahg: i don't know, really
[03:21] <hyperair> micahg: what creates .Xauthority?
[03:21] <hyperair> besides lightdm?
[03:21] <hyperair> i had a root-owned .Xauthority for some reason
[03:22] <micahg> sorry, this is one area i know very little about, maybe robert_ancell could help
[04:22] <pitti> Good morning
[07:11] <dholbach> good morning
[08:12] <cjwatson> tkamppeter: it looks as though c2esp needs to be updated to version 26~rc4 or so to handle cups 1.6 (it's showing up on http://people.canonical.com/~ubuntu-archive/nbs.html) - is that something reasonable that you could take care of, or does it need the relevant changes to be backported instead, or ...?
[08:56] <dupondje> We stay on kernel 3.5 for quantal?
[09:37] <cc11rocks> Hey guys. Just started fixing bugs today. Fixed 15 spelling/grammer <package>/debian/control files (package descriptions). I have already proposed them. If you want to accept them : https://code.launchpad.net/~cc11rocks
[09:38] <cc11rocks> Goodnight everyone
[09:38] <cc11rocks> Will try to find time when I get up to do a few more
[09:38] <cc11rocks> Takes approx. 4-5 min for each fix total (downloading, etc)
[09:48] <cjwatson> Sigh, if I'd caught cc11rocks in time I could have advised him to stop and submit to Debian instead
[09:48] <cjwatson> I've commented on one of the MPs to that effect
[09:49] <cjwatson> dholbach: ^- we should amend our docs somehow to discourage this - it's well-meaning but new people don't realise the ongoing merge cost it incurs and it ends up filling up sponsorship queues
[09:49] <xnox> cjwatson: I believe typpos is one of the developer initiatives we are running =) so I guess we should accept them & push to debian.
[09:49] <cjwatson> If it is that is horrendously misguided
[09:49] <cjwatson> We should stop
[09:50] <seb128> cjwatson, I think it's https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[09:50] <cjwatson> We should be making rational cost-benefit analyses here, not "developers at all costs"
[09:50] <cjwatson> Sigh
[09:51] <pitti> yeah, I used to reject those MPs as well and sent the diff as Debian bugs instead
[09:51] <seb128> that page is a bit misleading
[09:51] <seb128> it does ask to open a mr first then adds
[09:51] <seb128> "There are obviously more packages to be fixed, but as they are also in Debian, we'd prefer to get them fixed in Debian, so you might want to take these steps as well: "
[09:51] <cjwatson> It does have a tiny note at the bottom that you might want to submit to Debian
[09:51] <MCR1> cjwatson: I would prefer software without spelling errors, so if someone takes the time to fix those they should ofc be accepted. Why not ?
[09:51] <seb128> yeah, it should probably be the other way around
[09:51] <cjwatson> MCR1: Because there is a significant ongoing cost in diverging from Debian
[09:52] <seb128> MCR1, because the fix should directly go where it's useful for everyone and less work to maintain
[09:52] <cjwatson> MCR1: I too prefer software without spelling errors; what I'm saying is not that they should not be fixed, but that they should be sent directly to Debian rather than going via merge proposals to Ubuntu
[09:52] <MCR1> Then those should be somehow pushed upstream
[09:52] <cjwatson> That's what I'm saying!
[09:52] <MCR1> ok
[09:52] <cjwatson> The submitter should do that directly
[09:53] <cjwatson> It's no harder than preparing merge proposals (arguably easier - there's a different learning curve I suppose but the technology stack involved is simpler)
[09:54] <cjwatson> I don't think this is cc11rocks' fault in any way, just that he should be given better direction
[09:54] <seb128> we should reverse the instructions' order on that page
[09:55] <seb128> tell them to first send to Debian (if it applies there), then to open a m-r with a link to the debian bug
[09:55] <cjwatson> In general people should only do one of those; we should be careful to avoid advising them to do both
[09:55] <cjwatson> Otherwise duplicate effort etc.
[09:55] <pitti> I don't think we ever want MPs for those
[09:56] <cjwatson> And if that fails some kind of "should be of direct benefit to Ubuntu" test, perhaps we should consider advising people to do other things
[09:56] <seb128> right, that's what I was going to say, I think the idea is to get people contribute to Ubuntu (directly)
[09:56] <seb128> so maybe those typo fixes are not what we should recommend
[09:56] <seb128> dholbach, ^
[09:57] <cjwatson> It's a good classroom exercise for preparing merge proposals, but ...
[09:57] <xnox> I am ok with highly visible spelling error fixes. E.g. fontconfig started complaining a lot -> visible on the stderr on every app launch -> had a spelling mistake and we fixed it cause we are pedantic like that
[09:58] <xnox> if on the other hand the spelling error is GB vs US locale in an error message I will never see in a low-popcon package....
[09:58] <cjwatson> And for errors in things that are Ubuntu-specific
[09:58] <xnox> yes
[09:58] <cjwatson> But most new contributors won't have the ability to discern that, more or less by definition
[09:58] <cjwatson> Except in the odd obvious case
[09:59] <cjwatson> (Agreed on fontconfig - that was bugging me just this morning)
[09:59] <Laney> those warnings are irritating me enough that I will probably take some time to fix some of them this week
[09:59] <Laney> and I've seen some people worries in bug reports
[10:00] <pitti> xnox: you mean fontconfig s/was/fixed/will be fixed/? it's still complaining a lot here (but then this doesn't seem to be a simple typo)
[10:00] <Laney> there was some english error in the warning message
[10:00] <xnox> pitti: it used to complain with a spelling error. Now it complains in correct Queen's English.
[10:00] <seb128> pitti, I think he said the error message has a typo
[10:00] <MCR1> xnox: Apropos fontconfig :) - I've fixed a bug in font-manager - Can I speed up the merge of this somehow ? : https://code.launchpad.net/~mc-return/font-manager/font-manager.fix-961034/+merge/114991
[10:01] <pitti> oh, the "may not works", I guess
[10:01] <cjwatson> xnox: Either your fix hasn't landed yet, or your fix was buggy :-)
[10:01] <cjwatson> (If that was yours)
[10:02] <cjwatson> Fontconfig warning: "/etc/fonts/conf.d/25-wqy-zenhei.conf", line 11: Having multiple values in <test> isn't supported and may not works as expected
[10:02] <xnox> cjwatson: it was not mine =) I saw it somewhere
[10:02] <xnox> oh well, it's still there
[10:02] <MCR1> haha, yes I know this error message :)
[10:03] <xnox> MCR1: it's annoying as hell =) i get a screenful of them on every xdg-open call
[10:03] <MCR1> hehe
[10:05] <seb128> xnox, there is a bug with the details, I pointed to a diff to fix one of the package and gave details on how to fix those
[10:05] <seb128> xnox, I just didn't have time to work on them before ff
[10:14] <seb128> ogra_, infinity: thanks for the unity fixes, could you guys commit them to the vcs?
[10:14] <ogra_> nope
[10:14] <seb128> ogra_, why not? ;-)
[10:16] <xnox> no commit access to lp:unity?
[10:16] <ogra_> because the packaing has to be fixed anyway, whoever that does can pull in the fixes in one chunk ....
[10:18] <seb128> xnox, the packaging is lp:ubuntu/unity and those who can upload can commit there ;-)
[10:19] <xnox> seb128: meh =) for ubiquity we use lp:ubiquity only
[10:19] <seb128> xnox, bad you guys, no cookie
[10:19] <ogra_> xnox, desktop is a bit weird in that regard :)
[10:20] <seb128> ogra_, lp:ubuntu/... is not the desktop weird way :p
[10:20] <seb128> ogra_, the desktop weird ones are lp:~ubuntu-desktop/source/ubuntu
[10:20] <ogra_> oh, indeed, sorry :)
[10:21] <cjwatson> lp:ubiquity is because it's a native package
[10:22] <cjwatson> Which is a choice I'm happy to defend since it's the Ubuntu installer and not really intended for use elsewhere
[10:22] <cjwatson> If anyone ever gets to the point of being able to use it elsewhere then we might reconsider that
[10:23] <seb128> cjwatson, the only issue I have with those is that it means coredev doesn't have commit access to the vcs
[10:23] <cjwatson> Well
[10:23] <seb128> but it's not the end of the world, and not like ubiquity needed uploads from people out of the ubiquity team often
[10:23] <cjwatson> We could fix that by making ubuntu-core-dev a member of ubuntu-installer, and almost certainly should
[10:23] <cjwatson> The only reason I haven't is that I wanted to think about what that would do to bugmail
[10:24] <seb128> well, then it means you might give access to trunk to more people than you want to
[10:24] <cjwatson> I'm happy for anyone in core-dev to have commit access
[10:24] <cjwatson> I suspect that we should have separate "commit access" and "bug mail" teams
[10:24] <seb128> right
[10:31] <tkamppeter> cjwatson, I will update c2esp to said version. Thanks for the hint.
[10:33] <seb128> tkamppeter, what version? with the patch I sent you?
[10:34] <cjwatson> 09:12 <cjwatson> tkamppeter: it looks as though c2esp needs to be updated to version 26~rc4 or so to handle cups 1.6 (it's showing up on http://people.canonical.com/~ubuntu-archive/nbs.html) - is that something
[10:34] <cjwatson>                  reasonable that you could take care of, or does it need the relevant changes to be backported instead, or ...?
[10:34] <cjwatson> seb128: ^-
[10:34] <seb128> cjwatson, thanks, I had a patch locally to fix the ftbfs and I emailed it to Till for feedback but that staled since
[10:35] <seb128> nice to see that upstream fixed it though ;-)
[10:35] <seb128> I couldn't find their vcs by then
[10:39] <dholbach> cjwatson, on the wiki page I advertised only Ubuntu-only packages and mention submit to Debian (and how to submit) a couple of times - https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[10:40] <dholbach> it looks like c11rocks picked a bunch of others
[10:40] <dholbach> I'll try to make it even clearer
[10:40] <dholbach> and start a discussion on the mailing list about getting some help picking "useful, but easy" things
[10:42] <cjwatson> thanks
[10:45] <Laney> I suppose it's pretty hard though, since if the fixes are useful and easy then they are likely to be fixed fairly rapidly by existing developers
[10:46] <dholbach> or we could try to bundle them - a lot of the packages which haven't been touched for a while might have multiple problems
[10:46] <dholbach> in any case I agree that as much as possible should be sent to Debian
[10:47] <dholbach> so I'll take care of that one
[10:48] <dholbach> but first I'll have to get lunch, so see you in a bit :)
[11:02]  * xnox If you use bzr-cia please pull new revision to get it working again!
[11:11] <ogra_> xnox, bug 1044717 (see last comment)
[11:12] <ogra_> i assume thats not arm specific ?
[11:12] <xnox> ogra_: uno momento misseur
[11:12] <ogra_> :)
[11:13] <xnox> ogra_: *sigh*
[11:14]  * Laney eyes xnox
[11:14] <ogra_> how did i know you would say that :)
[11:17] <xnox> ogra_: I swear I tested it......
[11:17] <ogra_> wel, i find it inbtresting that we dont drown in similar bugs from other arches
[11:23] <dupondje> We stay on kernel 3.5 for quantal?
[11:30] <ogra_> xnox, i can confirm it on my panda, exact same issue here
[11:30] <xnox> ogra_: yes. if you try to do something which needs to show warning box, it will fail.
[11:31] <xnox> on any arch
[11:31] <ogra_> ah, thats why we only see it on arm
[11:31] <Laney> I added it to the pad as a respin trigger
[11:31] <ogra_> its the only arch with a warning box by default
[11:32] <xnox> ogra_: installation medium mounted.....
[11:33] <ogra_> yep
[11:33] <ogra_> i still think we should just blantly hide the mmc
[11:34] <ogra_> (in desktop ... but keep it shown in i.e. netinst ...)
[11:34] <cjwatson> dupondje: that's my understandng
[11:34] <cjwatson> +i
[11:34] <cjwatson> "installation medium mounted" is liable enough to happen in other situations, so worth a respin on all arches
[11:35] <xnox> ogra_: can I send you a file to test?
[11:35] <ogra_> sure
[11:35] <dupondje> ok thx cjwatson  :)
[11:36] <xnox> ogra_: see PM
[11:36] <ogra_> cjwatson, whats your opinion on having the mmc (source media) show up at all in the partitioner ? it fails if you dont pre-format/pre-partition the device, i really think we shouldne encourage third party partitioning installs ... if users want to install to their source media they should better use netinst
[11:37] <ogra_> *shouldnt
[11:37] <cjwatson> There's a general attempt in partman to stop the installation medium showing up
[11:38] <cjwatson> Doing something that's specific to MMC is likely wrong
[11:38] <cjwatson> Feel free to improve the existing code if you can do it in a general way, though
[11:38] <cjwatson> Perhaps first try to understand why whatever your current situation is doesn't trigger the existing checks
[11:38] <xnox> cjwatson: partman prevents changing the partition table of the installation medium, but it still shows it's partitions for the installation mount points.
[11:39] <xnox> ogra_ proposes to not show installation medium partitions / disk at all
[11:39] <xnox> and the window saying "you cannot change the partition table" does show up in the d-i and ubiquity currently. (as seen on panda boards)
[11:41] <cjwatson> If there's no remaining usable space on a disk due to the installation medium consuming it all, then I would say we should hide the dis
[11:41] <cjwatson> *disk
[11:41] <cjwatson> I wouldn't be in favour of hiding individual partitions from a disk with usable space, since I think that could easily get confusing
[11:43] <xnox> cjwatson: ok. except that you can't change empty space =) so it has to be a pre-made partition or show nothing then?!
[11:43] <cjwatson> I don't understand the question
[11:43]  * ogra_ would already be fine with a preseedable option, we set aubarch specific kernel cmdlines anyway on the arm images
[11:43] <cjwatson> Which of the above two cases are you talking about?
[11:43] <cjwatson> ogra_: I wouldn't
[11:43] <ogra_> *subarch
[11:44] <cjwatson> ogra_: Similar situations arise in other cases where that is much less convenient; general code is always better where possible
[11:46] <xnox> ogra_: for desktop if the sd card is less than 9GB (1GB for the installer image + 8GB for the minimum ubuntu desktop install size) i think it makes hence to hide the installation media from the partitioner.
[11:46] <xnox> in the ubiquity installer.
[11:47] <cjwatson> xnox: Could you please expand on "except that you can't change empty space =) so it has to be a pre-made partition or show nothing then?!"?  I don't know which case you're talking about here.
[11:47] <Laney> how did the current fix test out?
[11:47]  * Laney would like that in soon if possible
[11:47] <cjwatson> We should never be silently hiding only some parts of a disk
[11:47] <ogra_> well, moving with cjwatson's argument from above yu could use a 2G partition on the SD as /home ;)
[11:48] <cjwatson> Indeed, which is why it is invalid to make deductions about free space usability based on the minimum desktop install size
[11:48] <cjwatson> Let's not do that
[11:48] <ogra_> (if it was pre-formatted and nothing treis to touch the partition table)
[11:48] <ogra_> *tries
[11:48] <xnox> cjwatson: right so. If I have an SD card: 300 MB FAT boot partition, 1.2GB ubiquity/installcd partition, the rest is empty (20GB) for example.
[11:48] <cjwatson> You can generally append to the partition table even if an earlier partition is mounted
[11:48] <xnox> ah
[11:48] <cjwatson> The thing you can't do is manipulate anything <= the latest busy partition
[11:49] <ogra_> cjwatson, well, it seems to be pretty fragile
[11:49] <ogra_> i get bugs about it occasionally but its not always reproducable
[11:49] <xnox> but partman doesn't seem to let me make any changes to the partition table. Not even "append" operation as you say technically is possible.
[11:49] <ogra_> (about partman trying to touch the part-table regardless)
[11:49] <cjwatson> It should permit it with a warning
[11:49] <cjwatson> This has worked in the past
[11:49] <xnox> hmm.... Ok will test again.
[11:49] <cjwatson> And it's important in some USB-related use cases
[11:50] <ogra_> it often enough works for me when i try to verify such a bug
[11:50] <cjwatson> ISTR that some $bigcorp factory install scenario relied on it
[11:50] <cjwatson> So please don't break it :-P
[11:50] <ogra_> but these bugs come up
[11:51] <xnox> cjwatson: =)))))) not only it's a bigcorp it also has monies on the front =)
[12:19] <dholbach> does anyone have an idea how to fix https://launchpadlibrarian.net/114487674/buildlog_ubuntu-quantal-i386.ubuntu-packaging-guide_0.2.3-0~135~quantal1_FAILEDTOBUILD.txt.gz?
[12:23] <tkamppeter> seb128, cjwatson, I have uploaded a fixed c2esp now, but note that I have used 25c with seb's patch, as the upstream change is a mess. It is untested,m according to the README, file and it seems to be written completely from the top of the head of the author, not working at all.
[12:24] <cjwatson> Fair enough
[12:24] <tkamppeter> seb128, sorry for getting to that only lately, I had higher-priority things like auto driver download integration into s-c-p iteself and CUPS USB fixes to do.
[12:24] <seb128> tkamppeter, no worry, thanks for getting that uploaded
[12:25] <seb128> tkamppeter, the s-c-p and cups work were higher priorities so you worker in the right order ;-)
[12:46] <tumbleweed> dholbach: as far as I can tell. missing build-dep on texlive-lang-cjk
[12:47] <dholbach> that'd be too awesome to be true
[12:47] <dholbach> let me try
[12:47] <tumbleweed> it's pretty confusing
[12:47] <dholbach> I tried all kinds of other things already, but if that's it, that'd be awesome :)
[12:48] <tumbleweed> but ja uses a different latex, which isn't pdflatex, causing the error we saw there
[12:55] <dholbach> tumbleweed, does 'make pdflatex-ja' work for you?
[12:55] <dholbach> for me it doesn't :/
[13:00] <tumbleweed> dholbach: it does, now
[13:03] <dholbach> hum, can you maybe pastebin the output of   dpkg -l | cut -d' ' -f3 | grep tex   somewhere? I might be missing something
[13:04]  * tumbleweed has quick play in a chroot
[13:25] <shadeslayer> seb128: telepathy-glib is depping on valac >= 18, but valac depends on valac-0.14
[13:25] <shadeslayer> causes telepathy-glib to go into build dep wait
[13:25] <seb128> shadeslayer, thanks
[13:25] <shadeslayer> np
[13:25] <seb128> it should depends on valac-0.18 I guess
[13:26] <seb128> Laney, cjwatson: ^ is that something you would like to see fixed for beta1 or should we keep it depwaiting?
[13:26] <shadeslayer> don't know enough about vala packaging to give my opinion =)
[13:27] <cjwatson> I think we only care if there are important bug fixes we don't in practice have on images due to the dep-wait
[13:27]  * Laney grumbles about alternate build-depends
[13:31] <tumbleweed> dholbach: erm, dirty environment :( . So, we need something like the first hunk of https://bitbucket.org/birkenfeld/sphinx/pull-request/33/style-fixes-to-handle-japanese-documents#chg-sphinx/texinputs/sphinx.sty
[13:32] <seb128> cjwatson, no, they are none, I will get that fixed after beta1
[13:51] <brendand> is there a version of pyflakes that likes python3?
[13:51] <cjwatson> I haven't found one; I just write code compatible with both Python 2 and 3 and it's OK with that
[13:52] <cjwatson> Aside from a few warnings about duplicate imports
[13:54] <dholbach> tumbleweed, great - I'll have a look
[13:55] <tumbleweed> dholbach: (and then a platex to build it, which was the missing build dep)
[14:19] <dholbach> tumbleweed, still no dice over here, but I updated the bug and subscribed you as well
[14:19] <dholbach> I'll have a look at it tomorrow again, now I need to finish some other bits first :/
[14:20] <tumbleweed> dholbach: not building the PDF on JA for now is the easy answer. JA PDFs are a weird special case
[14:24] <dholbach> tumbleweed, I guess you're right
[14:46] <rbasak> I'm going to need linux 3.2.0-30 in precise-updates d-i netboot for maas to deploy highbank correctly. It's got an RTC fix I need, and is in precise-proposed at the moment. What's the policy on bumping d-i in a stable release in order to get a new kernel?
[14:51] <cjwatson> It's already done in -proposed
[14:51] <cjwatson> Would have replied last week but you'd quit IRC
[14:51] <cjwatson> The policy is JFDI
[14:52] <cjwatson> Of course d-i will need to wait for all contained kernels to go to -updates before it can go to -updates itself
[14:59] <cjwatson> But after that we can JFDI the copy
[15:06] <Riddell> mhall119: any idea when we learn about UDS sponsorship?
[15:14] <mhall119> Riddell: hopefully today
[15:45] <rbasak> cjwatson: got it - thanks!
[16:34] <Andy80> hi
[18:06] <dpm> hi cjwatson, would you mind approving the e-mail I just sent to ubuntu-devel?
[20:47] <cc11rocks> Bash script for repetitive bug fixes (instructions and explanations in link) : http://pastebin.com/a6AJQzJg
[20:49] <cc11rocks> Updated, refresh
[20:52] <jtaylor> cc11rocks: don't overdo it with typo fixes
[20:52] <jtaylor> many of them aren't worth deviating from debian
[20:52] <jtaylor> better forward the fixes to upstream/debian
[20:53] <cc11rocks> Can I do both?
[20:53] <xnox> cc11rocks: ubuntu specific packages -> send to ubuntu; if package unmodified from debian -> send to debian/upstream
[20:54] <cc11rocks> So I'll have to look at each package manually beforehand to determine?
[20:55] <jtaylor> in 9X% of cases its a package from debian
[20:55] <cc11rocks> Okay, thank you
[21:01] <bryce> cc11rocks, you could add a script that helps identify where fixes should be sent, and helps forward them the appropriate way
[21:02] <cc11rocks> Eh, have to look this stuff up...
[21:04] <cc11rocks> All I have to run is submittodebian ?
[21:05] <cc11rocks> And I deleted the packages and such that I changed. Can I forward my packages from/through the LaunchPad branches?
[21:07] <jtaylor> just download the branches again
[21:07] <jtaylor> with bzr branch ...
[21:11] <cc11rocks> But "submittodebian" will successfully forward it to debian?
[22:29] <cc11rocks> Is there a Colin Watson here? If so, please PM me (related to Ubuntu/Debian bugs...)
[22:30] <xnox> cc11rocks: his irc nick name is cjwatson and he is here.
[22:30] <cc11rocks> Thank you xnox
[22:31] <xnox> cc11rocks: it's better to actually type your question to start a conversation in a PM.
[22:31] <cjwatson> Yes, although I prefer to talk on channel if it isn't private
[22:31]  * xnox steps away =)
[22:31] <cjwatson> That way others can help
[22:33] <cjwatson> cc11rocks: http://irclogs.ubuntu.com/2012/09/03/%23ubuntu-devel.html#t09:48
[22:33] <cc11rocks> I was wondering whether I could submit my changes to both Debian and Ubuntu...
[22:33] <cjwatson> Please don't
[22:33] <cjwatson> Unless it's actually urgent
[22:33] <cjwatson> Otherwise it just duplicates effort
[22:33] <cc11rocks> And yes, that is how I got started from that link
[22:34] <cjwatson> (above discussion - up to maybe 09:57 or so, then it goes off on a few tangents)
[22:34] <cjwatson> I think this is very much our documentation directing you in an inappropriate way
[22:34] <cc11rocks> Should I delete my 30+ requests in LaunchPad then :| ?
[22:34] <cjwatson> If they're all spelling fixes, I think they should all be forwarded to Debian rather than being applied directly to Ubuntu
[22:34] <cc11rocks> Aw, crap
[22:34] <cc11rocks> Alrighty then
[22:35] <cjwatson> It's unfortunate nobody managed to give you better advice before you'd done a ton of work, and I'm sorry about that
[22:35] <cjwatson> The intention of the docs was (as I understand it) to fix up spelling issues like this in Ubuntu-specific packages
[22:35] <cc11rocks> Okay, thank you
[22:35] <cjwatson> In such cases of course the option of forwarding to Debian isn't present and it's fine to work in Ubuntu
[22:35] <cjwatson> You can use rmadison or packages.debian.org or packages.qa.debian.org to see whether the package is in Debian
[22:36] <cjwatson> On the upside you are now presumably thoroughly familiar with branching source package branches and creating merge proposals and such and can re-apply those skills
[22:36] <cc11rocks> Would this work : http://pastebin.com/PeDF5LJK
[22:36] <cjwatson> And it should be possible to extract the actual patches you wrote pretty quickly and reuse them
[22:37] <cjwatson> You don't necessarily have to use submittodebian as such
[22:37] <cc11rocks> It's edited from my old one...
[22:37] <cjwatson> Eh
[22:37] <cjwatson> Not a lot of point doing the whole branching dance
[22:37] <cjwatson> Patches sent to Debian should be against Debian, for obvious reasons :-)
[22:37] <cc11rocks> Here was my old one : http://pastebin.com/a6AJQzJg
[22:38] <cjwatson> If the package is currently in sync between Debian and Ubuntu then there's no difference
[22:38] <cjwatson> It would be quicker to extract patches from your existing branches, surely
[22:38] <cc11rocks> bzr branch lp:debian/$package?
[22:38] <cjwatson> Yeah, or pull-debian-source
[22:38] <cc11rocks> Okay, thanks
[22:38] <cc11rocks> So this will work fine : http://pastebin.com/PeDF5LJK
[22:38] <cjwatson> submittodebian relies on a build having happened
[22:38] <cc11rocks> Oops, meant to ask you to refresh, not repost...
[22:39] <cjwatson> Well, a source package build
[22:39] <cjwatson> I don't think it's appropriate here
[22:39] <cc11rocks> Agreed
[22:39] <cjwatson> Don't commit, just use bzr diff and send that in a bug report
[22:40] <cjwatson> 'reportbug -B debian' can help you file it, or you can see the Debian bug tracking system docs and send mail directly
[22:40] <cjwatson> But, the point of the page you were following was to try to encourage people to contribute to Ubuntu; perhaps you want to find something where directly sending patches to Ubuntu would be appropriate?
[22:40] <jtaylor> cc11rocks: if you forward stuff to debian now don't be let down if the patches won#t be applied swiftly, debian is currently frozen so updates only happen if they are important
[22:41] <cjwatson> It's a cost-benefit trade-off - causing a package to diverge from Debian is a hidden cost because somebody will have to manually merge or sync it later, but that can be offset by a sufficiently beneficial change
[22:41] <cc11rocks> Refresh again and confirm please :)
[22:42] <cc11rocks> I see
[22:42] <cjwatson> I would suggest you try the procedure by hand and then script what works for you, rather than trying to write a script first
[22:42] <cc11rocks> Right
[22:42] <cc11rocks> My bad
[22:42] <cc11rocks> Thank you
[22:43] <cc11rocks> Well, I cannot do anything more today as I have a ton of homework to do
[22:43] <cjwatson> So we often enough take patches for, say, applications that are crashing in Ubuntu, and simply encourage that patch to be submitted to Debian in parallel
[22:43] <cc11rocks> Talk to you guys soon. Thank you cjwatson and jtaylor for your help
[22:43] <cjwatson> Because that's something where having the patch earlier might make a real difference to users
[22:43] <cc11rocks> I see
[22:43] <cjwatson> Or maybe I should say a substantial difference
[22:44] <cjwatson> Spelling errors aren't imaginary :-)
[22:44] <cc11rocks> :P
[22:44] <cjwatson> I don't typically drive the entire cycle from a single script in my normal work
[22:45] <cc11rocks> So how long approximately would it take for a low level fix (spelling error/etc) to show up/be applied/etc?
[22:45] <cjwatson> Depends entirely on the activity level of the maintainer best placed to apply it
[22:45] <cjwatson> Can't really give you an approximation
[22:45] <cc11rocks> Within a month usually?
[22:45] <cjwatson> Can't say
[22:45] <cc11rocks> Okay, thanks
[22:47] <cjwatson> cc11rocks: I do want to emphasise that we appreciate the effort - and I think this is totally our fault (collectively) for the docs being a bit vague on what the point of it is
[22:48] <cjwatson> You clearly have the patience needed :-)
[22:48] <cc11rocks> :)
[22:48] <cc11rocks> No problem.
[22:49] <cc11rocks> I am a Java dev and am scared to get into real bug fixing. Will I be okay if I dove into Python/C++/etc code?
[22:49] <cc11rocks> (Scared because of the language differences)
[22:50] <cjwatson> Poor jamespage might appreciate some help with bugs in our various Java packages, which we currently tend to hurl in his direction :-)
[22:50] <cc11rocks> Also, because of the possible massive references, will I have to learn thousands of codebases to understand a variable, etc?
[22:51] <cjwatson> IME your second language tends to be about half as hard as your first (you have the concepts but have to unlearn a bunch of stuff too); after that it gets progressively easier
[22:51] <cjwatson> Better to learn to search effectively
[22:51] <cc11rocks> I've tried to dive into other languages, but it is very frustrating due to the syntax differences
[22:52] <cc11rocks> it seems to be not worth my time, though in the long run it would be
[22:52] <cjwatson> Variables are usually local to a single codebase; functions are (hopefully) namespaced reasonably rationally so that you can figure out what package they come from, but worst case there's always google
[22:52] <cc11rocks> Already, thanks
[22:53] <cc11rocks> So, to confirm, delete all my bzr branches...
[23:10] <xnox> cc11rocks: keep the branches, for personal reference. Delete/reject the merge proposals.
[23:10] <cc11rocks> I deleted the branches. The merges should be gone. Thank you
[23:10] <xnox> cc11rocks: fair enough. Thank you for your persistence. And sorry for re-directing you so late.
[23:11] <cc11rocks> No problem. Will try to work on it throughout the week, though I'll get most work done this weekend
[23:11] <cc11rocks> Very busy with school and work, so don't know how much I can get done, but I'll make an attempt to do it a bit :)
[23:20] <cc11rocks> If we are supposed to send to Debian, how come the bugs at https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative got accepted
[23:20] <cc11rocks> ?
[23:21] <cc11rocks> A lot of them have "fixed (andreagrandi)" next to them, indicating they got fixed already through Ubuntu...
[23:23] <jtaylor> they aren't fixed with an upload