[02:16] <vibhav> Is there any way I can get started with ubuntu documentation?
[02:17] <vibhav> I have been editing ubuntu-manual for some time now
[02:21] <jbicha> vibhav: sure, we definitely could use some help
[02:24] <jbicha> there's some info on https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation
[02:25] <jbicha> and you can find the source at https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/precise
[02:28] <vibhav> jbicha: Which are the files I need to edit
[02:28] <vibhav> I have downloaded the branch
[02:29] <jbicha> vibhav: look at the ubuntu-help/C directory
[02:29] <vibhav> jbicha: Thanks!
[02:30] <jbicha> you can run yelp . in that directory to see the current help
[02:31] <jbicha> Ctrl-L is an undocumented way to see what page you're looking at
[02:31] <vibhav> Do I need to then create a new branch , push my edited stuff to it and then propose it for merging?
[02:32] <jbicha> yes, you've proposed bzr branches for merging before, right?
[02:33] <vibhav> I edit ubuntu-manual where anyone can push branches
[02:33] <vibhav> also , what do the check_status.sh scripts do?
[02:33] <vibhav> \s\status\validation
[02:36] <jbicha> you can run ./check_validation.sh net-antivirus.page to make sure your page is valid Mallard syntax
[02:36] <vibhav> thanks jbicha , that should be fine now
[02:42] <jbicha> the Unity specific pages need the most help
[02:42] <jbicha> vibhav: are you running Precise?
[02:43] <vibhav> jbicha: On a Virtual Machine
[02:43] <vibhav> I run oneiric
[02:44] <jbicha> does Unity 3D work in your VM?
[02:44] <vibhav> jbicha: I have not yet installed the addons , but they should work
[04:47] <vibhav> jbicha: Unity 3d now works


[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<EMAIL_ADDRESS>[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


[10:57] <rvba> allenap: I'm creating a small utility to send an event and create the event type if it doesn't exist.  How will that function (which will be called from the power-{on, off} tasks) get hold of the rpc_service object?
[10:57] <allenap> rvba: That’s a good question :)
[10:58] <allenap> rvba: I think we need to create a singleton to refer to all the services (or the application). I have some work towards that lying around...
[10:58] <rvba> allenap: yeah, I was thinking about a singleton too.
[10:59] <rvba> I'll make the utility take a rpc_service argument for now.
[10:59] <rvba> We can figure out how to pass it around later.
[10:59] <allenap> rvba: Yeah, that sounds good.
[10:59] <rvba> Cool.  Ta.
[13:58] <rvba> blake_r: reviewing your add-boot-type-to-node branch now.
[13:59] <blake_r> rvba: oh, cool. thanks
[14:37] <rvba> allenap: how can I easily unit test a method that uses other methods from the RPC region service?  Since I can't call call_responder directly… is there a better option or will I have to patch all the RPC methods?
[14:50] <allenap> rvba: See ClusterRPCFixture (er, which may not yet have landed). That wires up RPC calls to the cluster without needing sockets and whatnot.
[14:53] <rvba> allenap: right, not landed yet…
[15:58] <allenap> rvba: Got time for a very quick review before you finish for the weekend? https://code.launchpad.net/~allenap/maas/rpc-cluster-client-service-ipv4-only/+merge/227358
[15:59] <allenap> Just think, what a great way to finish a Friday.
[16:03] <blake_r> allenap: i can do it
[16:03] <rvba> allenap: nice!
[16:03] <allenap> blake_r: What a wise man you are :) Thanks.
[16:07] <rvba> allenap: thanks for the review!  Now, I need a review for https://code.launchpad.net/~rvb/maas/event-rpc-methods/+merge/227215 and https://code.launchpad.net/~rvb/maas/event-model/+merge/227156 and I'll be able to land this thing!
[16:08] <allenap> rvba: Looking at that now.
[16:08] <rvba> allenap: Thanks!
[17:08] <allenap> blake_r: Do you mind taking another look at https://code.launchpad.net/~allenap/maas/rpc-cluster-client-service-ipv4-only/+merge/227358?
[17:08] <blake_r> allenap: looking at it now
[17:08] <allenap> Ta.
[17:16] <blake_r> done
[17:22] <allenap> blake_r: Thanks. Have a tip top weekend.
[17:22] <blake_r> allenap: you to!


