User1: 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?)
User2: User1 drop the ':'
User1: User2 Thanks!
User3: er, the colon should be fine
User3: I use that every time, and it works fine
User3: https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Vendor/Ubuntu.pm#n173
User3: here's the regular expression ;)
User1: User3 With "LP: #...", does it close the bug report (i.e. mark it "Fix released") on upload?
User3: it marks it as Fix Released as soon as it hits the release pocket, I believe
User2: User3 right, with a colon, i believe the watcher changes the bug state, rlaager asked what would prevent htat
User1: Note that I want to reference a bug report, but this is not an entire fix, so I do NOT want it to close.
User3: ohhh
User1: 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.
User1: Not that I can upload to Ubuntu anyway, but I'm trying to produce debdiffs that are 100% good-to-go.
User4: you could always go set it back to IN PROGRESS or something afterwards
User3: oh
User4: or open a new bug for this small problem?
User3: I misread
User4: "small"
User3: yes, removing the colon should work based on that regular expression
User3: sorry to cause confusion
User1: User4 So, can packages move from universe to main post release, or is ZFS stuck in universe for the lifetime of Xenial?
User4: User1 *sigh* I hadn't noticed it didn't make it to main.
User4: User1 there's precedent for making promotions to main retroactive, anyway: https://bugs.launchpad.net/ubuntu/+source/ppc64-diag/+bug/1417608
User5: Launchpad bug 1417608 in servicelog (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,Confirmed]
User1: User4 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).
User4: User1 yes :(
User4: 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.
User1: 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?
User4: yeah that should be fine
User4: 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.
User6: It's a bit annoying, aye. >_>
User1: 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.
User4: that works out well for everyone :) bugs get fixed
User7: User10 there would be another hanged s390x test, marble, at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
User7: that's the only thing blocking
User7: or maybe Laney ^ ?
User8: Mirv, pitti is in Austin so probably still sleeping
User7: User8 ok. I'm just trying to find someone who has access to the autopackagetest infra to restart that one test.
User8: yeah, no idea who that is
User8: but better to ask like than to ping one specific person that might not be around
User7: 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.
User8: that sounds like an issue
User9: User7 I skipped it now, looks like it got blacklisted
User7: User9 ok, let's see if it gets unblocked now
User7: User9 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src seems unchanged, still "Test in progress"
User7: (without being in progress or running page during the last hour)
User9: Dunno
User9: Need to wait then
User7: ...for pitti
User7: likely another case of bug #1571353 and some magic forcing is needed while the bug is still open
User5: 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
 * Laney tried one more thing
User7: ok, page updated, no change, and no new test runs completed or anything running currently
User10: seb128, User9 FYI: retry-autopkgtest-regressions --state RUNNING
User10: this generates all commands
User10: then pick out the ones you want/need
User10: re-running marble now
User8: pitti, hey! happy friday
User8: pitti, does that work with "hanging" instances?
User10: and that bug is high on my list, for next week
User10: User8 well, the test request got lost
User8: ah ok
User8: so retry would have worked
User10: which normally "should not happen"â¢, but can with bug 1571353
User5: 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
User10: User8 right, except that you don't have a convenient button on excuses, you need to use run-autopkgtest
User10: User8 other than heating up the universe it's completely safe to re-run tests
User10: if there are more than one results for a test, britney will just pick one (preferring PASSes)
User10: User8 et joyeux vendredi Ã  toi aussi ! comment vas-tu ?
User8: pitti, noted for next time
User8: pitti, Ã§a va bien, il fait beau et chaud ici ! tu rentres quand ?
User10: User8 well, hopefully there won't be many next times any more :)
User10: this is the only known way how to lose test requests right now, and we know how to fix it
User10: User8 cet Ã pres-midi, mon vol va Ã  17h15
User8: pitti, tu pourras profiter de ton dimanche alors :-)
User8: pitti, k, fingers crossed that once that one is fixed things are reliable then!
User10: User8 en effet ! et le temps est trÃ¨s bien, donc on va Ãªtre dehors tout le dimanche :)
User8: sounds great! :-)
User8: hum
User8: did launchpad stopped deleting SRUs from -proposed when they move to -updates?
User8: or are they staying there until the update is rolled out at 100% and they cleaned out?
User11: LP never did that automatically
User8: I never noticed packages having "updates, proposed" on their ubuntu package before
User8: e.g https://launchpad.net/ubuntu/+source/gnome-software
User11: they're listed on
User11: http://people.canonical.com/~ubuntu-archive/pending-sru.html
User8: oh ok
 * cjwatson processes the current batch
