[00:03] <xevious> nacc: phpdox 0.10.1 introduced namespaced PHPUnit classes. The latest tagged version is 0.11.0.
[00:04] <xevious> I've got a loose definition of calling it a day.
[00:05] <xevious> There's a 0.10.1 package in sid: https://packages.debian.org/source/sid/phpdox
[00:05] <nacc> xevious: i've uploaded 0.11 already
[00:05] <nacc> xevious: it's in bionnic-proopsed
[00:05] <xevious> hah
[00:06] <nacc> xevious: they are wedged (i just checked, thanks for the poke) on php-phpdocumentor-reflection
[00:06] <nacc> looking at it now
[00:08] <nacc> xevious: looks like it needs an update too
[00:09] <nacc> xevious: heh, 1.1.0 packaged, 3.0.0 released upstream
[00:09] <nacc> sometimes Debian
[00:09]  * nacc shakes fist
[00:11] <xevious> I wonder how strongly people would object to letting PHP project .deb packages contain a vendor folder that's created by running `composer install` during `debuild`.
[00:11] <nacc> well, i mean we use composer
[00:12] <nacc> the problem is the composer.json in 1.1.0 is so solld
[00:12] <nacc> 8old
[00:12] <nacc> bah, old
[00:12] <xevious> I mean instead of handling dependencies via dpkg dependencies.
[00:12] <nacc> xevious: so you mean shipping all your dependencies in the deb?
[00:12] <nacc> i think that would be expressly rejected
[00:12] <xevious> I think so, too.
[00:13] <nacc> i think debian/ubuntu would rather drop the php packages
[00:13] <nacc> now that cmoposer exists :)
[00:13] <xevious> Just having packages for the PHP interpreter and extensions would be a-ok with me.
[00:14] <nacc> yeah, that seems lilke a 'better' future
[00:14] <nacc> but i'm not sure we can do that for 18.04
[00:14] <nacc> maybe 20.04 :)
[00:14] <xevious> Yeah, that's definitely too much for 18.04.
[00:15] <nacc> and reallly, i'm hoping debian will pick up some of this 'slack'
[00:15] <xevious> Debian's PHP ecosystem is heavily tied to PECL/PEAR, which hardly anyone in the PHP community is using any more.
[00:15] <nacc> e.g., start dropping horde
[00:16] <xevious> Yeah, Horde's got to go.
[00:17] <xevious> I hope there's some activity on this front soon: https://wiki.php.net/rfc/deprecate-pear-include-composer
[00:18] <nacc> xevious: yeah that would make sense to me
[00:18] <nacc> so much of PECL is cruft
[00:20] <xevious> I agree with deprecating PEAR in that RFC, but I'm not sure about outright including Composer in the PHP core. I think it's doing a good job, but don't want to reject the possibility of something better coming along.
[00:20] <nacc> yeah, i'm not sure why it needs to be 'in' the core
[00:20] <nacc> but i'm not reallly a php user or developer
[00:20] <nacc> just stuck in this swamp :)
[00:27] <xevious> My job is all over the place. A pretty even mix of PHP, Python, JS, C, C++, C#. Sprinkle in a bit of Bash, Ruby, Assembly, ASL/DSL, and packaging for almost all platforms.
[00:29] <xevious> I think you're spot-on with calling it a swamp. Getting rid of the PHP applications and focusing on the interpreter and extensions would make it much easier to maintain.
[00:30] <xevious> It'd be interesting to monitor how often the PHP application packages are actually used.
[00:30] <cjwatson> There are probably some hot spots, like Icinga
[00:30] <cjwatson> I imagine popcon output in Debian would be helpful
[00:32] <nacc> cjwatson: yeah that's a good point
[00:35] <xevious> So, that brings me back around to my first suggestion... Most modern PHP applications manage their dependencies with Composer: have their packages put their source in /usr/lib/packagename (with a complete ./vendor hierarchy) and create /usr/bin symlinks for any `bin` entries in the composer.json.
[00:36] <xevious> It'd lead to duplicate files, but it would allow different PHP applications to depend on different versions of a library.
[00:36] <nacc> xevious: yeah, basically what snaps do for applications
[00:36] <xevious> Exactly
[00:38] <xevious> It'd be a small amount of bloat (bytes are cheap these days) in exchange for drastically simplifying the packaging process for PHP on Debian/Ubuntu.
[00:46] <xevious> nacc: Have you heard back about mcrypt?
[00:46] <nacc> xevious: not yet
[00:47] <xevious> If PHP upstream is abandoning it, it seems silly to go through the effort of packaging the PECL version.
[00:49] <xevious> Is there a proper venue for polling Ubuntu Server users about things such as "Can we remove Horde? Does anyone actually care?"
[00:49] <blahdeblah> horde == burn it with fire :-)
[00:52] <sarnold> mcrypt deserves the same inferno, right?
[00:56] <nacc> xevious: i'd start with ubuntu-server@lists.ubuntu
[00:57] <Unit193> sarnold: Except, I thought I needed that for something, but for the life of me can't remember what!
[00:59] <xevious> sarnold: Yeah. Projects still using mcrypt need to update and get with the times.
[09:12] <cpaelzer> hmm - all x86 builders seem to be locked in "cleaning"
[09:13] <cpaelzer> is there another maintenance change going on or do the just need some help to get out of that state?
[09:16] <cjwatson> probably just the latter.  poking
[09:18] <cpaelzer> I see them turn idle and picking up jobs again, thanks cjwatson
[10:02] <seb128> could somebody here trigger an Ubuntu/bionic iso build?
[10:02] <seb128> the daily one built a bit before some seed changes we want to try were in place
[10:04] <Laney> ok
[10:05] <seb128> Laney, thx!
[10:45] <tseliot> ginggs: I have just uploaded 390.25-0ubuntu1~ppa1.4, and the upgrading issues should be gone. Please test it, if you can
[11:07] <ahasenack> hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
[11:07] <ahasenack> python-sss is in main, that's the py2 version
[11:07] <ahasenack> python3-sss is in universe
[11:07] <ahasenack> these python3?-sss packages are produced by the sssd source itself
[13:29] <tarzeau> how to get software mentioned in "Software" ?
[13:30]  * tarzeau would like to suggest something for "Audio Creation & Editing": klystrack, protracker, schismtracker, milkytracker
[13:31] <tarzeau> and how come, in Games, "Mr Boom" has a "No screenshot provided"?
[13:32] <tarzeau> and the "Fonts" section is half-screen empty...
[13:33] <tarzeau> Education & Science, Astronomy: is missing saods9
[13:34] <juliank> tarzeau: saods9 does not provide any appstream data
[13:35] <juliank> same for everything else you mention probably
[13:35] <tarzeau> how, and who is one supposed to add appstream data?
[13:35] <jbicha> https://www.freedesktop.org/software/appstream/docs/
[13:35] <jbicha> very few fonts provide AppStream metadata
[13:35] <tarzeau> is that in the package? or external?
[13:36] <juliank> Summary: AppStream data is an XML file to be provided by upstream to be shipped in packages.
[13:36]  * tarzeau reads up on given url
[13:36] <juliank> in /usr/share/metainfo/%{id}.metainfo.xml,
[13:36] <juliank> where %{id} is a unique identifier
[13:36] <sladen> thought it used to also fetch from  http://screenshots.debian.net/  or is that out of date
[13:36] <jbicha> tarzeau: also https://wiki.debian.org/AppStream/Guidelines
[13:36] <tarzeau> sladen: mentioned things have screenshots.d.n
[13:36] <juliank> for example, /usr/share/metainfo/org.gnome.Calendar.appdata.xml
[13:36] <tarzeau> thanks for the links, /me will try to improve
[13:37] <juliank> screenshots have to be provided alongside the appstream metadata
[13:37] <juliank> unless someone patched something into gnome-software to do something with screenshots
[13:37] <tarzeau> jbicha: does debian use the appstream meta data, anywhere?
[13:37] <jbicha> you can add AppStream metadata downstream in the packaging but forward upstream if you can (I did this for Cantarell)
[13:37] <juliank> sure
[13:38] <jbicha> some fonts don't really have an active upstream though
[13:38] <juliank> and yes, Debian uses AppStream
[13:38] <tarzeau> where?
[13:38] <juliank> tarzeau: All the stuff in http://ftp.de.debian.org/debian/dists/unstable/main/dep11/ comes from it
[13:38] <jbicha> tarzeau: Debian GNOME installs the GNOME Software app by default. That app only works with AppStream
[13:38] <jbicha> there is also the Discover app for KDE users
[13:38] <tarzeau> oh, i've never used the gnome software app on debian (or any kind of gnome software at all, actually)
[13:39] <tarzeau> jbicha: never heard of that, but will try once i visit a kde user
[13:39] <jbicha> what desktop do you prefer?
[13:39] <tarzeau> jbicha: amiwm, or wmaker+gnustep software
[13:40] <tarzeau> not exactly a desktop, but with gworkspace you have a nice file manager
[13:40] <jbicha> oldschool :)
[13:40] <tarzeau> but fast! even with remote x on slow lines
[13:41] <tarzeau> the few hundred users @work use mate, unity, gnome mainly. and used to use kde but it got far less than a few years ago
[13:41] <tarzeau> some use tiling wms, ratpoison, fvwm2 still, but very rare
[13:41] <jbicha> if you like terminals, there's appstreamcli I guess
[13:41] <tarzeau> and enlightenment
[13:42] <tarzeau> desktop linux users are so rare
[13:43] <juliank> GNOME, GNOME, GNOME is the only thing I use
[13:43] <juliank> though nobody really knows why
[13:43] <juliank> I mean, I basically don't use much except the shell and the terminal
[13:43] <tarzeau> i've had headaches when i saw the menus of gedit lately
[13:44] <tarzeau> the hamburger menu, and menu placements etc
[13:44] <juliank> gedit looks awesome
[13:44] <tarzeau> i prefer any editor in terminal over it
[13:44] <juliank> but since it does not support mixed space/tab indentation, it's a toy
[13:45] <juliank> just like vs code, atom, gnome-builder, and their friends
[13:46] <juliank> or well, a bad joke, rather
[13:46] <juliank> hence I use geany
[13:47] <juliank> Unfortunately it does not have a header bar with client side decoration yet, but a menu bar and a tool bar
[13:47] <juliank> with colored toolbar icons
[13:47] <juliank> terrible
[13:48] <juliank> app has menu => throw away
[13:52] <tarzeau> what a pity must be in package. :(
[13:52] <tarzeau> and its creation is like work people already have done (like debian/* copyright, homepage etc)
[13:52] <tarzeau> there's no debian2appstream script or something?
[13:56]  * tarzeau found appstream-generator
[14:11] <jbicha> tarzeau: ideally, the appstream metadata is upstream (it is for official GNOME apps)
[14:12] <jbicha> see also https://appstream.debian.org/sid/main/ or http://appstream.ubuntu.com/
[14:14] <ginggs> tseliot: thanks, i'll try downgrading + upgrading - no problems with previous version and cuda 9.1
[14:19] <tseliot> ginggs: great, thanks
[14:24] <tarzeau> jbicha: i see. but the "Software" store, should not be GNOME only, well the gtk version, or the maybe qt version discover for kde (which I didn't have a look at yet)
[14:24] <tarzeau> but right, anyone can provide such appstreams... preferably upstream, i got that
[14:26] <jbicha> tarzeau: GNOME Software's .desktop doesn't set OnlyShowIn/NotShowIn; you can use it even if you don't use GNOME Shell
[14:26] <juliank> tarzeau: appstream is not a gnome thing - it's a cross distribution development effort that was started by distributions, for distributions, over half a decade ago.
[14:27] <juliank> Mostly by Fedora, SUSE, and Debian, IIRC
[14:28] <jbicha> LocutusOfBorg: you're going to have a problem with tracker's autopkgtests - upstream decided to add failing tests in the 2.0.x series after 2.0.1 :(
[14:29] <juliank> there also are more than those two store apps
[14:46] <roaksoax>  /win 3
[15:21] <xevious> It'd be convenient if the first line of the autopkgtest logs was the date & time that the job started.
[15:32] <LocutusOfBorg> jbicha, I know, maybe we can disable such tests?
[15:32] <LocutusOfBorg> I'm wondering what is the best thing to do here
[15:32] <LocutusOfBorg> new tests, failed probably even before... maybe a versioned hint is good
[15:32] <LocutusOfBorg> since they fail in Debian too, and in fedora too
[15:33] <LocutusOfBorg> (I spent some time over the fedora/upstream bugs today)
[15:37] <jbicha> the tracker tests worked fine until upstream added broken tests
[15:37] <jbicha> I complained at tracker, but maybe it would help if someone else complained
[15:40] <LocutusOfBorg> jbicha, I know, maybe we can disable such tests?
[15:40] <LocutusOfBorg> I'm wondering what is the best thing to do here, new tests, failed probably even before... maybe a versioned hint is good
[15:40] <LocutusOfBorg> since they fail in Debian too, and in fedora too (I spent some time over the fedora/upstream bugs today)
[15:40] <LocutusOfBorg> also freeipa is a sad thing
[15:40] <jbicha> what do you mean "failed probably even before"? the bad tests were added in 2.0.2
[15:43] <LocutusOfBorg> jbicha, I mean, they arent related to the transition, and probably the problem is also in release
[15:47] <jbicha> it is not related to the libunistring transition, but bionic only has 2.0.1 so you still have the problem of newly introduced bad tests
[15:53] <LocutusOfBorg> so, relaxing the tests is fine I would say
[15:58] <jbicha> that would make the tracker autopkgtest useless, right?
[16:01] <LocutusOfBorg> yep :/
[16:01] <jbicha> do you want to open a tracker bug upstream to complain about the troubles they are causing us?
[16:08] <juliank> Failing tests should be optionalllllllllllll
[16:08] <juliank> Well, it should say ignored failure or something, everything else is just bad
[16:29] <xevious> nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_101023_php-defaults_issues-md
[16:30] <nacc> xevious: thanks
[16:30] <nacc> i think mcrypt has more than that
[16:30] <nacc> based up on reverse-depends php-mcrypt
[16:31] <xevious> I just based that on the autopkgtest logs.
[16:31] <nacc> ah ok
[16:31] <nacc> yeah
[16:32] <xevious> The ones with "Declaration of DOMNodeComparator::assertEquals() must be compatible with ObjectComparator::assertEquals()" were almost all run on PHPUnit 5.4.6. Can you retrigger those with PHPUnit 6?
[16:32] <xevious> Maybe all, actually.
[16:32] <nacc> xevious: yeah i should be able to
[16:32] <nacc> sorry, 'm digging into the horde stack right now
[16:32] <nacc> and am on a call
[16:32] <xevious> Sure I understand.
[16:33] <nacc> but yeah i can use that
[16:50]  * Laney has a race condition with juliank's race condition post :-)
[16:51] <juliank> Laney ...
[16:51] <juliank> I feel like I really should go build apt update --strict
[16:51] <Laney> I wrote a draft saying "this is a race condition"
[16:51] <Laney> and then I saved it to test the patch I'm attaching
[16:51] <Laney> and there your post is :P
[16:52] <juliank> Laney: I wrote all this on IRC yesterday already, should have posted it to the ML then, but ML required some setup
[16:53] <juliank> I receive emails to ubuntu.com on one account, but can only send them from another :D
[16:53] <juliank> So I re-subscribed with my canonical.com account, so I can send emails from there too
[16:56] <juliank> Laney: I think it's best I introduce Acquire::TransientErrorsImportant, and then scripts can pass Acquire::TransientErrorsImportant=true or something
[16:56] <juliank> or a counter
[16:57] <Laney> it already has a bad exit status no?
[16:57] <juliank> It exits 0
[16:57] <juliank> Well the update exits 0
[16:57] <juliank> the install eatmydata exits 1 I guess
[16:57] <juliank> One shows "W:", the other "E:"
[16:57] <juliank> yes. for the same error type
[16:59] <Laney> mmm
[17:00] <juliank> Laney: There's a wait+retry in the script so that would have caught it
[17:00] <juliank> update || { sleep 10: update}
[17:00] <juliank> basically
[17:00] <juliank> um, ";", not ":"
[17:01] <Laney> yeah we have those in a few places
[17:01] <Laney> it's annoying having to sprinkle it everywhere
[17:01] <juliank> Well and it also does not work.
[17:01] <juliank> Probably because DonKult fixed a few bugs
[17:02] <juliank> and now more errors are transient than before or something
[17:02] <juliank> Well, any error from connect() is transient IIRC
[17:03] <juliank> and after connect some HTTP errors are transient
[17:03] <juliank> and transient errors only cause warnings, as they are "temporary"
[17:03] <juliank> :D
[17:04] <juliank> I should (1) add an option to control stuff (2) SRU it everywhere
[17:05] <xevious> nacc: Would you like me to work on 'Class 'PHPUnit_Framework_TestCase' not found'? Can you start the tests for php-net-ldap2 2.2.0-3ubuntu1, php-parser 3.1.3-1, php-text-captcha 1.0.2-4ubuntu1, and phpdox 0.11.0-0ubuntu1?
[17:07] <nacc> xevious: php-net-ldap2 and php-text-captcha retriggered
[17:07] <nacc> xevious: php-parser and phpdox i'm trying to unstick so that they can migrate through then it's easier to retrigger
[17:09] <nacc> xevious: that would be fine
[17:09] <nacc> xevious: php-mockery needs an update from upstream but that in turn is failnig here, i'm debugging that too
[17:11] <xevious> Ok. Is there a place I can see which packages are stuck like php-parse and phpdox? phpdox is listed as 'Valid candidate' on the 'excuses...' page.
[17:12] <nacc> xevious: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[17:12] <nacc> xevious: if it's valid and not migrating that page will explain why
[17:13] <xevious> Great. Thanks.
[17:13] <nacc> in this case because of php-phpdocumentor-reflection
[17:13] <nacc> which i believe depends on a specific rev of php-parser
[17:15] <nacc> xevious: oh that's why i was down that rathole yesterday
[17:15] <nacc> php-phpdocumenter-reflection needs an updated php-mockery
[17:15] <nacc> which in turn fails to pass its tests by default :)
[17:17] <ginggs> tseliot: downgrading was somewhat messy, but after cleaning up i enabled your ppa and everything upgraded smoothly :)
[17:18] <tseliot> ginggs: that's good. Thanks for testing
[17:18] <ginggs> yw!
[17:23] <nacc> xevious: ok, i see how to fix the mockery failure
[17:23] <nacc> xevious: just need to do it correctly :)
[17:26] <xevious> 'Correctly' seems like a solid plan.
[17:27] <nacc> xevious: ah is see mockery added a helpers file that needs to be sourced before running the tests
[17:27]  * nacc tries with an updated bootstrap.php
[17:29] <nacc> woo i think it is passing
[17:30] <nacc> that should unblock a few more (and fix the regression with php-defaults -> php-mockery)
[17:31] <nacc> xevious: also php-crypt-chap has been removed from bionic
[17:31] <nacc> xevious: see LP: #1749745
[17:31] <xevious> Wasn't that a dependency of one of the Horde packages?
[17:32] <nacc> xevious: reverse-recommends only
[17:33] <tarzeau> juliank: ah okay, completely missed it.
[17:34] <xevious> Yay, no more mcrypt!
[17:36] <tarzeau> jbicha: so it's only the debian/fonts-cantarell.metainfo.xml that is doing the appstream thing?
[17:37] <jbicha> tarzeau: yes, but that was upstreamed in Cantarell 0.100 (in Debian experimental)
[17:37] <tarzeau> jbicha: i'm always in contact with my packaged software, upstream (where possible)
[17:38] <tarzeau> so my plan would be, add it where it's useful, and provide it upstream for inclusion in future releases
[17:38] <jbicha> it's a bit tricky to test appstream metadata. If you upload a package that installs it, it will show up in Debian or Ubuntu's GNOME Software about a day later
[17:38] <tarzeau> jbicha: that's great :)
[17:39] <tarzeau> i'll try it for fonts first, then games, then multimedia apps, later scientific software
[17:39] <nacc> slangasek: i've got a package at 0.9.5 -- that then went to 1.0. There is also a 1.0.0~alpha1. uscan seems the 1.0.0-alpha1 and wants to use that and not the 1.0. Is it appropriate to mangle the uversion to suffix a .0 to two-digit versions so they sort properly?
[17:39] <nacc> (upstream versions for the above)
[17:39]  * tarzeau votes for epoch!
[17:42] <nacc> tarzeau: wrt to my question? not sure how that would help? I guess it would force 1:1.0 to sort after 0.9.5 ?
[17:50] <nacc> tarzeau: aiui, i don't think an epoch bump is neeeded here, 1.0 should sort after 0.9.5 (per the manual)
[17:51] <nacc> the problem is uscan doesn't compare them properly, i think
[17:51] <nacc> with my manual mangle, it sees 1.0 as 1.0.0 and correctly updates to ti
[17:51] <nacc> *it
[17:55] <tarzeau> ah
[17:56] <nacc> tarzeau: that's my understanding right now, at least...
[18:11] <nacc> xevious: and that pulls in a new php-hamcrest :)
[18:16] <nacc> xevious: uploding php-hamcrest
[18:16] <nacc> xevious: waiting on a response to the above before i upload php-mockery
[18:20] <xevious> php-mail-mime's log is unclear about what the actual errors are. It just says which tests failed, not why.
[18:21] <nacc> xevious: let me look
[18:22] <nacc> xevious: yeh that's becuse they are using pear not phpunit directly :/
[18:22] <nacc> it *might* need the php-pear from proposed
[18:22] <nacc> xevious: i can retry it locallyw ith propsed
[18:23] <nacc> xevious: do you have autopkgtest setup locally?
[18:24] <xevious> I don't. I was just going to ask how I can get my local machine configured so I can actually start helping with the packages.
[18:25] <nacc> xevious: 1) have lxd setup locally
[18:25] <nacc> xevious: 2) install autopkgtest
[18:26] <nacc> xevious: 3) autopkgtest-build-lxd ubuntu-daily:bionic
[18:27] <nacc> xevious: 4) autopkgtest -U -s php-mail-mime -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64
[18:28] <nacc> xevious: if you want to test with proposed, you puass --apt-pocket=proposed
[18:28] <nacc> xevious: you can also pass it a soruce package dsc rather than the name, fi you have local stuff
[18:28] <xevious> easy-peasy
[18:28] <xevious> Thanks
[18:29] <nacc> xevious: you can also specify specific packages in the apt-pocket line, iirc, which is what LP is doing
[18:29] <nacc> and what changing the triggers changes
[18:30] <nacc> infinity: would you have any opinion on the d/watch change i mentioned above? (I can repost it if that's easier)
[18:33] <nacc> xevious: php-mail-mime also fails with proposed enabled
[18:33] <nacc> xevious: debugging it
[18:55] <xevious> nacc: I'm running 16.04 on this machine and didn't get an autopkgtest-build-lxd, autopkgtest, or autopkgtest-virt-lxd commands from installing the autopkgtest package. It installed adt-build-lxd, adt-run, and adt-virt-lxd, but adapting your command 4) didn't work.
[18:56] <xevious> adt-run -U -s php-mail-mime -- adt-virt-lxd autopkgtest/ubuntu/bionic/amd64
[18:56] <nacc> xevious: s/autopkgtest/adt/ in what i wrote
[18:56] <nacc> it just got renamed
[18:57] <xevious> There isn't a command just named adt and adt-run is complaining about those parameters.
[18:59] <xevious> nacc: adt-run: error: adt/ubuntu/bionic/amd64: unsupported action argument
[18:59] <xevious> That was the output when I ran: adt-run -U -s php-mail-mime -- adt-virt-lxd adt/ubuntu/bionic/amd64
[19:13] <nacc> xevious: when you ran the build-lxd, it succeeded, right?
[19:14] <nacc> xevious: if so, then check then anme (`lxc image list`)
[19:14] <nacc> xevious: oh and adt might need three dashes
[19:14] <nacc> not two
[19:14] <xevious> Yes it succeeded. The image is named adt/ubuntu/bionic/amd64
[19:15] <xevious> Trying three dashes
[19:15] <xevious> That did it
[19:17] <nacc> xevious: sorry, i forgot about that
[19:19] <xevious> Seems like my container can't lookup hostnames. Can I pass it nameserver info or just tell it to use the host system's /etc/resolv.conf?
[19:22] <nacc> xevious: have you used lxd before on your system?
[19:22] <nacc> xevious: it might need soe network config if not
[19:45] <slangasek> nacc: yes, no problem with version mangling to 1.0.0.
[19:49] <nacc> slangasek: ok, thanks
[19:50] <xevious> nacc: php-mail-mime passed on my system.
[19:50] <xevious> (without proposed enabled)
[19:50] <nacc> xevious: hrm, but with php-defaults from proposed? that's what is broken
[19:51] <xevious> Rerunning it
[19:51] <nacc> xevious: thanks, i definitely saw lall the failure siwth all proposed (which is my usual first test)
[19:52] <nacc> as it's easier to type then figuring out the exact packages to test (locally)
[19:52] <xevious> Yeah, I just added '--apt-pocket=proposed' for this run.
[19:53] <nacc> xevious: yep
[19:54] <xevious> For the projects that need to be updated for namespaced PHPUnit classes, most of them have already fixed that upstream. Can we just update to a new upstream version, or do we have to patch the packaged version?
[19:54] <nacc> xevious: depends? :)
[19:54] <nacc> if uscan can find it, and uupdate works, and the package builds and tests successfully, go for it
[19:55] <nacc> but sometimes, that ends up making its own nest of dependency migrations
[19:55] <xevious> Yeah, gotta watch out for backwards incompatible changes, for sure.
[19:57] <xevious> If all the PHP library dependencies were packaged with the PHP applications, then several versions could happily coexist on a system.
[19:57] <xevious> I really need to post about that on the ubuntu-server mailing list.
[19:58] <xevious> nacc: Running the test with proposed enabled reproduced the log from the excuses... page.
[19:58] <nacc> xevious: yep
[19:59] <xevious> nacc: Now that I've got autopkgtest/adt set up on my system, how do I use it to test local changes to a package?
[19:59] <nacc> xevious: you know how to build source pacakges?
[20:00] <xevious> Yes
[20:00] <nacc> xevious: so e.g., `pull-lp-source  ... ` etc
[20:00] <nacc> make changes, etc. dpkg-buildpackage -S -nc -d
[20:00] <nacc> pass the resulting dsc to adt
[20:00] <nacc> (after modifying the changelog)
[20:01] <xevious> I'm very comfortable with everything but the LaunchPad aspect of it. I've either worked with repos from internal source control or just modifying packages downloaded with `apt-get source`.
[20:02] <nacc> ack
[20:02] <nacc> so don't worry about lp for now :)
[20:02] <nacc> (pull-lp-source is a way to do `apt-get source` without having to have sources defined)
[20:02] <nacc> and to pull down source from any release
[20:02] <nacc> you can file bugs against the srcpkg, and attach debdiffs (`debdiff existing.dsc new.dsc`) and i can sponsor them for you
[20:02] <xevious> That sounds relevant, since I've got LXC set up on a 16.04.3 system right now.
[20:03] <xevious> I'll read up on pull-lp-source and dig up my LP credentials.
[20:03] <xevious> I'm fairly certain my GPG keys are long gone. :\
[20:03] <nacc> xevious: pull-lp-source doesn't require auth, fwiw
[20:03] <nacc> just the bug filing will
[20:03] <xevious> Right.
[20:05] <xevious> I'm going to go find some food to munch on.
[20:06] <xevious> bbiaf
[20:07] <nacc> xevious: sounds good, i'm uploading php-mockery now and i filed a bug to remove php-phpdocumentor-reflection
[20:12] <nacc> xevious: php-mail-mime is using count() in Mail/mimePart.php line 314
[20:14] <nacc> xevious: changing it to be if (is_array($this->subparts) && .. ) and it passes
[20:14] <nacc> xevious: i'll upload that fix
[20:17] <nacc> xevious: oh i think it's fixed in 1.10.2 upstream
[20:17] <nacc> i'll update to that
[20:17] <nacc> (safer in this case)
[20:51] <nacc> xevious: ah it's in debian building right now (1.10.2-0.1
[20:51] <xevious> nacc: php-doctrine-cache 1.7.1 should resolve the issues. Can you rerun its tests with the new package?
[20:52] <xevious> Woops
[20:52] <xevious> I forgot to refresh.
[21:10] <xevious> nacc: Are you still focused on Horde?
[21:53] <infinity> nacc: Your debian/watch woes can be solved with a rewrite of -alpha to ~alpha (and similar for -beta) if you know that's how upstream names things.
[21:53] <xevious> watch woes?
[21:53] <infinity> nacc: It's not that uscan is sorting "incorrectly", just that it uses a dpkg version sort, and upstream doesn't.
[21:54] <xevious> I'm looking at php-guzzlehttp-promises and the archive it's pulling down doesn't include the tests folder.
[21:55] <xevious> ...just because they chose to upload a tarball without the tests folder for that release, apparently.
[22:00] <xevious> Using the GH API tarball URL also produces an archive without the 'tests' directory. Anyone have any idea what's going on here?
[22:00] <nacc> infinity: it does that already (afaict)
[22:01] <nacc> infinity: but ack on the 'incorrectly'
[22:01] <nacc> xevious: i can look
[22:01] <xevious> nacc: Is there a setting on GH that makes it not include a 'tests' directory in archives?
[22:02] <nacc> xevious: not that i know of, but possibly it's controlled by a file in the repo
[22:03] <xevious> It sure is
[22:03] <xevious> .gitattributes
[22:03] <nacc> xevious: yeah
[22:03] <nacc> xevious: does that imply guzzlehttp-promises also fails without -proposed?
[22:03] <infinity> nacc: Oh!  I focussed on the ~ and missed the 1.0 versus 1.0.0.  Derp.
[22:03] <nacc> infinity: yeah, it's that bit
[22:04] <xevious> nacc: I was trying to just update it from 1.1.0 to 1.3.1, since they've already switched to namespaced PHPUnit classes.
[22:04] <infinity> nacc: Yeah, you could either mangle to add another .0 or (which seems more sane) add a version ignore for the 1.0.0~* ones.
[22:04] <xevious> 1.3.0 should work, though.
[22:04] <nacc> infinity: ack, thanks
[22:04] <nacc> sigh, libc6 in bionic is < libc6 in artful-security?
[22:05] <nacc> that seems less than ideal?
[22:05] <nacc> 2.26-0ubuntu2 vs 2.26-0ubuntu2.1
[22:05] <nacc> and does that imply a security fix raced with the bionic open?
[22:08] <nacc> xevious: you might compare the current package's results on artful
[22:09] <nacc> xevious: so the version in the archive now has a tests/ dir
[22:10] <xevious> Everything prior to 1.3.1 did, because there wasn't a .gitattributes file in the repo preventing tests from being exported.
[22:10] <nacc> xevious: oh i see
[22:10] <nacc> xevious: yeah, so you cn bump to just 1.3.0 if you want
[22:11] <xevious> Is it reasonable to submit a "Fix Debian/Ubuntu packaging" PR that removes 'tests' from .gitattributes to the upstream repo, or should I adapt the package to upstream's changes?
[22:12] <xevious> I could change the get-orig-source target in rules to use `git archive` instead of uscan.
[22:12] <nacc> xevious: you could do that, but then you'd also need to change it to git cloen first
[22:12] <nacc> that's not great
[22:12] <nacc> as you'd need to make git a build-depends
[22:14] <xevious> A 1 line PR to upstream to include tests in the archive is the simpler solution from the packaging perspective. However, I'm hesitant to make Debian/Ubuntu-specific requests in an upstream project.
[22:14] <nacc> xevious: i've done it before :)
[22:14] <nacc> xevious: do they explain upstream why they changed it?
[22:15] <xevious> To "improve packaging" https://github.com/guzzle/promises/commit/e278912eaaa94079b9277d5dbe23fc0a22d308bf
[22:16] <nacc> xevious: phpdox just migrated
[22:16] <xevious> It wouldn't need a 'git clone' in the build process. Updating the get-orig-source target to use `git archive` would still produce a tarball.
[22:16] <nacc> xevious: how? it's run from debian/rules?
[22:17] <nacc> xevious: where youdon't have a git repo
[22:19] <xevious> Well that plan's out the window
[22:20] <xevious> GitHub doesn't allow archiving.
[22:20] <nacc> xevious: so 1.3.0 didn't work?
[22:20] <xevious> nacc: You can pass `--remote=` to `git acrhive` to create a tarball of a remote repository.
[22:20] <nacc> xevious: oh interesting
[22:20] <nacc> xevious: i didn't realize that, sorry
[22:21] <xevious> It would still require adding git as a build dependency, which isn't great.
[22:21] <nacc> yeah
[22:21] <xevious> I'll just open a PR to make the tests directory export again. We'll see what they say.
[22:23] <nacc> xevious: fwiw, i think php-horde-core is more than just a retry -- you can see that some did run against the version in b-p and still failed
[22:28] <nacc> xevious: so you're still working on guzzlehttp-promises? mockery should migrate in a bit and i'll retrigger it then
[22:29] <xevious> I'm just going to open a PR with the change and move onto the next PHPUnit-related one.
[22:32] <xevious> Alternatively, I could just make the package not run the tests.
[22:32] <xevious> That doesn't seem great.
[22:32] <nacc> it has been done to a few packages now
[22:32] <xevious> Well, if there's precedent...
[22:32] <xevious> What do you recommend?
[22:34] <nacc> xevious: so, aiui, the issue is that the upstream isn't packaging the tests, so the dep8 tests fail? doe sit still build?
[22:34] <nacc> xevious: you can remove the dep8 tests if they really aren't available anymore, i think, and i will need to send a hint MP to ignore the regression (removing tests is considred a regression too)
[22:35] <xevious> It doesn't build because there's a patch for bootstrap.php in the tests directory.
[22:35] <nacc> xevious: right i had to fix soethig similar recently
[22:35] <nacc> in a different package
[22:35] <nacc> xevious: but i mean the dep8 tests no longer make sense right?
[22:35] <nacc> xevious: since the tests are no longer shipped
[22:35] <xevious> Right
[22:36] <xevious> I can either remove the tests from the packaging process or I can open a PR with upstream in hopes that they quickly tag a new version.
[22:36] <nacc> xevious: you can do both :)
[22:37] <nacc> xevious: which is probably ideal ;)
[22:37] <xevious> Ok
[22:37] <xevious> I'll do both
[22:41] <xevious> nacc: https://github.com/guzzle/promises/pull/87
[22:41] <nacc> xevious: yeah, i can understand the upstream theory, you don't need the tests to have a functional package
[22:41] <nacc> but i've not seen other upstreams do that
[22:42] <nacc> and the extra space is ... minimal
[22:43] <xevious> Yeah, I understand their reasoning, However, I can think of a number of cases where you'd want to use an archive download rather than git, and then be able to run the tests.
[22:43] <jbicha> cjwatson: if you're around, can you kick the ppc64el builders?
[22:43] <nacc> xevious: yep
[22:46] <xevious> nacc: It looks like php-guzzlehttp-promises is inherited from Debian. How does cooperating with them work? Should I make the change on LaunchPad and we incorporate it into Bionic, then upstream it to Debian? Or, should I work with Debian from the start and pull it into Bionic when it's in their repo?
[22:46] <nacc> xevious: either is ok, the latter tends to take longer
[22:46] <nacc> xevious: so the simpleset answer is make the change in ubuntu, and we can send stuff up to debian (there is a submittodebian helper)
[22:46] <nacc> after we get ubuntu working :)
[22:46] <xevious> Perfect
[22:46] <nacc> xevious: fixed php-horde-core
[22:47] <nacc> testing it again and then i'll upload
[22:47] <xevious> Right on!
[22:47] <nacc> that might be what's needed throughout
[22:47] <nacc> i *think* possibly phpunit 6 dropped support for autoloading a boostrap.php file?
[22:47] <nacc> that seems to fix a lot of packages (passing the option to phpunit)
[22:54] <sarnold> slangasek,bdmurray, I have a suspicion Something Is Wrong: a friend showed me 'apt upgrade' https://bpaste.net/show/a0ccc1e394d7 and 'apt dist-upgrade' https://bpaste.net/show/aa8d1ff48634 results that looked like they worried him, and I can reproduce something very similar: http://paste.ubuntu.com/p/WTD9rYCcFq/ (please ignore firefox..)
[22:54] <nacc> yep somoene elsehwere also reported the removal of unity-scope* from their system
[22:55] <sarnold> nacc: oh, hooray, did you recall where? or bug number?
[22:55] <nacc> looking in my logs
[22:55] <nacc> sarnold: #ubuntu-discuss, no bug filed
[22:56] <bdmurray> sarnold: what release?
[22:56] <sarnold> bdmurray: I believe xenial all around
[22:56] <nacc> checking on that there but they did say xenial at one point
[22:56] <nacc> which seems 'even worse' :)
[22:57] <sarnold> https://irclogs.ubuntu.com/2018/02/15/%23ubuntu-discuss.html#t20:17
[22:57] <nacc> sarnold: thanks
[23:00] <nacc> uggggh
[23:00] <nacc> compiz-core migrated without a unity rebuild?
[23:00] <nacc> unity: depends on compiz-core-abiversion-20151010,
[23:01] <nacc> Provides: compiz-core-abiversion-20170630
[23:01] <nacc> latter from compiz-core in updates
[23:01] <bdmurray> if its already in -updates we'll need an archive admin
[23:02] <nacc> it looks to be in both right now
[23:02] <nacc> https://launchpad.net/ubuntu/+source/compiz
[23:02] <nacc> updates and proposed, i mean
[23:02] <nacc> bdmurray: i'm not 100% on my analysis but that abi mismatch seems worrisome with no changes to unity
[23:07] <sarnold> is this time for the !regressions batsignal or whatever it is?
[23:07] <nacc> heh
[23:08] <nacc> sarnold: it's being discussed in #ubuntu-release
[23:08] <sarnold> nacc: <3
[23:08] <nacc> sarnold: phasing stopped
[23:08] <nacc> (presumably all affected were in the last 4 hours)
[23:10] <nacc> xevious: fyi php-horde-core uploaded
[23:12] <xevious> Great. Looking forward to seeing a bunch more green...
[23:14] <nacc> xevious: bbiab
[23:17] <tsimonq2> Can a Core Dev please approve this bug nomination? 1746807
[23:17] <tsimonq2> bug 1746807 even
[23:17] <rbasak> tsimonq2: why does it need nomination for Bionic?
[23:18] <tsimonq2> rbasak: It's a Bionic-specific bug, I'll nominate Bionic out of habit I guess (for future ref should I need to revisit it at any point).
[23:19] <tsimonq2> s/Bionic out/Bionic if I have access to out/
[23:20] <tsimonq2> rbasak: I guess there's no *need* to but it's good for bookkeeping I guess
[23:22] <rbasak> tsimonq2: it'll affect >= Bionic until it is fixed, no?
[23:22] <rbasak> That's the same as any other bug, and we don't usually nominate the development release for that kind of thing.
[23:22] <tsimonq2> OK
[23:23] <rbasak> There was a time when people were adding a development-release-specific bug task for release bug tracking purposes
[23:23] <rbasak> I'm not sure if we still do that
[23:23] <rbasak> I'm not sure it's a good idea in general, because it collides with tracking SRUs when a series is relaesed.
[23:24] <rbasak> But I don't think anyone has actually tried to define a policy on this since Kate left.
[23:24] <tsimonq2> OK
[23:25] <rbasak> infinity, slangasek: ^ opinion?
[23:26] <slangasek> rbasak: we do have per-team reports on bugs targeted to the current development release; I gather Server Team isn't using this? http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html#ubuntu-server
[23:27] <xnox> rbasak, for foundations it does make a different if something is "whenever" vs "whenever, but to fix for bionic"
[23:27] <rbasak> slangasek: we're aware of the link, but we never controlled what was actually on that list, or how to get bugs out of the list, partially (IMHO) due to a lack of an Ubuntu-wide policy on it.
[23:28] <rbasak> So (again IMHO) it never seemed to be a particularly useful way of tracking anything
[23:28] <xnox> rbasak, well, the report is fixed, in what it is generating into accepted / incoming / rejected pages.
[23:28] <rbasak> xnox: who accepts/rejects though, and what if the server team disagrees with such a nomination?
[23:28] <slangasek> rbasak: there is a tag to decline a bug from that list as not-committed-by-team despite being targeted to the release; I forget the exact name, bdmurray would remember
[23:29] <bdmurray> notfixing
[23:29] <slangasek> it might be rls-$series-declined
[23:29] <slangasek> ok that
[23:30] <xnox> rbasak, people who what it request for a bug to be considered add rls-LL-incoming; if $team accepts it, the $team removes the tag and targets to series, and potentially to a monthly milestone (but we moved on to creating trello cards for these)
[23:30] <xnox> rbasak, or drop incoming tag and replace by notfixing.
[23:30] <xnox> rbasak, as $server team is meant to keep track of the bugs, to packages, which the team is subscribed to, for rls-incoming bugs.
[23:31] <xnox> at least foundations does it for foundations-bugs subscribed packages.
[23:31] <slangasek> "is meant to" - well, that's the intent of the report, but we obviously don't dictate how other teams use it
[23:31]  * xnox wonders if we due to scope we need automation for this
[23:31]  * xnox wonders if we do, due to scope we need automation for this
[23:31]  * xnox wonders if we do, due to scope. Hence we need automation for this
[23:31]  * bdmurray wonders about xnox
[23:31] <xevious> nacc: Should I add `override_dh_auto_test` to rules, or should I delete the `test` rule from the upstream project's Makefile?
[23:32] <rbasak> We use Trello too
[23:32] <xnox> bdmurray, i had a volleyball training, my fingers are a bit shaky, and I'm misstyping a lot.
[23:32] <slangasek> can we automate the scope, if the guards come with him
[23:32] <xnox> rbasak, for us bugs are public; trello is private.
[23:32] <rbasak> Our Trello is public I think
[23:33] <rbasak> But it's really a ~canonical-server Trello, rather than an ~ubuntu-server Trello.
[23:33] <xnox> rbasak, yeah, most teams have it like that. It's just the PDX based managers who have it private.... kernel team / foundations team / security (?!) / is (?!)
[23:33] <tsimonq2> rbasak: You guys have your plans to take over the world there? :P
[23:33] <tsimonq2> s/guys/guys and gals/ if you will
[23:34]  * tsimonq2 steps away from that debate real quick
[23:34] <slangasek> xnox: we were keeping the managers' locations private
[23:34] <rbasak> Private customer work happens on a different board
[23:34] <xnox> rbasak, yeah, so rls-incoming is "canonical-foundations is commiting to things" vs "non rls-tracked bugs ubuntu-foundations may volunteer to do it with no sla"
[23:34] <rbasak> xnox: for packages to which you subscribe, presumably
[23:35] <xnox> rbasak, typically rls-LL-incoming bugs we get; are escalations from either community or other ~canonical-foo or ~ubuntu-foo teams. We try to assess criticality, and impact. As we get flodded with bugs =/ and we use that for people to bubble things up to us; we review incoming bugs at every weekly meeting.
[23:36] <xnox> we hardly are a zero-boogz-found team =/
[23:36] <xnox> aka inbox-zero
[23:37] <rbasak> That sounds reasonable except I'm not convinced about the need to peg it to a particular release
[23:38] <xnox> well, we used to have foundations STS handle stable releases incoming bugs a bit ;-)
[23:38] <xnox> and reports currently track things as "accepted" when targetted to a release, instead of an 'rls-LL-accepted' tag.
[23:38] <xnox> i guess that is simply how the reports got implemented.
[23:40] <rbasak> tsimonq2: so I suppose that means that you need to tag your bug rls-bb-incoming
[23:40] <rbasak> tsimonq2: rather than asking for a nomination to be accepted directly
[23:40] <rbasak> tsimonq2: since Foundation is subscribed to that package (presumably)
[23:40] <tsimonq2> rbasak: aha, ok
[23:41] <xnox> that =) at least for packages that are subscribed by ~foundations-bugs team
[23:41] <tsimonq2> rbasak: I'm trying to see if it's something I can figure out on my own, but obviously if I can't do that, I'll pass to Foundations
[23:41] <xnox> rbasak, rls-xx-incoming sometimes become hot in the run up to point releases... vs rls-bb-incoming in the run up to feature freeze / milestones....
[23:46] <xevious> nacc: adt-run [18:42:14]: @@@@@@@@@@@@@@@@@@@@ summary
[23:46] <xevious> *                    SKIP no tests in this package
[23:46] <xevious> On to the next one...
[23:55] <nacc> xevious: i'm back now
[23:56] <nacc> xevious: nice, i'm guessing you need sponsorship for that? file a bug against hte srcpkg and upload the debdiff to it
[23:57] <nacc> xevious: and subscribe me to it
[23:59] <cjwatson> jbicha: done