[07:06] <apw> clivejo, depends on the source of the new, debian syncs are faster
[09:36] -queuebot:#ubuntu-release- Unapproved: autopkgtest (trusty-backports/main) [4.2.2~ubuntu14.04.1 => 4.3~ubuntu14.04.1] (core)
[09:36] -queuebot:#ubuntu-release- Unapproved: autopkgtest (xenial-backports/main) [4.2.2~ubuntu16.04.1 => 4.3~ubuntu16.04.1] (core)
[09:37] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (trusty-backports) [4.3~ubuntu14.04.1]
[09:37] -queuebot:#ubuntu-release- Unapproved: autopkgtest (yakkety-backports/main) [4.2.2~ubuntu16.10.1 => 4.3~ubuntu16.10.1] (core)
[09:37] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (xenial-backports) [4.3~ubuntu16.04.1]
[09:37] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (yakkety-backports) [4.3~ubuntu16.10.1]
[10:14] -queuebot:#ubuntu-release- New: accepted ubiquity-slideshow-ubuntu [amd64] (zesty-proposed) [119]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [amd64] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [armhf] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [powerpc] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [s390x] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [arm64] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [ppc64el] (zesty-proposed) [16.12.1-0ubuntu1]
[10:19] -queuebot:#ubuntu-release- New: accepted libkf5kipi [i386] (zesty-proposed) [16.12.1-0ubuntu1]
[10:23] -queuebot:#ubuntu-release- New: accepted cantor [amd64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:23] -queuebot:#ubuntu-release- New: accepted cantor [armhf] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:23] -queuebot:#ubuntu-release- New: accepted cantor [ppc64el] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:23] -queuebot:#ubuntu-release- New: accepted cantor [arm64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:23] -queuebot:#ubuntu-release- New: accepted cantor [i386] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:26] -queuebot:#ubuntu-release- New: accepted marble [amd64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:26] -queuebot:#ubuntu-release- New: accepted marble [armhf] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:26] -queuebot:#ubuntu-release- New: accepted marble [powerpc] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:26] -queuebot:#ubuntu-release- New: accepted marble [s390x] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted marble [arm64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted marble [ppc64el] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:27] -queuebot:#ubuntu-release- New: accepted marble [i386] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:33] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [amd64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [armhf] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [powerpc] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [s390x] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [arm64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [ppc64el] (zesty-proposed) [4:16.12.1-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted kdegraphics-mobipocket [i386] (zesty-proposed) [4:16.12.1-0ubuntu1]
[11:04] -queuebot:#ubuntu-release- New: accepted spyder [amd64] (yakkety-proposed) [3.0.2+dfsg1-0ubuntu0.1]
[11:58] <acheronuk> Quick question: is the 'Testsuite: autopkgtest' field in main control file the way the autopkgtest system knows their are tests to execute?
[11:59] <acheronuk> *there
[12:21] -queuebot:#ubuntu-release- New binary: okular [ppc64el] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:22] <apw> acheronuk, i believe so, i think it is generated as part of package gneeration if that package has a debian/test/control
[12:22] -queuebot:#ubuntu-release- New binary: okular [amd64] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:22] -queuebot:#ubuntu-release- New binary: okular [i386] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:22] <apw> but i could be missing a step
[12:23] -queuebot:#ubuntu-release- New binary: okular [s390x] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:24] <apw> acheronuk, for the kernel we seem to specifiy the source package header Testsuite: autopkgtest by hand ... for what that is worth
[12:24] <acheronuk> apw: well, on a package we have where the last merge with debian removed the the testsuite (debian/tests/control and all), seems it's still trying to have tests run. so that main control field left in there looked the main candidate for blame to me
[12:25] -queuebot:#ubuntu-release- New binary: okular [powerpc] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:25] <acheronuk> I just wanted to check that seems likely before getting a ubuntu2 done
[12:25] <apw> acheronuk, yep, it is curtianly used for that
[12:26] <acheronuk> apw: ok. thanks :)
[12:29] -queuebot:#ubuntu-release- New binary: okular [arm64] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[12:29] -queuebot:#ubuntu-release- New binary: okular [armhf] (zesty-proposed/universe) [4:16.12.1-0ubuntu1] (kubuntu)
[16:25] <clivejo> hi, would someone with the necessary permission, please re-run autotests for purpose/1.1-4ubuntu1 with all-proposed enabled ?
[16:45] <ginggs> clivejo: done
[16:53] <clivejo> thanks
[16:54] <clivejo> need to get that added to our package list
[17:27] -queuebot:#ubuntu-release- New binary: caffe [s390x] (zesty-proposed/universe) [1.0.0~rc4-1] (no packageset)
[17:44] -queuebot:#ubuntu-release- New: accepted caffe [s390x] (zesty-proposed) [1.0.0~rc4-1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [amd64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [armhf] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [powerpc] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [s390x] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [arm64] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [ppc64el] (zesty-proposed) [4:16.12.1-0ubuntu1]
[18:11] -queuebot:#ubuntu-release- New: accepted okular [i386] (zesty-proposed) [4:16.12.1-0ubuntu1]
[20:46] -queuebot:#ubuntu-release- New binary: astyle [amd64] (zesty-proposed/universe) [2.06-2] (no packageset)
[20:46] -queuebot:#ubuntu-release- New binary: astyle [i386] (zesty-proposed/universe) [2.06-2] (no packageset)
[20:46] -queuebot:#ubuntu-release- New binary: astyle [s390x] (zesty-proposed/universe) [2.06-2] (no packageset)
[20:47] -queuebot:#ubuntu-release- New binary: astyle [arm64] (zesty-proposed/universe) [2.06-2] (no packageset)
[20:47] -queuebot:#ubuntu-release- New binary: astyle [armhf] (zesty-proposed/universe) [2.06-2] (no packageset)
[20:47] -queuebot:#ubuntu-release- New binary: astyle [powerpc] (zesty-proposed/universe) [2.06-2] (no packageset)