User11: it's just manual to avoid accidents
User8: I guess it's usally done frequently enough that I never noticed
User11: and because cleanup is in no way urgent
User8: cjwatson, thanks!
User11: np
User8: (or maybe usually whoever does the pocket copy does the cleanup as well while they are at it?)
User11: more usual to wait for it to show up in the report IME
User7: User8 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)
User8: Mirv, pitti said he was doing it
User8: pitti, did you do? just checking if there was an issue before doing it as well
User8: cjwatson, k, thanks for the details!
User10: User8 I did run the command, yes
User8: Mirv, ^
User10: sorry, can't check this now, in meeting
User7: ok thanks pitti, I'm just not finding any new log at http://is.gd/aX745A listing nor anything on the running page
User10: triggering it again
User7: 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.
User10: right
User10: oh!
User10: Mirv, User8 sorry, completely forgot: the workers blacklist yakkety/s390x/marble
User10: as this is killing the workers and causing tmpfail loops
User10: so hinting it is the right solution
User10: and Laney did that
User10: so the next britney run ought to pick this up
User8: pitti, Laney did that earlier, shouldn't it have picked it up by now?
User10: ah, because it's in progress, and we wait for that, it's not failed
User10: meh
 * pitti hints it harder
User10: will go in next roud
User10: roud
User10: round
User8: pitti, thanks!
User8: Mirv, ^
User9: meow
User9: User10 what did you do?
User9: I killed it from pending.json but that didn't work, it came back
 * Laney wasn't sure how to clear it
User10: User9 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
User10: if someone could file a bug about this, I'd appreciate
User9: User10 fine, but I want to know how you cleared out the inprogress too so I can do that next time
User10: User9 I didn't, I just force-skiptest'ed qt
User10: right now nothign tells britney that the test is "done" (i. e. not really ran, but ignored)
User9: nod
User9: but force-badtest could force INPROGRESS too
User9: filed the other bug anwyays
User10: User9 no, that only forces over failures
User10: regressions, I mean
User9: User10 is there a reason it has to be like that?
User10: User9 no, we could fix britney to apply force-badtest on inprogress
User9: ya, that was my question really
User10: User9 but I think we should still clean up the blacklisting handling, as there's no feedback from infra â britney
User10: and we have to have explicit hints
User9: User10 I filed both
User10: thanks
User12: 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
User12: Mirv, the alternative is to remove the pocl dependency
User8: pitti, did you see Laney's reply on bug #1575152?
User5: bug 1575152 in gstreamer1.0 (Ubuntu Xenial) "[SRU] gstreamer 1.8.1" [Undecided,New] https://launchpad.net/bugs/1575152
User8: slangasek, xnox, seems the upstart changes in yakkety are not warning free, .xsession-errors has some complains about UpdateActivationEnvironment
User13: seb128, right, that's what i thought was the case which tinoco (?!) said are all good.
User13: let me find where we talked about that
User14: User13 me
User14: ?
User13: inaddy, oh. are you Trevinho?
User14: tinoco == inaddy
User14: not me =)
User13: seb128, https://launchpad.net/~3v1n0
User13: inaddy, not you =)
User15: User13 ehm?
User15: ah...
User15: User8 which warning? any log?
User8: Trevinho, bug #1578934
User5: 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
User13: Trevinho, possibly there are things we try to push before dbus is up...
User15: User13 no, it's just about fixing the dbus path
User13: =)
User15: User13 it's one line change in dbus_proxy = ...
User15: User13 /org/freedesktop/DBus instead of /
User13: /o\ that's what i said, i never recalled that thing actually worked right.... =/
User15: User13 it's weird that it fixed the pete-woods bug, on his terminal... As thigns were exported
User15: but, well... fixing the path should fix things
User15: User13 should I do the branch, or you do it?
User13: Trevinho, send a merge proposal and I can land it for you
User7: tjaalton: doko is interested in you looking into pocl ftbfs, at 17:31
User15: User13 ok, fine
User12: Mirv, ouch again ...
User15: User13 here you are https://code.launchpad.net/~3v1n0/upstart/activation-proper-dbus-path/+merge/294025
User15: User13 FYI this error wasn't present at the time you did the patch, though... Since testing it in trusty still works with no errors.
User13: fun.
User13: does this new thing work in both old and new?
User15: User13 yes
User15: User13 can you also care about SRUing those MPs?
User13: maybe
User15: maybe? :)
User15: User13 Iv'e tested that change again, and it seems that it also fixes some missing env vars now... so nice one
User16: are there sufficient tests in place to use the pre-release ubuntu?
User16: i used xenial long before it was released and experienced few problems
User16: 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
User4: it's probably fine for enthusiasts, though I wouldn't recommend it for people who just want a computer to work
User4: but if you like filing bug reports when things break, it should fit alright :)
 * dobey wishes computers would work
