[01:04] <rlaager> Is there a convention for referencing Launchpad bugs in debian/changelog that does not close the Launchpad bug on upload? (Or am I wrong in my assumption that LP: #... closes the bug?)
[01:04] <nacc> rlaager: drop the ':'
[01:06] <rlaager> nacc: Thanks!
[01:07] <Logan> er, the colon should be fine
[01:07] <Logan> I use that every time, and it works fine
[01:08] <Logan> https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Vendor/Ubuntu.pm#n173
[01:08] <Logan> here's the regular expression ;)
[01:08] <rlaager> Logan: With "LP: #...", does it close the bug report (i.e. mark it "Fix released") on upload?
[01:08] <Logan> it marks it as Fix Released as soon as it hits the release pocket, I believe
[01:08] <nacc> Logan: right, with a colon, i believe the watcher changes the bug state, rlaager asked what would prevent htat
[01:08] <rlaager> Note that I want to reference a bug report, but this is not an entire fix, so I do NOT want it to close.
[01:09] <Logan> ohhh
[01:10] <rlaager> The downside here is that the changelog won't get automatically copied into the bug either, but oh well. In my in-house thing at work, I support "Closes #..." vs "Refs #...", which I think is a convention I copied from Pidgin development.
[01:10] <rlaager> Not that I can upload to Ubuntu anyway, but I'm trying to produce debdiffs that are 100% good-to-go.
[01:10] <sarnold> you could always go set it back to IN PROGRESS or something afterwards
[01:11] <Logan> oh
[01:11] <sarnold> or open a new bug for this small problem?
[01:11] <Logan> I misread
[01:11] <sarnold> "small"
[01:11] <Logan> yes, removing the colon should work based on that regular expression
[01:11] <Logan> sorry to cause confusion
[01:12] <rlaager> sarnold: So, can packages move from universe to main post release, or is ZFS stuck in universe for the lifetime of Xenial?
[01:13] <sarnold> rlaager: *sigh* I hadn't noticed it didn't make it to main.
[01:14] <sarnold> rlaager: there's precedent for making promotions to main retroactive, anyway: https://bugs.launchpad.net/ubuntu/+source/ppc64-diag/+bug/1417608
[01:14] <ubottu> Launchpad bug 1417608 in servicelog (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,Confirmed]
[01:14] <rlaager> sarnold: See my previous rant/whinge about the lack of feedback. Basically, do I hassle people (and annoy them if they're going to get to it) or not and it doesn't get done (if they weren't working on it).
[01:15] <sarnold> rlaager: yes :(
[01:16] <sarnold> I'd rather be bothered; most releases there's no way we can get to all the MIR requests, so it's nice to know which ones are _needed_ vs which ones aren't.
[01:16] <rlaager> By the way, what's the policy on assigning bugs? Specifically, is it okay for me to assign a bug to myself, even if I'm not an Ubuntu developer?
[01:16] <sarnold> yeah that should be fine
[01:17] <sarnold> maybe make a comment in the bug if you're actively working on it -- people assign bugs to themslves all the time without meaning to.
[01:17] <Unit193> It's a bit annoying, aye. >_>
[01:17] <rlaager> Okay. I've been taking the "be bold" (or "better to beg forgiveness than ask permission") approach and figured someone would slap me down if I was creating a problem.
[01:19] <sarnold> that works out well for everyone :) bugs get fixed
=== happyaro1 is now known as happyaron
=== fginther` is now known as fginther
=== unixpro1970 is now known as _unixpro1970
[05:56] <Mirv> pitti: there would be another hanged s390x test, marble, at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
[05:56] <Mirv> that's the only thing blocking
[08:07] <Mirv> or maybe Laney ^ ?
[08:09] <seb128> Mirv, pitti is in Austin so probably still sleeping
[08:11] <Mirv> seb128: ok. I'm just trying to find someone who has access to the autopackagetest infra to restart that one test.
[08:11] <seb128> yeah, no idea who that is
[08:11] <seb128> but better to ask like than to ping one specific person that might not be around
[08:18] <Mirv> in the trickier cases it has been only one specific person who knows what to do. there's a bug filed about this "stuck in running state" which happens every now and then.
[08:21] <seb128> that sounds like an issue
[08:43] <Laney> Mirv: I skipped it now, looks like it got blacklisted
[08:52] <Mirv> Laney: ok, let's see if it gets unblocked now
[09:50] <Mirv> Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src seems unchanged, still "Test in progress"
[09:50] <Mirv> (without being in progress or running page during the last hour)
[09:50] <Laney> Dunno
[09:50] <Laney> Need to wait then
[09:51] <Mirv> ...for pitti
[09:52] <Mirv> likely another case of bug #1571353 and some magic forcing is needed while the bug is still open
[09:52] <ubottu> bug 1571353 in Auto Package Testing "test results get lost and stay "in progress" forever when multiple tests finish at the exact same time" [Medium,Triaged] https://launchpad.net/bugs/1571353
[09:52]  * Laney tried one more thing
[10:15] <Mirv> ok, page updated, no change, and no new test runs completed or anything running currently
=== _salem is now known as salem_
=== JanC is now known as Guest26117
=== JanC_ is now known as JanC
[12:51] <pitti> seb128, Laney: FYI: retry-autopkgtest-regressions --state RUNNING
[12:52] <pitti> this generates all commands
[12:52] <pitti> then pick out the ones you want/need
[12:52] <pitti> re-running marble now
[12:52] <seb128> pitti, hey! happy friday
[12:52] <seb128> pitti, does that work with "hanging" instances?
[12:52] <pitti> and that bug is high on my list, for next week
[12:53] <pitti> seb128: well, the test request got lost
[12:53] <seb128> ah ok
[12:53] <seb128> so retry would have worked
[12:53] <pitti> which normally "should not happen"™, but can with bug 1571353
[12:53] <ubottu> bug 1571353 in Auto Package Testing "test results get lost and stay "in progress" forever when multiple tests finish at the exact same time" [Medium,Triaged] https://launchpad.net/bugs/1571353
[12:53] <pitti> seb128: right, except that you don't have a convenient button on excuses, you need to use run-autopkgtest
[12:54] <pitti> seb128: other than heating up the universe it's completely safe to re-run tests
[12:54] <pitti> if there are more than one results for a test, britney will just pick one (preferring PASSes)
[12:55] <pitti> seb128: et joyeux vendredi à toi aussi ! comment vas-tu ?
[12:56] <seb128> pitti, noted for next time
[12:57] <seb128> pitti, ça va bien, il fait beau et chaud ici ! tu rentres quand ?
[12:57] <pitti> seb128: well, hopefully there won't be many next times any more :)
[12:57] <pitti> this is the only known way how to lose test requests right now, and we know how to fix it
[12:57] <pitti> seb128: cet àpres-midi, mon vol va à 17h15
[12:58] <seb128> pitti, tu pourras profiter de ton dimanche alors :-)
[12:58] <seb128> pitti, k, fingers crossed that once that one is fixed things are reliable then!
[12:59] <pitti> seb128: en effet ! et le temps est très bien, donc on va être dehors tout le dimanche :)
[13:00] <seb128> sounds great! :-)
[13:39] <seb128> hum
[13:39] <seb128> did launchpad stopped deleting SRUs from -proposed when they move to -updates?
[13:39] <seb128> or are they staying there until the update is rolled out at 100% and they cleaned out?
[13:40] <cjwatson> LP never did that automatically
[13:40] <seb128> I never noticed packages having "updates, proposed" on their ubuntu package before
[13:40] <seb128> e.g https://launchpad.net/ubuntu/+source/gnome-software
[13:40] <cjwatson> they're listed on
[13:40] <cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html
[13:40] <seb128> oh ok
[13:40]  * cjwatson processes the current batch
[13:41] <cjwatson> it's just manual to avoid accidents
[13:41] <seb128> I guess it's usally done frequently enough that I never noticed
[13:41] <cjwatson> and because cleanup is in no way urgent
[13:41] <seb128> cjwatson, thanks!
[13:41] <cjwatson> np
[13:42] <seb128> (or maybe usually whoever does the pocket copy does the cleanup as well while they are at it?)
[13:42] <cjwatson> more usual to wait for it to show up in the report IME
[13:43] <Mirv> seb128: can you try out pitti's instruction on the marble? it'd look like no-one ran the command yet (no new executed autopkgtest runs, nothing running, state still stuck)
[13:43] <seb128> Mirv, pitti said he was doing it
[13:44] <seb128> pitti, did you do? just checking if there was an issue before doing it as well
[13:44] <seb128> cjwatson, k, thanks for the details!
[13:47] <pitti> seb128: I did run the command, yes
[13:47] <seb128> Mirv, ^
[13:48] <pitti> sorry, can't check this now, in meeting
[13:49] <Mirv> ok thanks pitti, I'm just not finding any new log at http://is.gd/aX745A listing nor anything on the running page
[13:49] <pitti> triggering it again
[13:52] <Mirv> still nothing on http://autopkgtest.ubuntu.com/running.shtml - the previous runs have lasted for roughly 40 mins so it should be showing there. I guess needs time for debugging at a better time.
[13:53] <pitti> right
[13:56] <pitti> oh!
[13:56] <pitti> Mirv, seb128: sorry, completely forgot: the workers blacklist yakkety/s390x/marble
[13:57] <pitti> as this is killing the workers and causing tmpfail loops
[13:57] <pitti> so hinting it is the right solution
[13:57] <pitti> and Laney did that
=== chuck__ is now known as zul
[13:57] <pitti> so the next britney run ought to pick this up
[13:58] <seb128> pitti, Laney did that earlier, shouldn't it have picked it up by now?
[13:59] <pitti> ah, because it's in progress, and we wait for that, it's not failed
[13:59] <pitti> meh
[13:59]  * pitti hints it harder
[14:00] <pitti> will go in next roud
[14:00] <pitti> roud
[14:00] <pitti> round
[14:00] <seb128> pitti, thanks!
[14:00] <seb128> Mirv, ^
[14:08] <Laney> meow
[14:08] <Laney> pitti: what did you do?
[14:08] <Laney> I killed it from pending.json but that didn't work, it came back
[14:08]  * Laney wasn't sure how to clear it
[14:11] <pitti> Laney: the blacklisting on the workers is a bit poor right now, they don't get marked as failed; I think they should be, that's also something for next week
[14:11] <pitti> if someone could file a bug about this, I'd appreciate
[14:12] <Laney> pitti: fine, but I want to know how you cleared out the inprogress too so I can do that next time
[14:12] <pitti> Laney: I didn't, I just force-skiptest'ed qt
[14:13] <pitti> right now nothign tells britney that the test is "done" (i. e. not really ran, but ignored)
[14:14] <Laney> nod
[14:14] <Laney> but force-badtest could force INPROGRESS too
[14:15] <Laney> filed the other bug anwyays
[14:16] <pitti> Laney: no, that only forces over failures
[14:16] <pitti> regressions, I mean
[14:18] <Laney> pitti: is there a reason it has to be like that?
[14:19] <pitti> Laney: no, we could fix britney to apply force-badtest on inprogress
[14:19] <Laney> ya, that was my question really
[14:19] <pitti> Laney: but I think we should still clean up the blacklisting handling, as there's no feedback from infra → britney
[14:19] <pitti> and we have to have explicit hints
[14:21] <Laney> pitti: I filed both
[14:22] <pitti> thanks
[14:31] <doko> Mirv, please could you have a look at the pocl ftbfs? there seem to be issues on i386, however pulling the second clang version into main is a no-go
[14:33] <doko> Mirv, the alternative is to remove the pocl dependency
=== dgadomski_ is now known as dgadomski
[15:35] <seb128> pitti, did you see Laney's reply on bug #1575152?
[15:35] <ubottu> bug 1575152 in gstreamer1.0 (Ubuntu Xenial) "[SRU] gstreamer 1.8.1" [Undecided,New] https://launchpad.net/bugs/1575152
[15:42] <seb128> slangasek, xnox, seems the upstart changes in yakkety are not warning free, .xsession-errors has some complains about UpdateActivationEnvironment
[15:49] <xnox> seb128, right, that's what i thought was the case which tinoco (?!) said are all good.
[15:49] <xnox> let me find where we talked about that
[15:49] <inaddy> xnox: me
[15:50] <inaddy> ?
[15:50] <xnox> inaddy, oh. are you Trevinho?
[15:50] <inaddy> tinoco == inaddy
[15:50] <inaddy> not me =)
[15:50] <xnox> seb128, https://launchpad.net/~3v1n0
[15:50] <xnox> inaddy, not you =)
[15:50] <Trevinho> xnox: ehm?
[15:51] <Trevinho> ah...
[15:51] <Trevinho> seb128: which warning? any log?
[15:52] <seb128> Trevinho, bug #1578934
[15:52] <ubottu> bug 1578934 in upstart (Ubuntu) " Method 'UpdateActivationEnvironment' is only available at the canonical object path '/org/freedesktop/DBus'" [Undecided,New] https://launchpad.net/bugs/1578934
[15:53] <xnox> Trevinho, possibly there are things we try to push before dbus is up...
[15:53] <Trevinho> xnox: no, it's just about fixing the dbus path
[15:53] <xnox> =)
[15:53] <Trevinho> xnox: it's one line change in dbus_proxy = ...
[15:54] <Trevinho> xnox: /org/freedesktop/DBus instead of /
[15:54] <xnox>  /o\ that's what i said, i never recalled that thing actually worked right.... =/
[15:54] <Trevinho> xnox: it's weird that it fixed the pete-woods bug, on his terminal... As thigns were exported
[15:55] <Trevinho> but, well... fixing the path should fix things
[15:55] <Trevinho> xnox: should I do the branch, or you do it?
[15:56] <xnox> Trevinho, send a merge proposal and I can land it for you
[15:56] <Mirv> tjaalton: doko is interested in you looking into pocl ftbfs, at 17:31
[15:56] <Trevinho> xnox: ok, fine
[16:02] <doko> Mirv, ouch again ...
[16:06] <Trevinho> xnox: here you are https://code.launchpad.net/~3v1n0/upstart/activation-proper-dbus-path/+merge/294025
[16:07] <Trevinho> xnox: FYI this error wasn't present at the time you did the patch, though... Since testing it in trusty still works with no errors.
[16:12] <xnox> fun.
[16:12] <xnox> does this new thing work in both old and new?
[16:16] <Trevinho> xnox: yes
[16:16] <Trevinho> xnox: can you also care about SRUing those MPs?
[16:19] <xnox> maybe
[16:22] <Trevinho> maybe? :)
[16:56] <Trevinho> xnox: Iv'e tested that change again, and it seems that it also fixes some missing env vars now... so nice one
[19:02] <wutf> are there sufficient tests in place to use the pre-release ubuntu?
[19:03] <wutf> i used xenial long before it was released and experienced few problems
[19:03] <wutf> the only real problem i noticed is that sometimes the updater would get into a weird inconsistent state, in which case i would just ignore it and it would eventually fix itself
[19:06] <sarnold> it's probably fine for enthusiasts, though I wouldn't recommend it for people who just want a computer to work
[19:07] <sarnold> but if you like filing bug reports when things break, it should fit alright :)
[19:07]  * dobey wishes computers would work
[19:07] <wutf> sarnold, what kind of testing framework do you guys have?
[19:07] <wutf> is general system stability tested before packages go into the devel release?
[19:08] <sarnold> wutf: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[19:08] <dobey> not exactly
[19:08] <dobey> autopkgtests get run, but those of course don't test everything
[19:09] <wutf> there is an automated test generation and running framework?
[19:09] <sarnold> test running
[19:09] <wutf> ah
[19:10] <sarnold> the tests have to be built into the packages using http://dep.debian.net/deps/dep8/
[19:10] <dobey> if there was something generating tests automatically, i'd be more afraid of something other than my pc not breaking
[19:10] <wutf> you could autogenerate tests using fuzzing
[19:10] <dobey> viva la robolucion
[19:11] <sarnold> dobey: lol
[19:11] <sarnold> fuzzing only gets you so far. very little of what is tested via autopkgtests would be reproducable with fuzzing testing
[19:12] <wutf> command line tools can have the fuzzer seeded with the man page
[19:12] <wutf> gui tools could run through UIs
[19:12] <wutf> ^_^
[19:13] <dobey> i think we have a fairly decent idea of how to build our tests
[19:13] <sarnold> funny enough, i'm at the moment reading a debdiff that adds dep-8 tests to a package: https://launchpadlibrarian.net/258172429/spl-linux_0.6.5.6-0ubuntu1_0.6.5.6-0ubuntu3.diff.gz
[19:23] <wutf> is there a process for automatically keeping packages up to date with their releases?
[19:23] <wutf> or are all packages handled manually
[19:24] <nacc> wutf: what do you mean?
[19:24] <nacc> wutf: do you mean upstream releases?
[19:24] <wutf> i just sed -r 's/xenial/yakkety/' my /etc/apt/sources.list, and i'm wondering how there are so many new packages already...
[19:24] <wutf> yeah
[19:25] <nacc> well, the version in debian (which is typically the version in ubuntu, or was at some point) is not necessarily the same as upstream
[19:25] <nacc> there is an autosync that goes on for some time, for packages that can be synced (already in-sync between ubuntu and debian)
[19:26] <wutf> actually i mean for a specific package, like ode
[19:26] <wutf> ie a set of scripts that check each package..
[19:26] <nacc> ode has the same version in 16.04 as in 16.10?
[19:26] <wutf> yeah, but if it's updated..
[19:27] <wutf> a new release comes out
[19:27] <wutf> that's handled manually for all packages?
[19:27] <nacc> in debian
[19:27] <nacc> ?
[19:27] <wutf> no
[19:27] <wutf> up-up-stream
[19:27] <wutf> upupstream
[19:28] <nacc> wutf: IME, typically, a new version of a package only shows up if it's in Debian, unless there is someone actively pacakging/maintaining it in Ubuntu
[19:28] <nacc> for much of universe, i think it's just what is in Debian
[19:28] <nacc> but don't quote me on that :)
[19:29] <nacc> if Ubuntu does jump Debian's versioning, you can see that with a -0ubuntu1 style versioning (the -0 implies that is not a Debian published base)
[19:29] <wutf> i'm asking how it's possible that so many packages are kept up to date with their source releases
[19:29] <wutf> if it's not automated
[19:29] <sarnold> it's mostly up to debian maintainers to periodically check
[19:30] <sarnold> there are some automated tools (uscan) to try to help out but it's potentially overwhelming
[19:30] <nacc> it has to be packaged by someone
[19:30] <nacc> sarnold: does debian automate uscan runs? (j/w)
[19:30] <nacc> i know one of the websites notifies you if there is a new upstream based upon d/watch
[19:30] <wutf> ah, uscan
[19:31] <sarnold> nacc: ahh that might be more like it, perhaps uscan is only used once you're aware that there's something new :)
[19:31] <nacc> uscan + uupdate is how you update a package if the d/watch file is able to indicate a new upstream version
[19:31] <nacc> but it still requires someone to run those commands, aiui, and to verify the packaging is right, etc
[19:31] <wutf> this makes more sense. you write watch files for packages and get notified automatically when an update is detected
[19:32] <nacc> and i'm not entirely sure there is a notification side of htings (I assume there is, but I don't know where it lives or runs if so)
[19:33] <nacc> you can see here, at least, even though the watch file is broken, something did look for it: https://packages.qa.debian.org/p/php7.0.html
[19:36] <hallyn> pitti: got a minute by chance?
[19:40] <wutf> upgrade went off without a hitch
[19:40] <wutf> i searched online for any sign of autuomated uscans but didn't see anything
[19:41] <nacc> wutf: well clearly the debian package QA is running something
[19:41] <wutf> link?
[19:42] <wutf> ah.
[19:42] <wutf> yes, clearly they are doing automated uscan:)
[19:43] <pitti> hallyn: sorry, closing session > airport > 15 h flight :(
[19:43] <wutf> https://ouaza.com/static/conf/pts-internals.pdf
[19:43] <sarnold> pitti: oof. safe travels.
[19:44] <hallyn> pitti: \o  have a good and safe flight
[19:44] <hallyn> mbiebl: can i pester you? :)
[19:46] <hallyn> hm, guess not.  back to the google
[19:47] <pitti> sarnold, hallyn: thanks
[20:10] <tdaitx> doko: thanks for the arm32 fix
=== alexisb is now known as alexisb-afk
=== salem_ is now known as _salem
=== mnepton is now known as mneptok