[06:53] <chesedo> morning all
[06:55] <paddatrapper> morning chesedo
[07:04] <chesedo> hey paddatrapper, are you done with exams yet?
[07:09] <paddatrapper> chesedo: only start next week...
[07:09] <paddatrapper> But I only have 3, so not too bad
[07:32] <inetpro> good mornings
[07:33] <inetpro> and welcome back chesedo
[07:33] <inetpro> hope all went well with your exams
[07:54] <paddatrapper> Hi inetpro
[09:47] <inetpro> hi paddatrapper
[09:47] <inetpro> why are you only starting to write so late? Most others I know are done by now
[09:58] <paddatrapper> inetpro: we had a wonderful (/s) 6 month break at the end of last year thanks to the protests. It resulted in this year starting a month late, so exams are a month later than usual
[09:59] <inetpro> eish!
[10:46] <chesedo> ouch that a bad one
[16:46] <nsnzero> good evening all
[18:42] <andrewlsd> evening all
[18:42] <Maaz> andrewlsd: By the way, inetpro on freenode told me "tell andrewlsd thanks for the link to http://pinet.org.uk/" 4 days, 23 hours, 30 minutes and 30 seconds ago
[18:42] <inetpro> eh
[18:42] <inetpro> welcome back andrewlsd
[18:42] <andrewlsd> :-)
[18:42] <inetpro> and good evening world
[18:43] <andrewlsd> almost made it 5 days inetpro
[18:43] <andrewlsd> 29 mins 30 seconds short of 5 days
[18:44] <inetpro> haha


