| === 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 | ||
| 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:40 |
|---|---|---|
| cjwatson | directhex: that usually means that buildd-manager is downloading the binaries | 13:44 |
| cjwatson | sometimes that takes annoyingly long on large builds | 13:44 |
| cjwatson | though not seeing that in the log | 13:46 |
| directhex | ¯\(°_o)/¯ | 13:47 |
| cjwatson | let me see if I can find out | 13:48 |
| 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:53 |
| directhex | i'm beginnig to think just skipping that test is best | 13:54 |
| 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:55 |
| cjwatson | builds in uploading state now | 13:56 |
| directhex | cjwatson, do you remember whether it was monitor.exe on both boxes? | 13:58 |
| 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:00 |
| cjwatson | the latter was akateko | 14:01 |
| directhex | ok, both bugs disabled in master-experimental. i won't do a -6 upload just for this though | 14:04 |
| directhex | cjwatson, that's acceptable for now? otherwise, a full set of binaries is in trusty-proposed NEW now. yay, etc | 14:11 |
| 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:13 |
| 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:14 |
| directhex | cjwatson, if i sync another package into -proposed, it will use the mono package in there, right? | 14:16 |
| cjwatson | directhex: after the next publisher cycle, yes | 14:17 |
| === elopio_ is now known as elopio | ||
| 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 | 14:18 |
| === cprov is now known as cprov-afk | ||
| === cprov-afk is now known as cprov | ||
| === lfaraone_ is now known as lfaraone | ||
| Zoohouse | Hello everyone | 18:49 |
| 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. | 18:57 |
| Zoohouse | Scratch my question: https://help.launchpad.net/Projects/SeriesMilestonesReleases is helpful. | 19:00 |
| 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:21 |
| 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:29 |
| dobey | if you want to ask about bzr, #bzr would be a better channel for it | 19:30 |
| === ryanakca_ is now known as ryanakca | ||
| === caktux_ is now known as caktux | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!