| xevious | nacc: phpdox 0.10.1 introduced namespaced PHPUnit classes. The latest tagged version is 0.11.0. | 00:03 |
|---|---|---|
| xevious | I've got a loose definition of calling it a day. | 00:04 |
| 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:05 |
| nacc | xevious: they are wedged (i just checked, thanks for the poke) on php-phpdocumentor-reflection | 00:06 |
| nacc | looking at it now | 00:06 |
| nacc | xevious: looks like it needs an update too | 00:08 |
| nacc | xevious: heh, 1.1.0 packaged, 3.0.0 released upstream | 00:09 |
| nacc | sometimes Debian | 00:09 |
| * nacc shakes fist | 00:09 | |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| xevious | Yeah, Horde's got to go. | 00:16 |
| xevious | I hope there's some activity on this front soon: https://wiki.php.net/rfc/deprecate-pear-include-composer | 00:17 |
| nacc | xevious: yeah that would make sense to me | 00:18 |
| nacc | so much of PECL is cruft | 00:18 |
| 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:20 |
| 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:27 |
| 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:29 |
| 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:30 |
| nacc | cjwatson: yeah that's a good point | 00:32 |
| 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:35 |
| 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:36 |
| 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:38 |
| xevious | nacc: Have you heard back about mcrypt? | 00:46 |
| nacc | xevious: not yet | 00:46 |
| xevious | If PHP upstream is abandoning it, it seems silly to go through the effort of packaging the PECL version. | 00:47 |
| 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:49 |
| sarnold | mcrypt deserves the same inferno, right? | 00:52 |
| nacc | xevious: i'd start with ubuntu-server@lists.ubuntu | 00:56 |
| Unit193 | sarnold: Except, I thought I needed that for something, but for the life of me can't remember what! | 00:57 |
| xevious | sarnold: Yeah. Projects still using mcrypt need to update and get with the times. | 00:59 |
| === BrAsS_mOnKeY is now known as william | ||
| === sergiusens_ is now known as sergiusens | ||
| cpaelzer | hmm - all x86 builders seem to be locked in "cleaning" | 09:12 |
| cpaelzer | is there another maintenance change going on or do the just need some help to get out of that state? | 09:13 |
| cjwatson | probably just the latter. poking | 09:16 |
| cpaelzer | I see them turn idle and picking up jobs again, thanks cjwatson | 09:18 |
| 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:02 |
| Laney | ok | 10:04 |
| seb128 | Laney, thx! | 10:05 |
| tseliot | ginggs: I have just uploaded 390.25-0ubuntu1~ppa1.4, and the upgrading issues should be gone. Please test it, if you can | 10:45 |
| 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 | 11:07 |
| tarzeau | how to get software mentioned in "Software" ? | 13:29 |
| * tarzeau would like to suggest something for "Audio Creation & Editing": klystrack, protracker, schismtracker, milkytracker | 13:30 | |
| tarzeau | and how come, in Games, "Mr Boom" has a "No screenshot provided"? | 13:31 |
| tarzeau | and the "Fonts" section is half-screen empty... | 13:32 |
| tarzeau | Education & Science, Astronomy: is missing saods9 | 13:33 |
| juliank | tarzeau: saods9 does not provide any appstream data | 13:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| tarzeau | desktop linux users are so rare | 13:42 |
| 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:43 |
| 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:44 |
| juliank | just like vs code, atom, gnome-builder, and their friends | 13:45 |
| juliank | or well, a bad joke, rather | 13:46 |
| juliank | hence I use geany | 13:46 |
| 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:47 |
| juliank | app has menu => throw away | 13:48 |
| 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:52 |
| * tarzeau found appstream-generator | 13:56 | |
| jbicha | tarzeau: ideally, the appstream metadata is upstream (it is for official GNOME apps) | 14:11 |
| jbicha | see also https://appstream.debian.org/sid/main/ or http://appstream.ubuntu.com/ | 14:12 |
| ginggs | tseliot: thanks, i'll try downgrading + upgrading - no problems with previous version and cuda 9.1 | 14:14 |
| tseliot | ginggs: great, thanks | 14:19 |
| 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:24 |
| 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:26 |
| juliank | Mostly by Fedora, SUSE, and Debian, IIRC | 14:27 |
| 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:28 |
| juliank | there also are more than those two store apps | 14:29 |
| roaksoax | /win 3 | 14:46 |
| xevious | It'd be convenient if the first line of the autopkgtest logs was the date & time that the job started. | 15:21 |
| 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:32 |
| LocutusOfBorg | (I spent some time over the fedora/upstream bugs today) | 15:33 |
| 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:37 |
| 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:40 |
| LocutusOfBorg | jbicha, I mean, they arent related to the transition, and probably the problem is also in release | 15:43 |
| 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:47 |
| LocutusOfBorg | so, relaxing the tests is fine I would say | 15:53 |
| jbicha | that would make the tracker autopkgtest useless, right? | 15:58 |
| LocutusOfBorg | yep :/ | 16:01 |
| jbicha | do you want to open a tracker bug upstream to complain about the troubles they are causing us? | 16:01 |
| juliank | Failing tests should be optionalllllllllllll | 16:08 |
| juliank | Well, it should say ignored failure or something, everything else is just bad | 16:08 |
| xevious | nacc: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_101023_php-defaults_issues-md | 16:29 |
| nacc | xevious: thanks | 16:30 |
| nacc | i think mcrypt has more than that | 16:30 |
| nacc | based up on reverse-depends php-mcrypt | 16:30 |
| xevious | I just based that on the autopkgtest logs. | 16:31 |
| nacc | ah ok | 16:31 |
| nacc | yeah | 16:31 |
| 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:32 |
| nacc | but yeah i can use that | 16:33 |
| * Laney has a race condition with juliank's race condition post :-) | 16:50 | |
| 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:51 |
| juliank | Laney: I wrote all this on IRC yesterday already, should have posted it to the ML then, but ML required some setup | 16:52 |
| 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:53 |
| 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:56 |
| 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:57 |
| Laney | mmm | 16:59 |
| 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:00 |
| 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:01 |
| juliank | and now more errors are transient than before or something | 17:02 |
| juliank | Well, any error from connect() is transient IIRC | 17:02 |
| 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:03 |
| juliank | I should (1) add an option to control stuff (2) SRU it everywhere | 17:04 |
| 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:05 |
| 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:07 |
| 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:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| ginggs | tseliot: downgrading was somewhat messy, but after cleaning up i enabled your ppa and everything upgraded smoothly :) | 17:17 |
| tseliot | ginggs: that's good. Thanks for testing | 17:18 |
| ginggs | yw! | 17:18 |
| nacc | xevious: ok, i see how to fix the mockery failure | 17:23 |
| nacc | xevious: just need to do it correctly :) | 17:23 |
| xevious | 'Correctly' seems like a solid plan. | 17:26 |
| 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:27 | |
| nacc | woo i think it is passing | 17:29 |
| nacc | that should unblock a few more (and fix the regression with php-defaults -> php-mockery) | 17:30 |
| nacc | xevious: also php-crypt-chap has been removed from bionic | 17:31 |
| nacc | xevious: see LP: #1749745 | 17:31 |
| ubottu | Launchpad bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,Incomplete] https://launchpad.net/bugs/1749745 | 17:31 |
| xevious | Wasn't that a dependency of one of the Horde packages? | 17:31 |
| nacc | xevious: reverse-recommends only | 17:32 |
| tarzeau | juliank: ah okay, completely missed it. | 17:33 |
| xevious | Yay, no more mcrypt! | 17:34 |
| tarzeau | jbicha: so it's only the debian/fonts-cantarell.metainfo.xml that is doing the appstream thing? | 17:36 |
| 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:37 |
| 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:38 |
| 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:39 | |
| 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:42 |
| 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:50 |
| 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:51 |
| tarzeau | ah | 17:55 |
| nacc | tarzeau: that's my understanding right now, at least... | 17:56 |
| nacc | xevious: and that pulls in a new php-hamcrest :) | 18:11 |
| nacc | xevious: uploding php-hamcrest | 18:16 |
| nacc | xevious: waiting on a response to the above before i upload php-mockery | 18:16 |
| xevious | php-mail-mime's log is unclear about what the actual errors are. It just says which tests failed, not why. | 18:20 |
| nacc | xevious: let me look | 18:21 |
| 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:22 |
| nacc | xevious: do you have autopkgtest setup locally? | 18:23 |
| 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:24 |
| nacc | xevious: 1) have lxd setup locally | 18:25 |
| nacc | xevious: 2) install autopkgtest | 18:25 |
| nacc | xevious: 3) autopkgtest-build-lxd ubuntu-daily:bionic | 18:26 |
| nacc | xevious: 4) autopkgtest -U -s php-mail-mime -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64 | 18:27 |
| 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:28 |
| 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:29 |
| nacc | infinity: would you have any opinion on the d/watch change i mentioned above? (I can repost it if that's easier) | 18:30 |
| nacc | xevious: php-mail-mime also fails with proposed enabled | 18:33 |
| nacc | xevious: debugging it | 18:33 |
| 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:55 |
| 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:56 |
| xevious | There isn't a command just named adt and adt-run is complaining about those parameters. | 18:57 |
| 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 | 18:59 |
| nacc | xevious: when you ran the build-lxd, it succeeded, right? | 19:13 |
| 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:14 |
| xevious | Trying three dashes | 19:15 |
| xevious | That did it | 19:15 |
| nacc | xevious: sorry, i forgot about that | 19:17 |
| 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:19 |
| nacc | xevious: have you used lxd before on your system? | 19:22 |
| nacc | xevious: it might need soe network config if not | 19:22 |
| slangasek | nacc: yes, no problem with version mangling to 1.0.0. | 19:45 |
| nacc | slangasek: ok, thanks | 19:49 |
| 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:50 |
| xevious | Rerunning it | 19:51 |
| nacc | xevious: thanks, i definitely saw lall the failure siwth all proposed (which is my usual first test) | 19:51 |
| 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:52 |
| nacc | xevious: yep | 19:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| xevious | nacc: Running the test with proposed enabled reproduced the log from the excuses... page. | 19:58 |
| nacc | xevious: yep | 19:58 |
| 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? | 19:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| xevious | I'm going to go find some food to munch on. | 20:05 |
| xevious | bbiaf | 20:06 |
| nacc | xevious: sounds good, i'm uploading php-mockery now and i filed a bug to remove php-phpdocumentor-reflection | 20:07 |
| nacc | xevious: php-mail-mime is using count() in Mail/mimePart.php line 314 | 20:12 |
| nacc | xevious: changing it to be if (is_array($this->subparts) && .. ) and it passes | 20:14 |
| nacc | xevious: i'll upload that fix | 20:14 |
| 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:17 |
| 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:51 |
| xevious | Woops | 20:52 |
| xevious | I forgot to refresh. | 20:52 |
| xevious | nacc: Are you still focused on Horde? | 21:10 |
| 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:53 |
| xevious | I'm looking at php-guzzlehttp-promises and the archive it's pulling down doesn't include the tests folder. | 21:54 |
| xevious | ...just because they chose to upload a tarball without the tests folder for that release, apparently. | 21:55 |
| 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:00 |
| 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:01 |
| nacc | xevious: not that i know of, but possibly it's controlled by a file in the repo | 22:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| nacc | xevious: you might compare the current package's results on artful | 22:08 |
| nacc | xevious: so the version in the archive now has a tests/ dir | 22:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| xevious | To "improve packaging" https://github.com/guzzle/promises/commit/e278912eaaa94079b9277d5dbe23fc0a22d308bf | 22:15 |
| 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:16 |
| nacc | xevious: where youdon't have a git repo | 22:17 |
| xevious | Well that plan's out the window | 22:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| nacc | xevious: so you're still working on guzzlehttp-promises? mockery should migrate in a bit and i'll retrigger it then | 22:28 |
| xevious | I'm just going to open a PR with the change and move onto the next PHPUnit-related one. | 22:29 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| nacc | xevious: which is probably ideal ;) | 22:37 |
| xevious | Ok | 22:37 |
| xevious | I'll do both | 22:37 |
| 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:41 |
| nacc | and the extra space is ... minimal | 22:42 |
| 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:43 |
| 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:46 |
| 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:47 |
| 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:54 |
| 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:55 |
| 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:56 |
| sarnold | https://irclogs.ubuntu.com/2018/02/15/%23ubuntu-discuss.html#t20:17 | 22:57 |
| nacc | sarnold: thanks | 22:57 |
| nacc | uggggh | 23:00 |
| nacc | compiz-core migrated without a unity rebuild? | 23:00 |
| nacc | unity: depends on compiz-core-abiversion-20151010, | 23:00 |
| 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:01 |
| 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:02 |
| sarnold | is this time for the !regressions batsignal or whatever it is? | 23:07 |
| nacc | heh | 23:07 |
| 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:08 |
| nacc | xevious: fyi php-horde-core uploaded | 23:10 |
| xevious | Great. Looking forward to seeing a bunch more green... | 23:12 |
| nacc | xevious: bbiab | 23:14 |
| tsimonq2 | Can a Core Dev please approve this bug nomination? 1746807 | 23:17 |
| tsimonq2 | bug 1746807 even | 23:17 |
| ubottu | bug 1746807 in base-installer (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807 | 23:17 |
| rbasak | tsimonq2: why does it need nomination for Bionic? | 23:17 |
| 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:18 |
| tsimonq2 | s/Bionic out/Bionic if I have access to out/ | 23:19 |
| tsimonq2 | rbasak: I guess there's no *need* to but it's good for bookkeeping I guess | 23:20 |
| 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:22 |
| 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:23 |
| rbasak | But I don't think anyone has actually tried to define a policy on this since Kate left. | 23:24 |
| tsimonq2 | OK | 23:24 |
| rbasak | infinity, slangasek: ^ opinion? | 23:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| bdmurray | notfixing | 23:29 |
| slangasek | it might be rls-$series-declined | 23:29 |
| slangasek | ok that | 23:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| * 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:34 |
| 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:35 |
| xnox | we hardly are a zero-boogz-found team =/ | 23:36 |
| xnox | aka inbox-zero | 23:36 |
| rbasak | That sounds reasonable except I'm not convinced about the need to peg it to a particular release | 23:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:46 |
| nacc | xevious: i'm back now | 23:55 |
| nacc | xevious: nice, i'm guessing you need sponsorship for that? file a bug against hte srcpkg and upload the debdiff to it | 23:56 |
| nacc | xevious: and subscribe me to it | 23:57 |
| cjwatson | jbicha: done | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!