=== ScottK2 is now known as ScottK
=== Guest4645 is now known as LoganCloud
=== Logan_ is now known as GroupContact
=== GroupContact is now known as Logan_
=== Guest93739 is now known as Kyle
=== caktux_ is now known as caktux
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== caktux_ is now known as caktux
[13:40] <directhex> is something weird going on on akateko and sagari? build log looks like it should be finished/uploading, but it's been sat at the end of the build not updating the build log for a good 15 minutes now. https://launchpad.net/ubuntu/+source/mono/3.2.3+dfsg-5/+build/5435125 https://launchpad.net/ubuntu/+source/mono/3.2.3+dfsg-5/+build/5435124
[13:44] <cjwatson> directhex: that usually means that buildd-manager is downloading the binaries
[13:44] <cjwatson> sometimes that takes annoyingly long on large builds
[13:46] <cjwatson> though not seeing that in the log
[13:47] <directhex> ¯\(°_o)/¯
[13:48] <cjwatson> let me see if I can find out
[13:53] <cjwatson> buildd    1712  0.0  0.0   2352   624 ?        S    12:19   0:00 sh -c MONO_PATH=/build/buildd/mono-3.2.3+dfsg/mcs/class/lib/net_4_5 MONO_SHARED_DIR=/build/buildd/mono-3.2.3+dfsg/runtime MONO_CFG_DIR=/build/buildd/mono-3.2.3+dfsg/runtime/etc ../../doltlibtool --mode=execute  ../../mono/mini/mono --config tests-config --optimize=all --debug monitor.exe 2>monitor.exe.stderr 1>monitor.exe.stdout
[13:53] <cjwatson> buildd    1713  100  0.0  30692 11528 ?        Sl   12:19  91:51  \_ ../../mono/mini/mono --gc=boehm --config tests-config --optimize=all --debug monitor.exe
[13:53] <cjwatson> directhex: ^- stale processes caused the build to hang on cleanup
[13:54] <directhex> i'm beginnig to think just skipping that test is best
[13:55] <cjwatson> well, either skip it or make sure you don't leave stale processes around afterward by some other means
[13:55] <cjwatson> directhex: I've asked sysadmin to kill those processes, but it'll just reoccur on the next build unless the root cause is fixed
[13:56] <cjwatson> builds in uploading state now
[13:58] <directhex> cjwatson, do you remember whether it was monitor.exe on both boxes?
[14:00] <cjwatson> buildd   11042  0.0  0.0   2332   580 ?        S    12:20   0:00 sh -c MONO_PATH=/build/buildd/mono-3.2.3+dfsg/mcs/class/lib/net_4_5 MONO_SHARED_DIR=/build/buildd/mono-3.2.3+dfsg/runtime MONO_CFG_DIR=/build/buildd/mono-3.2.3+dfsg/runtime/etc ../../doltlibtool --mode=execute  ../../mono/mini/mono --config tests-config --optimize=all --debug bug-10127.exe 2>bug-10127.exe.stderr 1>bug-10127.exe.stdout
[14:00] <cjwatson> buildd   11043  196 11.2 1657524 1383460 ?     Rl   12:20 180:13  \_ ../../mono/mini/mono --config tests-config --optimize=all --debug bug-10127.exe
[14:00] <cjwatson> was the other one
[14:00] <cjwatson> sorry, didn't notice that difference
[14:01] <cjwatson> the latter was akateko
[14:04] <directhex> ok, both bugs disabled in master-experimental. i won't do a -6 upload just for this though
[14:11] <directhex> cjwatson, that's acceptable for now? otherwise, a full set of binaries is in trusty-proposed NEW now. yay, etc
[14:13] <cjwatson> directhex: yep, should be, thanks
[14:13] <cjwatson> though it may cause trouble for the test rebuild
[14:13] <directhex> how often do those happen?
[14:13] <cjwatson> but I guess we can deal with that when it comes
[14:13] <cjwatson> there's one due soon, doko is organising it
[14:14] <directhex> i'll feel better about minor-change uploads when i get the experimental/armhf build i've been waiting a month(!) for in debian
[14:14] <cjwatson> NEWed, hopefully approximately correctly
[14:16] <directhex> cjwatson, if i sync another package into -proposed, it will use the mono package in there, right?
[14:17] <cjwatson> directhex: after the next publisher cycle, yes
=== elopio_ is now known as elopio
[14:18] <cjwatson> directhex: you can wait for the version you care about to show up in the output of "rmadison -s trusty,trusty-proposed mono-devel", and then it's safe for builds
=== cprov is now known as cprov-afk
=== cprov-afk is now known as cprov
=== lfaraone_ is now known as lfaraone
[18:49] <Zoohouse> Hello everyone
[18:57] <Zoohouse> Quick question. Is there a general convention or what not on how to organize a project release? For example, how do you use trunks/series/milestones to organize a project in launchpad? I'm looking https://launchpad.net/do/+series and it seems that there's one trunk with each 0.x being it's own series. At https://help.launchpad.net/Code/QuickStart#Set_your_project.27s_trunk_branch it says you can set which of the 'branches' focus of development, so
[18:57] <Zoohouse>  it seems that you should have more than one branch? Perhaps a stable trunk and a development trunk? I'm a bit turned around with this topic if someone can clarify or point to a doc. I'm new to CVS in general.
[19:00] <Zoohouse> Scratch my question: https://help.launchpad.net/Projects/SeriesMilestonesReleases is helpful.
[19:21] <Zoohouse> Another question: https://launchpad.net/bzr series 2.7 comes from series 2.6. 2.6 is still being worked on, fixing bugs I suppose. Say someone fixes a bug in 2.6.1, would not the same bug be in 2.7b1? How does the workflow take care of this?
[19:29] <dobey> it doesn't necessarily mean the bug exists in 2.7, no. how projects are structured and managed is left pretty much entirely up to whoever owns the project
[19:30] <dobey> if you want to ask about bzr, #bzr would be a better channel for it
=== ryanakca_ is now known as ryanakca
=== caktux_ is now known as caktux