| 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:04 |
| rlaager | nacc: Thanks! | 01:06 |
| Logan | er, the colon should be fine | 01:07 |
| Logan | I use that every time, and it works fine | 01:07 |
| 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:08 |
| Logan | ohhh | 01:09 |
| 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:10 |
| 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:11 |
| rlaager | sarnold: So, can packages move from universe to main post release, or is ZFS stuck in universe for the lifetime of Xenial? | 01:12 |
| sarnold | rlaager: *sigh* I hadn't noticed it didn't make it to main. | 01:13 |
| 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:14 |
| sarnold | rlaager: yes :( | 01:15 |
| 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:16 |
| 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:17 |
| sarnold | that works out well for everyone :) bugs get fixed | 01:19 |
| === happyaro1 is now known as happyaron | ||
| === fginther` is now known as fginther | ||
| === unixpro1970 is now known as _unixpro1970 | ||
| 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 | 05:56 |
| Mirv | or maybe Laney ^ ? | 08:07 |
| seb128 | Mirv, pitti is in Austin so probably still sleeping | 08:09 |
| 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:11 |
| 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:18 |
| seb128 | that sounds like an issue | 08:21 |
| Laney | Mirv: I skipped it now, looks like it got blacklisted | 08:43 |
| Mirv | Laney: ok, let's see if it gets unblocked now | 08:52 |
| 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:50 |
| Mirv | ...for pitti | 09:51 |
| 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 | 09:52 | |
| Mirv | ok, page updated, no change, and no new test runs completed or anything running currently | 10:15 |
| === _salem is now known as salem_ | ||
| === JanC is now known as Guest26117 | ||
| === JanC_ is now known as JanC | ||
| pitti | seb128, Laney: FYI: retry-autopkgtest-regressions --state RUNNING | 12:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| pitti | seb128: et joyeux vendredi à toi aussi ! comment vas-tu ? | 12:55 |
| seb128 | pitti, noted for next time | 12:56 |
| 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:57 |
| 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:58 |
| pitti | seb128: en effet ! et le temps est très bien, donc on va être dehors tout le dimanche :) | 12:59 |
| seb128 | sounds great! :-) | 13:00 |
| 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:39 |
| 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:40 | |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| pitti | seb128: I did run the command, yes | 13:47 |
| seb128 | Mirv, ^ | 13:47 |
| pitti | sorry, can't check this now, in meeting | 13:48 |
| 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:49 |
| 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:52 |
| pitti | right | 13:53 |
| pitti | oh! | 13:56 |
| pitti | Mirv, seb128: sorry, completely forgot: the workers blacklist yakkety/s390x/marble | 13:56 |
| 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 | 13:57 |
| === chuck__ is now known as zul | ||
| pitti | so the next britney run ought to pick this up | 13:57 |
| seb128 | pitti, Laney did that earlier, shouldn't it have picked it up by now? | 13:58 |
| 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 | 13:59 | |
| pitti | will go in next roud | 14:00 |
| pitti | roud | 14:00 |
| pitti | round | 14:00 |
| seb128 | pitti, thanks! | 14:00 |
| seb128 | Mirv, ^ | 14:00 |
| 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:08 | |
| 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:11 |
| 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:12 |
| pitti | right now nothign tells britney that the test is "done" (i. e. not really ran, but ignored) | 14:13 |
| Laney | nod | 14:14 |
| Laney | but force-badtest could force INPROGRESS too | 14:14 |
| Laney | filed the other bug anwyays | 14:15 |
| pitti | Laney: no, that only forces over failures | 14:16 |
| pitti | regressions, I mean | 14:16 |
| Laney | pitti: is there a reason it has to be like that? | 14:18 |
| 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:19 |
| Laney | pitti: I filed both | 14:21 |
| pitti | thanks | 14:22 |
| 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:31 |
| doko | Mirv, the alternative is to remove the pocl dependency | 14:33 |
| === dgadomski_ is now known as dgadomski | ||
| 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:35 |
| seb128 | slangasek, xnox, seems the upstart changes in yakkety are not warning free, .xsession-errors has some complains about UpdateActivationEnvironment | 15:42 |
| 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:49 |
| 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:50 |
| Trevinho | ah... | 15:51 |
| Trevinho | seb128: which warning? any log? | 15:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| Trevinho | but, well... fixing the path should fix things | 15:55 |
| Trevinho | xnox: should I do the branch, or you do it? | 15:55 |
| 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 | 15:56 |
| doko | Mirv, ouch again ... | 16:02 |
| Trevinho | xnox: here you are https://code.launchpad.net/~3v1n0/upstart/activation-proper-dbus-path/+merge/294025 | 16:06 |
| 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:07 |
| xnox | fun. | 16:12 |
| xnox | does this new thing work in both old and new? | 16:12 |
| Trevinho | xnox: yes | 16:16 |
| Trevinho | xnox: can you also care about SRUing those MPs? | 16:16 |
| xnox | maybe | 16:19 |
| Trevinho | maybe? :) | 16:22 |
| Trevinho | xnox: Iv'e tested that change again, and it seems that it also fixes some missing env vars now... so nice one | 16:56 |
| wutf | are there sufficient tests in place to use the pre-release ubuntu? | 19:02 |
| 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:03 |
| sarnold | it's probably fine for enthusiasts, though I wouldn't recommend it for people who just want a computer to work | 19:06 |
| 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:07 |
| 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:08 |
| wutf | there is an automated test generation and running framework? | 19:09 |
| sarnold | test running | 19:09 |
| wutf | ah | 19:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| hallyn | pitti: got a minute by chance? | 19:36 |
| 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:40 |
| nacc | wutf: well clearly the debian package QA is running something | 19:41 |
| wutf | link? | 19:41 |
| wutf | ah. | 19:42 |
| wutf | yes, clearly they are doing automated uscan:) | 19:42 |
| 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:43 |
| hallyn | pitti: \o have a good and safe flight | 19:44 |
| hallyn | mbiebl: can i pester you? :) | 19:44 |
| hallyn | hm, guess not. back to the google | 19:46 |
| pitti | sarnold, hallyn: thanks | 19:47 |
| tdaitx | doko: thanks for the arm32 fix | 20:10 |
| === alexisb is now known as alexisb-afk | ||
| === salem_ is now known as _salem | ||
| === mnepton is now known as mneptok | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!