[09:08] <sil2100> jibel: hey! How's the xenial dailies testing going? How bad is it? ;)
[09:09] <cpaelzer> hi, I happened to hear that one can retrigger autopkgtests but group packages
[09:09] <cpaelzer> like retry test on A, but only with this version of B
[09:09] <cpaelzer> I need just that to resolve bug 1748135 that I just analyzed
[09:09] <ubottu> bug 1748135 in vagrant-mutate (Ubuntu) "autopkgtests after shutdown of atlas depend on vagrant 2.x" [Undecided,New] https://launchpad.net/bugs/1748135
[09:10] <cpaelzer> does anybody have link to a howto, scripts, or anything that I can use to learn how that is done?
[09:21] <cpaelzer> pitti: sorry to bother, but you might know the answer to above ^^
[09:23] <pitti> cpaelzer: yes, that can be done with specifying a set of "triggers" with appropriate versions; like, test package A with these three versions from -proposed
[09:24] <pitti> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format describes the syntax
[09:25] <pitti> cpaelzer: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests gives the CLI for run-autopkgtest, but I think this is obsolete (nobody should have access to snakefruit any more)
[09:26] <pitti> cpaelzer: but if you have a typical retry URL, you can just  append more &trigger=srcpkg/version arguments if you want to run it against more packages from -proposed
[09:27] <cpaelzer> pitti: thanks, I'd construct one of those and ask you to review if that is ok
[09:27] <cpaelzer> back in a few minutes
[09:27] <pitti> sounds good
[09:31] <cpaelzer> pitti: http://paste.ubuntu.com/26540222/ ok ?
[09:34] <pitti> cpaelzer: LGTM! (corresponds to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vagrant)
[09:35] <cpaelzer> thanks pitti!
[09:36] <cpaelzer> I used an urlencoder actually and not copied from #vagrant, but as long as it works it is fine :-)
[09:55] <pitti> cpaelzer: I meant I compared the version number
[09:56] <cpaelzer> yeah I relaized that you did check there how the trigger for vagrant was
[09:57] <cpaelzer> I just meant I didn't copy from there, but instead used an encoder to get the appendix needed
[09:57] <cpaelzer> in any case it seems to work, which was the important part :-)
[09:57] <pitti> 👍
[09:58] <cpaelzer> death by UTF
[09:59] <pitti> cpaelzer: since these appear in full color and nicely rendered in plain terminals, I just like them even more
[09:59] <pitti> that started in Fedora 27, supposedly there's a newer font; (haven't tried in Ubuntu yet)
[10:13] <ginggs> tseliot: do you have an ETA for nvidia-graphics-drivers-390 ?
[10:18] <tseliot> ginggs: in the next few days, at least in 18.04
[10:20] <doko> xnox: we will have openssl1.0 for a while now? promote it? and subscribe foundations?
[10:20] <tseliot> ginggs: it's going to be available in a PPA first, together with glvnd enabled mesa
[10:21] <ginggs> tseliot: thanks, please don't forget to add libcuda-9.1-1 - needed for cuda 9.1 in debian experimental
[10:22] <tseliot> ginggs: done
[10:22] <ginggs> tseliot: ta!
[10:24] <tseliot> thanks for reminding me ;)
[11:37] <xnox> doko, yes, foundations should be subscribed; looking at componenets-mismatches, i am confused why only the udeb shows up without the main library.
[11:37]  * xnox subscribes things
[11:39] <xnox> doko, foundations bugs subscribed
[11:53] <doko> jamespage: pysmi and pycryptodome need a MIR (dep of python-snmp4, openstack subscribed)
[12:06] <jamespage> doko: ta - either coreycb or I will pick that up
[12:07] <ginggs> tseliot: please ping me when it's in the PPA, I have a machine with two Titan X cards ready for testing!
[12:32] <jbicha> pitti: color emoji works in Ubuntu 18.04 but not 17.10
[12:32] <jbicha> it works in Debian GNOME Testing too
[12:33] <jbicha> pitti : is it possible to push https://launchpad.net/ubuntu/+source/gvfs/1.20.1-1ubuntu3 to Debian?
[12:45] <doko> xnox: did you find out where the -m64 on arm64 comes from?
[12:48] <pitti> jbicha: not necessarily; Debian's LXC containers likely don't have sudo installed or configured
[12:49] <pitti> the test could start out as root, depend on sudo, create a user, and drop privs maybe
[12:49] <pitti> but this has always been a bit awkward
[12:51] <jbicha> pitti: for ci.debian.net, it already has "SKIP Test requires machine-level isolation but testbed does not provide that"
[12:53] <pitti> jbicha: ah, I see; it would still not work when running it with qemu against a bootstrapped VM, but then again maybe the current debian test version also doesn't
[12:53] <pitti> so if that's the only remaining delta, I guess it doesn't hurt much to  commit that to debian
[12:56] <jbicha> we have two MIRs we need too, at least the libnfs MIR would be nice to simplify allowing us to sync from Debian
[12:56] <jbicha> if you have any idea about how the "create a user and drop privs" thing would work, that would be nice
[12:57] <jbicha> but I guess there aren't many people in Debian running autopkgtests besides ci.debian.net
[12:57] <pitti> (meeting, TTYL)
[13:17] <cpaelzer> xnox: the nova autopkgtest is resolved, I kicked the one from the openssl upload again
[13:33] <tseliot> ginggs: I will, thanks
[13:39] <xnox> doko, no, not yet, will do.
[13:40] <doko> xnox: if it was in kamailio, it's now fixed
[13:41] <xnox> doko, yes, as that is part of ssl1.1 transition, green on all other arches. thanks!
[13:47] <doko> seb128, didrocks, jbicha: how takes care about DX Packages, or Ubuntu Touch seeded packages these days? jbicha renamed d-conf to dconf, and it needs a new bug subscriber
[13:47] <doko> who even ...
[13:49] <seb128> doko, that's a desktop GNOME upstream package
[13:50] <seb128> nothing to do with dx or touch
[13:50] <seb128> but good point, we should unsubscribe ourselve from those if we are subscribe to any
[13:51] <seb128> doko, I subscribed desktop-packages to dconf now, thanks for pointing it out
[13:56] <doko> ta
[14:09] <doko> jbicha: gtk-doc still ftbfs
[14:16] <jbicha> doko: yes, I don't know how to fix gtk-doc
[14:17] <doko> :-/
[14:26] <seb128> doko, btw could you give another look to the libblockdev MIR, jbicha addressed your comments and it's blocked the udisks update which is blocking other things
[14:34] <doko> seb128: ok
[14:36] <seb128> doko, thanks
[14:37] <seb128> doko, also any idea if something is not set up right on https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1695565 , it has been sitting there since june, I know the MIR team is busy but that looks like it's too long and I wonder if it's not showing up on the review list for some reason?
[14:37] <ubottu> Launchpad bug 1695565 in chrome-gnome-shell (Ubuntu) "[MIR] chrome-gnome-shell" [Undecided,Confirmed]
[14:46] <dgadomski> hey seb128, fyi fix for bug #1644662 has been upstreamed, I've attached debdiffs with fixes for xenial-bionic
[14:46] <ubottu> bug 1644662 in gnome-themes-standard (Ubuntu Bionic) "Icons missing when appearance setting is "high contrast"" [Undecided,New] https://launchpad.net/bugs/1644662
[14:47] <seb128> dgadomski, yeah, nice, thanks
[14:47] <seb128> I'm going to try to have a look
[15:06] <pitti> jbicha: "there aren't many people in Debian running autopkgtests besides ci.d.n"> agreed, so commiting that wouldn't hurt too much
[15:06] <pitti> and it's a rather nasty hack anyway - the test needs to set up something as root, but wants to run as user, and makes assumptions about sudo working (without password)
[16:07] <doko> why are the python-gnupg tests hang on the buildds?  succeed locally
[16:10] <seb128> hum, dpkg/bionic changed in a way that makes pkgbinarymangler tests unhappy
[16:20] <seb128> ""no entry control.tar.gz in archive" hum
[17:41] <smoser> ok... i'm trying to come up with the url to a .dsc file for a specific version of a source package.
[17:43] <smoser> easiest way to get that ?
[17:46] <rbasak> Go via "Publishing History"?
[17:46] <rbasak> Or you mean automatically by API?
[18:09] <smoser> rbasak: well, i was  meaning just through apt
[18:10] <rbasak> I wonder if apt-get source foo=version works
[18:11] <rbasak> Another might be to run chdist against /var/lib/apt/lists/something, but that is perhaps not using apt depending on your definition :)
[18:11] <smoser> well, it would
[18:11] <smoser> here. i'll describe :)
[18:11] <rbasak> I'm pretty confident that the chdist would work
[18:11] <rbasak> Ah
[18:11] <rbasak> I mean
[18:11] <rbasak> Uh
[18:11] <rbasak> chdist?
[18:11] <rbasak> I mean grep-dctrl
[18:12] <xevious_> PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.1.
[18:12] <xevious_> hah
[18:12] <xevious_> oops
[18:12] <xevious_> Typo, clearly.
[18:12] <rbasak> A PHP transition is still in progress.
[18:12] <xevious_> Correction: PHP dependencies are currently questionable in Bionic: `php-cli` pulls in PHP 7.1, but `php-xdebug` pulls in PHP 7.2.
[18:12] <smoser> grep-dctrl, maybe helpful.
[18:13] <xevious_> rbasak: Is there a page or mailing list discussion that outlines the transition?
[18:13] <xevious_> Also, is there anything I can do to help with the transition?
[18:15] <rbasak> http://people.canonical.com/~ubuntu-archive/transitions/html/php7.2.html lists it as done, but I suspect that's only to -proposed rather than landed in the release pocket.
[18:15] <rbasak> nacc has been working on the transition, but he's out until Monday now I think.
[18:15] <rbasak> I wouldn't want to step on his toes.
[18:16] <xevious_> Of course.
=== xevious_ is now known as xevious
[18:18] <xevious> Hopefully we can chat about it more on Monday when he's back. If there's any work that can be split up, I'm able to help and can rally at least one more.
[18:18] <rbasak> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults is how it currently looks.
[18:18] <rbasak> There are probably other packages caught up in it as well.
[18:19] <rbasak> xevious: thank you for the offer. Let's see what nacc says on Monday (or feel free to ping him directly here)
[18:20] <smoser> rbasak: http://paste.ubuntu.com/26542394/
[18:21] <Pharaoh_Atem> rbasak: the php-libvirt-php import from Debian is crashing on php7.2
[18:21] <Pharaoh_Atem> which is weird, because in Fedora, my php-libvirt package built just fine with php7.2
[18:21] <Pharaoh_Atem> rbasak: that is, it's crashing on attempting to build against php7.2
[18:22] <Pharaoh_Atem> rbasak: has nacc been away for a while? I've been trying to get in touch with him...
[18:23] <rbasak> smoser: another approach I've seen done in quite a few packages is to generate another binary package for test purposes that contains what you need. Eg. "curtin-vmtest".
[18:24] <rbasak> That would depend on curtin. Then for your test run, just enable the PPA (or whatever your binary package source is) and install curtin-vmtest, and you have what you needed from the source tree.
[18:24] <smoser> rbasak: i had thought about that.
[18:24] <rbasak> Pharaoh_Atem: I'm not sure. He's got very little overlap with my timezone, so I tend not to notice.
[18:25] <Pharaoh_Atem> :/
[18:25] <smoser> that m ight be the easiest path forward.
[18:25] <smoser> or even just curtin-source
[18:26] <rbasak> smoser: reasons in favour: I've seen it done that way in various places; you don't have to rely on an out-of-band connection between the two things.
[18:26] <rbasak> A recent example I used is openscad-testing
[18:26] <rbasak> mysql has something similar too IIRC.
[18:27] <rbasak> I'm not so sure about curtin-source. A -test package has a specific user purpose. A -source package sounds like a corruption of what binary packages are meant to be.
[18:27] <rbasak> I accept there's not much difference :)
[18:27] <rbasak> OTOH you could in theory put packaging assistance into a -test package.
[18:27] <rbasak> (to run the test suite, etc)
[18:27] <smoser> yeah, -source just seemed a better name, because it is easier if i just grab all of source.
[18:27] <smoser> than try to pick out vmtest/ portion or something.
[18:28] <smoser> where woul dyou suggest it installing files to ?
[18:28] <rbasak> /usr/share/curtin-vmtest/
[18:29] <rbasak> Or /usr/share/curtin/vmtest/
[18:29] <rbasak> Assuming that they're not architecture-specific, etc.
[19:59] <jbicha> infinity: could you explain https://launchpad.net/ubuntu/+source/gvfs/1.34.1-1ubuntu3 ?
[21:04] <infinity> jbicha: Seems pretty self-explanatory?  /etc/init doesn't exist on all Ubuntu systems.
[21:09] <infinity> jbicha: It was fixing this: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/g/gvfs/20171028_074316_b5c74@/log.gz
[21:09] <infinity> jbicha: It would be failing in Debian the same way, except that Debian doesn't run the tests at all because they require isolation.
[21:19] <jbicha> ok, the file name was confusing though (upstart)
[21:19] <infinity> jbicha: Because "/etc/init" is a path specific to upstart.
[21:19] <infinity> jbicha: Hence that test started failing when we switched to systemd and removed upstart scripts from the testbed.
=== ogasawara is now known as Guest91911
=== TJ- is now known as Guest27109
=== TJ_Remix is now known as TJ-
[22:05] <cjwatson> smoser: If you literally just want a URL, I thought I mentioned that on #launchpad the other day?  https://launchpad.net/~OWNER/+archive/ubuntu/PPANAME/+files/PACKAGE_VERSION.dsc always works as long as the source package hasn't been removed for long enough that it's been garbage-collected.
[22:07] <cjwatson> (lp.soyuz.browser.archive.ArchiveNavigation -> lp.services.librarian.browser.FileNavigationMixin -> lp.soyuz.model.archive.Archive.getFileByName)
[22:32] <smoser> cjwatson: well that works if i know it came from a ppa. but this doesnt  just test ppa. also tests proposed or archive.
[22:32] <smoser> so i wanted to find where it comes from and go off that.
[22:32] <smoser> https://code.launchpad.net/~smoser/curtin/+git/curtin/+merge/337388 is what i have
=== Guest91911 is now known as ogasawara
=== ogasawara is now known as Guest23352