[00:44] <hallyn> pitti: d'oh, i'm afraid i'm dropping bug 1543170 in your lap
[00:45] <hallyn> seems liek a standing bug in invoke-rc.d called through debootstrap
[00:45] <hallyn> maybe the bug really is that debootstrap isn't setting things up right, dunno
[01:34] <nacc> 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] <sarnold> (guessing) mv debian/patches/series debian/patches/series.ignoremeplease   ?
[01:37] <nacc> heh
[01:37] <nacc> yeah, so i can do that
[01:38] <nacc> but i'm trying to come up with a "clean" way to do a bootstrap (for php7 purposes)
[01:38] <nacc> when i did it in my ppa, i basically did exactly what you said for the first build
[01:38] <slangasek> 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] <slangasek> so yeah, rm debian/patches/series (or mv) is better
[01:39] <nacc> slangasek: ok, so how do i capture that is only needed in, e.g., stage1?
[01:39] <slangasek> nacc: I don't think you do
[01:39] <slangasek> nacc: you can apply additional patches via debian/rules based on profile
[01:39] <slangasek> or you can make the patch against the source "clean" so that it can be applied for both stage1 and normal build
[01:40] <nacc> slangasek: in this particular case, i basically don't want to patch in stage1 and want to patch othewrise
[01:40] <nacc> the patch in question introduces a build-dep
[01:40] <nacc> that is not otherwise there, and leads to a cycle
[01:40] <cjwatson> can you modify the patch to make the behaviour conditional?  that's the usual answer
[01:40] <slangasek> ^^
[01:41] <sarnold> nacc: heh, cyclical deps on php7 bringup.. they threw you right into the deep end, didn't they? :)
[01:42] <nacc> 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] <nacc> cjwatson: slangasek: is taht acceptable? that is, stage1 is purely a build artifact?
[01:42] <slangasek> nacc: yes, stage1 packages should never be used for anything other than further bootstrapping
[01:42] <cjwatson> https://wiki.debian.org/BuildProfileSpec defines what's acceptable from stage1
[01:42] <nacc> i'd need to go look at what build-deps on this, to make sure *it* can build :)
[01:43] <nacc> cjwatson: yep, i'm reading (and rereading) that :)
[01:43] <nacc> cjwatson: i don't think i can modify the patch in any sane way, that i can see yet :)
[01:43] <nacc> sarnold: heh, yep
[01:44] <cjwatson> 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] <xnox> 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] <nacc> cjwatson: well, it's interpreted PHP code ... so not sure how far i want to go that route
[01:45] <nacc> xnox: they are; would i do that in an override_ section? that's what i was trying to figure out
[01:52] <nacc> cjwatson: hrm, maybe i can do what you're suggesting ... let me take a stab at it :)
[02:02] <nacc> 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] <cjwatson> depends whether that's an intrusive thing
[02:07] <mwhudson> can dep8 tests download random junk from the internet?
[02:08] <xnox> mwhudson, yes, through a proxy
[02:08] <mwhudson> cool
[02:08] <xnox> mwhudson, https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038448.html
[02:23] <nacc> 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] <tedg> xnox: I tried that first, this returns no results on xenial: $ apt-cache rdepends dh-acc
[02:55] <xnox> tedg, rdepends has nothing to do with build-dependencies.
[02:55] <xnox> $ reverse-depends -b dh-acc
[02:55] <xnox> Reverse-Build-Depends
[02:55] <xnox> [02:55] <xnox> * muffin
[02:56] <tedg> xnox: Ah, sorry, yes.
[02:56]  * tedg grabs a muffin
[04:40] <tedg> xnox: Not sure if you're still up, but I don't see any abi dump for muffin.
[04:40] <tedg> xnox: I'm not sure it's actually checking against anything.
[04:41] <xnox> tedg, i believe lp:upstart and/or upstart package had abi dumps, which we did verify.
[04:42] <xnox> $ du -a upstart-1.13.2/lib/abi/
[04:42] <xnox> 504	upstart-1.13.2/lib/abi/i686-linux-gnu/libupstart_1.0.0.abi
[04:42] <xnox> 508	upstart-1.13.2/lib/abi/i686-linux-gnu
[04:42] <xnox> 520	upstart-1.13.2/lib/abi/x86_64-linux-gnu/libupstart_1.0.0.abi
[04:42] <xnox> 524	upstart-1.13.2/lib/abi/x86_64-linux-gnu
[04:42] <xnox> 1036	upstart-1.13.2/lib/abi/
[04:42] <xnox> but that's without dh_acc help
[04:42] <xnox> tedg, well, not tarballs, just flat files.
[04:49] <RAOF> tedg: You're aware that Mir uses abi-compliance-checker in one of our release targets?
[04:50] <tedg> RAOF: Do you use dh_acc ?
[04:50] <RAOF> No, we don't use that though.
[04:50] <RAOF> We're the reason that abi-compliance-checker is in main, though.
[04:51] <RAOF> So feel free to MIR dh_acc :)
[04:52] <xnox> RAOF, same source package. so MIR shouldn't be required, just binary promotion.
[04:52] <tedg> 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] <RAOF> xnox: Oooh, even easier.
[04:52] <RAOF> tedg: Once you've got it all worked out, I'll happily steal it for Mir's packaging :)
[04:53] <xnox> tedg, both are interesting tools, and both do different stuff.
[04:53] <xnox> the are things one can catch with symbols vs acc.
[04:53] <RAOF> What can you catch with symbols that you can't catch with acc?
[04:53] <RAOF> Bah. Of course. Debian metadata!
[04:54] <tedg> 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] <xnox> versioned deps, alternative deps, etc.
[04:54] <xnox> tedg, use appropriate filters to mark them as optional.
[04:54] <tedg> xnox: Almost everything would be optional because the signature for string changed.
[04:55] <RAOF> Isn't your actual problem that you're trying to provide a stable C++ ABI? :P
[04:55] <xnox> there are plenty of c++ kde packages that get g++ symbols rihgt
[04:55] <tedg> Basically removing the checking almost completely at that point.
[04:55] <ScottK> xnox: But by using the pkg-kde symbolhelper.  Not the regular one.
[04:55] <xnox> tedg, have you used demangled c++ names? where the demangled name is used throughout rather than a mangled one?
[04:55] <xnox> ScottK, hello =) how are you.
[04:56] <ScottK> Hello.
[04:56] <xnox> tedg, yeah that pkg-kde symbolhelper is nice, for c++ heavy stuff.
[04:56] <tedg> xnox: Yes, the problem is how the containers changed in representing strings.
[04:56] <ScottK> Not bad, just passing through.
[04:56] <xnox> tedg, wait, that's an ABI break no? there is no way around that, you will have different abi in dual landing.
[04:56] <tedg> Sadly I still have to land things on Vivid :-/
[04:56] <xnox> tedg, and you _mus_ use different soname in vivid vs xenial.
[04:56] <tedg> xnox: Yes, but then I need both symbols files, which doesn't really work.
[04:56] <xnox> tedg, and you _must_ use different soname in vivid vs xenial.
[04:57] <xnox> tedg, you can do include directive to factor them out.
[04:57]  * tedg doesn't know what an include directive is
[04:57] <xnox> tedg, why do you say doesn't work? you should have e.g. libfoo1.symbols and libfoo1v5.symbols
[04:58] <xnox> and inside those you can do #include "packages.symbols.common" for common things
[04:58] <xnox> tedg, $ man dpkg-gensymbols
[04:58] <xnox> tedg, really read that, it has info on a lot of funky stuff one can do with symbols.
[04:58] <tedg> xnox: How does the symbols code know which to choose?
[04:59] <xnox> tedg, what do you mean which one to choose?
[04:59] <xnox> tedg, on vivid you should be generating libfoo1 binary package, on xenial libfoo1v5 binary package.
[04:59] <tedg> libfoo1.symbols vs libfoo1v5.symbols
[04:59] <xnox> which means, changing debian/control on the fly. or for example, simply skipping this or that binary package.
[05:00] <tedg> Uhg. Okay. How change debian/control on the fly?
[05:00] <xnox> 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] <tedg> K, thanks xnox !
[05:01]  * RAOF wonders what people would think about statically linking libstdc++ into libmirclient...
[05:01] <tedg> RAOF: As long as you wrap all the containers to "Mir::list" :-)
[05:02] <RAOF> libmirclient exposes no C++ types. :P
[05:02] <xnox> RAOF, i hate you
[05:02] <xnox> =)
[05:02] <RAOF> :P
[05:02]  * tedg hates types, rewrites everything in Python
[05:03]  * xnox alert resistance RAOF is charging the weapon
[05:06] <RAOF> 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] <tedg> What I guess I don't understand, is what is the knob that knows what distro series a package is building for?
[05:13] <tedg> Not sure how to make a control file that understands/works with that.
[05:15] <RAOF> debian/changelog, surely?
[05:18] <tedg> It has the information, but not sure how to build a control file from that.
[05:18] <tedg> Or, wait, doesn't control have to be read before rules? To determine build deps?
[05:21] <tedg> Uhg, shlibs is fine.
[05:40] <RAOF> You could *technically* change the control file between the start of build and when the binary packages are being built.
[05:40] <RAOF> So, early in debian/rules.
[05:41] <RAOF> I think that people are likely to hit you with sticks if you try that.
[05:41] <RAOF> Just maintain two separate packaging branches, one for vivid-overlay, one for xenial.
[05:46] <hallyn> tedg: fwiw qemu ships a debian/control-in which is parsed into debian/control
[05:46] <hallyn> allowing a single control-in to work for both edebian and ubuntu
[05:46] <hallyn> there is a target in debian/rules to make control
[06:40] <RAOF> Ah. I see the “something writes a malformed EFI entry, resulting in Ubuntu failing to appear” bug still exists, then.
[07:01] <pitti> Good morning
[07:01] <slangasek> 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] <xnox> pitti, good morning =)
[07:02] <pitti> hallyn: that sounds very familiar, I fixed that yesterday
[07:03] <pitti> oh, seems slangasek beat me to duping it by 5 mins :)
[07:03] <pitti> hey xnox!
[07:03] <slangasek> pitti: yes, and now I'm looking at the autopkgtest failures that are blocking init-system-helpers in -proposed
[07:03] <slangasek> cf apport ;)
[07:03] <Mirv> 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] <pitti> 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] <slangasek> 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] <xnox> 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] <slangasek> (HOME=/root, but not writable by the test?)
[07:05] <pitti> slangasek: right, these got broken before though, apport has a hint
[07:05] <pitti> slangasek: (on my list to investigate)
[07:05] <xnox> cjwatson, but i guess it's only I that has that problem =)
[07:05] <slangasek> pitti: haha, once again I failed to read down to the bottom
[07:05] <pitti> slangasek: it's held because of the linux and openssh regressions
[07:06] <slangasek> 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] <pitti> http://autopkgtest.ubuntu.com/packages/l/linux/xenial/ppc64el/ isn't very stable
[07:06] <pitti> slangasek: heh, indeed! this ween isn't a sprint week, so I'm slowly crawling through bug fixes and backlog like this
[07:06] <pitti> meh, ppc64el machines are *still* unhappy
[07:07]  * pitti follows up to the RT again
[07:07] <slangasek> 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] <pitti> right
[07:08] <pitti> I just hinted i-s-h, it's quite urgent
[07:08] <slangasek> pitti: thanks!
[07:08] <pitti> and retried openssh/armhf
[07:14] <xnox> pitti, doko - findutils migrated which breaks python3.4. python3.4 is stuck in -proposed, because of amd64 build-failure.
[07:14] <pitti> oh, I got python3.4 removed on dist-upgrade yesterday
[07:14] <pitti> I thought that was by intent
[07:14] <pitti> (doko was working on removing 3.4)
[07:14] <xnox> either all of those modules should not be arch:all, or we need to fix python3.4.
[07:14] <xnox> pitti, sure, but at the moment debootstrap now fails in xenial-release.
[07:15] <xnox> 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] <xnox> https://launchpadlibrarian.net/237057251/buildlog_ubuntu_xenial_s390x_s390x_cpc_BUILDING.txt.gz
[07:17] <xnox> actually, i'm not sure how/where/why python3.4 is pulled in.
[07:18] <xnox> doko, gave back python3.4:amd64 xenial-proposed
[07:43] <pitti> Mirv: bumped those
[07:57] <didrocks> do we have some busted buildds?
[07:57] <didrocks> https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz
[07:57] <didrocks> W: The repository 'file:/«BUILDDIR»/resolver-Oah2dz/apt_archive ./ Release' is not signed.
[08:02] <dholbach> good morning
[08:12] <xnox> didrocks, that's normal.
[08:13] <didrocks> xnox: not sure I feel reassured :)
[08:13] <xnox> didrocks, i believe sbuild now generates a brand new archive in a temporary location, to call $ apt-get build-dep $src_pkg
[08:13] <xnox> didrocks, instead of trying to parse the build-deps in the .dsc by itself.
[08:14] <xnox> 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] <didrocks> xnox: yeah, (I guess I meant apt build-dep ;))
[08:14] <xnox> 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] <didrocks> ok, didn't know that changed :)
[08:15] <xnox> 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] <didrocks> ok, good to know! :)
[08:16] <didrocks> 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] <didrocks> didn't see any upload, nothing
[08:21] <didrocks> xnox: do you have a chdist handy? The one on snakefruit doesn't seem to want to get up to date
[08:21] <xnox> didrocks, i do, what's up?
[08:21] <xnox> argcomplete thing?
[08:21] <didrocks> xnox: do you mind trying to install python3-argcomplete (as the logs above mention, it doesn't want to in -proposed)
[08:22] <didrocks> yep ;)
[08:47] <didrocks> xnox: any lead or should I setup my own chdist?
[08:50] <xnox> didrocks, let me find that terminal
[08:51] <didrocks> hidden in a jungle of others! :)
[08:51] <xnox> didrocks, it's installable in -proposed.
[08:51] <xnox> but without findutils.
[08:52] <xnox> didrocks, soon python3.4 will be fully removed, and then things will get better.
[08:56] <pitti> Mirv: valid candidate  now
[08:57] <pitti> slangasek: I get the regressions locally as well, so not a firewall issue
[08:58] <pitti> slangasek: ooh -- that's bug 1541925 again
[08:59] <xnox> 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] <didrocks> xnox: hum, what is your definition of "soon", not sure how to unblock ubuntu-make today :)
[08:59] <xnox> didrocks, remove python3.4 from the archive =)
[08:59] <xnox> didrocks, or make the python3.4/amd64 build and pass test-suite.
[08:59] <didrocks> xnox: I guess doko is on it, right? ;)
[08:59] <xnox> didrocks, what do you mean "unblock" ubuntu-make? if it's in a ppa, enable building with -proposed.
[09:00] <didrocks> xnox: no, it's in xenial
[09:00] <xnox> and on !amd64 =)
[09:00] <xnox> ah
[09:00] <xnox> =(
[09:00] <didrocks> and blocked in proposed due to this FTBFS
[09:00] <pitti> 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] <xnox> pitti, thanks.
[09:00] <pitti> xnox: err .. look at the queues on http://autopkgtest.ubuntu.com/running.shtml
[09:00] <pitti> that will take a while
[09:01] <xnox> pitti, from same numpy triggers, python-pywcs is werid it says regressions yet no test exist in that package
[09:01] <pitti> the Perl did it again
[09:01] <xnox> pitti, is that something you have to manually remove?
[09:01] <didrocks> so, basically a lot of packages are going to FTBFS due to this half-transition/removal I guess?
[09:01] <xnox> didrocks, well. it's an arch skew, yes.
[09:01] <pitti> 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] <pitti> so I at least want to have a look and make sure it's intended
[09:02] <seb128> @pilot out
[09:02] <xnox> pitti, but it looks like it's getting reverted to a older version.
[09:02] <pitti> xnox: ah no, it seems they were added only in -proposed, so running against the released version doesn't work
[09:02] <xnox> =/
[09:02] <xnox> quite.
[09:04] <pitti> xnox: requeued with running both from -proposed
[09:04]  * pitti expects having to shortcut perl a bit
[09:07] <xnox> blimey
[09:08] <xnox> pitti, we need more builders =)
[09:30] <xnox> pitti, i'm failing to run components-missmatch report locally. Are there magic options that one should pass to it?
[09:31] <xnox> cause at the moment, it tries to like demote dash for me, which should remain in required =/
[09:31] <xnox> what options are used to run the official report for e.g. xenial-release?
[09:38] <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.
[09:39] <pitti> xnox: looking at snakefruit's bin/archive-reports, I don't see anything fancy really
[09:39] <pitti>                         component-mismatches -e touch \
[09:39] <pitti>                                 -d "$OUT/$name.dot" -o "$OUT/$name.txt.new" \
[09:39] <pitti>                                 --html-output-file "$OUT/$name.html" \
[09:39] <pitti>                                 --csv-file "$OUT/$name.csv" \
[09:39] <pitti>                             component-mismatches
[09:40] <xnox> horum.
[09:40] <pitti> although the latter argument doesn't seem to belong to the c-m call itself
[09:40]  * pitti tries to interpret what
[09:40] <pitti>                 background pids component_mismatches component-mismatches
[09:40] <pitti> means
[09:41] <xnox> pitti, is that bin/archive-reports at all available for mere mortals to view? e.g. in ubuntu-archive-tools repository?
[09:41] <xnox> pitti, i was expecting to see included/excluded seeds.
[09:41] <pitti> xnox: http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/changes
[09:41] <xnox> maybe my output is incomplete for components-mismatches to process.
[09:42] <pitti> i. e. http://bazaar.launchpad.net/~ubuntu-archive/+junk/scripts/view/head:/archive-reports
[09:42] <pitti> xnox: although there's an uncommitted delta there: http://paste.ubuntu.com/15000949/
[09:42] <pitti> (not sure who added this)
[09:42] <pitti> so maybe the "-e touch" does something magic
[09:43] <pitti> but if anything, including touch should want *more* packages in main
[09:46] <cjwatson> pitti: what's up with snakefruit?
[09:46] <cjwatson> oh, component-mismatches arguments
[09:46] <pitti> cjwatson: xnox wondered how we call c-m ... that
[09:47] <xnox> 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] <xnox> i don't think that would fly =)
[09:48] <cjwatson> it expects a mirror of dists/ in ~/mirror/ubuntu/
[09:48] <cjwatson> and you might need to pass --germinate-path
[09:49] <cjwatson> 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] <cjwatson> though running generate-extra-overrides from there probably shouldn't be ridiculously impossible
[09:50] <cjwatson> (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] <cjwatson> I still need to stare at your germinate MP at some point :)
[10:03] <xnox> 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] <xnox> 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] <xnox> i'll ask steve to figure out components-missmatches. as i have customer work to do =)
[10:16] <michael-vb> Once more - any one here knowledgeable about how unity-settings-daemon works, and specifically the RandR code?  If not, who might know?
[10:16] <Mirv> pitti: nice! too bad the Train still thinks the silo has failed automated signoff.
[10:17] <xnox> michael-vb, try #ubuntu-desktop? desktopy developers are there.
[10:17] <seb128> 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] <michael-vb> Oh dear, that was what I was afraid of.
[10:18] <seb128> what's your issue?
[10:18] <xnox> michael-vb, i only work on things from "nothing installed" to "reaching multi-user.target" =)
[10:18] <michael-vb> (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] <michael-vb> 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] <michael-vb> I suspect that back then someone got it working "well enough" but a VM places more strain on it.
[10:19] <michael-vb> 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] <xnox> michael-vb, don't use VirtualBox =) install ubuntu for real? =)
[10:20] <michael-vb> Rather hard, given my current job.
[10:21] <michael-vb> That said, I run Ubuntu on my host system too.
[10:23] <seb128> michael-vb, it's worth a bug report (we might already have one) but would need debugging by somebody having the issue...
[10:23] <michael-vb> I am happy to debug, and obviously I can read and write code.
[10:25] <michael-vb> 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] <seb128> yeah, there are more things to work on that we have people/hours in the week
[10:25] <michael-vb> Don't worry, I know all about that.
[10:26] <seb128> is that buggy monitors.xml recreated if you delete it?
[10:26] <michael-vb> (https://www.virtualbox.org/report/1)
[10:26] <michael-vb> It hasn't been re-created since I deleted it last.  But of course I would take time to observe what happens.
[10:27] <michael-vb> And things have been working since then too in my test guest system I must say.
[10:28] <michael-vb> I dare say that when I find what triggers it that may also give me an idea for a work-around.
[10:29] <michael-vb> 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] <seb128> 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] <seb128> I doubt we are going to have slots for that sort of debugging this week
[10:31] <michael-vb> Oh, is it feature freeze time?  Perhaps I should be updating to 16.04...
[10:32] <seb128> next week it is
[10:32] <michael-vb> 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] <michael-vb> But I wouldn't have expected a debugging slot in the week anyway.
[10:34] <michael-vb> I will get back to then.  Hope the feature freeze goes well.
[10:34] <michael-vb> (get back to you)
[10:34] <michael-vb> Thanks all.
[10:37] <xnox> cjwatson, parted patch is kosher, and it was filed as a bug report in debian.
[10:37] <cjwatson> I noticed, on my queue, thanks.
[11:12] <sil2100> ginggs: hey!
[11:13] <sil2100> 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] <sil2100> ginggs: don't want to step on your toes
[11:16] <sil2100> ginggs: ...I'll go ahead with a few projects if you don't mind
[11:17] <sil2100> Since this libjsoncpp transition is blocking us a bit
[11:17] <xnox> 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] <xnox> pitti, cjwatson ^
[11:18]  * xnox is lost, i see bashism.
[11:18] <xnox> full thing http://paste.ubuntu.com/15001267/
[11:18] <pitti> xnox: what are these ':'?
[11:19] <pitti> oh, IFS
[11:19] <xnox> pitti, quality IBM code =)
[11:19] <pitti> xnox: and what is <<< ?
[11:19] <pitti> is that some shorthand for echo 'string' | ?
[11:20] <pitti> i. e. constructing stdin from a string?
[11:20] <xnox> pitti, <<< is bash HEREDOC or some such, it's liek <<EOF, apart from without "EOF" and i think it spawns a separate shell.
[11:20] <pitti> right, that's bash
[11:20] <xnox> 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] <pitti> i. e. two nested loops, one over the bridges, one over the three commands
[11:22] <pitti> or  just expand out the latter, it's just three after all (same number of lines as a for loop)
[11:26] <ginggs> hi sil2100, please go ahead, i've been meaning to find out how to set up a transition tracker in ubuntu
[11:26] <ginggs> debian's is here: https://release.debian.org/transitions/html/auto-libjsoncpp.html
[11:26] <sil2100> ginggs: yeah, that would be useful, but in the case of libjsoncpp at least there's not too many reverse-deps
[11:38] <zbenjamin> 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?
[12:01] <didrocks> 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] <didrocks> python3-argparse can't be installed with findutils
[12:02] <doko> didrocks: pointer?
[12:02] <didrocks> doko: https://launchpadlibrarian.net/237060009/buildlog_ubuntu-xenial-amd64.ubuntu-make_16.02_BUILDING.txt.gz for instance
[12:02] <didrocks> and as xnox said:
[12:02] <didrocks> 09:51:15       xnox | didrocks, it's installable in -proposed.
[12:02] <didrocks> 09:51:26       xnox | but without findutils.
[12:04] <xnox> 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] <xnox> 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] <xnox> doko, or e.g. shall we upload a findutils without breaks for a little while?
[12:05] <xnox> (breaks on the python3.4 package)
[12:06] <doko> meh, looking
[12:22] <doko> jtaylor, tumbleweed: what's the way to go forward with numpy? 1.11 beta doesn't look promising either ...
[12:44] <doko> what is the distutils numpy autopkg test supposed to test?
[12:47] <doko> fails in -release too
[12:48] <didrocks> doko: thanks for the fix. I'll do a give back once it's published in proposed
[12:52] <jtaylor> doko: whats the failure?
[12:59] <doko> jtaylor, the distutils test emits a user warning on stderr. now allowing stderr for this test
[13:01] <jtaylor> what is it printing?
[13:01] <Laney> there's actual failures
[13:01] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-numpy/20160207_105740@/log.gz
[13:02] <jtaylor> ah its still 1.10
[13:02] <jtaylor> thats the issue I told you about a while ago
[13:02] <jtaylor> + patch for it
[13:02] <doko> hmm, can't remember
[13:03] <jtaylor> should be fixed in 1.11 I think
[13:03] <doko> yep, but that one is introducing more failures in autopkg tests
[13:04] <jtaylor> in others I guess?
[13:05] <doko> see ole's report for debian
[13:43] <tjaalton> 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] <doko> tjaalton, please check with 3.8
[13:44] <tjaalton> check?
[13:44] <tjaalton> I can push it to a ppa first
[13:44] <tjaalton> at least mesa builds with it
[14:10] <pitti> neither current desktop live system, nor ubiquity-only are currently booting in QEMU for me -- is that only me?
[14:12] <davmor2> pitti: which are you saying is current?
[14:12] <pitti> http://cdimage.ubuntu.com/cdimage/daily-live/ says it's from today, yes
[14:13] <davmor2> pitti: give me 5 I'll see if I can confirm for you
[14:13] <cjwatson> pitti: see #ubuntu-release
[14:13] <cjwatson> apparently a missing video driver package
[14:14] <pitti> ah, thanks!
[14:16] <ogra_> finally ... headless desktop images !
[14:18] <davmor2> ogra_: careful it'll overtake snappy if you are not careful :P
[14:18] <ogra_> haha
[14:22] <seb128> pitti, see #ubuntu-desktop backlog
[14:22] <pitti> seb128: thanks
[14:23] <seb128> it's a bit annoying that images manage to move to "current" despite having no xorg working
[14:23] <seb128> "images to have passed any automatic testing"
[14:23] <seb128> rrright ;-)
[14:43] <sil2100> 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] <sil2100> I need to modify the seeds as part of the transition itself
[14:44] <seb128> sil2100, don't know, I'm not the right person to ask about that
[14:46] <cjwatson> I think that's reasonable if it's a necessary part of the transition.
[14:47] <sil2100> cjwatson: thanks :)
[14:47] <cjwatson> This is an unfortunate consequence of the touch seeds hardcoding particular ABIs.
[15:07] <Nitrigaur> 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] <Nitrigaur> The install crashes before I can get access to a proper terminal, so I'm unable to try the workarounds described there
[15:12] <pitti> robru: ah! I finally found some time to investigate bug 1537866 again, and now I understand what's going on
[15:15] <damascene> leave Britney alone
[15:16] <pitti> no way, she's working around the clock for us!
[15:17] <damascene> :(
[15:30] <pitti> ah, someone just published the d-i SRU for bug 1537136
[15:30] <pitti> but not systemd (where the chagne actually comes from)?
[15:36] <xnox> pitti, people request package testing overrides in #ubuntu-release =) but you don't seem to be there at =)
[15:36] <xnox> all
[15:36]  * dholbach hugs seb128 
[15:37]  * seb128 hugs dholbach back
[15:37] <xnox> 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] <xnox> <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] <xnox> <apw> is preventing maas images from workgin, which is bleeding through to testing, preventing testing for the kernel
[15:37] <xnox> <apw> i am therefore requesting we hint that test for initramfs-tools
[15:37] <xnox> =)
[15:37] <seb128> 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] <pitti> xnox: well, there's plenty of people who can add that override :)
[15:38] <pitti> xnox: anyway, adding
[15:38] <pitti> xnox: I can't influence the kernel, that gets controlled by the kernel team itself
[15:38] <apw> 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] <xnox> pitti, but you are like the best and the most responsive =)
[15:39] <pitti> hint added
[15:39] <xnox> apw, hmm... you are running maas on s390x?
[15:39] <xnox> apw, please ellaborate
[15:41] <apw> xnox, we have been unable to test any as far as i know, and smosers fix is meant to be part of the solution there
[15:42] <apw> xnox, my fix is related to alternate image builds failing
[15:42] <apw> xnox, i don't think we are runnign maas on s390x, but its not me who does the automation there
[15:43] <pitti> tjaalton: ah, did you release d-i? the systemd change should be released along then, as that's the actual change in d-i
[15:43] <pitti> tjaalton: (udev-udeb)
[15:44] <pitti> tjaalton: I didn't yet see confirmation from the reporter that it fixes the bug, but if it's still broken we can always re-open
[15:44] <pitti> tjaalton: and I tested the -proposed netboot images to make sure they are okay
[15:44] <tjaalton> pitti: the d-i one was just a rebuild, and there was another one needed which had to get in proposed
[15:45] <pitti> tjaalton: right, a rebuild against the proposed udev-udeb
[15:45] <tjaalton> pitti: so yeah the actual bug is still unverified by the reported
[15:45] <tjaalton> -er
[15:45] <xnox> doko, your "fixed" python3.4 looks "better" than the previous upload =/
[15:45] <pitti> tjaalton: to make that change actually effective, as udebs get "collected" during d-i build
[15:45] <tjaalton> yes
[15:47]  * pitti releases
[16:03] <sidi> Anyone ever programmatically mounted partitions? Trying to find a way to mount arbitrary partitions on top of an overlayFS partition (lower dir is root, basically I  wanna ensure that /dev, /run, etc are mounted as ro, and that /home is mounted as part of the overlayFS)
[16:15] <marlinc> Is there a channel with people (trying) to run the latest development release as daily driver?
[16:17] <xnox> marlinc, /j #ubuntu+1 i think
[16:18] <xnox> marlinc, as long as you do not enable xenial-proposed it should be fine, unless you are talking about phone releases in that case #ubuntu-touch
[16:19] <didrocks> doko: I guess you did see that https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2ubuntu1 FTBFS, right?
[16:19] <marlinc> Ah, thanks xnox. I'm not on proposed
[16:19] <doko> didrocks, I guess you saw https://launchpad.net/ubuntu/+source/python3.4/3.4.4-2ubuntu2 before asking
[16:20] <didrocks> doko: oh, launchpad didn't list it when I refreshed
[16:20] <didrocks> great!
[16:20] <didrocks> thanks doko :)
[16:22] <marlinc> I've never in my life filled this many bug reports :P
[16:22] <marlinc> I kind of like it
[16:30] <seb128> hum
[16:30] <seb128> Suppression de python3.4 (3.4.4-1) ...
[16:30] <seb128> xargs : l'option -s contient un nombre non valide
[16:30] <seb128> Usage: xargs [OPTION]… COMMANDE [ARGS-INITIAUX]…
[16:30] <seb128> barry, doko, ^ known issue?
[16:30] <seb128> Suppression de libpython3.4-stdlib:i386 (3.4.4-1) ...
[16:30] <seb128> xargs : l'option -s contient un nombre non valide
[16:31] <seb128> dist-upgrading xenial
[16:31] <barry> seb128: doko's had some recent uploads, but sorry i don't understand the french output ;)
[16:32] <seb128> barry, it's close enough from the english words ;-)
[16:32] <seb128> barry, invalid number used for the -s xargs option
[16:33] <barry> seb128: ah.  i'm not aware of this problem, but doko is working on the package (i've seen a couple of uploads in the last day or so)
[16:33] <seb128> while removing those python3.4 packages
[16:38] <doko> seb128, which awk do you have installed?
[16:38] <seb128> $ dpkg -l | grep awk
[16:38] <seb128> ii  gawk                                                  1:4.1.3+dfsg-0.1                            i386         GNU awk, a pattern scanning and processing language
[16:38] <seb128> ii  mawk                                                  1.3.3-17ubuntu2                             i386         a pattern scanning and text processing language
[16:38] <seb128> doko, ^
[16:38] <tjaalton> mterry: hi, do you have time to look at bug 1543659?
[16:39] <seb128> doko, * 0            /usr/bin/gawk    10        mode automatique
[16:39] <doko> seb128, well, try running the prerm/postrm manually and tell me what goes wrong
[16:39] <mterry> tjaalton, sure
[16:39] <doko> never saw this locally
[16:39] <tjaalton> mterry: cool, it needs to move to fix images
[16:40] <doko> pete-woods1, there is a duplicate package sphinx3 in the archive. can it be removed?
[16:40] <seb128> doko,  libpython3.4-minimal install wants to remove findutils
[16:40] <seb128> not sure I want to do that :p
[16:46] <tjaalton> findutils breaks libpython3.4-minimal (<< 3.4.4-2)
[16:47] <doko> pete-woods1, removed, no rdeps, pocketsphinx is the more recent package in the archive
[16:50] <tjaalton> seb128: looks like python3.4 isn't needed anymore, so should be safe to let it go?
[16:51] <seb128> tjaalton, yeah, it's just that I got " xargs : l'option -s contient un nombre non valide" error on removal and doko asked if I could run the prerm manually to get debug info, so I tried to reinstall it
[16:51] <tjaalton> yeah, the added breaks was related to that
[16:53] <doko> anyway, afk now
[16:55] <pitti> barry, slangasek: with the demise of the tech board I have lost the ability to approve https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only for xenial; slangasek, can you please do that? (I suppose you are in ~ubuntu-drivers somehow)
[16:56] <Laney> RIP techboard
[16:56] <barry> oh?
[16:58] <pitti> barry: we all timed out about a week ago, it now needs sabdfl to pick candidates, then we can re-vote
[16:58] <dholbach> pitti, shall I extend the members' terms by 3 weeks?
[16:58] <barry> pitti: ah right, i remember seeing the call for candidates
[16:59] <dholbach> that's probably the least amount of time required until we have a new TB
[17:00] <dholbach> let me set it to 1st March
[17:04] <dholbach> infinity, kees, mdeslaur, pitti, slangasek, stgraber: I extended your TB terms for another 3 weeks
[17:05] <mdeslaur> dholbach: thanks
[17:17] <pitti> dholbach: thanks!
[17:17] <pitti> SIGSEGV
[17:19] <Laney> $ gdb ./pitti
[17:28] <nacc> slangasek: for a package that is in Debian experimental (e.g., libbson, libmongoc) that are not yet in Ubuntu, should I file a sync bug or a needs-packaging bug?
[17:29] <xnox> Laney, maybe simply re-initialise matrix back to the known state of the 90s?
[17:35] <xnox> nacc, request-sync from experimental.
[17:36] <pete-woods1> doko: okay, I can't actually remember now, it's so long since we used it
[17:36] <xnox> nacc, $ man requestsync
[17:36] <nacc> xnox: thanks -- found more relevant documentation of the same on the wiki
[17:36] <xnox> nacc, excellent =)
[17:37] <dsmythies> The last couple of updates to the installation-guide package appear to have been done somewhere downstream from the Ubuntu master source at:
[17:37] <dsmythies> https://code.launchpad.net/~ubuntu-core-dev/installation-guide/ubuntu
[17:38] <dsmythies> When we publish the installation guide on help.ubuntu.com we prefer to work from the master source (we didn't the other day).
[17:38] <dsmythies> Would be possible to get this situaiton corrected?
[17:39] <xnox> dsmythies, i'm not sure what you mean. That branch is the master branch for packaging installtion-guide source package in ubuntu, which is then uploaded into the archive.
[17:39] <xnox> and the generated pages are also published online. for a given series.
[17:39] <xnox> that branch is now at xenial, and xenial guide is live now.
[17:40] <xnox> dsmythies, what do you mean by "downstream"?
[17:41] <xnox> dsmythies, and what would you like to be corrected?
[17:41] <cjwatson> xnox: https://launchpad.net/ubuntu/+source/installation-guide/20160121ubuntu2 wasn't committed to bzr, nor were some previous uploads
[17:41] <xnox> is there something wrong with the website vs the branch vs the .deb package?
[17:41] <xnox> oh.
[17:42] <dsmythies> The master bzr branch and the current package and the web site are not in sync
[17:42] <xnox> sigh.
[17:42] <xnox> dsmythies, yeap, i see that now.
[17:42] <xnox> dsmythies, i don't have time to do this now, but i'll open a bug report to reconcile the lot.
[17:43] <xnox> dsmythies, thanks for spotting this.
[17:43] <dsmythies>  O.K. note: the web site is preliminary anyhow and with a disclaimer that stuff might be wrong.
[17:44] <xnox> dsmythies, yeah. it's just there is a bunch of new stuff in it, and we do want as many eye balls on it as possible.
[17:44] <dsmythies> See: https://help.ubuntu.com/
[18:10] <dsmythies> xnox: O.K. I see bug 1543700
[18:12] <xnox> dsmythies, yes.... i opened that bug.... and assigned to myself.
[18:12]  * xnox is xnox
[18:13] <xnox> dsmythies, but will not get to do it this week though =(
[18:13] <xnox> -ENOTIME
[18:23] <nacc> as I go through and file bugs for various PHP updates in anticipation of the PHP7.0 move (and removal of PHP5), is there a more efficient way to file the staged build bugs than using the launchpad web UI? apport seems to be more for reporting functional problems? I could script something using launchpadlib, but that seems like time I don't quite have right now :)
[18:25] <cjwatson> if you want a scripted way of doing things with Launchpad, then launchpadlib is it
[18:25] <nacc> cjwatson: ok :)
[18:26] <nacc> cjwatson: i can c&p for most of the bugs, and it's probably good for me doing my due diligence, just wasn't sure if there was a more efficient way
[18:36] <sabdfl> pitti, i have nominations, need to think through the short-listing, will ask TB for comments this weekend
[18:39] <pitti> sabdfl: ah great, thanks
[18:49] <nacc> slangasek: i assume it's ok for debian/tests/control to not understand staged dependencies (that is, i've only been modifying debian/rules and debian/control, since I figure during the bootstrapping, autopkgtest may be "known broken")?
[18:51] <slangasek> nacc: yes
[18:51] <pitti> nacc: it's indeed fairly easy; if you need some inspiration, http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L1745
[18:51] <nacc> slangasek: great, thanks
[18:52] <pitti> nacc: there are some oddities due to being bilingual, and you don't need the "blob" stuff
[18:52] <nacc> pitti: thanks! i'll try and take a look at that!
[18:53] <nacc> admittedly, doing it manually is making me consider each staged build and decide if it's really necessary :)
[18:53] <nacc> which is probably good
[18:53] <pitti> nacc: i. e. unless you have attachments, it's basically just the single createBug() call at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L1778
[18:54] <nacc> pitti: wonderful, that's probably exactly what i need
[18:54] <pitti> nacc: https://launchpad.net/+apidoc/1.0.html#bugs-createBug
[18:57] <nacc> pitti: thanks!
[19:17] <roaksoax> 34/win 13
[20:49] <pitti> cyphermox: hey, how are you?
[20:49] <cyphermox> hey
[20:49] <cyphermox> doing alright, you?
[20:50] <pitti> cyphermox: I just found a little "one of these days" item on my list -- do you know about NM's captive portal detection by any chance?
[20:50] <pitti> some Fedora guys mentioned that NM has done that for a long time already, but I've never seen it actually working
[20:50] <pitti> did we disable that by any chance?
[20:50] <cyphermox> it's not enabled by default
[20:51] <pitti> it seems to be one of the values of the NM_CONNECTIVITY dbus properties
[20:51] <cyphermox> but yeah, it's there, just it doesn't always work as well as some people would like... there was a rather long thread about this on ubuntu-devel@ some time ago
[20:52] <pitti> cyphermox: well, having it in NM is one side, but I suppose that actually needs to be handled in nm-applet somehow, changing the icon and menu accordingly
[20:52] <pitti> but I can't find anything with grep -Eri 'captive|portal' in n-m-applet
[20:52] <cyphermox> not that much
[20:52] <cyphermox> there has never been anything special for it in nm-applet
[20:52] <cyphermox> not even in fedora
[20:53] <pitti> like on Android you get a wifi notification symbol with a question mark
[20:53] <cyphermox> yeah
[20:53] <cyphermox> I suppose it could be added
[20:53] <pitti> which opens some kind of randomly generated URL on google
[20:53] <cyphermox> err
[20:53] <pitti> I wonder what fedora uses for that then, this can hardly be a fedora patch to nm-applet?
[20:53] <cyphermox> I don't think there is any special patch for that
[20:54] <cyphermox> they might only enable it and let applications deal by itself with the actual DBus API value
[20:54] <cyphermox> ie. CONNECTED_GLOBAL, or CONNECTED_LOCAL, or whatever
[20:54] <pitti> NM also doesn't have a switch for it
[20:54] <pitti> oooh! https://lists.fedoraproject.org/pipermail/desktop/2014-July/010061.html
[20:54] <pitti> that says that it's handled in gnome-shell, not nm-applet
[20:54] <pitti> bah! why would you put that there..
[20:55] <cyphermox> because they use gnome-shell?
[20:55] <pitti> yeah, I figure
[20:56] <pitti> js/ui/status/network.js:        let isPortal = this._client.connectivity == NetworkManager.ConnectivityState.PORTAL;
[20:56] <pitti> cyphermox: ah, got it, grepped gnome-shell now
[20:56] <pitti> cyphermox: ok, nevermind then
[20:56] <cyphermox> well, it could well be added to nm-applet
[20:57] <cyphermox> it just isn't there yet, and I'm not sure what it could look like?
[20:57] <mwhudson> infinity: ping
[20:57] <pitti> wifi symbol with a question mark?
[20:57] <cyphermox> ahh
[20:58] <cyphermox> I wish we didn't need to create new icons :P
[20:58] <pitti> I thought one could put an emblem on a standard icon
[20:58] <pitti> like nm-applet does with the lock when you are on VPN?
[20:59] <cyphermox> that's no longer composited together
[20:59] <cyphermox> that used to be the case, but at some point I had to put the icons together, since indicators didn't support the necessary composited / passing a pixbuf
[20:59] <cyphermox> or something to that extent
[21:00] <pitti> cyphermox: as background, this came up when we quickly discussed how to enable DNSSEC on desktops, and apparently this was a necessary part (I forgot the details, though)
[21:00] <pitti> cyphermox: oh, a shame
[21:00] <cyphermox> well, perhaps that has changed
[21:00] <cyphermox> or someone more knowledgeable might want to have a crack at it
[21:01] <cyphermox> but yeah, before you do DNSSEC you might want to do some checking to know whether you really are online, or trapped behind a portal of some sort
[21:01] <cyphermox> even though that won't get you that much more security either, since that portal could fake whatever it wants :)
[21:23] <ginggs> doko, i  managed to get petsc to build on powerpc porterbox by skipping the 2 MPI process test (the 1 MPI process tests run fine)
[21:24] <darkxst> pilot out
[21:24] <darkxst> @pilot out
[21:33] <nacc> slangasek: question about what to do with a package for code that is EOL upstream? and we carry the supported upstream version of the same code in a different package
[21:35] <slangasek> nacc: hmmm, request the package's removal?
[21:36] <slangasek> nacc: which is 1) bug report against the package, 2) subscribe ubuntu-archive
[21:36] <nacc> slangasek: i'm tempted to do that (and is what i did during my side build)
[21:36] <nacc> slangasek: ok, thanks!
[21:38] <nacc> slangasek: and i think the upstream versions of the deps that exist, ahve updated to use the new libs ... will note that in their bugs
[21:39] <jderose> random question: any one able to get UEFI vms working with qemu? previously i used "-bios /usr/share/ovmf/OVMF.fd" for UEFI, but there seem to be problems booting into the install afterward
[21:40] <cyphermox> jderose: yes, it does work well here
[21:40] <jderose> cyphermox: you happen to have an example command line that works for you?
[21:41] <cyphermox> sure
[21:42] <jderose> cyphermox: in my case, it boots to the correct drive with the -cdrom option is supplied, but wont boot to it from subsequent calls that don't include the -cdrom option
[21:42] <cyphermox> ah, I'm not changing the options from one boot to the next
[21:43] <jderose> hmm, maybe i can work around it by always including -cdrom
[21:43] <cyphermox> qemu-system-x86_64 -name efi-test-x86_64 -cpu core2duo -enable-kvm -monitor stdio -serial pty -boot menu=on -usb -m 1024 -vga qxl -m 1024 -bios /usr/share/qemu/OVMF.fd -net user -net nic -drive file=../iso/xenial-desktop-amd64.iso,media=cdrom -drive file=disks/efi-testdisk1.qcow2
[21:43] <pitti> jderose: I regularly use that for testing, yes
[21:44] <pitti> jderose: but I grabbed the OVMF.fd from upstream, not the packaged one (but that was a while ago, perhaps the packaged one works too now)
[21:44] <cyphermox> jderose: this is what I'd use ^
[21:44] <cyphermox> the packaged one did indeed have issues before, AFAIK they are fixed now
[21:44] <jderose> cyphermox: pitti: thanks! yeah, i've been using the pre-build ovmf package since trusty or so, seems to work well
[21:46] <cyphermox> jderose: I put my vm spawning commands in scripts that I published on bzr too: https://code.launchpad.net/~mathieu-tl/+junk/vm
[21:46] <jderose> oh yeah, i'm only having trouble since upgrading from wily to xenial, forgot to include that bit
[21:48] <jderose> cyphermox: i didn't realize you could emulate 4k logical sector size with qemu... very handy, thanks!
[21:48] <cyphermox> jderose: that's... special
[21:48] <cyphermox> it *used to work*
[21:48] <cyphermox> now I mucked with it some earlier this cycle and it didn't seem to, but I may have been doing something wrong
[21:48] <jderose> cyphermox: with what qemu version did it stop working?
[21:49] <cyphermox> I don't know
[21:49] <jderose> no worries, just curious :)
[21:49] <cyphermox> :)
[21:56] <mwhudson> taaalking of ubuntu-archive bugs ... https://bugs.launchpad.net/ubuntu/+source/golang-go.tools/+bug/1534313
[22:22] <jderose> cyphermox: pitti: my hunch is my Xenial problem might be related to this - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918
[22:28] <rharper> jderose: sudo qemu-system-x86_64 -enable-kvm -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash  boots the uefi bios in xenial;
[22:31] <jderose> rharper: awesome, thanks! i think that's what i was looking for :)
[22:31] <rharper> jderose: cool, though the bug you referenced is good background;  I was somewhat aware of this split but reading more to see if we need to make any changes,
[22:32] <jderose> rharper: so you don't use the -bios option in how you set this up? that's how i always used to do this, but perhaps that's been outdated for a while
[22:37] <nacc> slangasek: in the process of updating a package's explicit deps (e.g., php5-mongo -> php-mongodb) and also adding staged builds, can I do that in one bug (i.e., "php-monolog: bootstrap for PHP7") or would it be preferred to do it via two bugs?
[22:37] <slangasek> nacc: one bug is fine with me
[22:37] <nacc> slangasek: ok, thanks!
[22:39] <nacc> mwhudson: thanks for the tweaks to a few of those bugs, apologies you needed to do that. Any advice for me on fields to check are generally correct? Don't want to make more work for anyone!
[22:42] <mwhudson> nacc: i've entirely forgotten context
[22:42] <nacc> mwhudson: all the php bugs going by you probably
[22:42] <mwhudson> nacc: or alternatively you didn't mean to direct that at me :-)
[22:42] <mwhudson> nacc: ah no definitely not me then :-)
[22:42] <nacc> mwhudson: ah sorry!
[22:43] <mwhudson> hodson vs hudson?
[22:43] <nacc> yep :)
[22:43] <nacc> and not paying close enough attention on my part :)
[22:43] <sarnold> feel free to ignore what he does on bugs; most of the time it's just noise
[22:57] <jderose> rharper: quick question: in your example, are you using sudo because you need write access to /usr/share/OVMF/OVMF_VARS.fd? as in the debian bug, not sure i totally understand the purpose of OVMF_VARS.fd. sort of seems like something that might need a per-VM writable copy
[22:57] <rharper> jderose: yeah, temporarily;  you are free to copy that template and put that in per-user writable space and can drop the sudo and use kvm group
[22:58] <rharper> the _VARS is a UEFI write space for pre-boot configuration (like which device to boot and a bunch of other stuff)
[22:58] <rharper> still reading the bug, but in general we'll need to switch over and figure out of apparmor profiles and other things need to change
[22:58] <teward> has the process for requesting FeatureFreeze exceptions changed, or is still relatively the same process?
[22:58] <jderose> rharper: so just OVMF_VARS.fd needs to be writable by the process, not OVMF_CODE.fd?
[22:59] <teward> been an eon since i've had to req. an FFe, so i'm prepping ahead of needing to, making sure I know what I need ;)
[22:59] <rharper> jderose: that's my understanding
[22:59] <rharper> the _CODE.fd is the runtime read-only UEFI code, the VARS are writable settings that the UEFI runtime inside a guest can modify
[22:59] <jderose> rharper: okay, thanks! seems few on the internets yet know how to work with this new way of doing things
[23:00] <rharper> it looks like libvirt will DTRT for you w.r.t making copies and keeping things per-user
[23:01] <rharper> if you use qemu directly, then you'll need to make that copy yourself
[23:01] <rharper> jderose: virtual uefi adoption goes just about as slow as physical uefi adoption =/
[23:01] <jderose> rharper: yeah, i'm using qemu-system directly, but this should be a pretty minor change once i get it figured out
[23:01] <jderose> hehe :D