=== salem_ is now known as _salem
=== bluesabre_ is now known as bluesabre
=== mfisch is now known as Guest16197
=== stub` is now known as stub
[05:56] <hikiko> hello
=== JanC_ is now known as JanC
[06:07] <noam> Hi! Where is the script that produces the ubuntu ISO images?
=== Guest64506 is now known as ahasenack
=== ahasenack is now known as Guest79511
[08:53] <seb128> doko, hey, re your reply on the list about the sponsoring item, see +activity on the log, somebody sponsored the item yesterday and unsubscribed sponsors when doing so, so they were subscribed... it's just that we don't have much active sponsors :-/
[08:53] <doko> seb128: ahh, I see
[09:29] <alkisg> The version of nbd-client in xenial doesn't really support systemd, see for example https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679
[09:29] <alkisg> The version of nbd-client in debian stretch does support systemd.
[09:29] <alkisg> How easy would it be to have an SRU for syncing with the new version, instead of targetting individual bug fixes, which I think is quite hard wrt the code changes?
[09:29] <ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged]
[09:30] <seb128> bdmurray, hey, the +activy package does show when the team was unsubscribed on that sponsoring bug, where are you looking?
[09:31] <seb128> alkisg, hey, depending of the complexity of the changes and how good the package testsuite (or manual testing) is, you basically need to convince the SRU team that the update is not going to create new issues for users who had it working
[09:32] <seb128> alkisg, if the previous version can't work for anyone it should be pretty easy to argument for an update, if it's not that obvious then you need to convince of the pros&cons
[09:33] <alkisg> seb128: ty; I'll file a bug report and make a few arguments there
[09:33] <seb128> alkisg, thanks
[09:37] <ricotz> helloW: APT had planned for dpkg to do more than it reported back (4 vs 6).
[09:37] <ricotz>    Affected packages: base-files:amd64
[09:38] <ricotz> oops, was about to ask if this was reported somewhen in the past
[09:39] <ricotz> "apt-get install --reinstall base-files" doesn't resolve it
[09:42] <ricotz> juliank, hi, ^
[09:43] <juliank> ricotz: oh, a bug there, nice. I sometimes wish DonKult was here, he wrote that stuff ...
[09:44] <juliank> ricotz: That's in yakkety?
[09:44] <juliank> or zesty?
[09:44] <juliank> or where?
[09:44] <ricotz> juliank, no idea, what this is about ;), on zesty
[09:44] <juliank> OK.
[09:44] <ricotz> I assume this package is in this state for a while
[09:45] <juliank> ricotz: It's a disagreement how many steps dpkg will execute.
[09:45] <juliank> ricotz: Does that actually break anything?
[09:46] <ricotz> so far I dont see any side-effect, the package was configured too
[09:46]  * juliank has no idea, that's fairly new stuff - DonKult recently made apt not queue each dpkg request in detail but allowed dpkg to act a bit more on its own. This obviously means that our view of what dpkg will do should match what dpkg does.
[09:46] <juliank> I told DonKult about it, but it's probably a good idea to open a bug for that
[09:46] <ricotz> (but it is marked as not completely installed)
[09:47] <ricotz> iW  base-files                                                       9.6ubuntu8                                           amd64
[09:47] <juliank> Open a bug in LP, and add all your details there :)
[09:47] <juliank> I don't want to play proxy between #ubuntu-devel here on #debian-apt on OFTC
[09:48] <Laney> but you do it so efficiently
[09:48] <juliank> and a bug is more persistent and we can actually mark it as solved :)
[09:48] <Laney> almost no dropped packets
[09:48] <juliank> Laney: How do you know?
[09:48] <Laney> the N in laney stands for NSA
[09:49] <juliank> Oh. I always thought Laney means LA, ney - a misspelling of LA, nay.
[09:50] <Laney> La NSA 'ears you
[09:50] <juliank> Actually, it appears ney is used as well
[09:50] <mmmm> Would my computer be able to run ubuntu? https://postimg.org/image/yqfdsljtb/
[09:50] <juliank> but it's an instrument
[09:50] <juliank> A type of end-blown flute.
[09:51] <sladen> mmmm: the hardware would be more than capable for installing Debian or Ubuntu, yes
[09:53] <mmmm> Trying to get the secure boot disabled has been the hardest part
[09:53] <bdmurray> seb128: In the wrong column on the activity log. :-|
[09:53] <seb128> bdmurray, k
[09:54] <bdmurray> seb128: feel free to follow up
[09:54] <seb128> bdmurray, somebody else did
[09:55] <sladen> mmmm: yes, the difficulties will be things like changing the boot order/boot setup to get either Debian or Ubuntu installed
[10:20] <mitya57> pitti, hi, can you please help me a bit using your archive team powers?
[10:20] <mitya57> I need a package removal (bug 1646867) and decruft of gnome-panel (rm old binaries)
[10:20] <ubottu> bug 1646867 in command-runner-applet (Ubuntu) "Please remove command-runner-applet from Zesty" [Undecided,New] https://launchpad.net/bugs/1646867
[10:21]  * mitya57 did a general ping two times here, but nobody responded :(
=== ginggs_ is now known as ginggs
[10:32] <rharper> pitti: thanks for the sanity check, I was able to get things working with just adding a +Before=systemd-networkd.service to resolvconf.service
[10:34] <rharper> pitti: since that file is part of the resolvconf package I'll update bug 1636912 with the details;  should I mark that verification-failed and link to a resolvconf change? or leave it -needed, and wait till we also have a resolvconf update ?
[10:34] <ubottu> bug 1636912 in cloud-init (Ubuntu) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912
[10:37] <infinity> mitya57: Removal done, though LP is timing out on me trying to close the bug. :P
[10:38] <mitya57> infinity, thanks a lot!
[10:38] <infinity> mitya57: Not sure what "decrufting" you're looking for for gnome-panel.
[10:39] <mitya57> infinity, I meant removing old libpanel-applet0{,-dbgsym} and gir1.2-panelapplet-5.0 binaries to that the new version can migrate
[10:40] <mitya57> (which changed to libpanel-applet2 and no gir bindings)
[10:40] <infinity> mitya57: It'll migrate fine without doing that.
[10:40] <infinity> mitya57: We remove NBS packages *after* migration, not before.
[10:40] <infinity> (doing it before would break the archive)
[10:40] <mitya57> OK, I was probably confusing with Debian then. Thanks again!
[10:40] <mitya57> pitti, unping :)
[10:41] <infinity> mitya57: http://paste.ubuntu.com/23587930/ shows that the only issue is command-runner-applet, which will clear up after the next publisher run.
[10:43] <mitya57> OK, I do check that page, but not always sure that I parse it correctly.
[11:05] <pitti> mitya57: good; sorry, sprint week, negligible IRC bandwidth
[11:07] <mitya57> Thanks anyway and sorry for the noise!
=== freyes__ is now known as freyes
=== _salem is now known as salem_
=== hikiko is now known as hikiko|ln
[13:38] <slashd> cyphermox, xnox, I have a critical bug here LP: #1579609 for os-prober, there is a patch proposed in debian, I test the patch with different users experiencing the issue, and they claimed it solve the situation, since the patch is not yet merge in debian and that this is a CRITICAL bug as it may cause some FS corruption, do you think we can go ahead with the SRU anyway or better wait the merge in debian ?
[13:38] <ubottu> Launchpad bug 1579609 in os-prober (Ubuntu Xenial) "os-prober bug resulting in possible FS corruption" [Critical,In progress] https://launchpad.net/bugs/1579609
=== hikiko|ln is now known as hikiko
[13:42] <juliank> mdeslaur: Feel free to query ...
[13:49] <cyphermox> slashd: we can land it in a SRU, it's not a problem if the patch is sane.
[13:50] <slashd> cyphermox, it is, and has been tested by different users
[13:50] <cyphermox> well, I'll be the judge of that ;)
[13:50] <slashd> cyphermox, sure
[13:54] <cyphermox> slashd: seems to me like it probably should just drop the else part
[13:54] <slashd> cyphermox, agree
[13:56] <slashd> cyphermox, if I understand properply you are good with it (minus the else part) ? or you need more time to check ?
[13:56] <cyphermox> slashd: I think I'd be more ok if it was just changing the else part of that if, rather than changing both branches
=== Guest16197 is now known as mfisch
=== mfisch is now known as Guest73037
[14:04] <slashd> like this ? https://pastebin.canonical.com/172868/
[14:04] <slashd> cyphermox ^
[14:04] <cyphermox> right, but the error message is probably wrong too in this case
[14:08] <slashd> cyphermox, any suggestion ?
[14:15] <cyphermox> "failed to probe for filesystem type" or something like that?
=== Guest73037 is now known as mfisch
[14:15] <slashd> Yeah, I like that
=== mfisch is now known as Guest13281
=== Guest13281 is now known as mfisch
[14:16] <slashd> cyphermox, ok will proposed a debdiff today, tks, do you think you'll have time to sponsor it this week ?
=== mfisch is now known as Guest40664
[14:17] <slashd> cyphermox, enjoy Seville chanceux ;)
=== Guest40664 is now known as mfisch
[14:22] <xnox> pitti, i do not understand the libseccomp NMU
[14:22] <xnox> it seems weird. What does Build-Depends-Package in .symbols do?
[14:43] <pitti> xnox: it makes sure that the generated shlibs depends is never lower than the version of the specified package in that flag
[14:43] <pitti> xnox: see dpkg-shlibdeps(1)
[14:44] <pitti> xnox: "version" as in "installed during package build", that is
[14:49] <xnox> pitti, interesting
[14:50] <juliank> Someone remind me to actually try to SRU ndiswrapper everywhere with newer kernels - all these build failure reports are somewhat annoying...
[14:50] <juliank> s/build failure/dkms failure/
[14:51] <juliank> It certainly would be nicer if we also did ndiswrapper uploads that work with new kernels when new kernels enter LTS releases
[14:54] <doko> wgrant: because you fixed xdelta3 to run the tests ... is the desktop team really the correct bug subscriber?
[14:55] <doko> I mean, they were for trusty, but now?
[15:06] <pitti> cpaelzer: https://launchpad.net/ubuntu/+source/postgresql-9.5/9.5.4-3
[15:22] <slashd> cyphermox, I have attach the debdiffs to LP: #1579609
[15:22] <ubottu> Launchpad bug 1579609 in os-prober (Ubuntu Xenial) "os-prober bug resulting in possible FS corruption" [Critical,In progress] https://launchpad.net/bugs/1579609
=== PaulW2U_ is now known as PaulW2U
[16:41] <seb128> @pilot in
[17:22] <chiluk> sarnold: mind if you upload https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304 for me?
[17:22] <ubottu> Launchpad bug 1634304 in virt-manager (Ubuntu) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Confirmed]
[17:31] <chiluk> seb128:  ^^
[17:58] <sarnold> chiluk: sorry, I don't have sufficient privileges :(
[17:59] <chiluk> ah.. I figured you did considering your earlier review of that bug.
[17:59] <chiluk> or were you just a concerned user of virtinst?
[18:00] <chiluk> sarnold ^
[18:11] <sarnold> chiluk: pff, worse than that, I just can't help myself. I read every patch just because it's there. I should try to just a group therapy for it or something but no one else is wlling to publicly admit they suffer from the same condition
[18:12] <chiluk> sarnold: you are definitely in the minority within the minority.
[18:12] <sarnold> chiluk: aye.
[18:12] <sarnold> at least regular obsessed people climb mountains or something.
[18:13] <chiluk> sarnold: we give free operating systems to underprivileged kids in third world countries.
[18:13] <chiluk> I think that's pretty respectful.
[18:13] <sarnold> chiluk: thanks for being my ennabler :)
[18:14] <chiluk> any time.
[18:14] <chiluk> now go find me a sponsor.
[18:14]  * chiluk works on motu application.
=== msbrown is now known as msbrown-afk
[20:59] <wgrant> doko: I'm not sure who owns the snappy packages for main purposes. Will poke around.
[20:59] <wgrant> doko: Do you have any other concerns about the MIR so far?
[21:04] <maqifrnswa> Hello again - when someone gets a chance, can you re-trigger autopkgtest for python-qtconsole against ipython? https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=ipython&trigger=python-qtconsole%2F4.2.1-3
[21:08] <maqifrnswa> There might be a circular dependency problem preventnig ipython, glueviz, and python-qtconsole from migrating
[21:09] <maqifrnswa> (from proposed). ipython used to have a bug in autopkgtest, so it would fail and never migrate. python-qtconsole autopkgtest saw that ipython couldn't migrate, so it wouldn't. glueviz sees python-qtconsle can't automigrate, so it won't - but it also requires the newest version of ipython (which is also stuck)
[21:11] <maqifrnswa> migrating ipython is prevented because it will break the old version of glueviz, but the new version of glueviz requires the new version of ipython
[21:12] <maqifrnswa> thank you!
=== salem_ is now known as _salem