User16: sarnold, what kind of testing framework do you guys have?
User16: is general system stability tested before packages go into the devel release?
User4: User16 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
User17: not exactly
User17: autopkgtests get run, but those of course don't test everything
User16: there is an automated test generation and running framework?
User4: test running
User16: ah
User4: the tests have to be built into the packages using http://dep.debian.net/deps/dep8/
User17: if there was something generating tests automatically, i'd be more afraid of something other than my pc not breaking
User16: you could autogenerate tests using fuzzing
User17: viva la robolucion
User4: User17 lol
User4: fuzzing only gets you so far. very little of what is tested via autopkgtests would be reproducable with fuzzing testing
User16: command line tools can have the fuzzer seeded with the man page
User16: gui tools could run through UIs
User16: ^_^
User17: i think we have a fairly decent idea of how to build our tests
User4: funny enough, i'm at the moment reading a debdiff that adds dep-8 tests to a package: https://launchpadlibrarian.net/258172429/spl-linux_91.69.162.6-0ubuntu1_91.69.162.6-0ubuntu3.diff.gz
User16: is there a process for automatically keeping packages up to date with their releases?
User16: or are all packages handled manually
User2: User16 what do you mean?
User2: User16 do you mean upstream releases?
User16: i just sed -r 's/xenial/yakkety/' my /etc/apt/sources.list, and i'm wondering how there are so many new packages already...
User16: yeah
User2: well, the version in debian (which is typically the version in ubuntu, or was at some point) is not necessarily the same as upstream
User2: there is an autosync that goes on for some time, for packages that can be synced (already in-sync between ubuntu and debian)
User16: actually i mean for a specific package, like ode
User16: ie a set of scripts that check each package..
User2: ode has the same version in 16.04 as in 16.10?
User16: yeah, but if it's updated..
User16: a new release comes out
User16: that's handled manually for all packages?
User2: in debian
User2: ?
User16: no
User16: up-up-stream
User16: upupstream
User2: User16 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
User2: for much of universe, i think it's just what is in Debian
User2: but don't quote me on that :)
User2: 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)
User16: i'm asking how it's possible that so many packages are kept up to date with their source releases
User16: if it's not automated
User4: it's mostly up to debian maintainers to periodically check
User4: there are some automated tools (uscan) to try to help out but it's potentially overwhelming
User2: it has to be packaged by someone
User2: User4 does debian automate uscan runs? (j/w)
User2: i know one of the websites notifies you if there is a new upstream based upon d/watch
User16: ah, uscan
User4: User2 ahh that might be more like it, perhaps uscan is only used once you're aware that there's something new :)
User2: uscan + uupdate is how you update a package if the d/watch file is able to indicate a new upstream version
User2: but it still requires someone to run those commands, aiui, and to verify the packaging is right, etc
User16: this makes more sense. you write watch files for packages and get notified automatically when an update is detected
User2: 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)
User2: 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
User18: User10 got a minute by chance?
User16: upgrade went off without a hitch
User16: i searched online for any sign of autuomated uscans but didn't see anything
User2: User16 well clearly the debian package QA is running something
User16: link?
User16: ah.
User16: yes, clearly they are doing automated uscan:)
User10: User18 sorry, closing session > airport > 15 h flight :(
User16: https://ouaza.com/static/conf/pts-internals.pdf
User4: User10 oof. safe travels.
User18: User10 \o  have a good and safe flight
User18: mbiebl: can i pester you? :)
User18: hm, guess not.  back to the google
User10: sarnold, User18 thanks
User19: User12 thanks for the arm32 fix
ubuntu-devel
Ubuntu IRC