[00:03] nacc: phpdox 0.10.1 introduced namespaced PHPUnit classes. The latest tagged version is 0.11.0. [00:04] I've got a loose definition of calling it a day. [00:05] There's a 0.10.1 package in sid: https://packages.debian.org/source/sid/phpdox [00:05] xevious: i've uploaded 0.11 already [00:05] xevious: it's in bionnic-proopsed [00:05] hah [00:06] xevious: they are wedged (i just checked, thanks for the poke) on php-phpdocumentor-reflection [00:06] looking at it now [00:08] xevious: looks like it needs an update too [00:09] xevious: heh, 1.1.0 packaged, 3.0.0 released upstream [00:09] sometimes Debian [00:09] * nacc shakes fist [00:11] 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] well, i mean we use composer [00:12] the problem is the composer.json in 1.1.0 is so solld [00:12] 8old [00:12] bah, old [00:12] I mean instead of handling dependencies via dpkg dependencies. [00:12] xevious: so you mean shipping all your dependencies in the deb? [00:12] i think that would be expressly rejected [00:12] I think so, too. [00:13] i think debian/ubuntu would rather drop the php packages [00:13] now that cmoposer exists :) [00:13] Just having packages for the PHP interpreter and extensions would be a-ok with me. [00:14] yeah, that seems lilke a 'better' future [00:14] but i'm not sure we can do that for 18.04 [00:14] maybe 20.04 :) [00:14] Yeah, that's definitely too much for 18.04. [00:15] and reallly, i'm hoping debian will pick up some of this 'slack' [00:15] Debian's PHP ecosystem is heavily tied to PECL/PEAR, which hardly anyone in the PHP community is using any more. [00:15] e.g., start dropping horde [00:16] Yeah, Horde's got to go. [00:17] I hope there's some activity on this front soon: https://wiki.php.net/rfc/deprecate-pear-include-composer [00:18] xevious: yeah that would make sense to me [00:18] so much of PECL is cruft [00:20] 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] yeah, i'm not sure why it needs to be 'in' the core [00:20] but i'm not reallly a php user or developer [00:20] just stuck in this swamp :) [00:27] 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] 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] It'd be interesting to monitor how often the PHP application packages are actually used. [00:30] There are probably some hot spots, like Icinga [00:30] I imagine popcon output in Debian would be helpful [00:32] cjwatson: yeah that's a good point [00:35] 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] It'd lead to duplicate files, but it would allow different PHP applications to depend on different versions of a library. [00:36] xevious: yeah, basically what snaps do for applications [00:36] Exactly [00:38] 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] nacc: Have you heard back about mcrypt? [00:46] xevious: not yet [00:47] If PHP upstream is abandoning it, it seems silly to go through the effort of packaging the PECL version. [00:49] Is there a proper venue for polling Ubuntu Server users about things such as "Can we remove Horde? Does anyone actually care?" [00:49] horde == burn it with fire :-) [00:52] mcrypt deserves the same inferno, right? [00:56] xevious: i'd start with ubuntu-server@lists.ubuntu [00:57] sarnold: Except, I thought I needed that for something, but for the life of me can't remember what! [00:59] sarnold: Yeah. Projects still using mcrypt need to update and get with the times. === BrAsS_mOnKeY is now known as william === sergiusens_ is now known as sergiusens [09:12] hmm - all x86 builders seem to be locked in "cleaning" [09:13] is there another maintenance change going on or do the just need some help to get out of that state? [09:16] probably just the latter. poking [09:18] I see them turn idle and picking up jobs again, thanks cjwatson [10:02] could somebody here trigger an Ubuntu/bionic iso build? [10:02] the daily one built a bit before some seed changes we want to try were in place [10:04] ok [10:05] Laney, thx! [10:45] 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] hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd [11:07] python-sss is in main, that's the py2 version [11:07] python3-sss is in universe [11:07] these python3?-sss packages are produced by the sssd source itself [13:29] 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] and how come, in Games, "Mr Boom" has a "No screenshot provided"? [13:32] and the "Fonts" section is half-screen empty... [13:33] Education & Science, Astronomy: is missing saods9 [13:34] tarzeau: saods9 does not provide any appstream data [13:35] same for everything else you mention probably [13:35] how, and who is one supposed to add appstream data? [13:35] https://www.freedesktop.org/software/appstream/docs/ [13:35] very few fonts provide AppStream metadata [13:35] is that in the package? or external? [13:36] 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] in /usr/share/metainfo/%{id}.metainfo.xml, [13:36] where %{id} is a unique identifier [13:36] thought it used to also fetch from http://screenshots.debian.net/ or is that out of date [13:36] tarzeau: also https://wiki.debian.org/AppStream/Guidelines [13:36] sladen: mentioned things have screenshots.d.n [13:36] for example, /usr/share/metainfo/org.gnome.Calendar.appdata.xml [13:36] thanks for the links, /me will try to improve [13:37] screenshots have to be provided alongside the appstream metadata [13:37] unless someone patched something into gnome-software to do something with screenshots [13:37] jbicha: does debian use the appstream meta data, anywhere? [13:37] you can add AppStream metadata downstream in the packaging but forward upstream if you can (I did this for Cantarell) [13:37] sure [13:38] some fonts don't really have an active upstream though [13:38] and yes, Debian uses AppStream [13:38] where? [13:38] tarzeau: All the stuff in http://ftp.de.debian.org/debian/dists/unstable/main/dep11/ comes from it [13:38] tarzeau: Debian GNOME installs the GNOME Software app by default. That app only works with AppStream [13:38] there is also the Discover app for KDE users [13:38] oh, i've never used the gnome software app on debian (or any kind of gnome software at all, actually) [13:39] jbicha: never heard of that, but will try once i visit a kde user [13:39] what desktop do you prefer? [13:39] jbicha: amiwm, or wmaker+gnustep software [13:40] not exactly a desktop, but with gworkspace you have a nice file manager [13:40] oldschool :) [13:40] but fast! even with remote x on slow lines [13:41] 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] some use tiling wms, ratpoison, fvwm2 still, but very rare [13:41] if you like terminals, there's appstreamcli I guess [13:41] and enlightenment [13:42] desktop linux users are so rare [13:43] GNOME, GNOME, GNOME is the only thing I use [13:43] though nobody really knows why [13:43] I mean, I basically don't use much except the shell and the terminal [13:43] i've had headaches when i saw the menus of gedit lately [13:44] the hamburger menu, and menu placements etc [13:44] gedit looks awesome [13:44] i prefer any editor in terminal over it [13:44] but since it does not support mixed space/tab indentation, it's a toy [13:45] just like vs code, atom, gnome-builder, and their friends [13:46] or well, a bad joke, rather [13:46] hence I use geany [13:47] Unfortunately it does not have a header bar with client side decoration yet, but a menu bar and a tool bar [13:47] with colored toolbar icons [13:47] terrible [13:48] app has menu => throw away [13:52] what a pity must be in package. :( [13:52] and its creation is like work people already have done (like debian/* copyright, homepage etc) [13:52] there's no debian2appstream script or something? [13:56] * tarzeau found appstream-generator [14:11] tarzeau: ideally, the appstream metadata is upstream (it is for official GNOME apps) [14:12] see also https://appstream.debian.org/sid/main/ or http://appstream.ubuntu.com/ [14:14] tseliot: thanks, i'll try downgrading + upgrading - no problems with previous version and cuda 9.1 [14:19] ginggs: great, thanks [14:24] 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] but right, anyone can provide such appstreams... preferably upstream, i got that [14:26] tarzeau: GNOME Software's .desktop doesn't set OnlyShowIn/NotShowIn; you can use it even if you don't use GNOME Shell [14:26] 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] Mostly by Fedora, SUSE, and Debian, IIRC [14:28] 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] there also are more than those two store apps [14:46] /win 3 [15:21] It'd be convenient if the first line of the autopkgtest logs was the date & time that the job started. [15:32] jbicha, I know, maybe we can disable such tests? [15:32] I'm wondering what is the best thing to do here [15:32] new tests, failed probably even before... maybe a versioned hint is good [15:32] since they fail in Debian too, and in fedora too [15:33] (I spent some time over the fedora/upstream bugs today) [15:37] the tracker tests worked fine until upstream added broken tests [15:37] I complained at tracker, but maybe it would help if someone else complained [15:40] jbicha, I know, maybe we can disable such tests? [15:40] 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] since they fail in Debian too, and in fedora too (I spent some time over the fedora/upstream bugs today) [15:40] also freeipa is a sad thing [15:40] what do you mean "failed probably even before"? the bad tests were added in 2.0.2 [15:43] jbicha, I mean, they arent related to the transition, and probably the problem is also in release [15:47] 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] so, relaxing the tests is fine I would say [15:58] that would make the tracker autopkgtest useless, right? [16:01] yep :/ [16:01] do you want to open a tracker bug upstream to complain about the troubles they are causing us? [16:08] Failing tests should be optionalllllllllllll [16:08] Well, it should say ignored failure or something, everything else is just bad [16:29] nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_101023_php-defaults_issues-md [16:30] xevious: thanks [16:30] i think mcrypt has more than that [16:30] based up on reverse-depends php-mcrypt [16:31] I just based that on the autopkgtest logs. [16:31] ah ok [16:31] yeah [16:32] 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] Maybe all, actually. [16:32] xevious: yeah i should be able to [16:32] sorry, 'm digging into the horde stack right now [16:32] and am on a call [16:32] Sure I understand. [16:33] but yeah i can use that [16:50] * Laney has a race condition with juliank's race condition post :-) [16:51] Laney ... [16:51] I feel like I really should go build apt update --strict [16:51] I wrote a draft saying "this is a race condition" [16:51] and then I saved it to test the patch I'm attaching [16:51] and there your post is :P [16:52] Laney: I wrote all this on IRC yesterday already, should have posted it to the ML then, but ML required some setup [16:53] I receive emails to ubuntu.com on one account, but can only send them from another :D [16:53] So I re-subscribed with my canonical.com account, so I can send emails from there too [16:56] Laney: I think it's best I introduce Acquire::TransientErrorsImportant, and then scripts can pass Acquire::TransientErrorsImportant=true or something [16:56] or a counter [16:57] it already has a bad exit status no? [16:57] It exits 0 [16:57] Well the update exits 0 [16:57] the install eatmydata exits 1 I guess [16:57] One shows "W:", the other "E:" [16:57] yes. for the same error type [16:59] mmm [17:00] Laney: There's a wait+retry in the script so that would have caught it [17:00] update || { sleep 10: update} [17:00] basically [17:00] um, ";", not ":" [17:01] yeah we have those in a few places [17:01] it's annoying having to sprinkle it everywhere [17:01] Well and it also does not work. [17:01] Probably because DonKult fixed a few bugs [17:02] and now more errors are transient than before or something [17:02] Well, any error from connect() is transient IIRC [17:03] and after connect some HTTP errors are transient [17:03] and transient errors only cause warnings, as they are "temporary" [17:03] :D [17:04] I should (1) add an option to control stuff (2) SRU it everywhere [17:05] 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] xevious: php-net-ldap2 and php-text-captcha retriggered [17:07] xevious: php-parser and phpdox i'm trying to unstick so that they can migrate through then it's easier to retrigger [17:09] xevious: that would be fine [17:09] xevious: php-mockery needs an update from upstream but that in turn is failnig here, i'm debugging that too [17:11] 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] xevious: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [17:12] xevious: if it's valid and not migrating that page will explain why [17:13] Great. Thanks. [17:13] in this case because of php-phpdocumentor-reflection [17:13] which i believe depends on a specific rev of php-parser [17:15] xevious: oh that's why i was down that rathole yesterday [17:15] php-phpdocumenter-reflection needs an updated php-mockery [17:15] which in turn fails to pass its tests by default :) [17:17] tseliot: downgrading was somewhat messy, but after cleaning up i enabled your ppa and everything upgraded smoothly :) [17:18] ginggs: that's good. Thanks for testing [17:18] yw! [17:23] xevious: ok, i see how to fix the mockery failure [17:23] xevious: just need to do it correctly :) [17:26] 'Correctly' seems like a solid plan. [17:27] 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] woo i think it is passing [17:30] that should unblock a few more (and fix the regression with php-defaults -> php-mockery) [17:31] xevious: also php-crypt-chap has been removed from bionic [17:31] xevious: see LP: #1749745 [17:31] Launchpad bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,Incomplete] https://launchpad.net/bugs/1749745 [17:31] Wasn't that a dependency of one of the Horde packages? [17:32] xevious: reverse-recommends only [17:33] juliank: ah okay, completely missed it. [17:34] Yay, no more mcrypt! [17:36] jbicha: so it's only the debian/fonts-cantarell.metainfo.xml that is doing the appstream thing? [17:37] tarzeau: yes, but that was upstreamed in Cantarell 0.100 (in Debian experimental) [17:37] jbicha: i'm always in contact with my packaged software, upstream (where possible) [17:38] so my plan would be, add it where it's useful, and provide it upstream for inclusion in future releases [17:38] 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] jbicha: that's great :) [17:39] i'll try it for fonts first, then games, then multimedia apps, later scientific software [17:39] 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] (upstream versions for the above) [17:39] * tarzeau votes for epoch! [17:42] 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] 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] the problem is uscan doesn't compare them properly, i think [17:51] with my manual mangle, it sees 1.0 as 1.0.0 and correctly updates to ti [17:51] *it [17:55] ah [17:56] tarzeau: that's my understanding right now, at least... [18:11] xevious: and that pulls in a new php-hamcrest :) [18:16] xevious: uploding php-hamcrest [18:16] xevious: waiting on a response to the above before i upload php-mockery [18:20] php-mail-mime's log is unclear about what the actual errors are. It just says which tests failed, not why. [18:21] xevious: let me look [18:22] xevious: yeh that's becuse they are using pear not phpunit directly :/ [18:22] it *might* need the php-pear from proposed [18:22] xevious: i can retry it locallyw ith propsed [18:23] xevious: do you have autopkgtest setup locally? [18:24] 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] xevious: 1) have lxd setup locally [18:25] xevious: 2) install autopkgtest [18:26] xevious: 3) autopkgtest-build-lxd ubuntu-daily:bionic [18:27] xevious: 4) autopkgtest -U -s php-mail-mime -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64 [18:28] xevious: if you want to test with proposed, you puass --apt-pocket=proposed [18:28] xevious: you can also pass it a soruce package dsc rather than the name, fi you have local stuff [18:28] easy-peasy [18:28] Thanks [18:29] xevious: you can also specify specific packages in the apt-pocket line, iirc, which is what LP is doing [18:29] and what changing the triggers changes [18:30] infinity: would you have any opinion on the d/watch change i mentioned above? (I can repost it if that's easier) [18:33] xevious: php-mail-mime also fails with proposed enabled [18:33] xevious: debugging it [18:55] 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] adt-run -U -s php-mail-mime -- adt-virt-lxd autopkgtest/ubuntu/bionic/amd64 [18:56] xevious: s/autopkgtest/adt/ in what i wrote [18:56] it just got renamed [18:57] There isn't a command just named adt and adt-run is complaining about those parameters. [18:59] nacc: adt-run: error: adt/ubuntu/bionic/amd64: unsupported action argument [18:59] That was the output when I ran: adt-run -U -s php-mail-mime -- adt-virt-lxd adt/ubuntu/bionic/amd64 [19:13] xevious: when you ran the build-lxd, it succeeded, right? [19:14] xevious: if so, then check then anme (`lxc image list`) [19:14] xevious: oh and adt might need three dashes [19:14] not two [19:14] Yes it succeeded. The image is named adt/ubuntu/bionic/amd64 [19:15] Trying three dashes [19:15] That did it [19:17] xevious: sorry, i forgot about that [19:19] 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] xevious: have you used lxd before on your system? [19:22] xevious: it might need soe network config if not [19:45] nacc: yes, no problem with version mangling to 1.0.0. [19:49] slangasek: ok, thanks [19:50] nacc: php-mail-mime passed on my system. [19:50] (without proposed enabled) [19:50] xevious: hrm, but with php-defaults from proposed? that's what is broken [19:51] Rerunning it [19:51] xevious: thanks, i definitely saw lall the failure siwth all proposed (which is my usual first test) [19:52] as it's easier to type then figuring out the exact packages to test (locally) [19:52] Yeah, I just added '--apt-pocket=proposed' for this run. [19:53] xevious: yep [19:54] 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] xevious: depends? :) [19:54] if uscan can find it, and uupdate works, and the package builds and tests successfully, go for it [19:55] but sometimes, that ends up making its own nest of dependency migrations [19:55] Yeah, gotta watch out for backwards incompatible changes, for sure. [19:57] If all the PHP library dependencies were packaged with the PHP applications, then several versions could happily coexist on a system. [19:57] I really need to post about that on the ubuntu-server mailing list. [19:58] nacc: Running the test with proposed enabled reproduced the log from the excuses... page. [19:58] xevious: yep [19:59] 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] xevious: you know how to build source pacakges? [20:00] Yes [20:00] xevious: so e.g., `pull-lp-source ... ` etc [20:00] make changes, etc. dpkg-buildpackage -S -nc -d [20:00] pass the resulting dsc to adt [20:00] (after modifying the changelog) [20:01] 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] ack [20:02] so don't worry about lp for now :) [20:02] (pull-lp-source is a way to do `apt-get source` without having to have sources defined) [20:02] and to pull down source from any release [20:02] you can file bugs against the srcpkg, and attach debdiffs (`debdiff existing.dsc new.dsc`) and i can sponsor them for you [20:02] That sounds relevant, since I've got LXC set up on a 16.04.3 system right now. [20:03] I'll read up on pull-lp-source and dig up my LP credentials. [20:03] I'm fairly certain my GPG keys are long gone. :\ [20:03] xevious: pull-lp-source doesn't require auth, fwiw [20:03] just the bug filing will [20:03] Right. [20:05] I'm going to go find some food to munch on. [20:06] bbiaf [20:07] xevious: sounds good, i'm uploading php-mockery now and i filed a bug to remove php-phpdocumentor-reflection [20:12] xevious: php-mail-mime is using count() in Mail/mimePart.php line 314 [20:14] xevious: changing it to be if (is_array($this->subparts) && .. ) and it passes [20:14] xevious: i'll upload that fix [20:17] xevious: oh i think it's fixed in 1.10.2 upstream [20:17] i'll update to that [20:17] (safer in this case) [20:51] xevious: ah it's in debian building right now (1.10.2-0.1 [20:51] nacc: php-doctrine-cache 1.7.1 should resolve the issues. Can you rerun its tests with the new package? [20:52] Woops [20:52] I forgot to refresh. [21:10] nacc: Are you still focused on Horde? [21:53] 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] watch woes? [21:53] nacc: It's not that uscan is sorting "incorrectly", just that it uses a dpkg version sort, and upstream doesn't. [21:54] I'm looking at php-guzzlehttp-promises and the archive it's pulling down doesn't include the tests folder. [21:55] ...just because they chose to upload a tarball without the tests folder for that release, apparently. [22:00] 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] infinity: it does that already (afaict) [22:01] infinity: but ack on the 'incorrectly' [22:01] xevious: i can look [22:01] nacc: Is there a setting on GH that makes it not include a 'tests' directory in archives? [22:02] xevious: not that i know of, but possibly it's controlled by a file in the repo [22:03] It sure is [22:03] .gitattributes [22:03] xevious: yeah [22:03] xevious: does that imply guzzlehttp-promises also fails without -proposed? [22:03] nacc: Oh! I focussed on the ~ and missed the 1.0 versus 1.0.0. Derp. [22:03] infinity: yeah, it's that bit [22:04] 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] 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] 1.3.0 should work, though. [22:04] infinity: ack, thanks [22:04] sigh, libc6 in bionic is < libc6 in artful-security? [22:05] that seems less than ideal? [22:05] 2.26-0ubuntu2 vs 2.26-0ubuntu2.1 [22:05] and does that imply a security fix raced with the bionic open? [22:08] xevious: you might compare the current package's results on artful [22:09] xevious: so the version in the archive now has a tests/ dir [22:10] Everything prior to 1.3.1 did, because there wasn't a .gitattributes file in the repo preventing tests from being exported. [22:10] xevious: oh i see [22:10] xevious: yeah, so you cn bump to just 1.3.0 if you want [22:11] 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] I could change the get-orig-source target in rules to use `git archive` instead of uscan. [22:12] xevious: you could do that, but then you'd also need to change it to git cloen first [22:12] that's not great [22:12] as you'd need to make git a build-depends [22:14] 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] xevious: i've done it before :) [22:14] xevious: do they explain upstream why they changed it? [22:15] To "improve packaging" https://github.com/guzzle/promises/commit/e278912eaaa94079b9277d5dbe23fc0a22d308bf [22:16] xevious: phpdox just migrated [22:16] 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] xevious: how? it's run from debian/rules? [22:17] xevious: where youdon't have a git repo [22:19] Well that plan's out the window [22:20] GitHub doesn't allow archiving. [22:20] xevious: so 1.3.0 didn't work? [22:20] nacc: You can pass `--remote=` to `git acrhive` to create a tarball of a remote repository. [22:20] xevious: oh interesting [22:20] xevious: i didn't realize that, sorry [22:21] It would still require adding git as a build dependency, which isn't great. [22:21] yeah [22:21] I'll just open a PR to make the tests directory export again. We'll see what they say. [22:23] 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]