[07:02] <dholbach> good morning
[08:27] <jfi> Hi, if I propose a bzr branch merge throw LP without setting a reviewer (don't know who can do the review/upload...) for universe package, do I also need to create a 'bug report'? Or is there a ubuntu team automaticaly notified and someone going to handle it?  Or should I better follow https://wiki.ubuntu.com/SyncRequestProcess for people requiring sponsorship and not follow the bzr merge proposal way?
[08:56] <geser> jfi: IIRC you shouldn't need to do any special things to get your branch sponsored.
[08:57] <geser> If it's listed on the sponsoring overview page then it should get picked up by a sponsor.
[08:59] <jfi> geser,  yes, you are right, it is already in http://reqorts.qa.ubuntu.com/reports/sponsoring/. Thanks.
[22:34] <epikvision> How do you know if pbuilder was successful?
[22:34] <epikvision> in running a package?
[22:35] <jtaylor> running?
[22:35] <jtaylor> pbuilder builds
[22:35] <epikvision> building.
[22:35] <epikvision> sorry
[22:35] <jtaylor> exit code 0 and a result in the result folder
[22:35] <jtaylor>  /var/cache/pbuilder/result by default
[22:43] <epikvision> what if there is no result?
[22:43] <jtaylor> then it likely failed
[22:43] <jtaylor> if you were building a package
[22:43] <jtaylor> what does the log say?
[22:43] <epikvision> does that mean a failure? (i was only trying out the packaging a new software tutorial at package guide site.)
[22:44] <epikvision> where can I find the logs?
[22:44] <jtaylor> depends how you use pbuilder
[22:44] <jtaylor> if you use pbuilder-dist the result is in ~/pbuilder/*_result along with the log
[22:44] <epikvision> pbuilder-dist precise ...
[22:45] <epikvision> what part of the log is appropriate to share?
[22:45] <epikvision> pbuilder calls it an invalid version.
[22:46] <jtaylor> the end is usually enough
[22:46] <epikvision> it finished with a time-stamp
[22:46] <jtaylor> please use a pastebin, e.g. via pastebinit
[22:46] <epikvision> what does that mean?
[22:47] <jtaylor> pastebins are just websites where you can paste text to share
[22:47] <epikvision> ahh
[22:47] <jtaylor> echo "test" | pastebinit
[22:47] <epikvision> do developers use pastebins often?
[22:48] <epikvision> whoa!
[22:48] <jtaylor> yes its the most common way to share buildlogs
[22:48] <epikvision> that's so cool
[22:49] <epikvision> how do I pastebin the command?
[22:49] <epikvision> 's results?
[22:49] <jtaylor> you can just copy it into http://paste.ubuntu.com/
[22:50] <epikvision> http://paste.ubuntu.com/1090686/
[22:50] <jtaylor> pastebinit is a useful program to semi automatize this, it takes input from stdin or a file
[22:50] <jtaylor> looks like it was successful
[22:50] <epikvision> ah ok.  :)
[22:50] <jtaylor> there should be a result in ~/pbuilder/ somewhere
[22:51] <epikvision> well, it was just a tutorial.  how do know if it was successful? by not showing any errors?
[22:51] <jtaylor> yes
[22:51]  * epikvision shudders at the countless times of going through this tutorial for the past few weeks.
[22:53] <epikvision> how do I use pastebinit?
[22:53] <epikvision> for say, an output of a command?
[22:54] <jtaylor> either you save the log and do "pastebinit log" or you pipe it in with "command | pastebinit"
[22:54] <jtaylor> you can also just type pastebinit and paste the text followed by ctrl+d
[22:54] <jtaylor> see the manpage for some more options including syntax highlighting for source code
[22:55] <epikvision> ok
[23:00] <epikvision> thanks jtaylor for the help
[23:01] <epikvision> I feel like I learn more from others than alone.
[23:03] <epikvision> does motu do packaging work for the development release too?
[23:03] <jtaylor> yes
[23:05] <epikvision> i heard that it's good practice to run the dev release via chroot.
[23:05] <jtaylor> you should have lots of chroots to build stuff
[23:06] <jtaylor> to fully run dev releases VM's are good
[23:06] <jtaylor> or if its more stable a extra partition
[23:06] <epikvision> I tried virtualbox and qemu, and both fails... :(
[23:11] <tumbleweed> we almost only work on the devolpment release, after all, it's the *development* release...
[23:53] <Laney> grah, precise's debmirror has no --config-file
[23:54] <tumbleweed> debmirror takes a config file?
[23:54]  * tumbleweed is suprised he didn't notice that, considering I've been merging it for the last few releases
[23:54] <Laney> sure it does
[23:54] <Laney> you don't use one?
[23:54] <tumbleweed> no, I use a script
[23:55] <Laney> anything clever?
[23:55] <tumbleweed> (which made a lot of sense for other reasons too, such as rsyncing i18n, before debmirror supported that)
[23:56] <tumbleweed> the most clever bit is that it calls a debmirror in a git checkout, containing all the patches I've submitted upstream that joey hasn't done anything about
[23:57] <tumbleweed> such as the patch that stops my mirror being deleted when my upstream mirror has a hash mismatch
[23:57] <Laney> heh
[23:59]  * Laney starts the initial armhf sync
[23:59] <Laney> yay for being able to run a local mirror
[23:59] <Laney> it's not as big as i thought actually
[23:59] <tumbleweed> http://paste.debian.net/178975/
[23:59] <Laney> i hope it can deal with merging them into the same directory