[00:06]  * ogra_ curses ...
[00:07] <ogra_> popey, i got wlan working on the nanopi-air ... but that now just shows a bug in netplan ... (the same one we had with the pi3)
[00:08] <ogra_> cyphermox, can we disable unbind/bind for all brcmfmac drivers in netplan ?
[00:08] <ogra_> (not just for -sdio)
[00:09]  * ogra_ has console-conf reliably explode (and the wlan device vanish when the config gets applied)
[00:13] <kyrofa> ogra_, why on _earth_ are you still awake?
[00:13] <ogra_> kyrofa, battling with my nanopi-air ... my head doesnt stop thinking when i go to bed ... so i can as well just fix it :)
[00:13] <ogra_> (and i did ... apart from that damned netplan bug)
[00:13] <kyrofa> Yeah I feel ya on that problem
[00:20] <mup> PR snapd#3565 closed: cmd/snap-repair: skeleton code around actually running a repair <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3565>
[00:35] <ogra_> cyphermox, (or mwhudson, not sure who cares for nplan nowadays ...) bug 1712224
[00:35] <mup> Bug #1712224: netplan should not try to unbind brcmfmac  <nplan (Ubuntu):New> <https://launchpad.net/bugs/1712224>
[00:35] <mup> PR snapcraft#1499 opened: repo: make errors based on SnapcraftError <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1499>
[00:44] <mup> PR snapcraft#1500 opened: grammar: move out of pluginhandler <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1500>
[04:38] <Son_Goku> jjohansen: hey
[04:45] <mup> PR snapcraft#1501 opened: tests: use assertThat instead of assertEqual <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1501>
[06:22] <mup> PR snapd#3776 opened: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3776>
[06:27] <zyga-suse> good morning
[06:47] <mvo> hey zyga-suse_ good morning. how are you?
[06:48] <mvo> zyga-suse_: if you could have a look a 3776 that would unbreak master
[07:03] <zyga-suse_> mvo: good morning, doing fine though we could use less rain :)
[07:03] <zyga-suse_> looking at the PR
[07:04] <zyga-suse_> mvo: looks good,
[07:04] <zyga-suse_> mvo: I'll grab breakfast/coffee and be back shortly
[07:05] <mvo> ta
[07:35] <zyga-suse_> re
[07:36] <mup> PR snapd#3776 closed: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3776>
[07:40] <zyga-suse_> mvo: 2.27.3 is non in stable yet, what are we waiting on?
[07:43] <mvo> zyga-suse_: I need to catchup with sergio and fgimenez - if QA is ok and CE got green light as well we can promote. but sergio was off yesterday so we couldn't promote then
[07:52] <mwhudson> ogra_: i think probably cyphermox, but if it's just a case of skipping the replug for another driver that sounds pretty easy
[07:53] <mwhudson> oh heh you patched it already
[07:54] <mwhudson> ogra_: give cyphermox a chance to look today if not, ping me and i'll merge it tomorrow?
[08:01] <fgimenez> hey mvo, afaik CE results are good so far (i've just forwarded you the last message in the 2.27.2 validation thread), not sure if they have finished though
[08:05] <mvo> fgimenez: thanks, that sounds promising
[08:06] <cjwatson> ogra_: The revision field of LP snap builds dates from May.  The difference you point out isn't mysterious: one of those snaps builds from bzr and the other from git.
[08:09] <cjwatson> ogra_: (The revision is the source VCS revision that the snap was built from, not the revision in the store.)
[08:20] <ogra_> cjwatson, oh, how confusing... but that explains it, thanks :)
[08:47] <mup> PR snapd#3777 opened: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
[08:59] <popey> ogra_: oooh!
[09:00] <popey> ogra_: looking forward to playing with it :)
[09:01] <ogra_> popey, i'll have an image ready soon
[09:05] <mup> Bug #1708703 changed: "enable" does not apply connected slot security policy <snapd:New for zyga> <https://launchpad.net/bugs/1708703>
[09:08] <mup> Bug #1711847 changed: "snap run" doesn't support not installed packages <snapd:New> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1711847>
[09:09] <popey> ogra_: super news :)
[09:09]  * ogra_ sits here waiting for "please press enter" already ....
[09:12] <ogra_> popey, note that you need an antenna ... the wifi wont find anything without one
[09:12] <popey> yeah, i have one
[09:13] <ogra_> bah, and i messed up
[09:13]  * ogra_ starts over
[09:13] <mup> PR snapd#3774 closed: spread: opt into unsafe IO during spread tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3774>
[09:13] <ogra_> (accidentially removing the SD when attaching the antenna on the running board isnt helpful ...)
[09:13] <zyga-suse> mvo: hey, I've assigned  https://bugs.launchpad.net/snapd/+bug/1709536 to you, since you worked on it recently and know the status better than I do
[09:13] <mup> Bug #1709536: snapd 2.26.14 on ubuntu-core won't start in containers anymore <lxd> <snapd:New for mvo> <systemd (Ubuntu):Fix Released by xnox> <systemd (Ubuntu Xenial):Confirmed for xnox> <systemd (Ubuntu Artful):Fix Released by xnox> <https://launchpad.net/bugs/1709536>
[09:14] <zyga-suse> mvo: can you please update the bug? I believe this is fixed but I wanted to be sure
[09:14] <zyga-suse> woot
[09:14] <zyga-suse> with the unsafe-io flag tests ran in sub 30 minutes :)
[09:14] <zyga-suse> it's a net win for all PRs
[09:21] <ogra_> ogra@localhost:~$ snap list
[09:21] <ogra_> Name                     Version       Rev   Developer  Notes
[09:21] <ogra_> core                     16-2.27.2     2715  canonical  core
[09:21] <ogra_> linux-generic-allwinner  4.11.0-13.19  16    ogra       kernel
[09:22] <ogra_> nanopi-air               16-0.1        x1               gadget
[09:22] <ogra_> ogra@localhost:~$
[09:22] <ogra_> popey, ^^^^
[09:22] <popey> is that good? :)
[09:22] <ogra_> (uploading an image for you noow)
[09:22] <ogra_> i'm ssh'ed in, yes, thats good ;)
[09:22] <popey> ok, now I need to find my nano pi!
[09:22] <popey> they're so small I lost it
[09:24] <ogra_> i lost one of my antennas on the weeked ... they're even smaller and the plug on the board isnt really fitting 100% here
[09:32] <ogra_> popey, http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz (once you found it)
[09:32] <popey> ta
[09:36] <pedronis> mvo: could you try to merge master into snapd#3757
[09:36] <mup> PR snapd#3757: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/3757>
[09:38] <zyga-suse> please don't merge 3778
[09:38] <mup> PR snapd#3778 opened: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <https://github.com/snapcore/snapd/pull/3778>
[09:39] <mup> PR snapd#3778 closed: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3778>
[09:41] <mvo> pedronis: sure, I have a look now
[09:57]  * zyga-suse reboots
[09:58] <ogra_> OH!
[09:58] <ogra_> thats cool
[09:59] <ogra_> popey, seems the image work just as fine if you dd it to the internal mmc, so you only need the SD to dd it to /dev/mmcblk1
[09:59] <ogra_> *works
[09:59] <popey> there's internal mmc?
[09:59] <ogra_> yeah :D
[09:59] <popey> huh, that's handy
[09:59] <popey> so boot from it, then copy image to it then dd that to internal mmc?
[09:59] <ogra_> right
[10:00] <popey> thats amazing
[10:00] <ogra_> well, its a bit more tricky since you need to get nanopi-air.img.xz onto the SD ...
[10:00] <ogra_> and you indeed need to configure twice
[10:00] <popey> right, but that part is known
[10:00] <ogra_> but yeah, the board can run completely standalone, no SD needed
[10:00] <mup> PR snapd#3779 opened: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
[10:01] <ogra_> i might produce an image with hacked initrd and the img file pre-loaded on the SD ;)
[10:01] <ogra_> so that you get an option to directly write to mmc ... (just an initrd UI to dd)
[10:02] <mvo> pedronis: just to clarify for 3777 - we need to look at both state *and* disk because one might be corrupted (or both :)
[10:02] <pedronis> mvo: well, my point was not about corrupted, more that state has only the last runs
[10:03] <pedronis> per seq
[10:04] <pedronis> mvo: for each sequence num we could have multiple revisions and for each revision we could have multiple runs
[10:04] <zyga-suse> mvo: did you push https://github.com/snapcore/snapd/pull/3779 earlier? I recall seeing the same diff
[10:04] <mup> PR snapd#3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
[10:04] <mvo> pedronis: aha, indeed, let me fix that
[10:05] <mvo> zyga-suse: no, but its similar to 3502 which you reviwed 6 days ago
[10:05] <zyga-suse> aha, thank you
[10:05] <ogra_> mvo, FYI, i added the debdiff from https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1712224 to our netplan package in the image PPA
[10:05] <mup> Bug #1712224: netplan should not try to unbind brcmfmac (like brcmfmac-sdio) <patch> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1712224>
[10:06] <mvo> ogra_: thank you
[10:07] <mvo> pedronis: I will rework it to ignore the state, sounds reasonable?
[10:08] <mvo> zyga-suse: fwiw, I addressed your comments on 3502
[10:08] <mvo> zyga-suse: it has a +1 from jamie, so an extra +1 would help :)
[10:08] <zyga-suse> aha, thank you, I'll check that out
[10:10]  * zyga-suse needs a break
[10:11] <zyga-suse> it's finally less cloudy/rainy, I'm stuck indoors for too long
[10:17] <pedronis> mvo: you will still need the state for skip
[10:18] <pedronis> mvo: I mean some stuff will be skip immediately and then there's no files on disk (at least atm)
[10:18] <mvo> pedronis: aha, what condition currently skips them?
[10:19] <pedronis> mvo: not matching model,  arch etc
[10:19] <mvo> pedronis: ok
[10:19] <pedronis> mvo: anyway probably non verbose mode shouldn't list skipped stuff that didn't run anything
[10:19] <pedronis> (there might be a lot of those for a given device)
[10:20] <mvo> pedronis: ok, I added a FIXME for myself and will look once the other bits are in place
[10:20] <mvo> pedronis: will work on the on-disk thing after lunch
[10:21] <pedronis> mvo: I'm waiting for green to merge one of my repair PRs
[10:22] <mvo> pedronis: how do you feel about renaming "scipt.r0" to "r0.script" for consistency with the other file prefixes (output and stamp)?
[10:24] <popey> ogra_:
[10:24] <popey> popey@localhost:~$ uname -a
[10:24] <popey> Linux localhost.localdomain 4.11.0-13-generic #19 SMP Sun Aug 20 16:36:37 CEST 2017 armv7l armv7l armv7l GNU/Linux
[10:24] <popey> popey@localhost:~$ snap list
[10:24] <popey> Name                     Version       Rev   Developer  Notes
[10:24] <popey> core                     16-2.27.2     2715  canonical  core
[10:24] <popey> linux-generic-allwinner  4.11.0-13.19  16    ogra       kernel
[10:24] <popey> nanopi-air               16-0.1        x1               gadget
[10:24] <popey> \o/
[10:24] <popey> thank you!
[10:24] <ogra_> wohooo !!!!
[10:25]  * ogra_ pushes the gadget to the store
[10:25] <popey> so mmcblk0 is the sd card and mccblk1 is the internal mmc, but I guess the internal one will be 0 once i reboot without the sd card?
[10:25] <ogra_> nope, it stays 1
[10:26] <ogra_> but you dont need to care anyway, core operates based on filesystem labels
[10:26] <popey> how big is it?
[10:26] <popey> wonder how many snaps I can install before it blows up
[10:27] <popey> oh, 8GB
[10:27] <ogra_> /dev/mmcblk1p2  7.1G  400M  6.3G   6% /writable
[10:27] <popey> that's enough
[10:27] <ogra_> yeah
[10:27] <popey> sweeet!
[10:27] <popey> interesting, there is already two partitions on the internal device here
[10:28] <ogra_> i wonder how long it will take to empty my USB powerbank
[10:28] <popey> it has a filesystem on it already
[10:28] <ogra_> yeah, there are some hardcoded "boot" partitions ... thats a kernel thing
[10:28] <ogra_> oh ?
[10:28] <ogra_> mine didnt have any filesystems i think
[10:29] <popey> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
[10:29] <ogra_> ah
[10:29] <ogra_> that their hacked up deboostrap thingie that they advertise as Ubuntu Core
[10:29] <popey> ah okay
[10:29] <popey> will dd over it
[10:37] <popey> yay, booting off internal mmc, nice work ogra_ ! I smell a forum post :)
[10:38] <ogra_> gimme a bit ... i need to get the gadget snap past jdstrand in the store first and want to build a proper image :)
[10:39] <popey> super, I won't steal your thunder :)
[10:39] <ogra_> just imagine how cool it will be once you dont need a serial cable anymore (thats my next task with that kernel)
[10:40] <ogra_> jdstrand, https://dashboard.snapcraft.io/dev/snaps/8227/rev/1/ for you :)
[10:41] <mup> Bug #1712312 opened: Cannot add secondary group to user <Snappy:New> <https://launchpad.net/bugs/1712312>
[10:45] <mup> PR snapd#3780 opened: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
[10:51] <pedronis> mvo: I'm thinking about that, I'm not a fan of "r1..." tbh,  also because (though I'm not checking) revision can only increase, so we could use one counter across all revisions, and have revision later in the name
[10:55] <pedronis> mvo: we have also "repair.r#"  for the assertion atm
[10:55] <mup> PR snapd#3571 closed: cmd/snap-repair: recover brand/model from /var/lib/snapd/seed/assertions checking signatures and brand account <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3571>
[11:14] <pedronis> mvo: do you know when we are goin to cut 2.28 ?  there's some ongoing discussion that might need to changes to things that landed before it goes out
[11:19] <ogra_> pedronis, we dont even have 2.27.3 out
[11:20] <ogra_> (unless mvo decided to drop it and move the fix to 2.28)
[11:27] <mup> PR snapcraft#1486 closed: core: improve source caching logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1486>
[11:31] <zyga-suse> re
[11:31]  * zyga-suse feels better now
[11:33] <jdstrand> ogra_: yep, I saw. approved
[11:34]  * ogra_ hugs jdstrand
[11:34] <jdstrand> ogra_: also updated the review tools, but need a store sync of course
[11:34]  * jdstrand hugs ogra_ :)
[11:35] <popey> ogra_: what would you use to get the air on a new wifi network?
[11:35] <popey> like, over serial console, when at a meetup, connecting to their wifi
[11:35] <ogra_> either console-conf or edit the netplan config and call netplan apply
[11:36] <popey> is this documented somewhere?
[11:36] <ogra_> not sure ... /etc/netplan/00-snapd-config.yaml is the file to edit
[11:36] <popey> ta
[11:36] <ogra_> i guess cyphermox would know
[11:36] <popey> kk
[11:37] <ogra_> ah, wait ... i think it is "edit file", then "netplan generate" and then "netplan apply""
[11:39] <zyga-suse_> hey jdstrand
[11:39] <zyga-suse_> how are you doing
[11:47] <diddledan> would the LD_PRELOAD hack help with libpeas looking for libpythonloader.so in /usr/lib/libpeas-1.0/loaders/libpythonloader.so without $SNAP prefix?
[11:49] <zyga-suse> diddledan: maybe, maybe not, depending on some factors
[11:51] <diddledan> specifically I am referring to this preload hack: https://github.com/sergiusens/snapcraft-preload
[11:52] <mvo> pedronis: aha, so the dir also contains "repair.r#"? I will update my mocks
[11:52] <ogra_> diddledan, will that prevent peas from walking its buildin search path ?
[11:53] <diddledan> it looks like the thing does hook dlopen, so I'll give it a go
[11:53] <mvo> pedronis: I want to talk to cachio about the release, hopefully we can release today
[11:53] <ogra_> diddledan, alternatively https://developer.gnome.org/libpeas/stable/PeasEngine.html#peas-engine-add-search-path ...
[11:53] <pedronis> mvo: no, that is in a different set of dirs
[11:53] <ogra_> but i guess thats something you'd have to patch ...
[11:54] <ogra_> (and use getenv() to give it a env var with the $SNAP search path)
[11:55] <mvo> pedronis: aha, ok. what do you mean with " we have also "repair.r#"  for the assertion atm"?
[11:55] <diddledan> ogra_: afaict it doesn't do any "searching" it seems to memoize the prefix at build time and then use that when building paths - the libpythonloader is found by literally "libdir" + "loaders" + "libpythonloader.so"
[11:55] <ogra_> diddledan, well, it has that function above
[11:55] <ogra_> (also prepend_search_path() as well)
[11:55] <pedronis> mvo:  /var/lib/snapd/repair/assertions/{$BRAND_ID}/${REPAIR_ID}  vs /var/lib/snapd/repair/run/{$BRAND_ID}/${REPAIR_ID}
[11:56] <ogra_> so it allows it ... just not OOTB
[11:56] <diddledan> but we don't want to be hacking stuff to make it work in snappy - that is a sure WONTFIX when pushing upstream
[11:57] <ogra_> asking them to ccep an env var for more flexibility ? not sure
[11:57] <pedronis> mvo:  we have a hierarchy for the assertions and a different one for the run artifacts
[11:57] <ogra_> *accept
[11:57] <mvo> pedronis:yes
[11:57] <diddledan> I tried that: https://bugzilla.gnome.org/show_bug.cgi?id=786581
[11:57] <diddledan> NOTABUG
[11:58] <pedronis> mvo: just saying repair.r# exists but is not under */run/*
[11:58] <diddledan> I even gave them a patch
[11:58] <mvo> pedronis: aha, ok. now I see what you mean
[11:58] <ogra_> booo
[11:59] <diddledan> maybe I should reword my bug report and try again
[11:59] <mvo> pedronis: quick brainstorm on your idea about just using the counter as the prefix? http://pad.ubuntu.com/c3Ku7ZRkGk has that what you have in mind?
[11:59] <pedronis> mvo: anyway maybe it's ok to turn them all aorund to be "r#..."
[11:59] <ogra_> yeah, talk about flexibility and advantages ;)
[11:59] <ogra_> (make it sound like a positive thing they want :) )
[12:00] <popey> ogra_: in snap changes, I'm seeing a bunch of errors when doing Initialize device
[12:00] <popey> Error   2017-08-22T11:57:13Z  2017-08-22T11:57:18Z  Request device serial
[12:00] <ogra_> popey, about get a serial" ?
[12:00] <popey> ya
[12:00] <pedronis> mvo: yes,  but as I said now, not sure it's a good idea
[12:01] <ogra_> popey, yeah, thats pointless ... pedronis once promised me it would stop doing that over time (but it isnt ... at least for me)
[12:01] <ogra_> :)
[12:01] <pedronis> mvo: anymore
[12:01] <mvo> pedronis: ok, let me do the alternative in the pad
[12:01] <ogra_> popey, it wont ever get a serial since it isnt an official canonical image, but that doesnt do any harm apart from spamming the log
[12:02] <mvo> pedronis: maybe its a gustavo question, I'm sure he has an opinion, I don't mind either way much as long as its somewhat consistent
[12:02] <pedronis> ogra_: no, it's my fault it back offs but per reboot, so if you reboot often it spams a bit anyway
[12:02] <popey> ogra_: ok
[12:03] <mvo> pedronis: which means I will write/update the forum post I guess
[12:03] <ogra_> pedronis, heh, well, an edge image reboots daily for the daily core ... thats it then (i only use edge everywhere)
[12:03] <pedronis> mvo: anyway my point   is that r1.repair is probably more consistent to what we usually do thatn repair.r1 and then it goes from there
[12:04] <pedronis> mvo: other those are more than the repair, they are streams
[12:09] <mup> PR snapd#3781 opened: cmd/snap-repair: track and use a lower bound for the time for TLS checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3781>
[12:09] <mvo> pedronis: right
[12:16] <mup> PR snapd#3757 closed: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3757>
[12:36] <mup> Issue snapcraft#1502 opened: Support :target suffix for build-packages <designed> <Created by kalikiana> <https://github.com/snapcore/snapcraft/issue/1502>
[12:39] <mup> Issue snapcraft#1477 closed: multi-arch build packages <design-required> <Created by sergiusens> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1477>
[12:39] <mup> PR snapcraft#1346 closed: repo: multi-arch build deps <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1346>
[12:40] <mup> PR snapd#3782 opened: client: fix go vet 1.7 errors <Created by mvo5> <https://github.com/snapcore/snapd/pull/3782>
[12:42] <Son_Goku> who manages mup?
[12:42] <Son_Goku> the syntax of issue URLs is wrong
[12:43] <zyga-suse> Son_Goku: we were wondering ourselves recently
[12:43] <zyga-suse> not sure, maybe niemeyer?
[12:45] <cachio> mvo, hey, is it sru validation ready to start?
[12:50] <mvo> cachio: yes
[12:51] <cachio> mvo, starting with it
[12:52] <mvo> ta
[13:00] <jdstrand> hey zyga-arch :)
[13:03] <mup> PR snapd#3783 opened: tests: make 17.04 shellcheck clean <Created by mvo5> <https://github.com/snapcore/snapd/pull/3783>
[13:26] <kenvandine> nessita, remember we talked about collaborators will remain when we change the publisher of a snap?  Is that only active shares or will the pending go along as well?
[13:27] <kenvandine> nessita, i'm trying to decide how persistently i nag the collaborators I invited :)
[13:31] <nessita> kenvandine, hum I'm not 100% sure and I'm otp, I can check after this call I'm in
[13:31] <kenvandine> nessita, no rush :)
[13:43] <diddledan> the desktop-gnome-platform has a minor bug (this is a PR fixing it): https://github.com/ubuntu/snapcraft-desktop-helpers/pull/70
[13:43] <mup> PR ubuntu/snapcraft-desktop-helpers#70: update init to fix cases where the helper exits <Created by diddledan> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/70>
[13:46] <zyga-suse> diddledan: looking
[13:55] <zyga-suse> diddledan: not sure what I think about it, I'd have to look at what the code is doing there elsewhere
[13:55] <zyga-suse> diddledan: I'll let others review
[13:56] <diddledan> ok
[13:56] <diddledan> the line I removed is duplicated currently in mark-and-exec: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/mark-and-exec#L5
[13:57] <diddledan> so it's just removing the early setting of the .last_revision
[14:36] <didrocks> diddledan: this was a missing git add -p a long time ago
[14:36] <didrocks> was supposed to be in
[14:36] <didrocks> (when I added the mark-and-exec statement)
[14:36] <diddledan> aha
[14:36] <diddledan> :-)
[14:36] <didrocks> so yeah, completly my fault, thanks for spotting it! :)
[14:36] <diddledan> no problem .. glad to help :-)
[14:37] <didrocks> merged, thanks again
[14:44] <zyga-suse> obviously after adding measurements I cannot reproduce this failure
[14:44] <zyga-suse> but running tests over and over I see failures all over the tree
[14:54] <ogra_> popey, here you go https://forum.snapcraft.io/t/new-nanopi-neo-air-ubuntu-core-developer-image/1814
[15:01] <diddledan> sergiusens: the snappy-preload rewriting shared memory. have you tried it against an application that uses pulseaudio?
[15:02] <diddledan> specifically I'm getting [pid 21683] open("/dev/shm/snap.liferea.pulse-shm-908736786", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[15:02] <diddledan> I'm wondering if the pulse-shm is not meant to be rewritten
[15:03] <diddledan> ref: https://github.com/sergiusens/snapcraft-preload
[15:09] <popey> ogra_: yay
[15:18] <zyga-arch> mvo: so...
[15:19] <zyga-arch> https://paste.gnome.org/pmlk7zgjb
[15:19] <zyga-arch> mvo: I added this patch in the build: https://paste.gnome.org/pkepaslix
[15:19] <zyga-arch> and came out with this https://paste.gnome.org/p8akyvrfy
[15:19] <zyga-arch> I'm totally puzzled now
[15:20] <zyga-arch> shall I leave it on memcheck for the evening?
[15:20] <zyga-arch> (the host)
[15:20] <zyga-arch> did we run into any golang bugs recently?
[15:20] <zyga-arch> niemeyer: ^
[15:34] <niemeyer> zyga-arch: AFAIK only the one about fork/exec concurrency, which arguably is a kernel bug
[16:00] <zyga-arch> https://paste.gnome.org/p1hsubmo4
[16:05] <zyga-arch> pedronis: ^ any ideas/
[16:07] <pedronis> in daemon?
[16:07] <pedronis> zyga-arch: our tests don't always use the lock correctly for convenience, it also means though that a test failure can turn into such a panic
[16:08] <zyga-arch> aha, I see
[16:08] <zyga-arch> this is not the error I'm researching but I wanted to share it in case it is more serious
[16:08] <pedronis> so something else is failing but you get this insteaad
[16:09] <pedronis> some printing around in the test exploding should reveal what's happening
[16:12] <zyga-arch> it's not easily reproducible, it feels like each time I run it some part explodes but not the same part
[16:27] <mup> PR snapd#3741 closed: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3741>
[17:42] <mup> PR snapd#3783 closed: tests: make 17.04 shellcheck clean <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3783>
[18:12] <niemeyer> Stepping out into the non-eclipsed sun for a while
[19:14] <pedronis> niemeyer: added this to the topic with a question that we didn't consider:  https://forum.snapcraft.io/t/lazy-fallback-serial-registration-for-classic/1232/8
[19:17] <pedronis> niemeyer: I also I have an errand tomorrow that will not allow me to make the standup I think
[19:55] <jdstrand> roadmr: hi! can you sync r913? this isn't urgent, but note there are a number of code changes
[19:55] <roadmr> jdstrand: oh boy.. sure
[19:56] <roadmr> jdstrand: as long as you're fairly confident it won't start rejecting snaps or crashing, we should be ok :)
[19:56] <roadmr> jdstrand: I do a basic smoke check before proposing the merge, and then we can test on staging a bit
[19:57] <jdstrand> roadmr: I have a bunch of tests to test things. they aren't crazy changes
[19:57] <jdstrand> err, bunch of snaps
[19:57] <roadmr> nice :)
[19:57] <jdstrand> and a lot of testsuite changes
[19:57] <jdstrand> so I am confident it'll be fine, but I watch the queue every day so I'll pay the price if things get rejected
[19:58] <niemeyer> pedronis: Thanks for the topic, and thanks for the note
[19:59] <jdstrand> roadmr: more seriously, it's mostly data changes. then there is a safety check for verifying there is enough disk space to uncompress, and then another check for executable stacks, which is rarely used by anything
[20:00] <jdstrand> roadmr: and then a few things to help the tools when run as a snap
[20:00] <roadmr> which we're not using yet :/ but can't hurt
[20:00] <jdstrand> roadmr: I use it regularly and I run it through all the same tests
[20:02] <jdstrand> roadmr: but I discovered an issue that would've caused you problems: the snap was defaulting to using python3's default for gettemptdir(), which is /tmp, which in snappy is a memory backed tmpfs, which means that the size of reviewable snaps would've been smaller (eg, out of space if the snap didn't fit in half the ram on the review system)
[20:03] <jdstrand> roadmr: the change was to use SNAP_USER_COMMON, but then because we didn't get cleanup of that directory for free, I implemented some stale review dir reaping code
[20:04] <jdstrand> I'm particularly happy that the snap no longer needs to 'plugs: [ network ]'
[20:07] <roadmr> \o/
[20:37] <mup> PR snapcraft#1488 closed: lxd: always remove existing device for project folder <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1488>
[20:40] <mup> PR snapcraft#1495 closed: cli: don't raise from excepthook <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1495>
[20:40] <mup> PR snapcraft#1499 closed: repo: make errors based on SnapcraftError <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1499>
[20:46] <mup> Issue snapcraft#1454 closed: python plugin recording <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1454>
[20:46] <mup> PR snapcraft#1487 closed: python plugin: record manifest <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1487>
[22:16] <mup> PR snapcraft#1503 opened: ci: speedup the CLA check <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1503>


