[00:56] <tgm4883> infinity: downloading the isos now
[00:57] <tgm4883> infinity: sorry meant to do it a few days ago when you pinged me
[05:01] <hallyn> pitti: i've only run adt_run with --source.  How do I tell it to use the .debs in my cwd ?
[05:14] <nacc> hallyn: the order of params matters, iirc, if you pass it properly as the first param ("filename" in the manpage) and then specify -B, it won't build the source
[05:21] <hallyn> nacc: as it turns out pkg doesn 'thave tests anyway :)  but still curious.  thanks
[05:25] <smoser> pitti, around ?
[06:01] <tjaalton> any hope getting libpng16 (in experimental) to xenial?
[06:01] <tjaalton> a migration to it might be out of the question, but having this even in universe should be ok?
[06:04] <smoser> pitti, well, when you come in, if you could look at my debdiff for open-iscsi and see if it is in line with yours and then just upload .. i'd appreciate it.
[06:04] <smoser> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1546877
[06:06] <RAOF> doko: Is https://gcc.gnu.org/bugzilla really the gcc bugzilla? I've run into a clear bug with gcc-6 compilation in Mir, but none of my searches seem to find anything there.
[06:08] <RAOF> (Specifically, “delete this;” triggers -Wnonnull-compare, which is clearly bollocks)
[06:09] <RAOF> Oh, hah. Missed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
[06:09] <RAOF> doko: Unping.
[06:31] <cpaelzer> good morning
[06:58] <Pharaoh_Atem> argh
[06:58] <Pharaoh_Atem> I'm rather frazzled trying to figure out why the php7.0 autopkgtests are failing...
[06:59] <Pharaoh_Atem> I see it here that every test except cli fails
[07:02] <Pharaoh_Atem> ugh, I'm tired
[07:37] <pitti> Good morning
[07:41] <pitti> hallyn: adt-run with .debs> adt-run *.deb -B *.dsc ...  -- it's one of the cases in https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html
[07:41] <pitti> hallyn: queued the libvirt bug, but adding a proper reproducer to the bug would be appreciated
[07:42] <pitti> hallyn: i. e. starting from a blank install
[07:42] <pitti> smoser: yes, will do
[07:43] <hallyn> pitti: if you have any VMs defined, just apt-get install systemd-container will make them break.  is that enough of a reproducer?
[07:43] <hallyn> if not i'll post soemthing in th emorning
[07:44] <hallyn> thanks, will store that adt-run exacmple cmd for next time ^
[07:44] <cyphermox> good morning pitti!
[07:44] <hallyn> (btw, for starting from clean install it'll basically be https://wiki.ubuntu.com/SergeHallyn_libvirtnest, but i'l post details in the monring)
[07:45]  * hallyn out
[07:46] <pitti> hallyn: adding them with virt-manager?
[07:46] <pitti> hey cyphermox
[07:47] <pitti> I'll try that
[07:53] <seb128> barry, thanks for the libpeas depends fixed but can you commit your changes to the packaging vcses as well?
[07:53] <seb128> barry, gedit/rhythmbox at least have one
[08:05] <dholbach> good morning
[08:07] <pitti> smoser: we still need the debian/net-interface-handler? can't we teach those images to either not write an interfaces.d/ stanza or set a "manual" one at least?
[08:07] <pitti> smoser: that seems much cleaner than doing the wrong thing in the install and then hacking around it
[08:12] <ginggs> morning! any archive admins around to look at removing the last 3 packages that directly depend on python-support LP: #1535318 ?
[09:22] <doko> sil2100, could you still merge python-pysaml2?
[09:23] <sil2100> doko: hey, sure, adding it for my today's todo list
[09:29] <Laney> juliank: hi, any idea if there's a way we can make appstream download its files the first time it is installed instead of requiring a second apt update?
[09:34] <juliank> Laney: Hmm, maybe you could install an APT config file somewhere else (in an unsynced package, not apt...) that adds a script in DPkg::Post-Invoke that checks whether appstream was installed and runs update, but apart from that, no.
[09:34] <juliank> Laney: You could of course also add an identical appstream config file to a base package.
[09:44] <doko> tjaalton, xorg gained two new deps, needs a MIR, or be dropped
[09:45] <tjaalton> doko: which ones?
[09:45] <doko> tjaalton, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[09:47] <pitti> smoser: but otherwise LGTM, so I'll upload this for now; I hope we clean this up further at some point; thanks for the merge!
[09:47] <doko> cjwatson, stgraber, cyphermox: casper wants to pull in lzma (since 2011). wondering why we didn't care until now, or is this a false positive?
[09:49] <tjaalton> doko: -void is for s390, and freedreno for arm, guess we want both
[09:50] <jtaylor> anyone tried open-iscisi on xenial?
[09:50] <jtaylor> seems we have bug 1444555 again
[09:50] <jtaylor> not fun when it randomly decides to not start networkmanager
[09:56] <doko> tjaalton, looks like so
[09:57] <jtaylor> bug 1465196, pitti if you need help testing I have a system that can be used
[09:57] <doko> seb128, Laney: appstream needs a MIR (dependency of gnome-software)
[09:57] <Laney> you mean https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1538293 ?
[10:01] <jtaylor> doko: can we have a vim built with python2 in xenial? switching to python3 breaks evverything
[10:01] <jtaylor> ok maybe not everything, but a lot ._.
[10:02] <doko> jtaylor, well, there's one bug report, and apparently upstream is working on it
[10:02] <doko> I'd rather grant exceptions to fix things
[10:02] <jtaylor> doko: which upstream? there are hundreds of scripts in python2
[10:03] <jtaylor> almost none of them are packaged
[10:04] <doko> jtaylor, sure, but then can you point out a way forward? these scripts will be still there in years
[10:04] <jtaylor> stick with python2?
[10:04] <jtaylor> provide a new vim-py3 for the few who actually have py3 only scripts
[10:04] <doko> no, python2 is a dead end. I mean, you could package it separately.
[10:05] <doko> no, our default vim is linked with python. if you want that, then do a vim-py2
[10:05] <jtaylor> a vim-py2 would be fine too
[10:05] <jtaylor> but given that probably 100% of all plugins are python2 I think the other way round is better
[10:06] <jtaylor> there is no distro that ships py3 vim, so zero plugins support it
[10:06] <doko> not even arch?
[10:06] <jtaylor> maybe arch
[10:06] <doko> https://github.com/Valloric/YouCompleteMe/issues/1940
[10:07] <doko> that's one packaged I know about
[10:07] <jtaylor> actually they have a vim-python3 package
[10:08] <jtaylor> yes in a version thats old and doesn't work
[10:08] <jtaylor> though I didn't check if it changed since vivid
[10:09] <jtaylor> imo switching vim is a larger problem than switching gdb was and that was a catastrophy
[10:09] <jtaylor> basically gdb from repo was unusable for years for many people
[10:10] <doko> ugh, years == 2, you seem to exxagerate ;)
[10:10] <doko> so which variants should be provided for python2, nox and gtk?
[10:10] <doko> or all?
[10:10] <jtaylor> I'd say all, though I only use terminal vim
[10:11] <jtaylor> other people might use the guis
[10:11] <jtaylor> 2 > 1 = years ;) still a very long time
[10:12] <jtaylor> gdb has the advantage that its a dev tool so its no problem for users to rebuild gdb yourself, vim is not only a dev tool so I think its more problematic
[10:13] <doko> lets see how easy these loops would be ...
[11:07] <cjwatson> swt2c: I didn't see anyone answer you; we can certainly retry such things.  Which package are you talking about?
[11:07] <cjwatson> doko: When you say "since 2011" ... lzma was in main in vivid, and then for some reason demoted in wily despite casper's dependency
[11:08] <doko> cjwatson, ok, just promoting then
[11:09] <cjwatson> thanks
[11:17] <doko> Laney, seb128: texlive-extra-fonts (owned by desktop) wants to promote 20 font packages ... I assume we just don't care about all those maintained by the debian fonts task force, however there are two maintained by individal maintainers
[11:17] <doko> fonts-cabin fonts-comfortaa fonts-crosextra-caladea fonts-crosextra-carlito fonts-dejavu fonts-ebgaramond fonts-font-awesome fonts-freefont fonts-gfs-artemisia fonts-gfs-complutum fonts-gfs-didot fonts-gfs-neohellenic fonts-gfs-olga fonts-gfs-solomos fonts-junicode fonts-lato fonts-linuxlibertine fonts-lobstertwo fonts-oflb-asana-math fonts-roboto fonts-sil-gentium fonts-sil-gentium-basic fonts-sil-gentiumplus fonts-stix ttf-adf
[11:17] <doko> these are fonts-stix ttf-adf
[11:17] <doko> could you have a look at these?
[11:17] <doko> writing a MIR for the others
[12:20] <xnox> slangasek, cjwatson, pitti - is lp:~ubuntu-release/britney/britney2-ubuntu up to date? e.g. s390x is not listed as an Architecture in britney.conf
[12:21] <xnox> ADT_ARCHES don't look to be up to date either.
[12:22] <pitti> xnox: britney1-ubuntu adds it for xenial only
[12:22] <pitti> xnox: yes, it's up to date, and snakefruit pulls that branch before every run
[12:23] <pitti> xnox: search for s390x in http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/view/head:/britney
[12:23] <pitti> xnox: this part munges the default config to release-specific settings, such as "no ppc64el on precise" or "s390 on xenial only"
[12:24] <pitti> xnox: arguably this could be swapped around, e. g. add s390 to the default and remove it from all earlier series
[12:25] <xnox> pitti, gotcha. it's all good, just looking about.
[12:37] <carldani> Hi!
[12:38] <carldani> Is this the right channel to ask about updating packages before the freeze?
[12:56] <ogra_> pitti, cjwatson, what happened to livecd-rootfs now, did you already do the git switch (i have some changes to make and it would be good to know the proposed new workflow (bzr branch/make changes as UNRELEASED/commit/bump version/debcommit/push was my old flow)
[12:56] <ogra_> (might probably be good to have that on the https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup wikipage
[12:56] <ogra_> )
[13:05] <pitti> ogra_: I don't know if it already got coverted, I didn't hear about updates either
[13:06] <pitti> ogra_: dch -r / debcommit -ar etc. work with git branches too, FTR
[13:06] <ogra_> good
[13:06] <ogra_> still, it would be nice to have it documented if there is new workflow :)
[13:06] <xnox> pitti, cjwatson - in our ogre model, do universe packages allowed to depend on restricted packages?
[13:07] <ogra_> shouldnt restricted be solely for HW enablement ?
[13:07] <ogra_> (would anything depend on such stuff at all ?)
[13:10] <pitti> xnox: they certainly shouldn't
[13:10] <pitti> however, I'm not entirely sure how buildds etc. implement that
[13:11] <xnox> pitti, i'm making britney component aware and i was hoping to make it a simple <= integer comparison. main is 0, multiverse is 3, and things can depend on stuff which is <= of their number =)
[13:11] <xnox> pitti, i guess the buildlog for a universe package would tell me, e.g. if restricted is enabled or not.
[13:11] <cpaelzer> Hi, I try to reproduce an dependent autopkgtest failure of an upload - so I have package A (the trigger) and B (the dependent one which fails its test)
[13:11] <cpaelzer> I try to puzzle to gether the equivalent adt-run invokation, so far I'm assuming it is using the triggers "--source A.dsc" (to build and test) and the dependent from the archive as is like "--no-built-binaries --apt-source B"
[13:12] <cpaelzer> So overall "adt-run --source A.dsc --no-built-binaries --apt-source B  ..." does that make sense?
[13:12] <pitti> xnox: indeed, it's main and universe  only
[13:12] <wgrant> xnox: No, free can only depend on free.
[13:12] <xnox> wgrant, darn =)
[13:12] <xnox> wgrant, ok.
[13:13] <pitti> cpaelzer: no, we don't test two different source pacakges
[13:13] <pitti> cpaelzer: the trigger just defines that we take the trigger's binaries from -proposed, and the rest (as much as possible) from -release
[13:13] <wgrant> xnox: https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/adapters/archivedependencies.py#n60
[13:13] <pitti> cpaelzer: if you look at the build log, the full adt-run invocation is printed there
[13:13] <xnox> wgrant, omg partner...
[13:14] <cpaelzer> pitti: in the build not the test log, thanks I'll take a look
[13:14] <pitti> cpaelzer: that has some extra stuff which you don't need, and it uses ssh nova instead of qemu, but you should get the idea
[13:14] <xnox> wgrant, wait how does that work? partner manages to build without main?!
[13:14] <pitti> cpaelzer: sorry, yes, test log; what's teh URL?
[13:14] <cpaelzer> pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/o/openvswitch-dpdk/20160217_200054@/log.gz yeah its right at the top
[13:15] <cpaelzer> pitti: I focussed so much on the issue at the end to overlook that - great thank you a lot
[13:15] <cpaelzer> I can derive my invokation from there I think
[13:15] <pitti> cpaelzer: right, so: adt-run --apt-pocket=proposed=src:dpdk --apt-upgrade openvswitch-dpdk --- qemu ...
[13:15] <pitti> (or --- lxd or whatever suits you)
[13:17] <cpaelzer> pitti: thanks
[13:22] <wgrant> xnox: Parter is a separate archive, and that archive has a separate dependency on the primary archive.
[13:23] <wgrant> That dependency includes all components.
[13:23] <cpaelzer> I must thank all of the channel in general at least once, I try to keep questions rare to not annoy, but whenever I get here with a question you are all so full of help - even with FF around
[13:23] <xnox> wgrant, ack.
[13:24]  * xnox grabs coffee
[13:30] <cjwatson> ogra_: I haven't done any conversion as yet.
[13:30] <ogra_> cjwatson, ok, thanks
[13:35] <doko> smoser, http://autopkgtest.ubuntu.com/packages/o/open-iscsi/xenial/amd64/
[13:40] <flexiondotorg_> I new package has just landed in Debian unstable that I would like to use in Ubuntu MATE 16.04.
[13:40] <flexiondotorg_> When will the sync with Debian be halted?
[13:41] <flexiondotorg_> Is there time for this to flow into the Xenial automatically?
[13:42] <cjwatson> I was planning to halt it after I get back from the pub tonight.
[13:42] <cjwatson> i.e. after the 23:00 UTC run finishes
[13:43] <cjwatson> So a package that just hit unstable will probably just about make it automatically
[13:46] <jamesh> would anyone be able to help me with a problem in the new sqlite3 upload?
[13:46] <jamesh> It has broken mediascanner, and I've left the information I've gathered at https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1546911
[13:56] <flexiondotorg_> cjwatson, Thanks. If it does make it in time I'll file a requestsync.
[13:56] <flexiondotorg_> *doesn't
[13:58] <ogra_> pitti, oh, and before i forget about it *again* ... there is bug 1547033 for you
[13:58] <doko> xnox, looks like s390x only: https://bugs.launchpad.net/bugs/1546987
[13:58] <ogra_> (purely cosmetic though)
[13:58] <xnox> doko, it is s390x only.
[14:00] <mterry> I'm seeing an odd test failure only on arm64: inside the standard python lib, tempfile.TemporaryFile() fails with "No such file or directory" when it's trying to open a file with O_CREAT...  Am I crazy or does that seem crazy...?
[14:00] <mterry> Oh... I guess that would happen if the directory it's trying to create in doesn't exist
[14:01] <xnox> pitti, cjwatson - i have a patch for britney... how does one run britney locally?
[14:01] <xnox> (teaching exuses unsatisfyable dependency about components)
[14:17] <Unit193> mitya57: Know anything about Qt5 not showing the icon in the indicator?  indicator icons of Qt5 applications in Xenial are getting the "broken icon", or little x.
[14:20] <mdeslaur> cjwatson: I'm stealing your cpio merge
[14:22] <pitti> xnox: tests/test_autopkgtest.py works straight out of a checkout
[14:23] <pitti> xnox: and sets up necessary bits; for running manually, see https://wiki.ubuntu.com/ProposedMigration/LocalSetup
[14:32] <cjwatson> mdeslaur: go for it
[14:33] <doko> jtaylor, new vim in -release
[14:36] <mitya57> Unit193, do you have an example of such application?
[14:36] <Unit193> mitya57: Dropbox (which ships its own stuff), cmst.  Using Xfce.
[14:37] <xnox> pitti, maybe that britney-indexes script should be simply committed into britney2-ubuntu branch.
[14:37] <pitti> xnox: it's more like a PoC, I'm afraid, far from production ready
[14:37] <pitti> xnox: robru has a better implementation in the CI train, if anything we should rather take his'
[14:38] <pitti> xnox: but, just write a test case and the tests will set up stuff or you :)
[14:38] <xnox> =))))
[14:42] <barry> seb128: yes, let me look into it
[14:42] <seb128> barry, thanks
[14:42] <seb128> barry, also unsure if you noticed, but software-center&co are off the iso today
[14:43] <barry> seb128: i haven't, but YAY!
[14:43] <seb128> :-)
[14:43] <barry> seb128: thank everyone who worked on this.  i'll grab a daily later today and see what's left of py2, though i suspect it'll be samba-libs
[14:45] <_hc> hey all, I checked in here last week about the Android SDK packages.  We just did a big push to get lots of it done in time for the xenial freeze, so I wanted to make sure it all gets smoothly imported before that freeze happens.  There are a couple still outstanding, like android-platfrom-frameworks-base
[14:45] <_hc> and android-sdk-meta
[14:46] <doko> barry, I started adding packages for talloc, tdb and ldb
[14:47] <barry> doko: oh!  anything i can look at or help with?  that's the next thing to attack i think
[14:47] <_hc> I'm a DD, so I can trade Debian work for Ubuntu work :)
[14:47] <seb128> barry, right, seems mostly samba-libs
[14:48] <doko> mdeslaur, just saw your cpio upload. maybe we should just promote mingw64, it's easier to let these packages drop to universe than to change everything. and there is no fear that pitti will be able to run autopkg tests on these binaries ;)
[14:48] <_hc> I spoke with cjwatson before ^^
[14:48] <seb128> but also deja-dup-backend-gvfs which depends on python-gi, but that might just be a packaging error
[14:48] <seb128> mterry, ^ do you know?
[14:48] <pitti> doko: lol
[14:48] <barry> seb128, doko i traded some emails w/a fedora guy.  he made it seem like samba-libs was a long way off, but i haven't really started looking at it in detail
[14:49] <doko> barry, I'll upload talloc
[14:49] <barry> (he said it wasn't as easy as splitting the packaging because some stuff does imports at the c level)
[14:49] <barry> doko: cool, thanks
[14:49] <mterry> seb128, hrm...  right...
[14:49] <seb128> mterry, deja-dup-backend-gvfs seems empty, is that wanted?
[14:49] <mterry> seb128, it's not a packaging error...
[14:49] <cjwatson> _hc: looking
[14:49] <seb128> mterry, if so maybe the description should state it's a transitional package?
[14:49] <mterry> seb128, it's a metapackage meant to pull in the python dependencies that duplicity will need to support gvfs backends
[14:49] <xnox> pitti, winning! it found maas -> probably built elsewhere, main package depends on a universe one.
[14:50] <mterry> seb128, but now that we pull in duplicity on the fly...
[14:50] <cjwatson> _hc: I think the main problem is that android-platform-system-core is failing to install its build-dependencies, but it's a little hard to tell since it's running into a build daemon crash that we're working on separately
[14:50] <mitya57> Unit193, dropbox is Qt 4, isn't it? Will look at cmst a bit later
[14:50] <_hc> hmm
[14:51] <cjwatson> that might just work now if I cancel and retry, so I'll give that a go
[14:51] <Unit193> mitya57: Not as of recently.
[14:51] <mterry> seb128, it's not transitional
[14:51] <_hc> something related to GCC6? That's the only one I'm aware of
[14:51] <seb128> mterry, yeah, sorry I was typing before reading your previous comment
[14:52] <cjwatson> _hc: no, https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=e2d63ebc20c8d2ef5d96db83828087505928895f
[14:52] <mterry> seb128, but I guess deja-dup should pull it in at the same time it pulls in duplicity
[14:52] <seb128> right
[14:52] <cjwatson> _hc: I don't know what you're referring to about GCC6
[14:52] <barry> seb128: gedit & rhythmbox pushed
[14:52] <mterry> seb128, let me look at a quick patch
[14:52] <seb128> mterry, thanks!
[14:52] <mitya57> Unit193, didn't know about that, nice!
[14:52] <Unit193> Not if they've bundled half the stack still. :P
[14:53] <Unit193> mitya57: Oh bah, while those two don't, vlc does show fine.
[14:54] <_hc> this is the GCC6 FTBFS that we haven't had a chance to look at, gcc6 seems far off https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811716
[14:54] <cjwatson> _hc: no, nothing to do with that, like I say this is in build-dep installation
[14:54] <cjwatson> _hc: BTW there isn't really a freeze concern here, since it's already in -proposed, but we certainly ought to get it finished off
[14:55] <_hc> (sorry, I bit slow, since I'm sick)
[14:55] <_hc> ok, good to know about proposed
[14:55] <xnox> pitti, cjwatson: so https://code.launchpad.net/~xnox/britney/deps-components/+merge/286511 is good to go imho =) tested it as best as possible outside of production infrastructure.
[14:57] <_hc> cjwatson: there are a couple less critical ones just hitting Debian/unstable now, will those make it automatically? for example android-platform-tools-base
[14:58] <cjwatson> _hc: marginal
[14:58] <cjwatson> _hc: you may have to ask for those, either using requestsync(1) or by asking an Ubuntu developer
[14:59] <_hc> shall I check in on those tomorrow, or later today?
[14:59] <cjwatson> xnox: (I'm quite unlikely to have time to review this, at least not today - been procrastinating the thing I'm actually supposed to be doing badly enough as it is)
[14:59] <_hc> just trying to figure out when the best time to ask is
[15:00] <xnox> cjwatson, no worries. it's mostly my knee-jerk reaction to rebute doko on the archive reorg proposal =)
[15:00] <_hc> we're going to be uploading a couple more packages since we have them done, but we don't expect those to make it.  But we're happy to help if y'all want them in
[15:00] <_hc> ubuntu
[15:00] <cjwatson> xnox: I don't see anything immediately odd but would be nice to spell "available" and "component-mismatches" correctly :)
[15:00] <cjwatson> (yes, most useless review ever, sorry)
[15:00] <cjwatson> _hc: it depends on dinstall cycles and such, so I think probably tomorrow
[15:00] <xnox> cjwatson, ^_^ thanks =)
[15:01] <xnox> will fix.
[15:01] <_hc> thanks!
[15:06] <kickinz1> caribou, can you review two quick package merges for me?
[15:07] <caribou> kickinz1: if they'r not overly complex, sure
[15:07] <kickinz1> caribou, thanks!
[15:08] <seb128> https://launchpad.net/ubuntu/+source/graphite2/1.3.3-1ubuntu1/+build/8214089 seems stucked, can somebody kill/restart it?
[15:08] <seb128> it's " Started 18 hours ago " but should take some minutes to build
[15:10] <cjwatson> seb128: known problem with dep-wait builds, fix in progress
[15:10] <seb128> cjwatson, ok, thanks
[15:10] <jgrimm> thanks caribou!
[15:10] <cjwatson> seb128: I've cancelled it and will retry in a bit, but will have to wait for buildd-manager to time out as launchpad-buildd will have crashed
[15:11] <seb128> ok
[15:13] <cjwatson> pitti: please could you pre-emptively bump the sbuild force-badtest to 0.67.0-2ubuntu3, same reason as before (or if you have any ideas on why armhf and s390x are failing, that would be good too)?
[15:14] <cjwatson> pitti: this is to fix the issue seb128 points out above, I want to be able to install that new sbuild on the s390x builders ASAP
[15:15] <pitti> cjwatson: at first sight it seems my custom apparmor policy to allow mounts (for chroot-in-lxc) has stopped working; perhaps lxc 2.0 has a stricter default policy
[15:16] <pitti> cjwatson: anyway, hint bumped
[15:16] <mitya57> Unit193, can you test if the official example (/usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray from qtbase5-examples) works for you?
[15:16] <cjwatson> thanks
[15:21] <Unit193> mitya57: The application icon does not, hit 'Show' and the icon appears.
[15:22] <mitya57> Unit193, where do you click Show? Show icon or Show message?
[15:23] <Unit193> Sorry, yes. 'Show Message'
[15:23] <Unit193> Eg, critical/warning/informational icons work.
[15:25] <mitya57> Well, those are not tray icons, those are notifications
[15:26] <mitya57> Unit193, do you have $QT_QPA_PLATFORMTHEME set?
[15:26] <mitya57> I.e. if you have appmenu-qt5 installed, it should set it
[15:26] <Unit193> I do not have this set, no.
[15:27] <mitya57> Ok, so D-Bus tray won't work for you :)
[15:27] <mitya57> Do you have a classic systray on your panel then?
[15:27] <Unit193> Yes.
[15:28] <mitya57> That's quite strange — the X11 tray implementation in Qt hasn't got any significant changes recently.
[15:29] <mitya57> Ok, looks like I understand what's going on.
[15:30] <mitya57> It uses the upstream D-Bus systray implementation, which is broken in Qt 5.5
[15:32] <mitya57> Unit193, can you try to install appmenu-qt5, and run some app with QT_QPA_PLATFORMTHEME=appmenu-qt5?
[15:33] <mitya57> I suppose the issue may be fixed in Qt 5.6 branch, but for now the code in appmenu-qt5 is better than upstream code.
[15:33] <mitya57> (because I wrote it :P)
[15:34] <Unit193> mitya57: Installed, logged out and back in and now it is fixed.
[15:37] <mitya57> Mirv, ^^^ do you think it will be possible to get http://code.qt.io/cgit/qt/qtbase.git/commit/?id=9c7f37e648024a8c http://code.qt.io/cgit/qt/qtbase.git/commit/?id=7ad930987da7bb1d http://code.qt.io/cgit/qt/qtbase.git/commit/?id=a4fac65938fdee74 in for Xenial?
[15:38] <mitya57> This should make Qt's own dbustray implementation much less broken.
[15:41] <caribou> rbasak : I've just reviewed the MP for moin & urlgrabber. Do you want me to proceed with accepting the merges ?
[15:42] <Unit193> mitya57: Would that have been in a Qt update?
[15:42] <Unit193> I don't suppose there's a way to force it to fallback to trayicon either?
[15:44] <mitya57> Unit193, the patches I linked will be only in Qt 5.6.1. And there is no easy way to force it to X11, unfortunately.
[15:45] <Unit193> mitya57: Bummer.  Thanks for all the help!
[15:47] <mitya57> You are welcome!
[15:48] <mitya57> Maybe if Mirv thinks that these patches are too big, we'll add a recommends on appmenu-qt5 or something like that.
[15:49] <Mirv> mitya57: if those apply cleanly to our 5.5.1, I think they would be nice to get a better solution than appmenu-qt5. do you think Debian would accept them to their 5.5 too, so that we'd sync from there?
[15:50] <Mirv> now that 5.6 is really quite clearly no-go, getting 5.5 as good as possible is the plan b
[15:55] <mitya57> Mirv, yes, they should apply to 5.5. I'll commit them to Debian (will ask Lisandro first, but I'm sure he's ok with this).
[15:58] <Mirv> ok, sounds good
[16:03] <caribou> kickinz1: just saw one thing about your MP : shoudn't they be against ~ubuntu-server-dev/ubuntu/+source/urlgrabber:ubuntu/devel and not ~ubuntu-server-dev/ubuntu/+source/urlgrabber:debian/sid ???
[16:03] <caribou> (ubuntu/devel and not debian/sid) Not sure of the process here
[16:03] <kickinz1> caribou, yes but I got OOPs when doing so.
[16:04] <kickinz1> caribou, maybe I did it wrong, I'll forward you the launchpad reply.
[16:05] <superm1> sarnold: just wanted to double check, fwupd and fwupdate updated security checks for their MIR's are on you and tyler's list at some point still right?
[16:06] <tyhicks> superm1: they are
[16:06] <superm1> ok thanks
[16:06] <tyhicks> superm1: we have one in from of them right now
[16:06] <tyhicks> superm1: sarnold will be starting on that one today
[16:09] <doko> barry, python3.5-venv still depends on python-pip-whl. is this correct?
[16:10] <barry> doko: oh, thanks for reminding me.  i need to make sure that python3 -m venv still works.  but yes, it should dep on python-pip-whl
[16:10] <doko> ok
[16:10] <willcooke> barry, u-s-c is gone
[16:11] <barry> willcooke: i saw that in today's daily and seb128 mentioned it earlier.  \
[16:11] <barry> willcooke: \o/
[16:11] <barry> thanks very much
[16:11] <willcooke> glad to be of service.  kudos to seb128, Laney and robert_ancell (amongst others)
[16:18] <doko> barry:
[16:18] <doko> Trying easy from autohinter: python-pip/8.0.2-7 six/1.10.0-3 distlib/0.2.2-1 python-colorama/0.3.6-1 requests/2.9.1-3 python-urllib3/1.13.1-2 html5lib/0.999-4
[16:18] <doko> start: 139+0: a-31:a-18:a-17:i-16:p-19:p-19:s-19
[16:18] <doko> orig: 139+0: a-31:a-18:a-17:i-16:p-19:p-19:s-19
[16:18] <doko> easy: 160+0: a-40:a-20:a-19:i-18:p-21:p-21:s-21
[16:18] <doko>     * amd64: dh-virtualenv, python-tox, python-virtualenv, python3-venv, python3-virtualenv, python3.5-venv, tox, virtualenv, virtualenvwrapper
[16:19] <barry> doko: it hasn't picked up tox 2.3.1-3 yet
[16:20] <doko> ahh, ok
[16:21] <doko> toxic
[16:21] <barry> that would be a good name :)
[16:22]  * doko shouldn't test build on i386 to fix 64bit issues ...
[16:24] <bartolo> hi, (disclaimer I'm not sure that this is the right channel) I'm trying to build libunity on fedora I've set --prefix=some_install_path during the autogen phase but when I run make install it's trying to install some python modules under /usr http://pastebin.com/HjW1mtq0
[16:25] <bartolo> do I have to set something else?
[16:27] <hallyn> xnox: https://code.launchpad.net/~xnox/britney/deps-components/+merge/286511  oh, nice
[16:28] <hallyn> would be really nice if we had a locally runnable tool that ppl doing merges could use :)
[16:28] <hallyn> or if ppas did that check
[16:28] <xnox> hallyn, it only deals at escuse level. E.g. missmatched things in release pocket already are not considered bad.
[16:28] <xnox> hallyn, there is $ check-mir tool for local usage in unpacked package.
[16:29] <xnox> hallyn, for PPAs, you should change the PPA settings to "use components as in Ubuntu release", instead of "use all available components"
[16:29] <hallyn> rharper: ^ check-mir, the good man says
[16:35] <frafu> Hi, We just released a new minor version of Onboard, the default on-screen keyboard in Ubuntu. This release is targeted at xenial. I also prepared the debianisation based on the Onboard package currently in xenial. Could anybody please have a look at it before feature freeze kicks in? Thanks in advance.
[16:36] <frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1547054
[16:40] <caribou> kickinz1: then I'm not too confortable with merging it as is, I'll put a note in the MPs
[16:41] <cjwatson> _hc: where's etc1tool meant to come from?
[16:42] <_hc> cjwatson: android-platform-development, I'm wrestling with that one now
[16:42] <cjwatson> _hc: also, i386 binaries in android-sdk-meta depend on dexdump, dmtracedump, and hprof-conv, which only seem to be available on amd64
[16:42] <_hc> odd
[16:42] <cjwatson> _hc: those two things are your current xenial blockers
[16:42] <_hc> thanks
[16:43] <cjwatson> _hc: in fact, they seem to block migration to Debian testing as well, basically the same output
[16:43] <_hc> yeah, we've been focused on getting this whole chunk in place, now we're circling back and checking in on all the issues
[16:43] <amorphous> hello, do you know if it's possible to add a i386 lib as a dependency to a amd64 metapackage that also includes the amd64 version of the same library?
[16:55] <frafu> seb128: Could you please have a look at the new upstream release of onboard, before feature freeze gets active, for it to make it into xenial? Thanks in advance.
[16:55] <frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1547054
[17:28] <rharper> hallyn: nice!  thanks!
[17:28] <rharper> hallyn: and I suppose I could also change the apt sources in sbuild to only pull from  main
[17:29] <nacc> jamespage: look at the possible demotion/sync of fop, which makes more sense: xmlto not recommending fop, or moving the recommendation to suggests? And would i move the entire (dblatex | fop) to suggests? in order to maintain that semantic (of dblatex being preferred)
[17:29] <hallyn> rharper: true
[17:45] <stgraber> pitti: any known problem with self-retries on autopkgtest?
[17:45] <stgraber> pitti: I requested a retry of LXD a couple of hours ago and it's not showing up in the queue or anywhere
[17:45] <stgraber> I'll go trigger one by hand from snakefruit now because I really want it to migrate
[17:46] <seb128> barry, just saw your font email, try downgrading/upgrade freetype, that had a non trivial update yesterday
[17:47] <stgraber> pitti: worked immediately when requesting from snakefruit, so I guess there's something wrong with the webapp somehow
[17:48] <mterry> stgraber, I have problems too -- I get "Log in with SSO" button, but that doesn't seem to take, or doesn't rebuild it anyway
[17:49] <seb128> mterry, just asking because I'm too lazy to check by myself, but does your deja-dup "install on demand" enable universe if needed?
[17:49] <stgraber> mterry: yup, exact same behavior here
[17:49] <mterry> seb128, aw crap no
[17:50] <jdstrand> tyhicks: I think we need to get the unpec patch into ubuntu rather quickly. the ntp bug is going to be quite annoying for people
[17:50] <seb128> mterry, k, because duplicity wants to go to universe according to component mismatch
[17:51] <seb128> mterry, we could seed it to supported to avoid that
[17:51] <mterry> seb128, yeah I think we should -- conceptually it's just as supported as before
[17:51] <tyhicks> jdstrand: ack - let me finish up some things and prepare a debdiff
[17:51] <mterry> seb128, I can do that
[17:51] <jdstrand> tyhicks: ah, ok, even better. I could do it too if you prefer
[17:51] <seb128> mterry, thanks
[17:52] <tyhicks> jdstrand: I was planning on doing it today so I can do it now
[17:52] <mterry> seb128, didn't even consider needing to enable universe, in case python-gi gets dropped eventually too...
[17:52] <mterry> seb128, but that seems to still have plenty of rdeps
[17:53] <seb128> mterry, good that I mentioned it then ;-) I think it's safe to seed them for this cycle, depending if you want to spend more time on the code or not
[17:53] <mterry> seb128, seeding makes sense -- I want them to remain in main
[17:55] <seb128> mterry, wfm
[18:06] <carldani> Hi!
[18:08] <carldani> I'm one of the upstream maintainers of flashrom, and I'd like to have a non-ancient version of flashrom in Ubuntu. Upstream has flashrom 0.9.9-rc1, and Ubuntu is still using some source snapshot shortly after on 0.9.7.
[18:08] <carldani> Our debian package maintainer is currently busy, so updating the debian package in time for the import freeze unfortunately won't work out.
[18:08] <jamespage> nacc, one sec - have my head in a debug
[18:08] <nacc> jamespage: np, would be good to sync with you when you're free
[18:09] <jamespage> nacc, fop is now listing for demotion - doko just let me know
[18:09] <jamespage> it was being help by other things trying to get into main
[18:09] <carldani> Is there a process of pushing current flashrom from our ppa to Ubuntu instead of relying on a debian import?
[18:10] <carldani> Or am I totally in the wrong IRC channel and should ask elsewhere?
[18:10] <nacc> jamespage: ah ok, good to know -- i think the sync will require one other merge, though, which i've documented in that bug
[18:15] <rbasak> carldani: yes, you can ask for sponsorship directly for this kind of case.
[18:15] <rbasak> carldani: it needs to land today though :-/
[18:15] <doko> nacc, needs demotion first
[18:16] <carldani> rbasak: ok, so whom can I aks for sponsorship?
[18:16] <rbasak> carldani: you can create a bug with a reference to the source package you want uploaded and subscribe ~ubuntu-sponsors to it
[18:17] <nacc> doko: right, demotion first then sync makes sense to me ... i wasn't aware of the ongoing demotion and it seemed like a few other packages would be affected by component-mismatches after demotion
[18:17] <rbasak> carldani: that will place it in the sponsorship queue. However it's a bit late for sponsorship requests given today is feature freeze. Do it anyway though, the release team may allow it to be late.
[18:18] <rbasak> I would look, but I'm working through a queue of sponsorship requests for my team right now.
[18:18] <carldani> rbasak: our debian packager had told us he'd have the debian package ready yesterday, so I thought I could just use the automatic debian import... that's why I'm late
[18:19] <carldani> rbasak: thanks for the hint, will do the sponsorship request
[18:21] <dasjoe> cking: #zfsonlinux is a bit stirred up due to mjg59's tweet about Canonical breaking CDDL/GPL by shipping ZFS with xenial, either as binary modules or as source. Maybe somebody could clarify Canonical's position here
[18:22] <barry> seb128: cool, let me try that, thanks!
[18:23] <cking> dasjoe, http://blog.dustinkirkland.com/
[18:24] <dasjoe> cking: oh right, kirkland to the rescue once again
[18:24] <seb128> barry, mdeslaur replied the same on the list but pointing an actual change
[18:25] <barry> seb128: i see that now.  i'll respond there, thanks
[18:25] <seb128> yw!
[18:26] <dasjoe> cking: I was not aware of you guys shipping zfs.ko, I assumed it would still be built at the customer's box by DKMS
[18:26] <mdeslaur> barry: does it look _bad_, or just different?
[18:27] <barry> mdeslaur: that's a difficult question.  it's readable, but i had it finely tuned for my desktops and it definitely looks worse now
[18:27] <cking> dasjoe,  spl + zfs
[18:29] <seb128> barry, mdeslaur, that's probably the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636776
[18:30] <barry> seb128, mdeslaur could be.  i don't see it in emacs, but i use different fonts there
[18:30] <dasjoe> cking: right, just found /lib/modules/4.4.0-4-generic/kernel/zfs/zfs/zfs.ko
[18:30] <seb128> barry, that's the bug related to the commit we were reverting and stopped doing so
[18:34]  * barry reads the bug more closely
[18:50] <tjaalton> anyone else seeing sbuild-update creating empty temp files in /tmp, roughly two per chroot?
[18:52] <tjaalton> no exactly two per chroot
[18:53] <tjaalton> though this is wily.. time to upgrade I guess :)
[18:57] <robert_ancell> jsalisbury, How many kernels do you have for bug 1498667? Happy to bisect if I have a list of .debs to try
[18:59] <jsalisbury> robert_ancell, since v4.2-rc1 does not have the bug, we need to test some additional release candidates to find the first one that does.  They can all be downloaded from:
[18:59] <jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:59] <jsalisbury> robert_ancell, Once we know the first bad kernel and last good kernel, we can then bisect between them.
[18:59] <robert_ancell> jsalisbury, cool, I'll run through those
[18:59] <jsalisbury> robert_ancell, great, thanks
[19:19] <barry> mdeslaur: was there a launchpad bug related to the removal of the freetype  patch?
[19:21] <mdeslaur> barry: no, I just wondered if it was still needed since I couldn't reproduce the original use-cases and it never went anywhere
[19:21] <mdeslaur> barry: cleary you've found something that broke with it gone
[19:21] <mdeslaur> barry: put it back?
[19:21]  * mdeslaur doesn't care
[19:23] <seb128> upstream report the issue maybe
[19:23] <seb128> also different doesn't mean less good
[19:23] <barry> if it was up to me, i'd put it back. :)
[19:23] <seb128> we should probably not carry a distro change to the rendering if it's just different and not buggy in an obvious way
[19:24] <xnox> barry, screenshot? or it didn't happen =)
[19:24] <mdeslaur> heh
[19:24] <xnox> barry, is that thing still using gtk2 by the way?
[19:24] <mdeslaur> barry: you can include private stuff in those screenshots, we don't care
[19:25] <Pharaoh_Atem> rbasak: I'm a bit puzzled why the php7.0 package tests are failing
[19:25] <barry> i can definitely appreciate not wanting to carry a delta from upstream, so dropping the patch is "better" in that case, but does it look better or worse?  well, that's subjective of course, and to me, it does look worse, but it's not *unreadably* so
[19:25] <Pharaoh_Atem> I run the pkgtest commands manually and they work
[19:25] <seb128> barry, it's probably worth opening an upstream bug and see what they say
[19:26] <Pharaoh_Atem> is it because not all the a2* commands have "|| true" for the return code stuff?
[19:26] <barry> xnox: yes, it looks like claws depends on libgtk2.0-0
[19:26] <barry> mdeslaur: yeah :)
[19:27] <barry> seb128: would that be: http://freetype.org/developer.html#bug-report ?
[19:27] <barry> xnox, mdeslaur i can probably sanitize some screenshots
[19:28] <mdeslaur> barry: I think he meant upstream claws
[19:28] <barry> mdeslaur: ah, yes
[19:29] <barry> mdeslaur, seb128: i'm tempted to open a lp bug for tracking purposes, even if eventually it gets closed.
[19:29] <mdeslaur> sure
[19:29] <barry> (on freetype)
[19:29] <Pharaoh_Atem> grr
[19:29] <seb128> barry, mdeslaur, depends if it's only that program
[19:29] <Pharaoh_Atem> pdebuilder makes me want to stab someone :/
[19:29] <seb128> barry, also I guess nobody is ever going to read your bug on launchpad
[19:29] <seb128> we don't really have a maintainer for freetype
[19:32] <barry> sucks to be me :)
[19:32] <barry> mdeslaur: do you happen to have a link handy to the patch that was removed?
[19:33] <mdeslaur> barry: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/freetype/wily/view/head:/debian/patches-freetype/revert_scalable_fonts_metric.patch
[19:33] <barry> mdeslaur: thanks
[19:50] <barry> mdeslaur, seb128 LP: #1547196 FTR
[19:50] <mdeslaur> barry: thanks
[19:54] <doko> barry, talloc, tdb, ldb in the archive
[19:57] <barry> doko: thanks
[20:01] <nacc_> rbasak: any guidance on why `pull-lp-source -d cakephp-instaweb` is failing?
[20:01] <nacc_> it seems to not be finding the source package in launchpad?
[20:02] <rbasak> nacc_: looks like it doesn't exist in Xenial.
[20:02] <rbasak> nacc_: https://launchpad.net/ubuntu/+source/cakephp-instaweb/+publishinghistory top entry
[20:03] <ericdc> I have a embedded board (armhf) running kernel 2.6.32. I would like to use the Ubuntu Core 14.04 as my root filesystem. When booting I get the following errors "Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory", "init: plymouth-upstart-bridge main process (434) terminated with status 1". How can I get it working?
[20:04] <nacc_> rbasak: ah ha! that's what i was looking for
[20:04] <nacc_> ok, so can drop it from the list
[20:04] <nacc_> rbasak: thanks!
[20:05] <sarnold> ericdc: a kernel that ancient is unlikely to work well with a more modern userspace. You'll probably play whackamole with a dozen more of those sorts of things
[20:06] <rbasak> nacc_: np
[20:07] <ericdc> sarnold: Yes I know but unfortunately that is my only option. Do you think 12.04 would be better?
[20:08] <sarnold> ericdc: maybe; 12.04 was on 3.2, it seems closer..
[20:18] <Pharaoh_Atem> rbasak: do I need to do something to make it so I can build the php7.0 package from pbuilder? I get this error which stops the builder: http://fpaste.org/325105/58266731/
[20:20] <nacc_> Pharaoh_Atem: does your env have universe?
[20:23] <rbasak> Pharaoh_Atem: I use sbuild usually, which is closer to what Launchpad buildds do AIUI. sbuild needs --resolve-alternatives to build php5.6. Maybe pbuilder also needs something similar with php7.0?
[20:25] <Pharaoh_Atem> I didn't know there's a different tool
[20:26] <Pharaoh_Atem> I've been fighting pbuilder for an hour and a half now
[20:26]  * Pharaoh_Atem hopes sbuild is as nice as mock
[20:26] <Pharaoh_Atem> at this point, I'm trying to figure out what is causing the autopkgtests for php7.0 to fail
[20:27] <Pharaoh_Atem> because by all rights, they should be passing
[20:27] <Pharaoh_Atem> running the actions manually succeeds in my VMs
[20:29] <Pharaoh_Atem> rbasak: how do I use sbuild?
[20:32] <rbasak> Don't expect sbuild to be much better.
[20:32] <sarnold> sbuild's just as cranky, it'sjust closer to what the bujilders do..
[20:32] <sarnold> https://wiki.ubuntu.com/SimpleSbuild
[20:32] <rbasak> sarnold beat me to it :)
[21:00] <jamespage> nacc_, hey - looking through junit4 merge you proposed - its showing alot of merge conflicts?
[21:03] <nacc_> jamespage: hrm, i only see 3 files with conflicts? changelog ones are expected (I think), as we're fastforwarding the debian versions. control is due to the variables changing, and d/p/series is because they added some patches in debian
[21:03] <nacc_> sorry, i should have clarified that in the merge request
[21:03] <nacc_> jamespage: do you see somethig different?
[21:04] <rbasak> jamespage: LP invents MP conflicts because it thinks we'll be merging rather than rebasing, if that's what you're seeing. Effectively LP's web UI diff is useless, unfortunately :-/
[21:05] <nacc_> rbasak: they are helpful to me, to make sure what i'm suggesting makes sense, but yeah
[21:05] <rbasak> Oh, OK. I couldn't make sense of them :-(
[21:06] <nacc_> e.g., https://code.launchpad.net/~nacc/ubuntu/+source/junit4/+git/junit4/+merge/286553
[21:06] <nacc_> it *sort of* makes sense :)
[21:07] <nacc_> and it matches what happens if i try to merge locally, which is a good check that the trees match
[21:07] <rbasak> Hmm.
[21:08] <rbasak> I think I see, yes.
[21:08] <nacc_> jamespage: it might help to see the bit at https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L144
[21:08] <nacc_> as to what you'd actually be doing to the usd git tree in response to accepting the merge
[21:09] <Pharaoh_Atem> rbasak: I'm just wondering if I should just make a git patch and have someone test it while I try to figure out this weird stuff
[21:10] <rbasak> Let me update that spec with more information for sponsors.
[21:10] <rbasak> Done - note that broke line numbers
[21:10] <nacc_> rbasak: yep, nice
[21:11] <rbasak> jamespage: nacc_'s line is now https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L154
[21:11] <cjwatson> rbasak: Makes perfect sense :-)  You can always rebase and push the results first.
[21:11] <rbasak> jamespage: general information for sponsors starts at https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION#L144
[21:11] <cjwatson> (Which is useful anyway because then merge detection will work)
[21:11] <rbasak> cjwatson: what do you mean by "first"? Before sending the MP?
[21:11] <cjwatson> rbasak: LP isn't "inventing" the MP conflicts, they're what git gives us when trying to merge.
[21:12] <rbasak> cjwatson: sure, except that that's not exactly what we're using the MP for. We're filing a merge proposal because Launchpad doesn't do "rebase proposals" :)
[21:12] <nacc_> cjwatson: right, but the process doesn't actually use merges
[21:12] <cjwatson> rbasak: Well, drop "first".  I mean that if one were to rebase that branch and push the result to the source of that MP, then the conflicts would go away (but it would likely entail resolving the very same conflicts when rebasing, so I really don't see the complaint here)
[21:14] <rbasak> cjwatson: I'm not sure that applies here. What we want is an "--onto" type rebase proposal.
[21:14] <cjwatson> rbasak: Oh, no, I see what you mean now, you are intentionally not including the Ubuntu commits in this
[21:14] <rbasak> Right
[21:14] <cjwatson> I have to say I would just not do it that way.  The Ubuntu branch is a published branch and should therefore be fast-forwarding.
[21:14] <cjwatson> Otherwise it's painful for people following that branch.
[21:15] <cjwatson> Non-fast-forwarding branches are OK for work in progress and such, but a bad idea for long-lived published branches.
[21:15] <rbasak> I would argue that when we do an Ubuntu "merge", and document the changelog as we do, then what we're doing is exactly an --onto debian/sid rebase .
[21:15] <cjwatson> I can see how you get there, but it's going to be painful.
[21:15] <rbasak> I suppose we could artificially make the old ubuntu/devel tip a parent of the final commit though.
[21:16] <cjwatson> I would do something like that, yes.
[21:17] <cjwatson> It will not only work better with LP, but it will be less confusing for misc people following the branch.
[21:18] <rbasak> I'll mull over this. I do want to keep the "rebase" workflow, but we can maintain that by artificially constructing the merge commit over the top I think.
[21:18] <cjwatson> The "artificially ..." bit you suggest is similar in some ways to what git-dpm does.
[21:18] <rbasak> Yes, I see the similarity.
[21:19] <cjwatson> I've called it "pseudo-fast-forwarding" in the past; I don't know if that terminology makes sense to anyone other than me
[21:19] <rbasak> pretend-fast-forwarding maybe :)
[21:20] <cjwatson> I can see why a rebase-type workflow is worthwhile, for pretty much exactly the same reasons they're worthwhile in git-dpm.
[21:20] <rbasak> tbh, I don't see the benefit right now. I understand that it makes it difficult for others to follow ubuntu/devel automatically, but that doesn't bother me so much. OTOH, I see no harm in this as a solution.
[21:20] <rbasak> (doens't bother me so much because we don't really have a need to do it)
[21:20] <rbasak> I appreciate the suggestion though.
[21:20] <cjwatson> I think it's something best solved early before it gets too baked into everyone's tools to be fixable
[21:20] <rbasak> With some tooling sorted out, it would be relatively trivial.
[21:21] <rbasak> Agreed - we definitely want to resolve this before writing tooling.
[21:23] <rbasak> And I'm in favour right now unless I think of some reason to object.
[21:23] <rbasak> (or someone else does)
[21:23] <rbasak> nacc_: any opinion?
[21:23]  * doko hates d-shlibs
[21:24] <Pharaoh_Atem> doko: I can commiserate
[21:24] <nacc_> rbasak: i think having an ubuntu/devel that can be a reasonable 'master' to follow is probably a good goal
[21:25] <nacc_> rbasak: so i'd be ok with an artifical merge
[21:28] <doko> rbasak, online? please see https://bugs.launchpad.net/ubuntu/+source/ruby-net-http-persistent/+bug/1546948
[21:28] <doko> the requesting package bundler is unowned, however anything-ruby  else is subscribed by server. would you mind to subscribe=
[21:28] <doko> ?
[21:33] <rbasak> Looking
[21:36] <rbasak> doko: how come bundler has no team subscriber, or am I missing something?
[21:36] <rbasak> And I don't immediately see what seed is causing bundler to be pulled into main.
[21:37] <doko> rbasak, ENOCLUE, however how can we resolve this?
[21:37] <doko> no seed, just ruby
[21:37] <rbasak> (is there any easy way of doing that? http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/rdepends/bundler/bundler doesn't seem to recurse on reverse b-ds)
[21:37] <rbasak> doko: we seed ruby but I didn't think we wanted to seed rails.
[21:38] <rbasak> (and I don't understand how ruby would pull in rails)
[21:38]  * rbasak wonders if he's going backwards
[21:38] <doko> rbasak, this is not rails, but the ruby build system
[21:39] <doko> to some extent we just have to support these external build systems
[21:39] <doko> for python, barry even encourages this
[21:40] <rbasak> For the Ruby world, our (server team) perception is that users want the interpreter in main, but get all their deps from rubygems.org directly, so no need for us to maintain them.
[21:40] <rbasak> So I'd prefer to break the dependency tree where possible
[21:41] <doko> rbasak, feel free to demote the others. I looked, and I think it's not possible unless you disable all tests
[21:41] <rbasak> doko: OK. I think I want to understand the dependency tree a little better before I can give you an answer.
[21:42] <doko> rbasak, thanks for looking. I'll read scroll back, but I'm afk now
[21:42] <rbasak> OK
[22:04] <slangasek> nacc_: hi, do you want to have a look over the new components-mismatches on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed that reference php7.0, and handle the MIRs for them please?
[22:05] <slangasek> nacc_: (or, if appropriate, drop the build-dependencies from php7.0)
[22:08] <nacc_> slangasek: yes, i will take a look
[22:09] <slangasek> nacc_: cheers :)
[22:11] <nacc_> slangasek: is it just me or are many of the links on https://wiki.ubuntu.com/MainInclusionProcess dead?
[22:12] <slangasek> not that I was aware of, let's see
[22:12] <slangasek> which ones?
[22:12] <nacc_> i guess it's jsut https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[22:13] <nacc_> actually throwing an error
[22:13] <nacc_> 500
[22:16] <teward> who do i prod about package removals, if i've had such a request sitting for a while?  it's not in main, though, it's a Universe package...
[22:17] <slangasek> nacc_: ok - that page loaded for me, so the problem is intermittent
[22:18] <slangasek> teward: ~ubuntu-archive; have you subscribed them to the bug report? we may be behind on processing
[22:18] <slangasek> teward: if you want to point me at it, though, I don't mind queue jumping for removals :)
[22:18] <teward> slangasek: yeah i've had them subbed for a while
[22:18] <teward> slangasek: it may need considered given that it's the .deb LetsEncrypt client, which is still under development I think (and I would NOT say is ready for inclusion in an LTS if it's still under active / rapid development)
[22:18]  * teward grabs the bug number
[22:19] <teward> though it encompasses the removal of two source packages and binaries from Xenial and a blacklist
[22:19] <slangasek> ah, that kind of removal, hmm
[22:19] <teward> slangasek: https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1535101
[22:20] <teward> slangasek: indeed.  not related to the images/spins, hence the question
[22:20] <slangasek> teward: does the package have a blocker bug in Debian preventing it from reaching testing, also?
[22:20] <teward> though been in there since... wow, exactly one month ago
[22:20] <TheMuso> Is there an archive admin I can bribe to approve a new package for me in the new queue so I can get a MIR filed for it? a11y-profile-manager is the source package, there are a few versions, 0.1.3 is the newest.
[22:21] <teward> slangasek: no, not that I can tell, but judging that it is ONLY in unstable and testing, i'm not sure if it impacts anything
[22:21] <nacc_> slangasek: ha, wasn't on the vpn :)
[22:21] <slangasek> teward: if it's in testing, that means Debian has not judged it unfit for release at this point; so I would prefer to see discussion about such a blacklist on ubuntu-devel first
[22:21] <teward> the thought in my mind, though, is if they release 0.5.0 and it has enough changes to obsolete 0.4.0, then it's stuck in our level of being supported and dead
[22:21] <teward> slangasek: ACK, i'll take it there
[22:22] <teward> or just close it as "Invalid" until people start whining later, and watch the packages
[22:23] <teward> which is infact what I did heh
[22:35] <jamespage> rbasak, sorry - I missing something - can I just build the source package directly from the git repo?
[22:35] <jamespage> all of the stuff I do in git is based around gbp so includes pristine-tar and upstream branches...
[22:35] <jamespage> this appears to diff from that
[22:41] <nacc_> slangasek: that page mentions allowing one MIR bug and tasks for the various packages. Does that need the full Availability/Rationale/etc for each such package? Just in a comment for each one?
[23:02] <nacc_> slangasek: another question, it seems like basically the php5.6 and php7.0 deps are the same -- is that a suitable rationale package wise? Or do I need to go through each and figure it out? that is, did some packages possibly move to universe because php5 went to universe just now?
[23:05] <nacc_> ah, nm, i think i figure that out
[23:11] <rbasak> jamespage: yes, just build a source package from the git tree and you can pretend there is no new process. You'll need to grab the orig tarball using pull-debian-source -d <package> (for example) for a merge though, because there is no pristine-tar branch.
[23:25] <kees> xnox: got a weird question for you -- why would the surprise appearance of dm-0 during upstart boot cause upstart to shut down they system?
[23:33] <slangasek> nacc_: there were no packages demoted yet related to php5; so the things shown on components-mismatches now (as opposed to before I promoted php-defaults and php7.0) are new dependencies relative to php5.
[23:35] <slangasek> nacc_: oh, mind you, there may be newer versions of packages in -proposed that I haven't promoted yet, oops.  So http://people.canonical.com/~ubuntu-archive/component-mismatches is fairly accurate, Phttp://people.canonical.com/~ubuntu-archive/component-mismatches-proposed has noise that I need to fix
[23:35] <nacc_> slangasek: ok, thanks!
[23:42] <nacc_> slangasek: ok cool, testing it now, but i think i've got a build that just drops all the deps that are not in main ... similar to what was done for php5
[23:43] <nacc_> slangasek: will work on the MIR request correspondingly
[23:43] <slangasek> ah, great :)
[23:43] <slangasek> if you're dropping the deps not currently in main, then no MIR needed
[23:43] <nacc_> ok, should i just file a bug and post a debdiff? or how will that work?
[23:43] <slangasek> yes
[23:43] <nacc_> ok
[23:43] <nacc_> i should say all but dh-php can be dropped
[23:43] <nacc_> dh-php should be promoted to main too, though
[23:44] <nacc_> as it replaces dh-php5, currently in main
[23:44]  * slangasek nods
[23:44] <nacc_> so no MIR necessary? just make it clear in the bug that the outstanding dep is going to be promoted as well? or should I do a MIR for dh-php?
[23:48] <slangasek> nacc_: I will promote dh-php and demote dh-php5, no MIR needed
[23:49] <nacc_> slangasek: ok thanks
[23:50] <slangasek> nacc_: basically, MIRs are only needed for new code, not for new upstream versions of existing code under a new name - *unless* you're asking for two versions to be carried in main in parallel
[23:51] <slangasek> you just have to get an AA with enough context to make the swap for you
[23:51] <slangasek> now, how long should it take to build pkg-php-tools?
[23:51] <nacc_> slangasek: ah i see, that makes total sense
[23:51] <nacc_> slangasek: i don't think it should take long, iirc
[23:51] <slangasek> ok then something got stuck on the buildd
[23:52] <nacc_> hrm, let me run it again now to be sure
[23:52] <slangasek> nah, definitely a buildd problem
[23:52] <sarnold> (note that almost no one wants two versions of something to be in main in one release at once. so have a good reason before asking for that. :)
[23:53] <slangasek> it's gone from pointlessly spinning on 'building' to pointlessly spinning on 'cancelling build'
[23:53] <nacc_> sarnold: fair enough :)
[23:53] <nacc_> slangasek: ok :)