[00:00] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1483440 [00:00] Launchpad bug 1483440 in linux (Ubuntu) "odd behavior with /proc/net/route reading via sh 'read'" [Undecided,New] [01:02] infinity, is your /proc/net/route exactly 512 bytes like mine is [01:02] did i just really luck into the fencepost ? [01:05] smoser: No, mine is 768. Though, still a curiously round number in binary land, so I assume the lines are a padded length. [01:05] And, indeed, they are. [01:06] heh, mine's 77 * 128 bytes long [01:07] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1483440 [01:07] Launchpad bug 1483440 in linux (Ubuntu) "odd behavior with /proc/net/route reading via sh 'read'" [Undecided,Confirmed] [01:08] this reminds me so much of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381005 -- but that looks to be tty specific [01:08] Launchpad bug 1381005 in linux (Ubuntu Vivid) "Long stdin from terminal can result in code execution" [High,In progress] [01:08] walking through powers of two for byte size, i get error right at 512, which is exactly mine. [03:01] Good morning [03:02] slangasek: I heard you want to force gcc-5 into wily-release, so that at least some of the transitions can land? [03:02] hey pitti, this seems especially early.. [03:02] that would at least help a bit to untangle the mess [03:02] sarnold: yeah, can't sleep any more :/ [03:02] oh :( sorry [03:12] seems to be the trend.. [03:24] tjaalton: morning :) [03:25] The early bird can bite me [03:26] hehe [03:26] yeah or the cat, woke me up 1+ hrs ago [04:24] blargh [04:25] i can't install packages in the wily chroot on the ppc64el porter box [04:25] SystemError: E:Unable to correct problems, you have held broken packages. [04:25] how can this be unpicked? [04:25] i don't know how to use rapt very well [04:26] mwhudson: if apt-get -f install doesn't help, then you need an RT I'm afraid [04:26] unfortunately the schroots on our porter boxes are quite useless [04:26] ERROR: only install/update/upgrade/dist-upgrade supported as argument [04:26] rt time! [04:26] also eod time so that's ok i guess [04:26] mwhudson: perhaps while you are at it you can ask for re-setting them up properly [04:27] i. e. with session overlays instead of "everyone uses and breaks one single schroot" [04:27] pitti: heh uh, i don't think putting that literal text into the rt would be productive [04:27] I thought I did that years ago already [04:27] but it seems nobody got around to it yet [04:27] mwhudson: asking for session overlays? but that's the right thing to do, and constructive? [04:28] nobody except IS should ever be able to access the "real" (source) schroot [04:28] one should be able to start a session, hack in that, end it, and it's all gone [04:28] i can see how that would be useful [04:28] but i'm not sure i'm going to fight that fight today [04:29] what makes me wonder is how IS set this up in the first place, given that sessions are schroot's default mode of operation [04:29] you actually have to go through great lenghts of effort to set them up the way they are right now :) [05:50] pitti: if by "force" you mean "review the remaining autopkgtest blockers and make judicious decisions about whether to override them", yes [05:52] slangasek: oh, please don't force-badtest those; all the KDE failures also appear in more proper excuses where they *should* hold back stuff until the transitions get completed [05:52] slangasek: I thought you were going to force-skiptest gcc-5 itself only? [05:52] pitti: I was not suggesting a force-badtest at all [05:52] (after reviewing the remaining failures, yes) [05:53] pitti: there should be some information on the pad; I know robru confirmed that some of the regressions started only after gcc-defaults landed so are not related, but I think there are some remaining failures that need looked at [05:54] pitti: yeah i put those at the very bottom of the pad [05:54] but that's misleading [05:55] well, it can be argued that gcc-5 broke all those, but shouldn't they rather be tacked to the kde lib renames instead of gcc-5 itself? [05:56] pitti: how can that be argued? There's a handful of cases where tests passed after gcc5 was uploaded. [05:56] either way, for gcc itself it doesn't matter much whether it promotes; we effectively can't "hold back" gcc, as we build everything from -proposed [05:56] I thought we wanted to do this to unblock some unrelated transitions [05:57] I wouldn't say unrelated [05:57] e. g. scim, snappy, schroot, etc. [06:00] so, unrelated to kde but not unrelated to gcc, sure [06:27] pitti: fyi gr-* failed because gnuradio has a wrong dependency on libuhd [06:27] slangasek: yeah, just looked at it [06:27] slangasek: want me to fix, or are you on it? [06:28] (yay for not using proper shlibs..) [06:28] pitti: I'm just letting you know since you triggered the builds; I'm off to bed now [06:28] slangasek: right, the previous FTBFS was due to non-current gnuradio, so it looked worth a retry [06:28] slangasek: ack, will fix [06:31] slangasek: are you the blue editor on the pad? [06:31] (I don't see any names except robru's and mine) [06:32] pitti: yep [06:32] ah, thanks [06:32] and going to bed for real now ;) [06:33] slangasek: sleep well! [06:36] Logan: hmm, aqsis still fails, did that work locally for you for some weird reason? [06:40] jdstrand, can you look again at bug 1466290?, remaining core GNOME is blocked on that [06:40] bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New] https://launchpad.net/bugs/1466290 [07:10] good morning [07:15] I have a situation that I feel is a but in the ubuntu o/s (unity?) and I'm having a hell of a time finding a way to just submit a bug in my own words. Been to https://bugs.launchpad.net/ubuntu ... click "report a bug" and get a howto document (not a place to submit a bug). In my particular case, there is no system information that would be useful. it will effect every 14.04 system (no matter the hardware) because it's a design [07:15] choice I'm pointing out. [07:15] this isn't really a "bug" channel [07:15] Been on #ubuntu and not getting anywhere in an economic amount of time. What can I do? [07:15] (check the topic) [07:16] well perhaps the requirement is too much to ask (time wise) for something as simple as this. Shame if suffering result because the failure to report somethgin important [07:17] Suppse, at this point, ubuntu doesn't want you to report bugs [07:18] you know it does want you to report bugs, this was explained in #ubuntu [07:18] so hitting other channels and repeating won't help [07:18] getting the bug logged, will, which if you rejoin #ubuntu people will work through with you [07:20] I just don't feel it's fair to require someone to do research before they can report what seems like a problem to them. Person should be able to spend 5 or 10 minutes total, make a couple clicks, write in some text, click "submit" and be done with it. [07:20] this isn't the channel for this discussion [07:21] Suppse, at this point, ubuntu doesn't want you to report bugs [07:21] but hey - who cares - right? [07:21] this self pity stuff doesn't help [07:44] doko: bug 1483400> why is dropping -Werror not an option? IMHO -Werror is just plain wrong in "production" builds (specific errors are okay and good of course) [07:44] bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400 [07:45] -Werror is only ever a thing for local developer builds [07:46] pitti: I used to think that way too, but I've come to love gcc warnings more and more over the years. [07:46] sure, they are good [07:46] pitti: And a lot of them really, really do point to real bugs that will affect runtime. [07:46] infinity: not in my experience then [07:46] I used to see tons of FTBFS due to deprecation warnings wiht e. g. new glib which turned into FTBFS [07:46] Oh, well, that's glib. :P [07:47] I'm talking gcc warnings, not people abusing #warning. [07:47] and building a package with a new compiler which has new warnings doesn't suddenly break your software [07:47] No, it means it was already broken, often. [07:47] the developer of that software should build with it, but never packages [07:47] I still kinda want to know. [07:47] yes, but no-change rebuilds are the wrong place for that [07:48] See, I still disagree. [07:48] "It was always broken" is no excuse for not fixing it. [07:48] And when we discover it is a good time to fix it. [07:48] well, I was mostly interested in why doko said "not an option" -- just out of general principle, or whether he reviewed the warnings and they are actual errors [07:48] I have a slight bias here after putting in years to get glibc to build warning-free. :P [07:48] But the number of real bugs we found in the process was pretty shocking. [07:49] infinity: yes, and that's the very "developer build" use case [07:49] pitti: We build it with -Werror in Debian and Ubuntu too! [07:49] (And Fedora and Gentoo, and...) [07:49] I'm not going to fix all the warnings in juju-mongodb [07:50] and while I do agree that warnings are important, they are not *more* important to me as a random "do this transition" packager than to upstream [07:50] (or the package maintainer) [07:50] pitti: So, the answer for things you don't care about fixing is to see what *new* warning are affecting it, decide they don't matter, and build with -Wno-error=$warning [07:50] and I yet have to see a C++ package rebuild that doesn't have warnings :) [07:50] Cause a new warning might be a nasty bug. But maybe the warning of the day isn't. [07:50] infinity: right, that was kind of the point of my question to doko [07:51] Effectively, when you drop -Werror entirely, you're making a future decision that you can't support because you have limited info (you don't know if future warnings will catch awesome bugs or code style issues or cows in your comment blocks) [07:53] In my experience with Mir, we've had a bunch of new warnings appear as compilers advance. These have *all* been stylistic. [07:54] pitti, at least -Werror is not good enough to fix the ftbfs [07:54] well, it's a question of who can and will do something about it [07:54] But we're doing more fun things than the average package, and are aggressive with enabling warnings, and CI requires the build to succeed with -Wall -Werror before it lands, so... [07:54] upstream and a package's maintainer should [07:58] pitti: Anyhow, mongo may well be a lost cause, and maybe the answer is to turn off -Werror, and purists like doko and I should shut up. [07:58] pitti: I definitely get where you're coming from too. [07:58] pitti: But if it's just a few warnings on repeat, -Wno makes more sense. [07:58] IMO. [07:58] infinity: yes, agreed [07:59] pitti, if you work on this, please update to the current upstream of the 2.6 series ... [08:00] currently working on luabind and libcrypto++ FTBFSes (I spotted the above when reviewing the list) [08:00] doko: noted [08:09] infinity: "[-Werror=unused-variable]" -> that definitively sounds like a case of -Wno-error :) [08:09] pitti: Yeah, unused-variable probably should be in extra, not all. [08:09] (or is mongo building with -Wextra?) [08:10] I'll look at mongodb/juju-mongodb, and update the former to 2.6.10 [08:10] unused-variable is in -Wall. That seems perhaps wrong. [08:24] hmh, why does apt continuously give me hash mismatch on http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/i18n/Translation-en [08:25] good to complain, the continuity stopped [08:33] Mirv, I get that often, but usually on mirrors [08:33] usually clears up after 5mins or so [08:41] darkxst: this was on main. I do tend to see that every now and then, but usually it's immediately that the next apt update works. this was maybe that 5min or such [08:43] doko: looking at https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1483410 -- when I test-build the package from debain in a wily sbuild I get python 3.4 and it builds okay, what am I missing? [08:43] Launchpad bug 1483410 in checkbox-support (Ubuntu) "checkbox-support FTBFS in wily" [High,In progress] [08:43] doko: is that built using something (proposed?) that has 3.5 as default? [08:44] zyga, come out of your comfort zone and enable -proposed as the buildds? [08:44] doko: ack, thanks [08:44] :-) [08:56] I'm getting hash sum mismatch on wily-proposed, is that something common/expected? [08:57] odd, now it works [08:58] that's the case fairly often indeed [09:04] sil2100: did you have a chance to review http://pad.ubuntu.com/drop-obsolete-phone-packages already? [09:07] pitti: no, on it right now, I had a few firefights yesterday :) [09:07] sil2100: cool, thanks; not that urgent, I was just wondering [09:33] pitti: ok, had a look at those [09:33] pitti: so libdbusmenu-qt is required and can't be removed, but I'm not sure about libcolumbus [09:34] pitti: the rest looks fine to get rid of [09:34] I remember hud was using libcolumbus on the desktop as well some time ago, so I suppose it's still using it [09:34] And since we have hud still in unity7 desktops, I wouldn't remove it [09:51] doko: fixed, should I just request a new version in Debian (which might take a while, I cannot upload yet) or do you want to get the patch in ubuntu faster? [09:54] zyga, ubuntu then. and pretty please watch these packages, if you sync them, and they ftbfs [09:55] doko: I just realized this is not in my inbox, how can I ensure we are subscribed? [09:55] doko: I didn't explicitly sync them they just got auto synced [09:56] doko: I'm watching debian bugs carefuly now but bugs on source packages in ubuntu still seme not to be subscribed [09:58] doko: in bug 1483400, you say "just building without -Werror is not an option". Why? [09:58] bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400 [09:59] pitti: hi. Did you get any more reports of that symbols problem with fglrx? I'm asking as my 15.04 installation works well here [09:59] rbasak, because it fails later on boost1.58 (please talk with pitti) [10:10] tseliot: yes, the u-d-c test still fails [10:10] rbasak: I'm currently test-building a potential fix for both [10:11] argh, one failed with more followup errors, the other with "out of space" [10:11] pitti: can you point me to the link again, please? [10:11] pitti: thanks! Please let me know if you need anything. [10:11] tseliot: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-drivers-common/20150804_151050@/log.gz [10:11] tseliot: from http://autopkgtest.ubuntu.com/packages/u/ubuntu-drivers-common/wily/amd64/ [10:16] sil2100: cheers! I'll go through them with reverse-depends again and clean up [10:16] pitti: thanks a lot :) === soee_ is now known as soee [10:20] pitti: I'm not sure if you saw my last few messages. I was saying that it seems to me that you're testing fglrx instead of fglrx-core (which is what builds the module) [10:21] tseliot: yes, it installs fglrx indeed [10:21] tseliot: ah, did the module recently move from fglrx to fglrx-core? [10:21] tseliot: then I suppose we just need to adjust the test? [10:21] pitti: yes, that's what I was trying to say [10:22] tseliot: how is it called for fglrx-updates? there's no f-core-updates [10:22] ah, fglrx-updates-core [10:22] yep [10:22] tseliot: I'll try that once my computer becomes usable again (building two mongodbs ATM) [10:23] tseliot: thanks! [10:23] pitti: thanks to you [10:27] doko: how do you want me to send the patch (I never uploaded directly to ubuntu before), a debdiff attached to the bug? [10:28] zyga, do you have upload rights? [10:28] doko: no [10:28] pff [10:28] doko: (though I'd like to work on gettin that) [10:28] after all those years ... [10:28] apply for it [10:28] per package upload or UD? [10:28] dholbach, ^^^ here's your next victim [10:28] :D [10:28] dholbach: with pleasure :) [10:29] zyga, send me the patch, or file a bug report [10:29] allright [10:29] dholbach: and please tell me what to do to apply for upload rights [10:44] doko: sent [10:54] __hmm__ [10:54] doko: looking, I just built it like 12s of times [10:55] oh, I see... somehow the python3-gi dependency is not in the debdiff, sorry, my bad [10:55] that's all? [10:55] doko: yes [10:56] doko: it's in debian, I must have d'd it by accident before running debdiff [10:56] doko: it's a build-dependency [10:56] doko: sorry :/ [10:56] doko: I just checked that it's not in the debdiff [10:56] doko: do you want -1ubuntu2 or will you do that yourself? [10:59] https://launchpad.net/ubuntu/+source/checkbox-support/0.20-1ubuntu2 [11:00] rbasak: juju-mongodb now fails in that "smoke" test during build: http://paste.ubuntu.com/12054846/ [11:01] rbasak: any idea what's wrong with the pymongo module? [11:01] doko: thank you [11:01] rbasak: AFAICS there is no "Connection" in dir(pymongo) [11:02] pitti: I know no more than you on this, sorry. If the server team needs to take this on I can add it to our list. [11:03] * pitti retries mongodb, take IV [11:04] doko: built fine! I'll subscribe to all the source package bugs not to miss that next time [11:06] rbasak: I'm adding my preliminary patch with the above output to bug 1483400 [11:06] bug 1483400 in mongodb (Ubuntu) "mongodb ftbfs with GCC 5 and boost 1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483400 [11:06] Thanks! === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [11:10] pitti: are you still working on the bug or are you handing it over to us? [11:10] rbasak: I'm trying something [11:10] OK, np [11:11] I found http://api.mongodb.org/python/current/tutorial.html, I hope it's just a simple renaming [11:11] I see the test suite now, looking good [11:19] dpkg-deb: building package 'juju-mongodb' in '../juju-mongodb_2.4.10-0ubuntu4_amd64.deb'. [11:19] \o/ [11:19] rbasak: ^ [11:24] \o/ [11:24] Thank you! [11:24] zyga, sure... which packages do you want to upload? which did you upload in the past? [11:25] dholbach: I never uploaded packages directly to ubuntu before, it would be fantastic if we could (the checkbox development team in general but probably me in particular for now), upload plainbox, checkbox-ng, checkbox-support, plainbox-provider-checkbox, plainbox-provider-resource-generic and perhaps one or two misc packages that I also maintain in debian, python-guacamole, python-morris, python-padme [11:27] dholbach: we also want to land a whole new checkbox to wily and that will include two new packages (not in debian), checkbox-converged and qchartjs (a qml module) [11:27] nice, that should be possible [11:27] dholbach: excellent, what do I need to do? [11:30] zyga, https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess explains the application process [11:30] dholbach: allright [11:30] zyga, it's a lot like the membership process - so set up a wiki page, explain what you're after, get a few endorsements and attend a meeting [11:31] dholbach: one question, should I apply for per-package uploader or for something more generic? [11:32] zyga, as you like it... for something more generic, you might have to demonstrate a more diverse interest or prior work on other packages [11:33] dholbach: ok, let me read the precise difference between them and see what to do next [11:33] zyga, the process is very much the same [11:34] zyga, you might have to explain what your interests are and what you worked on in the past [11:37] Mirv, sil2100, seb128: I processed most of http://pad.ubuntu.com/drop-obsolete-phone-packages but qml-friends and friends (and thus libfriends) are still seeded on ubuntu-touch adn ubuntu-desktop-next; should these be dropped? [11:37] see "reverse-depends src:libfriends" [11:37] and "reverse-depends src:friends" [11:37] * ubuntu-desktop-next [amd64 armhf i386] (for friends-twitter) [11:37] * ubuntu-desktop-next [amd64 armhf i386] (for friends-facebook) [11:37] * ubuntu-touch [amd64 armhf i386] (for friends-facebook) [11:37] * ubuntu-touch [amd64 armhf i386] (for friends-twitter) [11:37] * unity-lens-friends (for friends) [11:38] dholbach: for what we are after (creation of ubuntu-specific new packages) core dev might be better as it includes "specify, develop and deploy new features for the default installation of Ubuntu" but I lack the required "hitory of substantial direct contributions to the distribution" [11:39] history* [11:39] zyga, maybe start with a checkbox package set first? [11:39] get it created for you, and team mates can apply for that later on as well [11:39] dholbach: yes, I think that is appropriate [11:39] cool [11:39] let me know if I can help with anything [11:39] dholbach: so package sets are only briefly mentioned there [11:39] dholbach: how does one create a new set? [11:40] dholbach: is that the delegated team concept? [11:40] no [11:40] just mention which packages you need upload rights for [11:40] ok [11:40] and mention that A, B and C should be made a package set [11:40] ok [11:40] later on you can still go and get packages added and removed [11:40] makes sense, thanks! [11:41] cool :) [11:43] pitti: wow, that's true === _salem is now known as salem_ [11:46] pitti: I'm pretty sure we don't use that anymore [11:46] But hm [11:46] Let's double-confirm with robru [11:47] sil2100: yeah, and in general even though we don't use the Friends anymore on the images, robru can weigh in if it'd be nice to keep it in archives still [11:48] sil2100: anyway, created https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_remove_friends/+merge/267648 [11:48] it is/was a nice program from user point of view [11:49] but maybe it could rather live on as a click package rather than in archives, if somewhere [11:50] pitti, unsure about friends, to be checked with kenvandine [11:51] Mirv: thanks! === salem_ is now known as _salem [12:44] tseliot: that's not it -- fglrx Depends: fglrx-core [12:44] tseliot: it actually fails to build in -proposed; I'll file a bug with the details [12:45] make[1]: gcc-4.9: Command not found [12:45] heh, that would do it :) [12:48] tseliot: filed as bug 1483695 [12:48] bug 1483695 in fglrx-installer-updates (Ubuntu Wily) "fails to build module in wily-proposed: gcc-4.9: Command not found" [High,New] https://launchpad.net/bugs/1483695 [12:52] tseliot: what I'm not sure about is where the gcc-4.9 comes from -- I can't find anything in fglrx about it [12:52] then again, nvidia* build fine, and I don't see it in dkms itself either === _salem is now known as salem_ [13:07] bdmurray, FYI team mapping update: ~checkbox-dev has agreed to look after xlsxwriter in main [13:23] pitti: maybe something's pulled in as a result of the depending on these: lib32gcc1 [amd64], libc6-i386 [amd64], dkms, make, linux-libc-dev [13:23] tseliot: I didn't find anything that would set CC -- do you know where that gcc-4.9 might come from? [13:24] pitti: I believe the gcc-4.9 comes from the kernel due to parsing /proc/version in lib/modules/fglrx/build_mod/make.sh [13:24] ah, so it tries to invoke the same compiler that the kernel was built with? [13:25] that would explain it indeed (and why it doesn't affect nvidia or other DKMS mods) [13:25] oh [13:28] pitti, TJ-: yes, the set_GCC_version function in make.sh http://paste.ubuntu.com/12055486/ [13:29] tseliot: ah, that's it; so we either need to patch that out (preferred), or add a gcc-4.9 dep? [13:31] pitti: yes, a patch would be easier [13:31] I mean "better" -> so that users don't end up with a second compiler just for this [13:32] hm, LP keeps timing out on me, I wanted to add that info to the bug [13:33] pitti: I agree, I don't want to hardcode the gcc-$ver dependency [13:35] sarnold, on bug 1455644, is it ACK to be approved *now* or did you want a release with the fixes you've discussed in wily first? [13:35] bug 1455644 in ippusbxd (Ubuntu) "[MIR] ippusbxd" [High,In progress] https://launchpad.net/bugs/1455644 [13:36] bdmurray, FYI team mapping update: ~ubuntu-printing has agreed to look after ippusbxd in main [13:36] doko, hi, maybe you are able to confirm this? this is running aptitude from wily-proposed -- http://people.ubuntu.com/~ricotz/ubuntu/aptitude-gcc5.png [13:40] Riddell: as per http://pad.ubuntu.com/gcc-5-transition there are several KDE libs that need to be renamed to v5 and rdepends rebuilt: okular, libkdegames, marble, okteta [13:41] Riddell: for coordination: do you plan to upload them anytime soon? is there a new upstream version for those for 5.13 which changes SONAME anyway? [13:41] Riddell: if not, want me to upload renames? [13:41] (and rebuilds) [13:41] doko: ^ (FYI) [13:42] pitti: we're onto it [13:43] Riddell: cool, thanks (FYI, just uploaded cantor, but that was just a no-change rebuild) [13:43] pitti: it's KDE Applications 15.07.90 (the third large release from KDE along with Frameworks and Plasma) [13:43] pitti: it'll take us a couple more days because it's got stuff ported to frameworks5/qt5 as well as the gcc transitions but I can start uploading stuff sooner [13:44] Riddell: that's ok, I just don't want to step on your feet, thus asking who's on what [13:44] pitti: along with doko we're still poking the frameworks and plasma packages to compiling happyness [13:44] these four don't block gcc-5 any more, just the konsole FTBFS [13:44] "undefined reference to `Konsole::HistoryScroll::hasScroll()'" [13:46] doko: oh, you didn't rename the openvdb libs? because no rdepends? [13:47] pitti: ok I'll look at the new version of konsole [13:47] pitti, no cxx11 symbols [13:48] ricotz, I don't use aptitude [13:51] doko, hmm, ok [14:18] pitti, doko, infinity, slangasek: notmuch is now FTBFS on ppc64le, how can I get a ppa that has ppc64le? I need to add one debug flag to the build to see what is going on. I created LP: #1483760 [14:18] Launchpad bug 1483760 in notmuch (Ubuntu) "notmuch FTBFS on PPC64LE" [Undecided,New] https://launchpad.net/bugs/1483760 [14:19] tdaitx: we have porter boxes (with incredibly brittle schroots) [14:19] tdaitx: porter-ppc64el.canonical.com [14:19] tdaitx: however, note that this isn't a blocker -- notmuch never built on ppc64el, so britney won't block it on that [14:20] right, anyway, those are the only failures, that test runs gdb, I bet it is related to it [14:23] pitti, err... what am I supposed to do with porter-ppc64el.canonical.com? is it offline? I can ping it, but there is no response for either http or ssh [14:23] tdaitx: hm, I can ssh to it; maybe you aren't on the company VPN? [14:24] indeed, vpn is down [15:03] pitti: hey, i have some systemd ignorance i'm hopng you can help with [15:03] when you have a minute [15:07] hey hallyn -- better just ask, mostly left for the day already [15:11] pitti: trying to write systemd jobs for libvirt. i've got the libvirt-bin one working, trying to write the one which would shut down vms cleanly before machined kills them at shutdown [15:11] but i've not been able to get it to run in time. [15:12] i'm trying to figure out what it is that does tha tkilling. is it machined.service? having my job run before or after that doesn't seem to work [15:13] debian uses a job from upstream that is supposed to suspend vms at shutdown adn restart them at startup, but that doesn't seem to be working either [15:14] well i guess let me take another stab at that one [15:14] pitti: it seems http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html hasn't updated for 10 hours [15:14] slangasek: right, just noticed 10 mins ago (sorry), I'm at it [15:20] slangasek: I went over the gcc-5 test regressions today and cleared out some things, pad updated [15:20] some test fixes, some FTBFS fixes etc. [15:20] britney should be back in the next run [15:27] hallyn: machined doesn't really cause any peer service to get shut down; I assume you are talking about libvirt on the host, not in the guest? [15:28] hallyn: shutting down will cause all services to get stopped; if they specify an ExecStop= then by running that, otherwise by TERM and eventually KILL [15:28] hallyn: and with Before=/After= you can influence the shutdown order (note that it has an inverse meaning on shutdown) [15:28] hallyn: e. g. After=network.target will ensure that a service gets stopped before anything which brings the network down, like stopping ifupdown, NM, or networkd [15:31] pitti: in one attempt, my service was WantedBy shutdown.target and Before=shutdown.target. but it didn't run until later [15:32] in another, it is simply wantedby=multi-level.target and after=libvirt-bin.service, with execstart=/bin/true and remainafterexit=true, [15:32] but then the execstop seems to run as soon as /bin/true exits [15:33] ideally th eformer would work, [15:33] i.e. like a 'stop scrip' in upstart [15:34] hallyn: with ExecStart=/bin/true it needs to be Type=oneshot, is it? [15:34] yes it is [15:36] pitti: here's the one i was really hping toulw work: http://paste.ubuntu.com/12056134/ [15:39] hallyn: looks good at first sight; so this is running too early or too late, or what goes wrong? [15:42] pitti: too late. lemme get that one installed again and show the log output, [15:50] pitti: http://paste.ubuntu.com/12056205/ and /var/log/libvirt/shutdownlog.log . [15:51] maybe if i add After=libvirt-bin... [15:52] hallyn: http://paste.ubuntu.com/12056205/ is very short, and doesn't contain "libvirt" at all -- wrong log? [15:54] pitti: http://paste.ubuntu.com/12056205/ is syslog output, from where i 'virsh start cdboot' until after some things have shutdown due to shutdown [15:54] the other is the /var/log/libvirt/shutdownlog which is written to by the script called at ExecStop [15:55] is there a way to get 'journalctl' to show me the last boot's journal? [15:55] * hallyn sees --list-boots [15:55] hallyn: yes -- enable persistant journal (/usr/share/doc/systemd/README.Debian [15:56] hallyn: then sudo journalctl -b -1 [15:56] sigh [15:56] how come that's not auto-enabled? :) [15:58] thanks, that's very helpful [15:58] hallyn: because we install rsyslog by default, and I don't want every log be written to disk twice [15:59] /var/log/syslog should also contain most things [15:59] pitti: http://paste.ubuntu.com/12056255/ full boot log showing the ordering [15:59] pitti: sadly no syslog misses a lot of systemd ordering info [16:02] * pitti really needs to run now, o/ [16:04] pitti: thanks \o [16:09] jibel, please could you have a look at the autopilot autopkg test failure? somehow urgent [16:09] doko, sure [16:14] I'm migrating some Ubuntu MATE application to python3 because I see that is an objective for 16.04. [16:14] Should I reference python3 in the shebang or just rely on the packaging to install the correct versions? [16:15] Just interested to know what others are doing in this regard. [16:15] The code will run on Python 2.6+ and Python3.3+ now. === matsubara_ is now known as matsubara [16:17] barry, ^^^ [16:24] doko, it's an unreliable test apparently and nothing to do with gcc. Can you force it? I'll ask veebers to fix it. [16:26] slangasek, ^^^ can't do this myself [16:26] doko: context? what test? [16:27] doko: if you can document it on the pad, that's the best way to track at the moment [16:27] (I guess autopilot-gtk) [16:31] slangasek, done [16:34] barry, https://launchpad.net/ubuntu/+source/pytables/3.1.1-3build2 [16:35] doko, slangasek filed a bug and added details to the pad. [17:04] doko: We're trying to get current APT git building on travis-ci.org again, for continuous integration. But it keeps failing with internal compiler errors in most cases, with both gcc 4.9 and 5.1 from https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test - idea? [17:04] dobey: travis-ci runs precise, BTW. [17:04] juliank, check wily-proposed, not interested in anything else [17:04]