[00:31] <bigjools> wgrant or StevenK, can you decipher the error at the bottom of this please? https://launchpadlibrarian.net/156805473/buildlog.txt.gz
[00:39] <StevenK> bigjools: You can't have -'s in your version with 3.0 (native)
[00:40] <bigjools> StevenK: this has previously built on trusty, no changes made
[00:40] <bigjools> was this a recent toolchain change?
[00:40] <StevenK> Probably newer dpkg
[00:40] <bigjools> StevenK: so I need to remove all the - chars?
[00:41] <StevenK>       dpkg | 1.16.12ubuntu1 |         saucy | source, amd64, arm64, armhf, i386, powerpc
[00:41] <StevenK>       dpkg | 1.17.1ubuntu1 |        trusty | source, amd64, arm64, armhf, i386, powerpc
[00:41] <StevenK> (The error turns up in 1.17)
[00:41] <StevenK> Right, and 1.17.1ubuntu1 was uploaded 7 hours ago.
[00:42] <StevenK> bigjools: You have two choices. Change to 3.0 (quilt) and leave the version number alone; or leave it as 3.0 (native) and use periods as seperators
[00:43] <bigjools> StevenK: ok thanks
[00:45] <bigjools> StevenK: huh I thought it was already quilt
[00:45] <bigjools> yeah it is
[00:46] <StevenK> Based on that error, debian/source/format is 3.0 (native), no?
[00:47] <bigjools> debian/source/format:3.0 (quilt)
[00:47] <bigjools> in my packaging
[00:47] <bigjools> also look up the log file and see it applying quilt patches ...
[00:52] <StevenK> bigjools: Have you tried it in an up-to-date trusty chroot?
[00:52] <bigjools> no, I only added the recipe late last week and it worked the first time I built with it
[00:52] <StevenK> Yes, the new version of dpkg was only uploaded 7 hours ago.
[00:53] <bigjools> this log us from an hour ago or so
[00:53] <bigjools> is
[00:54] <StevenK> I think we're talking past each other. It worked last week, because dpkg was still the version shipped with saucy. The new dpkg in trusty was uploaded 7 hours ago, so would certainly impact the build you did an hour ago.
[00:55] <bigjools> StevenK: I understand.
[00:56] <bigjools> dpkg is complaining it's a native pacakge and it definitely is not, so perhaps dpkg is buggy?
[00:57] <StevenK> I'm trying to update my local trusty chroot
[00:57] <bigjools> could fire up a canonistack instance
[01:01] <StevenK> bigjools: Point me at your recipe?
[01:01] <bigjools> yup, one sec
[01:02] <bigjools> StevenK: https://code.launchpad.net/~maas-maintainers/+recipe/maas-daily-trusty
[01:18] <wgrant> bigjools: bzr-builder will in some scenarios convert quilt to native. possibly if there's no pristine-tar, but i don't quite recall
[01:19] <bigjools> wgrant: I don't think bzr-builder changed between today and Friday did it?
[01:19] <wgrant> no, the change is purely dpkg
[01:20] <wgrant> but it would explain why your quilt package has been native before and after
[01:21] <bigjools> right
[01:21] <bigjools> can we make it stop doing that?
[01:22] <wgrant> maybe
[01:22] <wgrant> on my phone atm, can't really poke right now
[01:24] <StevenK> % cat -A debian/control | head -n 21 | tail -n 1
[01:24] <StevenK>  (M-bM-^@M-^\nodeM-bM-^@M-^]) will be commissioned automatically on first boot.$
[01:25] <StevenK> Smart quotes in debian/control? You bad people.
[01:26] <wgrant> it's 2013
[01:26] <wgrant> Unicode is a thing :)
[01:33] <bigjools> StevenK: welcome to reality :)
[01:33] <StevenK> Hah
[01:34] <StevenK> bigjools: So, yes. wgrant is correct. bzr-builder will convert from 3.0 (quilt) to 3.0 (native) if you don't have pristine-tar information.
[01:34] <bigjools> yay?
[01:34] <bigjools> this is stretching my packaging knowledge now.
[01:36] <StevenK> It isn't packaging, it's bzr innards
[01:37] <wgrant> bzr-build{er,deb}, not bzr :)
[01:38] <StevenK> I've tried to ignore pristine-tar, not sure if you're supposed to use it directly.
[02:07] <wgrant> bigjools: So, for 3.0 (quilt) to work you need an orig.tar.*. bzr-builddeb can't generate one of those without pristine-tar information in the branch, which specifies how to turn a revision's tree into a bit-identical upstream orig tarball.
[02:07] <wgrant> It sounds like your branch doesn't have a pristine-tar delta for the upstream version that you've specified.
[02:08] <bigjools> hmmm
[02:08] <bigjools> I thought it generated a tarball in the makefile somewhere
[02:08] <bigjools> but this is all roaksoax work, so...
[02:09] <bigjools> so there's a get-orig-source target in debian/rules, is this not sufficient ?
[02:10] <StevenK> No, pristine-tar information is stored in the bzr history
[02:10] <StevenK> If you have a tarball, pristine-tar commit <path to tarball> will add a pristine-tar delta to the branch
[02:14] <bigjools> is that something we need in the get-orig-tarball target?
[02:14] <bigjools> get-orig-source I mean
[02:19] <StevenK> bigjools: pristine-tar wants to reproduce an exact copy of a tarball, so no, not in get-orig-source
[02:20] <bigjools> StevenK: ok sorry then I am clueless, I'd better leave this for now.
[02:36] <StevenK> bigjools: If you like, we could have a G+ hangout after lunch and I can go through it
[02:37] <bigjools> StevenK: thanks for the offer - I'll see if I have time, busy with stuff right now
[02:37] <StevenK> I'm about to disappear for lunch
[02:37] <bigjools> yeah I agree


