[00:44] pitti: d'oh, i'm afraid i'm dropping bug 1543170 in your lap [00:44] bug 1543170 in lxc (Ubuntu) "lxc fails to install" [Critical,Triaged] https://launchpad.net/bugs/1543170 [00:45] seems liek a standing bug in invoke-rc.d called through debootstrap [00:45] maybe the bug really is that debootstrap isn't setting things up right, dunno [01:34] is there a relatively straightforward way for me to tell dh or dpkg-buildpackage that i don't want d/patches to be applied? [01:37] (guessing) mv debian/patches/series debian/patches/series.ignoremeplease ? [01:37] heh [01:37] yeah, so i can do that [01:38] but i'm trying to come up with a "clean" way to do a bootstrap (for php7 purposes) [01:38] when i did it in my ppa, i basically did exactly what you said for the first build [01:38] it's not clean to skip debian/patches when unpacking a package, when using dpkg format 3.0 (quilt). It's part of the definition of the unpack [01:38] so yeah, rm debian/patches/series (or mv) is better [01:39] slangasek: ok, so how do i capture that is only needed in, e.g., stage1? [01:39] nacc: I don't think you do [01:39] nacc: you can apply additional patches via debian/rules based on profile [01:39] or you can make the patch against the source "clean" so that it can be applied for both stage1 and normal build [01:40] slangasek: in this particular case, i basically don't want to patch in stage1 and want to patch othewrise [01:40] the patch in question introduces a build-dep [01:40] that is not otherwise there, and leads to a cycle [01:40] can you modify the patch to make the behaviour conditional? that's the usual answer [01:40] ^^ [01:41] nacc: heh, cyclical deps on php7 bringup.. they threw you right into the deep end, didn't they? :) [01:42] cjwatson: hrm, i'm not sure ... it is patching the source to autoload some classes from Symfony (whch in turn depends on the package being rebuilt). I wonder, though, since it is just a bootstrap -- i'm not intending for it to be 'functional' in stage1 [01:42] cjwatson: slangasek: is taht acceptable? that is, stage1 is purely a build artifact? [01:42] nacc: yes, stage1 packages should never be used for anything other than further bootstrapping [01:42] https://wiki.debian.org/BuildProfileSpec defines what's acceptable from stage1 [01:42] i'd need to go look at what build-deps on this, to make sure *it* can build :) [01:43] cjwatson: yep, i'm reading (and rereading) that :) [01:43] cjwatson: i don't think i can modify the patch in any sane way, that i can see yet :) [01:43] sarnold: heh, yep [01:44] it's pretty rare for it not to be possible to at least bodge the patch to let you switch it off with an environment variable or something [01:44] nacc, i thought build-profiles are exported as environment variables, and you can e.g. do somthing like ifeq (stage1,$BUILD_PROFILE_VARIABLE_NAME) and do like quilt pop -a =) [01:45] cjwatson: well, it's interpreted PHP code ... so not sure how far i want to go that route [01:45] xnox: they are; would i do that in an override_ section? that's what i was trying to figure out [01:52] cjwatson: hrm, maybe i can do what you're suggesting ... let me take a stab at it :) [02:02] cjwatson: one issue i see is that i'm adding an environmental check to every user of this code just so we can bootstrap it? [02:04] depends whether that's an intrusive thing [02:07] can dep8 tests download random junk from the internet? [02:08] mwhudson, yes, through a proxy [02:08] cool [02:08] mwhudson, https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038448.html [02:23] cjwatson: slangasek: xnox: sarnold: for now, i think just letting the patch apply but removing the b-d works. Will test it in the AM to be sure. Thanks for the help/suggestions! [02:54] xnox: I tried that first, this returns no results on xenial: $ apt-cache rdepends dh-acc [02:55] tedg, rdepends has nothing to do with build-dependencies. [02:55] $ reverse-depends -b dh-acc [02:55] Reverse-Build-Depends [02:55] ===================== [02:55] * muffin [02:56] xnox: Ah, sorry, yes. [02:56] * tedg grabs a muffin [04:40] xnox: Not sure if you're still up, but I don't see any abi dump for muffin. [04:40] xnox: I'm not sure it's actually checking against anything. [04:41] tedg, i believe lp:upstart and/or upstart package had abi dumps, which we did verify. [04:42] $ du -a upstart-1.13.2/lib/abi/ [04:42] 504 upstart-1.13.2/lib/abi/i686-linux-gnu/libupstart_1.0.0.abi [04:42] 508 upstart-1.13.2/lib/abi/i686-linux-gnu [04:42] 520 upstart-1.13.2/lib/abi/x86_64-linux-gnu/libupstart_1.0.0.abi [04:42] 524 upstart-1.13.2/lib/abi/x86_64-linux-gnu [04:42] 1036 upstart-1.13.2/lib/abi/ [04:42] but that's without dh_acc help [04:42] tedg, well, not tarballs, just flat files. [04:49] tedg: You're aware that Mir uses abi-compliance-checker in one of our release targets? [04:50] RAOF: Do you use dh_acc ? [04:50] No, we don't use that though. [04:50] We're the reason that abi-compliance-checker is in main, though. [04:51] So feel free to MIR dh_acc :) [04:52] RAOF, same source package. so MIR shouldn't be required, just binary promotion. [04:52] Heh, I thought this was going to be an easy way to move from symbols.... but eh, it's being more painful than I'd wanted. [04:52] xnox: Oooh, even easier. [04:52] tedg: Once you've got it all worked out, I'll happily steal it for Mir's packaging :) [04:53] tedg, both are interesting tools, and both do different stuff. [04:53] the are things one can catch with symbols vs acc. [04:53] What can you catch with symbols that you can't catch with acc? [04:53] Bah. Of course. Debian metadata! [04:54] The problem with symbols is that you need a GCC version specifc symbols file for anything C++, which isn't well supported and annoying. [04:54] versioned deps, alternative deps, etc. [04:54] tedg, use appropriate filters to mark them as optional. [04:54] xnox: Almost everything would be optional because the signature for string changed. [04:55] Isn't your actual problem that you're trying to provide a stable C++ ABI? :P [04:55] there are plenty of c++ kde packages that get g++ symbols rihgt [04:55] Basically removing the checking almost completely at that point. [04:55] xnox: But by using the pkg-kde symbolhelper. Not the regular one. [04:55] tedg, have you used demangled c++ names? where the demangled name is used throughout rather than a mangled one? [04:55] ScottK, hello =) how are you. [04:56] Hello. [04:56] tedg, yeah that pkg-kde symbolhelper is nice, for c++ heavy stuff. [04:56] xnox: Yes, the problem is how the containers changed in representing strings. [04:56] Not bad, just passing through. [04:56] tedg, wait, that's an ABI break no? there is no way around that, you will have different abi in dual landing. [04:56] Sadly I still have to land things on Vivid :-/ [04:56] tedg, and you _mus_ use different soname in vivid vs xenial. [04:56] xnox: Yes, but then I need both symbols files, which doesn't really work. [04:56] tedg, and you _must_ use different soname in vivid vs xenial. [04:57] tedg, you can do include directive to factor them out. [04:57] * tedg doesn't know what an include directive is [04:57] tedg, why do you say doesn't work? you should have e.g. libfoo1.symbols and libfoo1v5.symbols [04:58] and inside those you can do #include "packages.symbols.common" for common things [04:58] tedg, $ man dpkg-gensymbols [04:58] tedg, really read that, it has info on a lot of funky stuff one can do with symbols. [04:58] xnox: How does the symbols code know which to choose? [04:59] tedg, what do you mean which one to choose? [04:59] tedg, on vivid you should be generating libfoo1 binary package, on xenial libfoo1v5 binary package. [04:59] libfoo1.symbols vs libfoo1v5.symbols [04:59] which means, changing debian/control on the fly. or for example, simply skipping this or that binary package. [05:00] Uhg. Okay. How change debian/control on the fly? [05:00] sorry go to go. but ACC will not solve your problem with symbols at all, nor the fact that you are maintaining two ABIs for two SDKs [05:00] K, thanks xnox ! [05:01] * RAOF wonders what people would think about statically linking libstdc++ into libmirclient... [05:01] RAOF: As long as you wrap all the containers to "Mir::list" :-) [05:02] libmirclient exposes no C++ types. :P [05:02] RAOF, i hate you [05:02] =) [05:02] :P [05:02] * tedg hates types, rewrites everything in Python [05:03] * xnox alert resistance RAOF is charging the weapon [05:06] This is a real thing that might happen at one point, though, unless we have some fancier way to handle the phone-15.10-ABI-exists-forever preblem. [05:13] What I guess I don't understand, is what is the knob that knows what distro series a package is building for? [05:13] Not sure how to make a control file that understands/works with that. [05:15] debian/changelog, surely? [05:18] It has the information, but not sure how to build a control file from that. [05:18] Or, wait, doesn't control have to be read before rules? To determine build deps? [05:21] Uhg, shlibs is fine. [05:40] You could *technically* change the control file between the start of build and when the binary packages are being built. [05:40] So, early in debian/rules. [05:41] I think that people are likely to hit you with sticks if you try that. [05:41] Just maintain two separate packaging branches, one for vivid-overlay, one for xenial. [05:46] tedg: fwiw qemu ships a debian/control-in which is parsed into debian/control [05:46] allowing a single control-in to work for both edebian and ubuntu [05:46] there is a target in debian/rules to make control [06:40] Ah. I see the “something writes a malformed EFI entry, resulting in Ubuntu failing to appear” bug still exists, then. [07:01] Good morning [07:01] pitti: good morning (nice timing ;)! do you know of any recent changes to scalingstack firewall configs that would explain apport autopkgtest no longer being able to hit api.launchpad.net? [07:02] pitti, good morning =) [07:02] hallyn: that sounds very familiar, I fixed that yesterday [07:03] oh, seems slangasek beat me to duping it by 5 mins :) [07:03] hey xnox! [07:03] pitti: yes, and now I'm looking at the autopkgtest failures that are blocking init-system-helpers in -proposed [07:03] cf apport ;) [07:03] pitti: robru suggested pinging you about autopkgtest running page being suspiciously short, no silos mentioned and still eg there are a lot of "Test in progress" at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html since yesterday [07:03] slangasek: eek, they can't? no, I'm not aware of changes, but I do have to adjust the $no_proxy list every now and then [07:04] pitti: well, maybe I'm misunderstanding https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/apport/20160208_130843@/log.gz - on second glance, the first set of errors seem to be a gpg problem [07:05] cjwatson, i wonder if perl-modules really outght to be arch:any. The reason being, arch-skew is a pain. Especially on architectures that are faster than amd64 =) [07:05] (HOME=/root, but not writable by the test?) [07:05] slangasek: right, these got broken before though, apport has a hint [07:05] slangasek: (on my list to investigate) [07:05] cjwatson, but i guess it's only I that has that problem =) [07:05] pitti: haha, once again I failed to read down to the bottom [07:05] slangasek: it's held because of the linux and openssh regressions [07:06] see, I'm just going to annoy you so much by not reading to the bottom that you'll eventually have no choice but to fix it [07:06] http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ isn't very stable [07:06] slangasek: heh, indeed! this ween isn't a sprint week, so I'm slowly crawling through bug fixes and backlog like this [07:06] meh, ppc64el machines are *still* unhappy [07:07] * pitti follows up to the RT again [07:07] pitti: ok, and I'm confident in saying that init-system-helpers didn't regress openssh's checksum testsuite to regress on armhf [07:08] right [07:08] I just hinted i-s-h, it's quite urgent [07:08] pitti: thanks! [07:08] and retried openssh/armhf [07:14] pitti, doko - findutils migrated which breaks python3.4. python3.4 is stuck in -proposed, because of amd64 build-failure. [07:14] oh, I got python3.4 removed on dist-upgrade yesterday [07:14] I thought that was by intent [07:14] (doko was working on removing 3.4) [07:14] either all of those modules should not be arch:all, or we need to fix python3.4. [07:14] pitti, sure, but at the moment debootstrap now fails in xenial-release. [07:15] because findutils breaks python3.4 in release. [07:15] * xnox has no idea why/how it migrated like that. [07:15] * xnox ponders to upload findutils with the breaks removed for now. [07:15] https://launchpadlibrarian.net/237057251/buildlog_ubuntu_xenial_s390x_s390x_cpc_BUILDING.txt.gz [07:17] actually, i'm not sure how/where/why python3.4 is pulled in. [07:18] doko, gave back python3.4:amd64 xenial-proposed [07:43] Mirv: bumped those [07:57] do we have some busted buildds? [07:57] https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz [07:57] W: The repository 'file:/«BUILDDIR»/resolver-Oah2dz/apt_archive ./ Release' is not signed. [08:02] good morning [08:12] didrocks, that's normal. [08:13] xnox: not sure I feel reassured :) [08:13] didrocks, i believe sbuild now generates a brand new archive in a temporary location, to call $ apt-get build-dep $src_pkg [08:13] didrocks, instead of trying to parse the build-deps in the .dsc by itself. [08:14] didrocks, in theory, recent enough apt should have gained capability to do $ apt-get build-dep $src_pkg.dsc without these extra archive thing. [08:14] xnox: yeah, (I guess I meant apt build-dep ;)) [08:14] didrocks, note it's the 'file:/«BUILDDIR»/resolver-Ls0sgY/apt_archive' which is unsigned, a temp directory, inside the build-directory, inside the brand new chroot. [08:14] ok, didn't know that changed :) [08:15] didrocks, but like version constraints, alternative deps are all resolved correctly like this, ditto multi-arch, build-profiles and a bunch of other stuff. [08:15] ok, good to know! :) [08:16] which comes to my next question (I guess it's for doko): any hint on python3-argcomplete now being installable in xenial? :p [08:16] didn't see any upload, nothing [08:21] xnox: do you have a chdist handy? The one on snakefruit doesn't seem to want to get up to date [08:21] didrocks, i do, what's up? [08:21] argcomplete thing? [08:21] xnox: do you mind trying to install python3-argcomplete (as the logs above mention, it doesn't want to in -proposed) [08:22] yep ;) [08:47] xnox: any lead or should I setup my own chdist? [08:50] didrocks, let me find that terminal [08:51] hidden in a jungle of others! :) [08:51] didrocks, it's installable in -proposed. [08:51] but without findutils. [08:52] didrocks, soon python3.4 will be fully removed, and then things will get better. [08:56] Mirv: valid candidate now [08:57] slangasek: I get the regressions locally as well, so not a firewall issue [08:58] slangasek: ooh -- that's bug 1541925 again [08:58] bug 1541925 in gnupg (Ubuntu) "Tries to create temp files under ~/.gnupg but doesn't create the dir" [High,New] https://launchpad.net/bugs/1541925 [08:59] pitti, python-numpy -> numexpr adt test looks strange, as it's using "old" numexpr unlike all other arches. Can it be triggered/hinted to test both numpy & numexpr from -proposed on s390x? or e.g. hinted over [08:59] xnox: hum, what is your definition of "soon", not sure how to unblock ubuntu-make today :) [08:59] didrocks, remove python3.4 from the archive =) [08:59] didrocks, or make the python3.4/amd64 build and pass test-suite. [08:59] xnox: I guess doko is on it, right? ;) [08:59] didrocks, what do you mean "unblock" ubuntu-make? if it's in a ppa, enable building with -proposed. [09:00] xnox: no, it's in xenial [09:00] and on !amd64 =) [09:00] ah [09:00] =( [09:00] and blocked in proposed due to this FTBFS [09:00] xnox: I retried it for now, so it should run against the new version; if that still doesn't help, I'll have a closer look and hint [09:00] pitti, thanks. [09:00] xnox: err .. look at the queues on http://autopkgtest.ubuntu.com/running.shtml [09:00] that will take a while [09:01] pitti, from same numpy triggers, python-pywcs is werid it says regressions yet no test exist in that package [09:01] the Perl did it again [09:01] pitti, is that something you have to manually remove? [09:01] so, basically a lot of packages are going to FTBFS due to this half-transition/removal I guess? [09:01] didrocks, well. it's an arch skew, yes. [09:01] xnox: right, I consider exit code 8 "no tests in this package" as regression, as usually it's not intended to remove htem [09:02] so I at least want to have a look and make sure it's intended [09:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst [09:02] pitti, but it looks like it's getting reverted to a older version. [09:02] xnox: ah no, it seems they were added only in -proposed, so running against the released version doesn't work [09:02] =/ [09:02] quite. [09:04] xnox: requeued with running both from -proposed [09:04] * pitti expects having to shortcut perl a bit [09:07] blimey [09:08] pitti, we need more builders =) [09:30] pitti, i'm failing to run components-missmatch report locally. Are there magic options that one should pass to it? [09:31] cause at the moment, it tries to like demote dash for me, which should remain in required =/ [09:31] what options are used to run the official report for e.g. xenial-release? [09:38] Hello again. I posted a question regarding unity-settings-daemon in combination with VirtualBox guests on Launchpad - https://answers.launchpad.net/unity-settings-daemon/+question/284461 - and was wondering whether anyone could comment. I might mention that sometimes resizing blocks altogether. [09:39] xnox: looking at snakefruit's bin/archive-reports, I don't see anything fancy really [09:39] component-mismatches -e touch \ [09:39] -d "$OUT/$name.dot" -o "$OUT/$name.txt.new" \ [09:39] --html-output-file "$OUT/$name.html" \ [09:39] --csv-file "$OUT/$name.csv" \ [09:39] component-mismatches [09:40] horum. [09:40] although the latter argument doesn't seem to belong to the c-m call itself [09:40] * pitti tries to interpret what [09:40] background pids component_mismatches component-mismatches [09:40] means [09:41] pitti, is that bin/archive-reports at all available for mere mortals to view? e.g. in ubuntu-archive-tools repository? [09:41] pitti, i was expecting to see included/excluded seeds. [09:41] xnox: http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/changes [09:41] maybe my output is incomplete for components-mismatches to process. [09:42] i. e. http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/view/head:/archive-reports [09:42] xnox: although there's an uncommitted delta there: http://paste.ubuntu.com/15000949/ [09:42] (not sure who added this) [09:42] so maybe the "-e touch" does something magic [09:43] but if anything, including touch should want *more* packages in main [09:46] pitti: what's up with snakefruit? [09:46] oh, component-mismatches arguments [09:46] cjwatson: xnox wondered how we call c-m ... that [09:47] cjwatson, well i ran components mismatches locally against https://code.launchpad.net/~xnox/germinate/+git/germinate output and it decided to demote dash to universe. [09:47] i don't think that would fly =) [09:48] it expects a mirror of dists/ in ~/mirror/ubuntu/ [09:48] and you might need to pass --germinate-path [09:49] also it expects germinate output in the format emitted by stuff in lp:ubuntu-archive-publishing because reasons ... it might be easiest to lay things out somewhat by hand [09:50] though running generate-extra-overrides from there probably shouldn't be ridiculously impossible [09:50] (it uses the germinate Python modules, so set PYTHONPATH appropriately if you want to run against your own versions from a working tree) [09:52] I still need to stare at your germinate MP at some point :) [10:03] i've spend this morning starring at mounting loop4p1 and then installing bootloader on to loop0 and not seeing what the problem was =) [10:04] cjwatson, yeah, starring at that mp might be useful. or e.g. diffing / starring at the produced outputs too http://people.canonical.com/~xnox/germinate-output/ [10:04] i'll ask steve to figure out components-missmatches. as i have customer work to do =) [10:16] Once more - any one here knowledgeable about how unity-settings-daemon works, and specifically the RandR code? If not, who might know? [10:16] pitti: nice! too bad the Train still thinks the silo has failed automated signoff. [10:17] michael-vb, try #ubuntu-desktop? desktopy developers are there. [10:17] michael-vb, #ubuntu-desktop is better placed for unity-settings-daemon questions but no we don't have anyone familiar with the randr code afaik, that part come from gnome-settings-daemon and wasn't change by us [10:17] Oh dear, that was what I was afraid of. [10:18] what's your issue? [10:18] michael-vb, i only work on things from "nothing installed" to "reaching multi-user.target" =) [10:18] (10:38:01) michael-vb: Hello again. I posted a question regarding unity-settings-daemon in combination with VirtualBox guests on Launchpad - https://answers.launchpad.net/unity-settings-daemon/+question/284461 - and was wondering whether anyone could comment. I might mention that sometimes resizing blocks altogether. [10:18] * xnox guesses seb128 has a highlight on "ubuntu-desktop" keyword. [10:18] It was an issue back in the days when it was still gnome-settings-daemon too, but I never found time to properly look into it. [10:19] I suspect that back then someone got it working "well enough" but a VM places more strain on it. [10:19] I am rather afraid to start trying to contribute code, as last time I tried I spend more time on the bureaucracy than the code. [10:20] michael-vb, don't use VirtualBox =) install ubuntu for real? =) [10:20] Rather hard, given my current job. [10:21] That said, I run Ubuntu on my host system too. [10:23] michael-vb, it's worth a bug report (we might already have one) but would need debugging by somebody having the issue... [10:23] I am happy to debug, and obviously I can read and write code. [10:25] But I was hoping we could somehow work around the issue. My experience of getting things fixed in Ubuntu is not great. Not wanting to complain, just to live with the facts. [10:25] yeah, there are more things to work on that we have people/hours in the week [10:25] Don't worry, I know all about that. [10:26] is that buggy monitors.xml recreated if you delete it? [10:26] (https://www.virtualbox.org/report/1) [10:26] It hasn't been re-created since I deleted it last. But of course I would take time to observe what happens. [10:27] And things have been working since then too in my test guest system I must say. [10:28] I dare say that when I find what triggers it that may also give me an idea for a work-around. [10:29] Then I take it I don't need to switch over to #ubuntu-desktop, but rather observe and open a bug report when I can report something sensible? I think in the first place I have moved on a bit. [10:30] michael-vb, best is to open a bug against unity-settings-daemon and maybe come ask about it again on #ubuntu-desktop after feature freeze [10:30] I doubt we are going to have slots for that sort of debugging this week [10:31] Oh, is it feature freeze time? Perhaps I should be updating to 16.04... [10:32] next week it is [10:32] I personally usually start off debugging that sort of thing by making the bug reporter work as much as possible. It also gives me an idea of how seriously to take it. [10:33] But I wouldn't have expected a debugging slot in the week anyway. [10:34] I will get back to then. Hope the feature freeze goes well. [10:34] (get back to you) [10:34] Thanks all. [10:37] cjwatson, parted patch is kosher, and it was filed as a bug report in debian. [10:37] I noticed, on my queue, thanks. [11:12] ginggs: hey! [11:13] ginggs: I saw you did a no-change rebuild for cmake for the libjsoncpp sync-transition that happened - are you working on the transition in overall, or can I proceed with all the other uploads? [11:13] ginggs: don't want to step on your toes [11:16] ginggs: ...I'll go ahead with a few projects if you don't mind [11:17] Since this libjsoncpp transition is blocking us a bit [11:17] Obscure shell -> is there any reason, why this thing doesn't do "for bridge in $br_list" instead of <<< ? http://paste.ubuntu.com/15001260/ [11:18] pitti, cjwatson ^ [11:18] * xnox is lost, i see bashism. [11:18] full thing http://paste.ubuntu.com/15001267/ [11:18] xnox: what are these ':'? [11:19] oh, IFS [11:19] pitti, quality IBM code =) [11:19] xnox: and what is <<< ? [11:19] is that some shorthand for echo 'string' | ? [11:20] i. e. constructing stdin from a string? [11:20] pitti, <<< is bash HEREDOC or some such, it's liek < right, that's bash [11:20] pitti, but, imho, there is no reason to do this crazy "while read" and <<<$br_list, when one can do: for bridge in $br_list; do [11:21] i. e. two nested loops, one over the bridges, one over the three commands [11:22] or just expand out the latter, it's just three after all (same number of lines as a for loop) [11:26] hi sil2100, please go ahead, i've been meaning to find out how to set up a transition tracker in ubuntu [11:26] debian's is here: https://release.debian.org/transitions/html/auto-libjsoncpp.html [11:26] ginggs: yeah, that would be useful, but in the case of libjsoncpp at least there's not too many reverse-deps [11:38] jdstrand: ping, hey this came up a few weeks ago: https://bugs.launchpad.net/ubuntu-sdk-ide/+bug/1520551 could we give the debug policy the ability to handle that correctly? [11:38] Launchpad bug 1520551 in Ubuntu SDK IDE "Profiling from Ubuntu SDK IDE is working only if "networking", policy group is enabled in apparmor" [Undecided,New] [12:01] doko: hey! any idea on the python issue in -proposed we discussed above? (I saw you talked on ubuntu-desktop so, I guess you are around? :)) [12:01] python3-argparse can't be installed with findutils [12:02] didrocks: pointer? [12:02] doko: https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz for instance [12:02] and as xnox said: [12:02] 09:51:15 xnox | didrocks, it's installable in -proposed. [12:02] 09:51:26 xnox | but without findutils. [12:04] doko, it would help a lot for https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2 to migrate, because findutils which breaks python3.4 is in release, thus python3.4 is not installable in release pocket anymore. [12:04] doko, given that python3.4 is on the way out, could you upload something that e.g. skips the testsuite on amd64? such that it migrates? [12:05] doko, or e.g. shall we upload a findutils without breaks for a little while? [12:05] (breaks on the python3.4 package) [12:06] meh, looking [12:22] jtaylor, tumbleweed: what's the way to go forward with numpy? 1.11 beta doesn't look promising either ... === vrruiz_ is now known as rvr [12:44] what is the distutils numpy autopkg test supposed to test? [12:47] fails in -release too [12:48] doko: thanks for the fix. I'll do a give back once it's published in proposed [12:52] doko: whats the failure? [12:59] jtaylor, the distutils test emits a user warning on stderr. now allowing stderr for this test [13:01] what is it printing? [13:01] there's actual failures [13:01] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-numpy/20160207_105740@/log.gz [13:02] ah its still 1.10 [13:02] thats the issue I told you about a while ago [13:02] + patch for it [13:02] hmm, can't remember [13:03] should be fixed in 1.11 I think [13:03] yep, but that one is introducing more failures in autopkg tests [13:04] in others I guess? [13:05] see ole's report for debian [13:43] doko: is llvm-3.8 ready to replace 3.6 in main or do you prefer to wait for next rc or final? pondering where to push new mesa.. [13:43] tjaalton, please check with 3.8 [13:44] check? [13:44] I can push it to a ppa first [13:44] at least mesa builds with it === marcusto_ is now known as marcustomlinson === tinoco is now known as inaddy [14:10] neither current desktop live system, nor ubiquity-only are currently booting in QEMU for me -- is that only me? [14:12] pitti: which are you saying is current? [14:12] http://cdimage.ubuntu.com/cdimage/daily-live/ says it's from today, yes [14:13] pitti: give me 5 I'll see if I can confirm for you [14:13] pitti: see #ubuntu-release [14:13] apparently a missing video driver package [14:14] ah, thanks! [14:16] finally ... headless desktop images ! [14:18] ogra_: careful it'll overtake snappy if you are not careful :P [14:18] haha [14:22] pitti, see #ubuntu-desktop backlog [14:22] seb128: thanks [14:23] it's a bit annoying that images manage to move to "current" despite having no xorg working [14:23] "images to have passed any automatic testing" [14:23] rrright ;-) === barry` is now known as barry_ === barry_ is now known as barry [14:43] seb128, pitti: hey! I'm updating the xenial ubuntu-touch-meta packages as per the libjsoncpp transition - but it seems the ./update script doesn't use -proposed (it removes libjsoncpp0v5 but doesn't add libjsoncpp1) - is it ok for me to modify the seeds manually in the metapackage in this case? [14:43] I need to modify the seeds as part of the transition itself [14:44] sil2100, don't know, I'm not the right person to ask about that [14:46] I think that's reasonable if it's a necessary part of the transition. [14:47] cjwatson: thanks :) [14:47] This is an unfortunate consequence of the touch seeds hardcoding particular ABIs. [15:07] I'm trying to test Xenial 64 Bit in a VirtualBox (version 4.3.6) environment, but the installer crashes on the "piix4_smbus error" as described at: http://askubuntu.com/questions/298290/smbus-bios-error-while-booting-ubuntu-in-virtualbox [15:08] The install crashes before I can get access to a proper terminal, so I'm unable to try the workarounds described there [15:12] robru: ah! I finally found some time to investigate bug 1537866 again, and now I understand what's going on [15:12] bug 1537866 in britney "Britney flops back and forth between Running and Approved a lot" [High,In progress] https://launchpad.net/bugs/1537866 [15:15] leave Britney alone [15:16] no way, she's working around the clock for us! [15:17] :( [15:30] ah, someone just published the d-i SRU for bug 1537136 [15:30] bug 1537136 in systemd (Ubuntu Trusty) "ISST-LTE: no network after install due to interface order change" [High,Fix committed] https://launchpad.net/bugs/1537136 [15:30] but not systemd (where the chagne actually comes from)? [15:36] pitti, people request package testing overrides in #ubuntu-release =) but you don't seem to be there at =) [15:36] all [15:36] * dholbach hugs seb128 [15:37] * seb128 hugs dholbach back [15:37] pitti, <apw> initramfs-tools is blocked for a test failure in linux (ppc64el). this issue is a known intermittent failure which is kernel not initramfs-tools related [15:37] <apw> i have asked for it to retry but the queue is really long, and the two fixes in this are blocking image generation and [15:37] <apw> is preventing maas images from workgin, which is bleeding through to testing, preventing testing for the kernel [15:37] <apw> i am therefore requesting we hint that test for initramfs-tools [15:37] =) [15:37] darkxst, I think you forgot to pilot out? [15:37] * xnox wants kernel released too, to get d-i released, with bundled udebs with client fixes =) [15:38] xnox: well, there's plenty of people who can add that override :) [15:38] xnox: anyway, adding [15:38] xnox: I can't influence the kernel, that gets controlled by the kernel team itself [15:38] xnox, the kernel hasn't been tested on baremetal in large part for the maas issues this initramgs-tools is attempting to fix [15:38] pitti, but you are like the best and the most responsive =) [15:39] hint added [15:39]