=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:21] <Harris> I want to make a custom install of elementary os which is based on ubuntu... is there a ubuntu base file that has 0 programs installed just the os
[03:45] <valorie> Harris: there is a mini-iso
[03:45] <valorie> !mini-iso
[03:46] <valorie> phooey
[03:47] <valorie> one can make a custom ISO as well
[03:47] <valorie> !iso
[03:47] <ubottu> To mount an ISO disc image, type « sudo mount -o loop <ISO-filename> <mountpoint> » - There is a list of useful cd image conversion tools at http://wiki.linuxquestions.org/wiki/CD_Image_Conversion - Always verify the ISO using !MD5 before !burning.
[03:48] <valorie> https://help.ubuntu.com/community/Installation/MinimalCD
[03:48] <valorie> also there is netboot
[03:48] <valorie> !netboot
[03:48] <ubottu> Ubuntu can be installed in lots of ways. Please see https://help.ubuntu.com/community/Installation for documentation. Problems during install? See https://wiki.ubuntu.com/CommonProblemsInstall - Don't want to use a CD? See http://tinyurl.com/3exghs - See also !automate
[04:23] <Harris> i need a base image though
[04:28] <valorie> the mini-iso, as I said above
[04:46] <krytarik> Harris: This might be what you're looking for: https://wiki.ubuntu.com/Base
=== miguel_ is now known as Guest80586
[08:27] <bdrung_work> Trevinho, ping (regarding #1671432)
[08:40] <rbasak> cpaelzer: argh. Bileto publishes Zesty at the same time as the SRUs? I was expecting to do Zesty only. Haven't actually reviewed the SRUs yet.
[08:41] <cpaelzer> cpaelzer: I'd have expected to give some choice which to pub
[08:42] <cpaelzer> rbasak: ^^
[08:42] <cpaelzer> talkign to myself
[08:42] <cpaelzer> rbasak: but eventually it is not too wrong either, the zesty publish will have to move on and has to pass z-p as usual
[08:42] <cpaelzer> rbasak: and while doing so the others stick in unapproved until that passed
[08:43] <rbasak> It's a pain from an SRU processing perspective, because as long as it isn't in the Zesty release pocket the SRU team won't want to release the upload from xenial/yakkety unapproved.
[08:44] <cpaelzer> rbasak: isn't that what I just said ... rereading ...
[08:50] <cpaelzer> rbasak: so right now it is in each releases unapproved, due to the freeze on z
[08:51] <cpaelzer> rbasak: it will stay in all of them, the first to accept at some point should be in Z
[08:51] <cpaelzer> rbasak: there it will hopefully migrate just fine
[08:51] <cpaelzer> and after that it is normal SRU/unapproved processing
[08:51] <rbasak> cpaelzer: yes, I think we agree on the mechanics
[08:51] <cpaelzer> rbasak: I don't see the extra pain yet?
[08:52] <rbasak> My complaint was just that it can waste some SRU time, that's all - if the SRU team look to process it before the release team release it from Zesty unapproved and it finishes landing in the release pocket.
[08:52] <rbasak> Or if there's a problem with the Zesty side, but I hope not as it is more tested by bileto in the correct environment of course.
[08:52] <cpaelzer> ack
[08:53] <cpaelzer> thanks to explain the extra SRU concerns
[08:53] <cpaelzer> let me add a comment to the bug so that SRU members know right away
[08:53] <cpaelzer> then it should only waste seconds
[08:58] <cpaelzer> rbasak: Done
[08:58] <cpaelzer> rbasak: didn't know that it does all-at-once publishes
[08:58] <cpaelzer> rbasak: will split them up next time
[09:12] <rbasak> cpaelzer: thanks. I'm not sure that's the right answer, or what the right answer is right now. I just wasn't expecting it, that's all.
[10:16] <brendand> autopkgtest is spewing:
[10:16] <brendand> Can't locate Dpkg/Deps.pm in @INC (you may need to install the Dpkg::Deps module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at - line 1.
[10:16] <brendand> but that appears to be blatantly false
[10:16] <brendand> $ ls /usr/share/perl5/Dpkg/Deps.pm
[10:18] <rbasak> rharper: thank you very much for the chart in bug 1649931 - it's very helpful. I'm afraid I still don't follow the details though - it'll take me a disproportionate amount of time compared to the SRU queue in general I think. slangasek, as you're more familiar with this, would it make more sense for you to take care of this please?
[10:18] <ubottu> bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed] https://launchpad.net/bugs/1649931
=== Guest80586 is now known as pastillage
[12:44] <arges> rbasak: planing on doing some sru reviews.
[12:46] <rbasak> arges: ack. I've only been looking at releases so far today.
[12:46] <rbasak> arges: bug 1656712 currently.
[12:46] <ubottu> bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress] https://launchpad.net/bugs/1656712
[12:48] <arges> ok starting with xenial upload queue
=== _salem is now known as salem_
[13:29] <am_> hi all, not sure if i'm in the correct place. I am wondering what happened to dh-make-pecl in 16.04 ?
[13:29] <am_> i am tryiing to package up a pecl extension but the dh-make-pecl package doesn't seem to exist
[13:58] <mterry> infinity: can you promote mediascanner2 and unity-scope-mediascanner?  Would help the unity8 scopes to not be so bare
[13:59] <infinity> mterry: Yup, getting there.
[13:59] <mterry> Gotcha, thx!
[14:01] <infinity> pitti: cockpit testsuite fails on armhf
=== scott is now known as Guest75173
[14:12] <cpaelzer> I'd need opinion on proper changelog construction for SRUs
[14:12] <cpaelzer> Example: apache2 in trusty has had a 2.4.7-1ubuntu4.14 in proposed but that failed verification
[14:12] <cpaelzer> I'm now creating a 2.4.7-1ubuntu4.15 for a different issue and wonder what the right changelog approach is
[14:12] <cpaelzer> a) mention the changes in the failed-to-verify as reverted in .15
[14:12] <cpaelzer> b) not mentioning them in .15 but keeping the .14 version in the history  (I'd consider that wrong)
[14:12] <cpaelzer> c) taking the old .14 OUT of the history so that from a users POV it goes .13 -> -15
[14:12] <cpaelzer> I've seen people do a) and c) and I personally would prefer c)
[14:12] <cpaelzer> rbasak: ^^
[14:12] <cpaelzer> moved the discussion to ubuntu-devel
[14:25] <pitti> infinity: you mean mips? it's fine on https://buildd.debian.org/status/fetch.php?pkg=cockpit&arch=armhf&ver=134-1&stamp=1491261708&raw=0
[14:25] <pitti> I'll look at the mipsen failures soon
[14:26] <infinity> pitti: I mean armhf on Ubuntu.
[14:26] <infinity> pitti: Note this is #ubuntu-devel :P
[14:26] <pitti> infinity: oh, wow -- I wasn't aware someone was that trigger happy to sync it to Ubuntu already :)
[14:27] <infinity> cpaelzer: If you've completely reverted .14, omitting that changelog entry is correct too, IMO.
[14:27] <pitti> infinity: # assertion failed (keyring >= 0) -- ah, same issue as on mips
[14:28] <pitti> infinity: I figure our ARM buildd kernel just has kernel keyrings disabled; I'll adjust the tests to skip in that case
[14:28] <infinity> pitti: jbicha synced it, apparently.
[14:28] <infinity> pitti: Err, as for kernels missing features, that seems... Wrong.
[14:28] <infinity> pitti: Which CONFIG is that?
[14:29] <cpaelzer> infinity: thanks
[14:29] <pitti> infinity: I haven't looked into that at all yet, not sure
[14:29] <infinity> CONFIG_SYSTEM_TRUSTED_KEYRING=y maybe?
[14:30] <infinity> We have tha enforced on in all arches on xenial.
[14:30]  * infinity scratches head.
[14:30] <pitti> infinity: possibly; I wonder if "keyctl list @u" works there
[14:30] <pitti> I'll try and find a Debian porter mips box to reproduce it (but not today)
[14:31] <pitti> also, I would have thought FF and all that, I was aiming for the adventurous aardvark
[14:31] <infinity> pitti: Yeah, FF doesn't really apply to new universe packages.
[14:33] <Trevinho> bdrung_work: sorry, I've been notified... Please let's get in touch tomorrow, as it's too late for me now...
[14:33] <Trevinho> I've *not* been
[14:34] <bdrung_work> Trevinho, no problem. just ping me tomorrow
[14:35] <Trevinho> ack
=== Guest44125 is now known as smb
=== smb is now known as Guest92937
[14:48] <sil2100> doko: hey! Looking at the FTBFS from the test-rebuild - is there a way to easily re-run a failed build to check if it wasn't just a transient failure?
[14:49] <doko> sil2100: just tell me which ones to retry
[15:11] <bdmurray> jbicha: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1656712/comments/3 does that indicate the possibility of a regression if we release flatpak and ostree?
[15:11] <ubottu> Launchpad bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress]
[15:16] <jbicha> bdmurray: no, that's not a regression but a missing feature and that comment was about xenial not yakkety
[15:16] <jbicha> bdmurray: but rbasak said he was looking at the yakkey part of that bug today
[15:17] <rbasak> I was almost about to release that (Yakkety), but I got distracted, sorry.
[15:17] <jbicha> currently, I have ostree and flatpak in the new queue for xenial but I didn't package xdg-desktop-portal (and -gtk) for xenial
[15:18] <rbasak> I'll try to look again today.
[15:18] <jbicha> thanks
[15:20] <rbasak> jbicha: released. Sorry for the delay.
[15:35] <jbicha> bdmurray: thanks for the ping though, I'm following up with the person that left the flatpak comment to make sure I understood correctly
[15:56] <sil2100> doko: I'd like to see if zeromq3 would fail again after a re-run
[15:56] <sil2100> doko: I vaguely remember the test-suite wasn't too solid
[17:29] <nacc> rbasak: how is the unapproved functionality looking?
[18:20] <rharper> slangasek: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606 ;  resolvconf change got tagged in this bug; but I don't believe it's related;  one user mentioned they had to downgrade, but another only had to downgrade network-manager;  the change in question to resolvconf has to do with unit start up sequence and does not affect any runtime behavior (ie, resolvconf service is already active/running
[18:20] <rharper>  when encountering the issue).  I'd like to mark the resolvconf task as invalid; does that seem reasonable? (and I'll include my logic for doing so )
[18:20] <ubottu> Launchpad bug 1671606 in resolvconf (Ubuntu) "DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1" [High,Confirmed]
[18:22] <slangasek> rharper: sure
[18:22] <slangasek> rharper: especially as NM+dnsmasq+resolvconf == 127.0.1.1 in /etc/resolv.conf and that shouldn't have changed
[18:32] <rharper> slangasek: thanks!
[18:38] <barry> bdmurray: python-babel ftbfs looks even more interesting in a local build test due to dst issues.  there's no bug # atm, but i'm investigating
[18:39] <nacc> xit
[18:39] <nacc> bah
[18:41] <rbasak> nacc: I haven't touched it in a while. It basically seems to work fine, though I'd like to tweak the CLI
[18:41] <rbasak> I want it to autodetect the package name from debian/changelog so it doesn't need to be specified
[18:41] <rbasak> And then replace the existing "usd queue <package>" with "usd queue sync". Then I think it'll be ready to land.
[18:41] <nacc> rbasak: ok, i can probably do that locally if you want to propose a MR?
[18:41] <rbasak> Sure, thanks!
[18:43] <nacc> rbasak: would like to get that in the latest snap just so i can document it on the wiki too :)
[18:44] <rbasak> nacc: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/322042
[18:44] <rbasak> nacc: the intention of "usd queue sync" is that then things like "usd queue approve" and "usd queue reject" will become possible. IOW, "usd queue" should take subcommands.
[18:45] <nacc> rbasak: ack
[18:46] <nacc> rbasak: any reason for USDQueueImporter rather than USDQueue ? (to match the others)?
[18:46] <rbasak> No, feel free to change
[18:46] <rbasak> It predates me deciding what to call the subcommand
[18:46] <nacc> thanks!
[19:30] <pfsmorigo> there is something wrong with https://insights.ubuntu.com/
[19:31] <sarnold> pfsmorigo: yes. it's under investigation now.
[19:31] <pfsmorigo> sarnold, ok
[19:31] <sarnold> thanks pfsmorigo :)
[19:31] <wxl> probably because everyone's hitting it hard in disbelief that unity's on its way out :)
[19:32] <pfsmorigo> wxl, yeah, I'm one of them!
[19:32] <pfsmorigo> wxl, since it's close to april 1st I was afraid that was a lie
[19:32] <wxl> hah it might be
[19:32] <wxl> but i don't think so
[20:07] <slangasek> rharper: looks like the submitter disagrees with your analysis on resolvconf
[20:07] <rharper> I replied
[20:07] <slangasek> ok :)
[20:07] <rharper> I Think we need a dnsmasq task there
[20:08] <rharper> at least if the analysis in the RH bugzilla is correct
[20:09] <rharper> in general, a change to the unit file on when resolvconf starts doesn't impact it at runtime;  no code changes to resolvconf so whatever one sees on 1.78ubuntu2 should be also seen on 178ubuntu4;  I think some folks aren't aware of the 'task' to package mapping and thought I was marking the bug invalid
[20:09] <rharper> I've invited the user to supply further details on "resolvconf not tracking interfaces" in case there is an element in resolvconf here; but that doesn't seem to be the case when pointing to an upstream fix for dnsmasq
[20:09] <slangasek> he specifically claimed that new NM exposed a bug in the behavior of resolvconf; anyway, I just wanted to draw it to your attention since I knew you had unassigned yourself
[20:10] <slangasek> right
[20:12] <rharper> slangasek: cool; yeah I'm still subscribed to the bug; I appreciate the ping and advice; thanks!
[21:56] <nacc> rbasak: i think i've got everything working with queue -- i will push it up and can you test with master?
[22:07] <slangasek> huh, what happened on 31Jul2014 that created a bunch of backup files of .pyc on my system
[22:12]  * mwhudson checks his diary
[22:44] <dasjoe> sarnold: probably better over here
[22:45] <sarnold> ohai a second dasjoe :)
[22:45] <sarnold> nacc: here?
[22:45] <sarnold> dasjoe: normally you'd file a bug report with the template in the wiki; fill out the bits you can; attach a debdiff, describe how you tested
[22:45] <nacc> sarnold: works for me
[22:46] <dasjoe> HELO
[22:46] <nacc> dasjoe: is there a bug filed?
[22:46] <dasjoe> So rbasak asked for a proper SRU in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193 and I'm trying to fulfil his request
[22:46] <ubottu> Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Medium,Confirmed]
[22:47] <nacc> dasjoe: ok, so you confirmed it's fixed in zesty?
[22:48] <dasjoe> nacc: well, I'm in the process of doing so. Haven't booted zesty yet, but manually installing zesty's debs in xenial fixes the not-appearing part of the bug
[22:49] <nacc> um, that's probably not the right way to test
[22:49] <nacc> hopefully that was in a removable VM :)
[22:49] <dasjoe> It's not a VM but a sandbox laptop ;)
[22:50] <nacc> oh ok
[22:50] <nacc> so presuming you do verify the fix in zesty, update the bug to fix released (if you can, or just put a comment in)
[22:50] <nacc> i just created tasks for x & y
[22:52] <dasjoe> So, the "fix" required two updated packages, network-manager-strongswan and strongswan-nm. I would have created a new bug in LP and marked both packages as affected
[22:52] <sarnold> dasjoe: so... what's the goal? move the packages from https://launchpad.net/~raharper/+archive/ubuntu/bugfixes/+packages to the main archive? have you tested those? or is another goal?
[22:52] <nacc> dasjoe: no, you can create tasks against multiple source packages in one bug
[22:53] <dasjoe> sarnold: the easiest goal would be to simply copy network-manager-strongswan, strongswan-nm from z to x & y
[22:53] <sarnold> dasjoe: aha :)
[22:53] <dasjoe> I haven't looked at raharper's PPA
[22:54] <nacc> dasjoe: taht won't happen
[22:54] <nacc> dasjoe: SRUs need to be small and self-contained
[22:54] <nacc> ideally
[22:54] <nacc> z is several minor version bumps
[22:54] <dasjoe> Yeah, I thought so
[22:54] <nacc> well, i should say, that won't happen normally
[22:55] <nacc> and certainly not in the context of this bug which seems to be for only one specific issue with one specific fix
[22:55] <dasjoe> It's just that the package in x does not work *at all* so there would be no harm in upgrading to a fresher upstream version
[22:56] <sarnold> heh, sounds persuasive to me :)
[22:57] <dasjoe> It's the one thing that's holding back a VPN rollout for a customer, so I'm looking to get IKEv2 usable via nm without having to build stuff by hand ;)
[23:03] <dasjoe> Oh well, time to a) build a IKEv2 VPN gateway VM and b) get and boot zesty. I'll be back… tomorrow, hopefully
[23:04] <sarnold> dasjoe: the backportpackage command may make it easy to test building the zesty pacakge against xenial