[15:59] <powersj> o/
[15:59] <dpb1> hola
[15:59] <slashd> o/
[15:59] <ahasenack> o/
[16:00] <rharper> o/
[16:00] <rbasak> o/
[16:00] <rharper> dpb1: don't forget to raise your hand before you speak =P
[16:01] <cpaelzer> o/
[16:01] <powersj> ok this looks good, away we go!
[16:01] <powersj> #startmeeting ubuntu-server-team
[16:01] <meetingology> Meeting started Tue Apr 25 16:01:19 2017 UTC.  The chair is powersj. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <powersj> #topic Review ACTION points from previous meeting
[16:01] <powersj> rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has (carried over)
[16:01] <powersj> Continue to carry over?
[16:02] <cpaelzer> carry further
[16:02] <powersj> #action rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has (carried over)
[16:02] <meetingology> ACTION: rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has (carried over)
[16:02] <cpaelzer> I actually wanted to write yesterday, but the page is in lockdown
[16:02] <powersj> smoser to write a release notes entry on cloud-init (ds-identify)
[16:02] <cpaelzer> several relogings didn't fix it
[16:02] <nacc> o/ sorry
[16:02] <powersj> #info smoser completed release note entry for cloud-init
[16:02] <powersj> nacc to write a release notes entry on ipv6 netboot
[16:03] <nacc> powersj: carry forward :/
[16:03] <powersj> ok :)
[16:03] <powersj> #action nacc to write a release notes entry on ipv6 netboot
[16:03] <meetingology> ACTION: nacc to write a release notes entry on ipv6 netboot
[16:03] <powersj> nacc to write a server guide entry on ipv6 netboot
[16:03] <dpb1> o/
[16:03] <rbasak> cpaelzer: perhaps follow up with IS if it remains stuck?
[16:03] <nacc> powersj: same
[16:04] <powersj> #action nacc to write a server guide entry on ipv6 netboot
[16:04] <meetingology> ACTION: nacc to write a server guide entry on ipv6 netboot
[16:04] <powersj> rharper to write a server guide entry on v2 yaml support in cloud-init
[16:04] <cpaelzer> rbasak: is wiki handled via IS - yes if it is still stuck next time I come there I'll do so
[16:04] <rharper> powersj: carry
[16:04] <powersj> #action rharper to write a server guide entry on v2 yaml support in cloud-init
[16:04] <meetingology> ACTION: rharper to write a server guide entry on v2 yaml support in cloud-init
[16:04] <powersj> rharper to write a release notes entry on v2 yaml support in cloud-init
[16:04] <powersj> same?
[16:04] <rharper> same
[16:04] <powersj> #action rharper to write a release notes entry on v2 yaml support in cloud-init
[16:04] <meetingology> ACTION: rharper to write a release notes entry on v2 yaml support in cloud-init
[16:04] <powersj> #action powersj to update copy and paste commands for IRC meeting to say artful
[16:04] <meetingology> ACTION: powersj to update copy and paste commands for IRC meeting to say artful
[16:04] <powersj> I'm taking that one ^
[16:05] <rharper> when I fix up my network-doc branch and it lands in cloud-init, I can point to the ReadTheDocs entry
[16:05] <powersj> anything else?
[16:05] <rbasak> cpaelzer: yes - managed by IS
[16:05] <powersj> #topic Zesty Development
[16:05] <powersj> One last time... anything for zesty?
[16:05] <rharper> powersj: there was a request to update the paste commands for SRU members, I did that last week
[16:05] <powersj> rharper: thx
[16:06] <powersj> closing out zesty in 3...2.... 1...
[16:06] <powersj> #topic Artful Development
[16:06] <powersj> #link https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
[16:06] <nacc> importer should be running for the merges -- i think i'm going to do a server all run later today (it will take a day or two, i expect)
[16:07] <powersj> #info nacc: importer running for merges, will take day or two
[16:07] <cpaelzer> we should identify any merges that we intentionally want to do late to pick the next versiosn
[16:07] <dpb1> how long does it take end to end?
[16:07] <cpaelzer> I'm currently in touch with HW manufacturers to clairfy on qmeu/libvirt
[16:07] <nacc> dpb1: how long does the importer take?
[16:07] <dpb1> yes
[16:07] <cpaelzer> but if others have similar constraints we can make them clear on our "merge schedule"
[16:08] <nacc> dpb1: not predictable -- i think smoser ran it last in this way?
[16:08] <smoser> man
[16:08] <nacc> dpb1: i would guess several days to import the entire history for 850 or so packages
[16:08] <nacc> although we've imported 300+ already
[16:08] <dpb1> ok, if we don't know its fine, just curious.
[16:08] <nacc> so maybe less now
[16:08] <dpb1> k
[16:08] <nacc> dpb1: speed hasn't been a priority :)
[16:08] <dpb1> :)
[16:09] <ahasenack> was it run for zesty in the same way?
[16:09] <nacc> ahasenack: no
[16:09] <nacc> ahasenack: for zesty it was done by hand when someone asked for a srckpkg to be imported
[16:09] <nacc> by myself, rbasak or smoser
[16:09] <dpb1> brave new world!
[16:10] <nacc> yeah
[16:10] <rbasak> I noticed one bit that's slow that I have code to speed up, FWIW.
[16:10] <rbasak> Just not had a need to address it yet.
[16:10] <nacc> rbasak: excellent, yeah, i was going to file a bug to do some profiling etc
[16:10] <nacc> similar to what smoser had done before and looking at the @lru_cache stuff
[16:10] <dpb1> nacc: I suspect the second run of it would be faster?
[16:11] <nacc> dpb1: once we run the 'full import' of the archive (or our subset), subsequent runs will only pick up what is new
[16:11] <dpb1> k
[16:11] <powersj> do we need an action for cpaelzer to figure timeline of merges? any other merge work needing action items?
[16:11] <nacc> and that is what the cron job does basically
[16:11] <nacc> powersj: i don't think we need an explicit action
[16:12] <powersj> ok :)
[16:12] <nacc> powersj: but we probably do need to coordinate, etc.
[16:12] <nacc> dpb1: we used to to do that via the blueprint
[16:12] <nacc> and you can see the list of merges from z in that bp
[16:12] <powersj> #subtopic blueprints
[16:12] <nacc> so we might want to, at first, at least copy all those smae srcpkgs, unassigned to aa
[16:12] <powersj> #link https://blueprints.launchpad.net/ubuntu/+spec/servercloud-aa-server-core
[16:12] <cpaelzer> powersj: no action needed atm, but I'd say we need to coordinate the release in general
[16:13] <powersj> #info cpaelzer nacc rbasak need to coordinate merges via blueprint
[16:13] <cpaelzer> I'm not set on blueprint, gdoc, ... (millions of options) but some sort of who-does-what-when is needed
[16:13] <nacc> powersj: thanks
[16:13] <cpaelzer> thanks powersj
[16:13] <dpb1> nacc: thoughts on using a board like trello instead of a blueprint?  we can still create a blueprint and link to it.
[16:13] <smoser> dpb1 likes trello
[16:13] <dpb1> s/nacc//
[16:13] <cpaelzer> I actually thought just that dpb1 when I saw the curtin board
[16:14] <cpaelzer> dpb1: you said those are public-read but write onyl to us right?
[16:14] <dpb1> it can be public, we can assign owners, invite other people
[16:14] <dpb1> yes
[16:14] <nacc> as long as it's public, i don't particularly care
[16:14] <cpaelzer> I used that for DPDK, I think it would be nice for many things except bug linking
[16:14] <cpaelzer> or is that improved now?
[16:14] <nacc> the blueprint sort of sucks
[16:14]  * dpb1 volunteers for action to create a skeleton
[16:14] <rbasak> Is there anything specific that trello will solve for us over blueprints?
[16:14] <nacc> as it doesn't gate itself
[16:14] <smoser> I do think we need to be careful on this. Ubuntu development takes place on Ubuntu.
[16:14] <rbasak> I understand how much better trello could be - just wondering how it applies to our specific case.
[16:14] <nacc> so we can both edit at the same time and things get lost
[16:15] <nacc> smoser: +1
[16:15] <dpb1> rbasak: saving my eyes is first on the list.
[16:15]  * nacc would also be fine with a text file :)
[16:15] <cpaelzer> turning away from LP is a bad thing more from the mood it represents than technically
[16:15] <dpb1> rbasak: but it's not a hard line for me.
[16:15] <smoser> and moving Ubuntu server development (or portions there-of) off launchpad makes that inconsistent with other Ubuntu developement.
[16:15] <smoser> we're part of a larger thing here and consistency matters.
[16:15] <rbasak> If we did blueprints properly, the status page would give us useful reporting.
[16:16] <dpb1> are blueprints rotted or is it just ours?
[16:16] <cpaelzer> rbasak: maybe we should do one properly, what did we miss last time to do so?
[16:16] <dpb1> do any other groups use them?
[16:16]  * cpaelzer <- no blueprint expert at all
[16:16] <rbasak> cpaelzer: I think there are some pieces to set on the blueprint and then it appears properly on status.qa.ubuntu.com or wherever it was.
[16:16] <cpaelzer> could we group items for months planned or any other timeline association?
[16:17] <rharper> cpaelzer: ack;
[16:17] <cpaelzer> so we see early when things slip?
[16:17] <rbasak> blueprints can do milestones, yes.
[16:17] <rbasak> And I believe status reports on that.
[16:17] <rharper> dpb1: we've certainly used blueprints for server;  but it's mostly been a  task tracker (todo, inprogress, done) and less of a planner w.r.t when we expect it to complete (17.05, 17.06, etc)
[16:17] <rharper> I think it's mostly matter of JFDI
[16:18] <cpaelzer> which translates to who volunteers
[16:18] <ahasenack> it's not a very rich content, you can't add comments to a task for example
[16:18] <dpb1> you would use a bug for that
[16:18] <ahasenack> saying where you are, what problems you encountered, how they were solved, ping someone else, etc
[16:18] <dpb1> I'm guessing
[16:18] <rharper> yes
[16:18] <rharper> it's very typical to create a bug with the feature
[16:18] <cpaelzer> ahasenack: actually every item usually carries a bug which can have details
[16:18] <powersj> Can I propose that as rbasak nacc cpaelzer plan merges, they look into using blueprint more effectively?
[16:18] <ahasenack> cpaelzer: ok
[16:19] <rbasak> Sure
[16:19] <cpaelzer> powersj: fair deal
[16:19] <powersj> #info rbasak nacc cpaelzer will look into using blueprints more effectively
[16:19] <nacc> yeah, and let's (probably) target 18.04 cycle for dtrt
[16:19] <dpb1> OK, let's try it
[16:19] <nacc> from the get-got that is
[16:19] <powersj> #subtopic Release Bugs
[16:19] <powersj> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-z-tracking-bug-tasks.html#ubuntu-server
[16:19] <powersj> I don't see a -a version of that page yet
[16:20] <ahasenack> how does a bug get into that list?
[16:20] <nacc> powersj: i wonder if whoever owns reqorts needs to update their code :)
[16:20] <powersj> do we know who does?
[16:20] <nacc> no idea
[16:21] <powersj> #action powersj to find out who owns bug tracking site, get artful link
[16:21] <meetingology> ACTION: powersj to find out who owns bug tracking site, get artful link
[16:21] <powersj> any comments on z bugs before moving on?
[16:21] <nacc> ahasenack: i believe it might be automatic?
[16:21] <ahasenack> I mean, via a tag? zesty task?
[16:22] <dpb1> nacc: based on what
[16:22] <dpb1> right
[16:22] <powersj> tag of release
[16:22] <nacc> ahasenack: as in, packages in the list of 'ubuntu-server' (which is a file) and then tag to that release
[16:22] <nacc> *task to that release
[16:22] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1645324 is in the list
[16:22] <powersj> oh it is task?
[16:22] <ahasenack> has tags "patch" and "sts-sru-needed"
[16:22] <ahasenack> ah, task
[16:22] <nacc> powersj: the one i randomly looked at had no tags
[16:22] <powersj> nacc: ok thx
[16:22] <nacc> i would need to grep my irc logs to find where the package list
[16:23] <powersj> nacc: that's just the package-team-mapping right?
[16:23] <nacc> powersj: that'd be my guess, yes
[16:23] <powersj> http://people.canonical.com/~ubuntu-archive/package-team-mapping.json
[16:23] <dpb1> rharpers json?
[16:23] <nacc> powersj: thanks, that's what i was looking for
[16:23] <ahasenack> so these are essentially sru candidates
[16:23] <ahasenack> at least they were nominated
[16:23] <nacc> ahasenack: or active development candidates
[16:23] <nacc> ahasenack: now they are SRU, yes ;0
[16:23] <nacc> :)
[16:24] <powersj> which brings us to....
[16:24] <powersj> #topic Server & Cloud Bugs & SRU/Pending Uploads (slashd)
[16:24] <powersj> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server
[16:24] <powersj> welcome slashd
[16:24] <slashd> thanks powersj
[16:24] <cpaelzer> powersj: thanks for driving this to not stall - we are all talkative today
[16:24] <slashd> LP: #1356211 - (sosreport) cannot collect rotated syslog.1
[16:24] <slashd>   - Series to SRU : trusty
[16:24] <slashd>   - Owners : Louis Bouchard
[16:24] <slashd> LP: #1366103 - (sosreport) sosreport doesn't collect all data from /etc/apparmor.d/
[16:24] <slashd>   - Series to SRU : trusty
[16:24] <powersj> :)
[16:24] <slashd>   - Owners : Louis Bouchard
[16:24] <slashd> LP: #1447695 - (sosreport) sosreport 3.2 does not collect systemd information
[16:24] <slashd>   - Series to SRU : trusty
[16:24] <slashd>   - Owners : Louis Bouchard
[16:24] <slashd> LP: #1566508 - (sssd) autofs races with sssd on startup
[16:24] <slashd>   - Series to SRU : yakkety xenial trusty
[16:24] <slashd>   - Verification : verification-failed-xenial verification-failed-yakkety verification-needed
[16:24] <slashd>   - Owners : Victor Tapia
[16:24] <slashd> LP: #1590799 - (nfs-utils) nfs-kernel-server does not start because of dependency failure
[16:24] <slashd>   - Series to SRU : yakkety
[16:24] <slashd>   - Verification : verification-done-xenial verification-needed
[16:24] <slashd>   - Owners : Rafael David Tinoco
[16:25] <slashd> LP: #1602057 - (nova) [SRU] (libvirt) KeyError updating resources for some node, guest.uuid is not in BDM list
[16:25] <slashd>   - Series to SRU : xenial
[16:25] <slashd>   - Owners : Edward Hope-Morley
[16:25] <slashd> LP: #1605243 - (sosreport) iscsi initiator related configs and logs are not recorded
[16:25] <slashd>   - Series to SRU : yakkety xenial trusty zesty
[16:25] <slashd>   - Owners : Louis Bouchard
[16:25] <slashd> LP: #1614052 - (sosreport) SOSREPORT need to collect OPAL msglog
[16:25] <slashd>   - Series to SRU : yakkety xenial trusty zesty
[16:25] <slashd>   - Owners : Louis Bouchard
[16:25] <slashd> LP: #1636322 - (ceph) [SRU] upstart: ceph-all service starts before networks up
[16:25] <slashd>   - Series to SRU : xenial trusty
[16:25] <slashd>   - Verification : verification-kilo-needed verification-liberty-needed
[16:25] <slashd>   - Owners : James Page None
[16:25] <cpaelzer> soon the server will ban you :-)
[16:25] <slashd> LP: #1645324 - (ebtables) ebtables: Lock file handling has races
[16:25] <slashd>   - Series to SRU : trusty zesty
[16:25] <slashd>   - Owners : Dragan S.
[16:25] <slashd> LP: #1648242 - (neutron) [SRU] Failure to retry update_ha_routers_states
[16:25] <slashd>   - Series to SRU : xenial
[16:25] <slashd>   - Owners : Edward Hope-Morley
[16:25] <slashd> LP: #1654600 - (unattended-upgrades) unattended-upgrade-shutdown hangs when /var is a separate filesystem
[16:25] <slashd>   - Series to SRU : xenial yakkety zesty
[16:25] <slashd>   - Verification : verification-failed
[16:25] <slashd>   - Owners : Louis Bouchard
[16:26] <slashd> LP: #1657489 - (qemu) qemu-xen: free all the pirqs for msi/msix when driver unload
[16:26] <slashd>   - Series to SRU : trusty
[16:26] <slashd>   - Owners : None
[16:26] <slashd> LP: #1666827 - (horizon) Backport fixes for Rename Network return 403 Error
[16:26] <slashd>   - Series to SRU : xenial
[16:26] <slashd>   - Owners : None
[16:26] <slashd> #info SRU pending for : sssd, nfs-utils, qemu, ebtables, unattended-upgrades, sosreport
[16:26] <rbasak> I appreciate the report - but honestly, I'm not reading that flood. I wonder if anyone is? I suggest sticking to just the list of packages. That single last line would do. Anyone who wants more info knows where to look.
[16:26] <cpaelzer> I read it
[16:26] <ahasenack> here, let me paste it for you again
[16:26] <dpb1> there are a lot of sosreports...
[16:26] <slashd> sorry guys, will do a pastebin next week ;)
[16:26]  * dpb1 slaps ahasenack
[16:26] <powersj> slashd: thx :)
[16:26] <cpaelzer> but I was good wit hthe short list and people polling on details where needed
[16:27] <powersj> #info SRU pending for: sssd, nfs-utils, qemu, ebtables, unattended-upgrades, sosreport
[16:27] <powersj> questions for slashd?
[16:27] <ahasenack> sssd? hm
[16:27] <cpaelzer> #info further SRU pending openssh (X, Y), sssd (T), qemu (Xx2), libvirt (X,Y,Z)
[16:27] <cpaelzer> I have my own set of shi$ :-)
[16:28] <powersj> ok moving on, thanks slashd
[16:28] <powersj> #topic Weekly Updates & Questions for the QA Team (powersj)
[16:28] <powersj> #link https://jenkins.ubuntu.com/server/
[16:28] <powersj> and of course I'm not prepared
[16:29] <powersj> This week I'm looking into some additional CI/pkg build for cloud-init and curtin. And getting the automated ISO tests running again for previous releases.
[16:29] <rbasak> What have you done with the real powersj? :-P
[16:29] <powersj> haha
[16:29] <powersj> Last week was the ericson qemu/hugepages QA, some SRU verification attempts on openssh and tomcat7/8, and I build my own local MAAS setup
[16:29] <powersj> Oh and I broke curtin vmtest badly
[16:30] <powersj> and won't do that again, I have learned my lesson
[16:30] <powersj> #info powersj to get automated ISO tests running again
[16:30] <dpb1> QA Team all about breaking things.
[16:30] <dpb1> amazing
[16:30] <cpaelzer> and on testing fyi - others might just as the virt tests run into cases that there are no lxd/cloud images for artful yet
[16:30] <rharper> powersj: lol
[16:30] <powersj> #info won't break curtin vmtest again
[16:30] <rharper> haha
[16:30] <cpaelzer> uh powersj; we will quote that the next time
[16:30] <rharper> I wouldn't have recorded that
[16:30] <powersj> please do :)
[16:31] <powersj> anything else for the qa noob
[16:31] <powersj> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee)
[16:31] <smb> Noting to report but will listen to questions/requests if there are any (smb not that much more prepared).
[16:31] <cpaelzer> smoser: did anybody else delete the wrong kernels because of special ordering ber LANG ?
[16:32] <cpaelzer> smb: any complaints about 4.10 getting removed unintended to the kernel team?
[16:32] <dpb1> apt-get autoremove deleted wrong kernels?
[16:32] <cpaelzer> na, purge-kernels did
[16:32] <cpaelzer> purge-old-kernels
[16:32] <dpb1> what is purge-old-kernels
[16:32] <smb> cpaelzer, not that we encourage people to use that :)
[16:32] <cpaelzer> hehe, you are safe anyway smb
[16:33] <rbasak> Is that the one inside byobu packaging?
[16:33] <cpaelzer> languages that do thousand separator on "." are good :-)
[16:33] <cpaelzer> yes rbasak
[16:33] <dpb1> rbasak: o.O
[16:33] <rbasak> If autoremove works just as well, should we deprecate and remove that?
[16:33] <smoser> https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/1685338
[16:33] <dpb1> smb: apt-get autoremove is what you all want, right?
[16:33] <cpaelzer> smoser: you are a user of that, please speak for or against the tool in contrast to autoremove
[16:34] <smoser> rbasak, i think the are probably right that we shoudl deprecate or just remove.
[16:34] <cpaelzer> I only happen to know it from a few bugs
[16:34] <smb> rbasak, I remember some people were afraid of autoremove because it might remover other stuff (though it never did remove anything for me which I still needed)
[16:34] <smoser> i have used since before autoremove dtrt
[16:34]  * dpb1 votes to remove this script from byobu
[16:34] <smoser> one reason to keep it would be that it specifically removes old kernels
[16:34] <dpb1> how do I rogers rule of meeting etiquite do that?
[16:35] <smoser> where as autoremove autoremoves whatever
[16:35] <ahasenack> did kikland create it, or did he just added something already existing to byobu?
[16:35] <smoser> possibly autoremove takes a filter.. i dont know.
[16:35] <rbasak> AIUI, he wrote it, and stuck it in with byobu for lack of somewhere else to put it.
[16:35] <rbasak> Let me file a bug at least
[16:36] <powersj> rbasak: for removal?
[16:36] <smoser> https://askubuntu.com/questions/2793/how-do-i-remove-old-kernel-versions-to-clean-up-the-boot-menu
[16:36] <smoser> rbasak, kirkland got something gfrom kees, there was a ubuntu-devel discussion on this i think
[16:36] <rharper> http://blog.dustinkirkland.com/2016/06/purge-old-kernels.html
[16:36] <dpb1> oh my goodness.
[16:37] <dpb1> ok
[16:37] <rharper> "You'll already have the purge-old-kernels command in Ubuntu 16.04 LTS (and later), as part of the byobu package. "
[16:37] <smoser> The definitive answer is: sudo purge-old-kernels
[16:37] <smoser> so there you have it
[16:37] <nacc> in the case where a user does "someting" and autoremove starts to not dtrt
[16:37] <nacc> purge-old-kernels works
[16:38] <nacc> *but* the real goal is to figure out what "something" was and why autoremove stops dtrt
[16:38] <nacc> (imo)
[16:38] <nacc> and fix it
[16:38] <rharper> honestly though, if it's the definitive answer, then it should be a stand-alone package and seeded
[16:38] <rbasak> bug 1686138
[16:38] <dpb1> no
[16:38] <nacc> oftentimes, i've found, it's pinning from an old release
[16:38] <rbasak> rharper: agreed.
[16:38] <dpb1> I think we need a follow up
[16:38] <smb> sudo apt-mark auto `apt-mark showmanual '^linux-(headers|image|image-extra|cloud-tools|tools)-[0-9]'`
[16:38] <rharper> dpb1: ack
[16:38] <smb> ^ I think that should fix autormeove
[16:38] <rharper> smb: that's user friendly
[16:39] <smoser> rharper, also if it is the definitive answer, it should not remove the wrong kernels
[16:39] <rharper> smoser: ack
[16:39] <smoser> even if you do not speak german
[16:39] <cpaelzer> hehe
[16:39] <nacc> smb: correct, my imporession as well
[16:39] <nacc> smb: the problem is joe user who intentionally pinned an old kernel and then un-marking it is wrong
[16:39] <powersj> anything else on removing old kernels?
[16:39] <dpb1> I'll contact dustin
[16:40] <dpb1> you can action me
[16:40] <powersj> #action dpb1 to talk to kirkland re: old kernels
[16:40] <meetingology> ACTION: dpb1 to talk to kirkland re: old kernels
[16:40] <powersj> anything else for smb
[16:40] <powersj> #topic Upcoming Call For Papers
[16:40] <powersj> #link https://lwn.net/Calendar/Monthly/cfp/
[16:41] <powersj> I don't see anything
[16:42] <powersj> #topic Ubuntu Server Team Events
[16:42] <powersj> any events?
[16:42] <powersj> tomorrow... tomorrow...
[16:42] <dpb1> does coffee and wine count?
[16:43] <powersj> #info Bug squashing day 3 tomorrow!
[16:43] <powersj> #link https://lists.ubuntu.com/archives/ubuntu-server/2017-April/007524.html
[16:43] <powersj> #topic Open Discussion
[16:43] <powersj> Free for all... anything else before closing
[16:44] <powersj> nada...
[16:44] <powersj> #topic Announce next meeting date, time and chair
[16:44] <powersj> same time, same place, with cpaelzer at the helm
[16:44] <powersj> cheers
[16:44] <powersj> #endmeeting
[16:44] <meetingology> Meeting ended Tue Apr 25 16:44:40 2017 UTC.
[16:44] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-04-25-16.01.moin.txt
[16:44] <ahasenack> thanks powersj
[16:46] <rharper> thanks powersj
[16:46] <rbasak> Thanks powersj!