=== chihchun_afk is now known as chihchun
=== fginther is now known as fginther`
=== chihchun is now known as chihchun_afk
=== Mirv__ is now known as Mirv
[04:33] <Mirv> morning
=== chihchun_afk is now known as chihchun
[06:53] <robru> morphis: you can't use debian/watch in the train. disallowed by firewall. needs to have everything it needs in the branch
[06:55] <morphis> robru: which silo/package are you refering too?
[06:56] <robru> morphis: https://requests.ci-train.ubuntu.com/#/ticket/242 this failure is due to debian/watch trying to download orig.tar from kernel.org, which is forbidden
[06:56] <morphis> robru: hm, that worked for weeks
[06:57] <robru> morphis: shouldn't have. firewall has always blocked debian/watch as far as I know. the only loophole is the debian/watch can point at lp PPAs and that's it
[06:57] <morphis> robru: yes that is correct but it constructs the source pacakge as fallback from the bzr tree
[06:57] <robru> morphis: you have the right bzr-builddeb file to do split building so it looks like you just need to drop the debian/watch file
[06:58] <morphis> so having debian/watch shouldn't be a problem
[06:58] <morphis> robru: in this case it must be sth else which goes wrong
[06:58] <robru> morphis: oh maybe you're right. I'm not sure what the error is then
[06:59] <morphis> robru: let me see
[06:59] <robru> morphis: looks like your quilt patches are in a bad state, I don't really know much about that stuff
[06:59] <morphis> robru: "bzr: ERROR: An error (1) occurred running quilt: None"
[06:59] <robru> morphis: I assumed the quilt errors were because the orig.tar failed to download, looks like I was wrong as it does say "using source tree without debian dir"
[07:00] <morphis> right
[07:00] <morphis> I've just added another patch in debian/patches
[07:01] <morphis> and before that the build went through
[07:03] <robru> morphis: "Patch /var/lib/jenkins/silos/ubuntu/landing-043/build-area/bluez-5.35+15.04.20151012/debian/patches/0001-hostname-handle-chassis-type-handset.patch does not exist" maybe your debian/patches/series has a typo
[07:04] <morphis> robru: yeah saw that now too
[07:04] <morphis> pushed the missing patch
[07:04] <robru> hehe
[07:04] <morphis> and retriggered the build ..
[07:04] <morphis> was too early today for that :D
[08:00] <jibel> alecu, ^
[08:01] <jibel> 55 granted.
[08:12]  * Mirv shows his PPU badge to the train
[08:15] <Mirv> jibel: there was an MP that was not built in there ^
[08:17] <sil2100> ;)
[08:22] <jibel> Mirv, argh
[08:22] <jibel> no fun
[08:22]  * sil2100 loves when people do that
[08:23] <jibel> we'll have to retest it again :(
[08:23] <Mirv> yeah, these problems occur too often and they suck
[08:23] <jibel> This silo was failed and blocked not work in progress
[08:23] <sil2100> I think that a separate jenkins job for setting the silo to 'ready for QA' could help
[08:24] <sil2100> SInce besides running autopkgtests or whatever, it could then do the check for unbuilt reivisons
[08:24] <Mirv> I think we should expand this bug #1483684 to include also non-built packages
[08:24] <ubot5`> bug 1483684 in CI Train [cu2d] "Check non-topapproved branches and show on dashboard" [Wishlist,Incomplete] https://launchpad.net/bugs/1483684
[08:24] <jibel> alecu, silo 55 won't land today then
[08:24] <sil2100> Damn, it's hard to work and type when the cat is blocking out half of my screen
[08:25] <Mirv> although that bug is stalled in general at the moment
[08:25] <Mirv> sil2100: yeah, I've learned to move the windows accordingly when that happens
[08:25] <Mirv> sil2100: they also sometimes start to hunt for the mouse pointer, which makes things even more problematic
[08:25] <sil2100> Yes, that's what mine was just doing ;)
[08:26] <jibel> the MP has conflicts
[08:36] <morphis> robru, sil2100: you know if I can easily switch the architecture of a package? like von all to linux-any?
[08:40] <robru> morphis: uh, in debian/control?
[08:40] <morphis> robru: yes
[08:40] <robru> morphis: yes. That's how.
[08:40] <morphis> robru: and that doesn't cause any problems when someone already has installed that package?
[08:41] <robru> morphis: if you regress an arch that is in the archive then the package will not be accepted.
[08:41] <morphis> robru: the package I want to change bluez-test-scripts
[08:41] <morphis> which currently has arch "all"
[08:42] <morphis> so changing that to "linux-any" will cause a regression?
[08:42] <robru> morphis: I'm not familiar with that one but I'm saying you can't just stop building an arch that we already have.
[08:42] <morphis> I see
[08:42] <morphis> but "all" is basically  a package which doesn't include any architecture specific things
[08:42] <robru> morphis: unless you have a really good reason for it and you can sell #ubuntu-release in the change
[08:43] <morphis> ok
[08:44] <robru> morphis: what are you doing? Adding arch-specific code to something that used to just be scripts r something?
[08:44] <morphis> yes
[08:45] <morphis> robru: the bluez-test-scripts package just has python scripts so far
[08:45] <morphis> but there are binary test programs we need to package too
[08:45] <robru> morphis: and your code doesn't compile for all available arches?
[08:45] <morphis> it does
[08:46] <robru> morphis: oh well if it compiles everywhere it should be fine
[08:46] <morphis> but an "all" package should include any binaries, right?
[08:47] <robru> morphis: i always get "all" and "any" confused because they're both 3 letter words that start with "a" and can be interpreted either way
[08:48] <morphis> :)
[08:49] <morphis> robru: imho dropping the package bluez-test-scripts and adding a new one bluez-tests would be the best way
[08:49] <robru> morphis: well i don't have an opinion about the name
[08:50] <morphis> robru: if I want to drop the bluez-test-scripts package and add a new one, I just rename the pacakge in debian/control?
[08:50] <robru> morphis: well no, you have to check the .install files and make sure they have sensible values, and change the source tree to not build the files that package contains
[08:51] <morphis> why the second?
[08:51] <morphis> if I want those bits in the new package now?
[08:52] <robru> morphis: so I'm not familiar with this package. Presumably your source tree has these files in it that get packaged. If you want "a new package" that doesn't have the old files then you probably wanna drop those files from the source tree rather than keep them around for nothing
[08:53] <morphis> ok
[08:53] <robru> morphis: and then you gotta make sure the .install files don't reference files you deleted
[08:53] <morphis> but I still have to ship the old package as empty one?
[08:54] <robru> morphis: no. Just set Replaces field so apt knows the upgrade path
[08:54] <robru> Mirv: can you give some packaging advice? ^^ 2am here ;-)
[09:03] <Mirv> robru: sure
[09:04] <Mirv> morphis: so is that something that is not yet in wily?
[09:04] <morphis> Mirv: the changes I am talking about?
[09:05] <Mirv> morphis: yes, I mean seb128 might have an opinion on bluez packaging regardless since he did the bluez5 in wily (at least the upload)
[09:05] <morphis> Mirv: yeah I talked with him the general way for bluez5
[09:05] <morphis> once we've landed bluez5 in vivid+overlay we will sync up wily+1 and the overlay so we can do proper dual landing
[09:06] <seb128> what's the discussed change?
[09:06] <morphis> seb128: https://bazaar.launchpad.net/~bluetooth/bluez/bluez5-upgrade/revision/20
[09:06] <morphis> I wondered if that is possible without any problems
[09:06] <morphis> or if that breaks an upgrade path
[09:07] <seb128> morphis, why do you rename it?
[09:07] <Mirv> morphis: that breaks upgrade path as is, yes, since the same files (plus the new ones) would be there
[09:07] <Mirv> seb128: he's adding some binary packages and changing the package to Any
[09:07] <Mirv> binary files
[09:07] <seb128> that's not adding a package
[09:08] <seb128> that's renaming one
[09:08] <morphis> right
[09:08] <Mirv> the alternative would be adding a new binary package to contain the new arch-specific binaries
[09:08] <Mirv> seb128: yes, that's what I corrected to myself
[09:08] <seb128> what problem is that trying to solve?
[09:08] <morphis> I would like to avoid having two packages in bluez about tests
[09:08] <morphis> seb128: we have certain test utilities which are testing the kernel part of bluez
[09:08] <seb128> well, that change doesn't reduce the number of binaries
[09:09] <morphis> seb128: I know, the part in debian/rules which installs TESTER_PROGRAM_LIST is what I've added before
[09:09] <morphis> that isn't in wily
[09:09] <morphis> I introduced that before without respecting that bluez-test-scripts is an "all" arch package
[09:10] <seb128> you can change all to any that's fine
[09:13] <morphis> seb128: and also renaming the package is fine?
[09:13] <morphis> as "bluez-test-scripts" doesn't really fit what it contains now
[09:14] <seb128> morphis, if you rename you want to Conflicts/Rename/Provides the old name
[09:14] <seb128> so apt knows to replace one by the other one
[09:14] <morphis> ah good
[09:14] <morphis> do I need all three or just one?
=== john-mca` is now known as john-mcaleely
[10:46] <cjwatson> morphis: For a package rename, if you must rename the package (I don't see why you need to, aside maybe from aesthetics), you must have at least Conflicts+Replaces, and you should have Provides if there are existing packages that depend on the old name but you don't need it otherwise
[10:48] <morphis> cjwatson: ok
[10:48] <morphis> cjwatson: yeah, renaming is only a cosmetic change
[10:48] <cjwatson> OK
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== chihchun_afk is now known as chihchun
[13:11] <pete-woods> hi! chance any core-dev could ack my packaging changes in silo 10? (https://ci-train.ubuntu.com/job/ubuntu-landing-054-2-publish/10/artifact/libqtdbusmock_packaging_changes.diff) would be much appreciated!
[13:18] <Saviq> jibel, you guys are busy with OTA testing? any ETA on when we could count on QA signoffs?
[13:19] <davmor2> Saviq: for you......never muhahahahahahaha  Tomorrow possibly
[13:26] <jibel> Saviq, OTA + national holidays, not before tomorrow sorry
[13:26] <Saviq> ack
[13:27] <Saviq> just wanted to know
[13:28] <davmor2> Saviq: https://www.youtube.com/watch?v=R-OoIvgtuzs
[13:31] <Saviq> davmor2, that video part of your testing routine?
[13:33] <davmor2> Saviq: No just a reminder that there is always a tomorrow and we didn't say which one :P
[14:14] <jibel> alecu, hey in silo 55 there is an unbuilt MP, could someone have a look and resubmit the silo for QA?
[14:21]  * sil2100 brb in a few moments
[14:26] <alecu> jibel: thanks for the update on silo 55. Sorry to hear about that :-(
=== alan_g is now known as alan_g|afk
[15:39] <greyback> cihelp: hey, we're having trouble with running dbus-mock tests - https://jenkins.qa.ubuntu.com/job/qtmir-vivid-amd64-ci/194/console
[15:39] <greyback> could it be possible the dbus daemon failed to start?
[15:46] <fginther> greyback, hi
[15:46] <greyback> fginther: hey!
[15:46] <fginther> greyback, do those tests start their own dbus deamon?
[15:46] <greyback> pete-woods: ^
[15:47] <pete-woods> fginther: yes
[15:47] <greyback> fginther: yes, a private session daemon
[15:47] <pete-woods> fginther: this lib is used in a bunch of other projects
[15:47] <pete-woods> starts a private bus
[15:47] <pete-woods> sets env vars, etc
[15:47] <pete-woods> it looks like the private dbus might be failing to start
[15:48] <pete-woods> but the lib doesn't have a nice way of reporting this
[15:49] <fginther> pete-woods, greyback, I don't immediately see anything off on this node that could be causing a problem. (i.e. no stuck dbus process and no cruft from prior builds setting around which have been known to cause problems in the past)
[15:50] <pete-woods> by the looks of the MR, it's not just one node
[15:50] <fginther> pete-woods, greyback, there is a dbus processing running, but that's the one spawned on init and I from what I understand, this isn't used by the test
[15:50] <pete-woods> yeah, that's correct
[15:51] <pete-woods> all the nodes are failing on the MR
[15:51] <pete-woods> so it seems unlikely to be an infrastructure problem
[15:51] <greyback> it's just weird, as afaics, nothing in the MP has any impact on that test/dbus
[15:52] <pete-woods> you could print out the contents of DBUS_SYSTEM_BUS_ADDRESS and DBUS_SESSION_BUS_ADDRESS environment variables
[15:52] <pete-woods> to check if the buses have started, and have provided us with addresses
[15:54] <pete-woods> it does look like a pretty innocent MR
[15:58] <fginther> greyback, pete-woods, There is a new version of libqtdbusmock1: 0.4+15.04.20151006.3-0ubuntu1, but I can't find anything else interesting
[16:00] <pete-woods> fginther: I would have expected other projects to be suffering if this was widespread
[16:01] <fginther> pete-woods, indeed. It's just the only other thing I can think to check here
=== alan_g|afk is now known as alan_g
[16:04] <fginther> greyback, I'm unable to find anything on the host or the build configuration that would lead to this failure. I did kick off a fresh build of trunk to see if that reveals anything interesting: http://s-jenkins.ubuntu-ci:8080/job/qtmir-ci/502/console
[16:04] <greyback> fginther: thanks. We'll do some more iterating on our end, in case it's our fault after all
[16:04] <greyback> alan_g: ^^
=== chihchun is now known as chihchun_afk
[16:22] <pete-woods> greyback: FYI, I just kicked a silo build for one of my projects that heavily uses libqtdbustest/mock ^
[16:23] <pete-woods> lets see what happens
[16:23] <greyback> cool
[16:23] <greyback> it'll probably be fine
[16:23] <greyback> the gremlins just like that qtmir branch
=== fginther is now known as fginther`
=== fginther` is now known as fginther