[18:33] <bjsnider> people are having this problem in kubuntu right now: http://pastebin.com/tYFGn85u
[18:33] <bjsnider> it's a packaging bug


 results in: … 1. Valorie Zimmerman … 2. Myriam Schweingruber … 3. Simon Quigley
 \o/
 Congratulations to Calorie, Myriam and Simon, and a massive thank you to @acheronuk for organising the council elections.
 Oh. Boy, I have auto spellcheck so much. My apologies, of course Calorie should be Valorie.
 LOL
 @acheronuk you around?
 @ahoneybun, Yeah.
 Thanks for doing the voting.
 No probs. :)


[02:01] <CIA-8> console-setup: cjwatson * r38 ubuntu/debian/ (changelog config.proto):
[02:01] <CIA-8> console-setup: * Handle an empty codeset in the configuration file gracefully (a remnant
[02:01] <CIA-8> console-setup:  of a previous bug, perhaps Debian #420802?), and re-ask the question on
[02:01] <CIA-8> console-setup:  upgrade (LP: #91399).
[02:01] <Ubotwo> Debian bug 420802 in console-setup "console-setup: Default for console-setup/codeset not in Choices" [Normal,Closed] http://bugs.debian.org/420802
[02:01] <ubotu> Debian bug 420802 in console-setup "console-setup: Default for console-setup/codeset not in Choices" [Normal,Fixed] http://bugs.debian.org/420802
[02:02] <cjwatson> sigh
[02:04] <cjwatson> I've asked #ubuntu-irc for help
[07:19] <evand> cjwatson: oem-config r391 feeds debian-installer/locale to the target system.  Sorry that took so long, I chased what turned out to be a non-existant bug in oem-config's language component.
[08:38] <evand> ugh, then again maybe it's not.
[09:39] <evand> ah, it appears to be a bug with language.py's interaction with hardy's localechooser as ubiquity has the same problem, which isn't present in gutsy.
[12:10] <xivuon> New code for zoom-map-widget is available at http://paste.ubuntu-nl.org/51336/ (cannot push to launchpad atm)
[12:10] <xivuon> added event notification and improved rendering speed
[12:11] <xivuon> mpt give it a look, should be close to what you suggested
[12:12] <xivuon> it also includes a full-zoom mode as specified in the spec (but it must be turned on in code since I like partial-zoom better)
[12:14] <xivuon> the code can be considered beta quality
[12:15] <mpt> nifty
[12:15] <mpt> but yeah, not as specified
[12:16] <mpt> I wonder how that interacts with an actual screen magnifier
[12:16] <xivuon> to run it you also need the png world map image
[12:16] <mpt> I downloaded a gif from Google Images :-P
[12:17] <xivuon> use http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/zoom-map-widget/download/ago%40nbago-20080109094346-qucbdu1yrybtp6ie/world_map1920.png-20080108235140-yqggaraa9m57xkqr-1/world_map-1920.png
[12:17] <xivuon> as png file
[12:17] <mpt> I think magnifying a little box makes it harder to see where you are
[12:17] <xivuon> in code you can change: full_zoom = True
[12:18] <xivuon> towards the end of the file
[12:18] <mpt> or rather, it makes it harder to see places *next to* where you are.
[12:18] <xivuon> that is what is in the spec
[12:18] <mpt> ooh yes
[12:19] <xivuon> I prefer the partial-zoom but it's a matter of taste, of course the size and shape of the zoom-window can be changed at will
[12:19] <xivuon> courtesy of cairo
[12:19] <mpt> The only thing that's missing is zooming out when the pointer is outside the map area
[12:19] <xivuon> yeah I forgot to add that
[12:20] <xivuon> but it's rather easy, simply call redraw_all when you have a out-of-widget notification
[12:25] <mpt> well, ideally it would zoom more smoothly than that :-)
[12:25] <mpt> over the course of 0.5 seconds or thereabouts
[12:30] <evand> xivuon: re beer and merges> I owe you both :)  Thanks a bunch for taking the time do implement this.
[12:30] <evand> to*
[12:30] <xivuon> evand you are most welcome
[12:31] <xivuon> you can take over from http://paste.ubuntu-nl.org/51336/
[12:31] <xivuon> I can merge that tonight into launchpad
[12:32] <evand> ok, I'll keep you posted on merging it in.
[12:33] <xivuon> mpt re zooming in/out I agree that some animation would be better, re zoomout on mouseout I am not sure how to detected way
[12:33] <xivuon> eveand all yours
[18:18] <CIA-8> installation-guide: cjwatson * r406 ubuntu/ (debian/changelog en/install-methods/automatic-install.xml):
[18:18] <CIA-8> installation-guide: * Document use of apt-install in Kickstart, and the fact that it only
[18:18] <CIA-8> installation-guide:  works with %post --nochroot (thanks, Ryan Lovett).
[18:45] <CIA-8> oem-config: evand * r393 oem-config/ (debian/changelog lib/components/language.py):
[18:45] <CIA-8> oem-config: * Properly handle situations where localechooser might ask
[18:45] <CIA-8> oem-config:  languagechooser/language-name-*.
[18:55] <CIA-8> ubiquity: evand * r2401 ubiquity/ (debian/changelog ubiquity/components/language.py):
[18:55] <CIA-8> ubiquity: * Properly handle situations where localechooser might ask
[18:55] <CIA-8> ubiquity:  languagechooser/language-name-* (LP: #181440).
[21:56] <CIA-8> debian-installer: cjwatson * r867 ubuntu/ (36 files in 4 dirs): * Update copyright years to 2008.
[23:12] <Michi> who am i?
[23:24] <xivulon> what happened to udevtrigger/udevsettle?
[23:26] <xivulon> guess have to use udevadm
[23:43] <xivulon> any chance of mounting hardy livecd squashfs within gutsy?
[23:50] <xivulon> where are /lib/partman/recipes.sh and friends? that breaks partman-auto-loop
[23:51] <xivulon> ahh /lib/partman/lib...
[23:52] <xivulon> is /lib/partman/definitions.sh going to be moved as well?