=== infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[01:23] <rbasak> nacc: agreed. Did I screw that up when refactoring?
=== hggdh is now known as vittnet
=== vittnet is now known as ayd
=== salem_ is now known as _salem
[08:15] <tjaalton> hrm, resolving local hostnames worked yesterday but today after a reboot I get SERVFAIL
[08:15] <tjaalton> resolv.conf doesn't have "search foo" anymore
[08:19] <sbeattie> tjaalton: what release?
[08:19] <tjaalton> zesty
[08:19] <sbeattie> ah okay
[08:21] <tjaalton> restarting systemd-resolved makes it timeout instead
[08:21] <tjaalton> "no servers could be reached"
[08:29] <tjaalton> filed a bug
=== _salem is now known as salem_
[12:42] <jbicha> didrocks: thanks for helping review the UKUI packages, UKUI added a COPYING.LGPL to the control-center source
[12:43] <jbicha> it's LGPL-3 but the code is LGPL-2+ or LGPL-2.1+ (or other licenses); is that fine or do they need to explicitly add a copy of the LGPL-2.1 instead?
[12:45] <jbicha> https://github.com/ukui/ukui-control-center
[12:45] <jbicha> https://github.com/ukui/debian-packages/blob/master/ukui-control-center/debian/copyright
[12:45] <handsome_feng> hi, jbicha, sorry, i will update it now
[12:46] <jbicha> handsome_feng: just a moment, I'm trying to find out what exactly needs to be done :)
[12:48] <didrocks> jbicha: I would prefer LGPL2
[12:48] <jbicha> didrocks: just LGPL2? not LGPL2.1?
[12:48] <didrocks> yeah, 2.1
[12:48] <didrocks> (just read it quickly ;))
[12:49] <jbicha> handsome_feng: ok, yeah, just replace the LGPL3 with the LGPL2.1 then
[12:53] <jbicha> handsome_feng: is switching to the org.mate.control-center schema intentional at https://github.com/ukui/ukui-control-center/commit/6e7769e9 ?
[12:53] <jbicha> if so, you'll need to depend on mate-control-center-common
[12:56] <jbicha> also, in the future could you not reuse your release tags? once you release a 1.0.1, you'll need to use a different version number if you want to change something
[12:59] <handsome_feng> sorry, i got it and the I will check the schema right now
[13:09] <handsome_feng> hi, jbicha, mate-settings-daemon depends the scheme, so we need to depends this, so we have added the dependence in control file. And we have updated the ukui-control-center and ukui-indicators.
[13:11] <jbicha> ok, I see, thanks!
[13:11] <hallyn> apw: so seriously, i thought that since a year or two ago, for sru's targeting $release-updates instead of $release-proposed was now ok, in fact perhaps preferred?
[13:12] <Laney> hallyn: You're probably thinking of $release instead of $release-proposed
[13:13] <Laney> The former is rewritten to the latter internally
[13:13] <rbasak> hallyn: yeah I'd been meaning to reply to your mail but was out last week.
[13:14] <rbasak> hallyn: usually people upload to just "$release". I'm not sure what would happen if I accepted something targetted to $release-updates directly and fear that it'll somehow go in without going through -proposed. To my knowledge, the only redirect that exists is $release -> $release-proposed, and that happens before the upload appears in the unapproved queue.
[13:15] <hallyn> Ok.  and nothing wrong with $release-proposed still?
[13:15] <rbasak> Whereas your uploads to $release-updates appears in the unapproved queue as the updates pocket.
[13:15] <rbasak> Nothing wrong with $release-proposed mechanically, though I always felt it was ugly as it looks odd when it lands. I'd still accept it though.
[13:15] <rbasak> Though I prefer consistency for ease of mentoring sponsors.
[13:16] <rbasak> Uh, mentoring sponsorees.
[13:16] <hallyn> ok, thx.  i'll stick with the old then, like the old man i am
[13:17] <hallyn> now maybe yakkety isn't worth uploading anyway
[13:19] <hallyn> meh, did it anyway.  now i'm still not sure what to do about t.
[13:19] <hallyn> is it the case that trusty-backports is basically enabled everywhere?
[13:35] <didrocks> jbicha: once you sponsored the new packages, mind poking me?
[13:47] <jbicha> didrocks: I uploaded ukui-control-center now; peony is also part of UKUI; I assume Laney is sponsoring ukui-indicators unless he says otherwise
[13:48] <didrocks> ok :)
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:52] <Laney> jbicha: I say otherwise
[14:05] <jbicha> Laney: what was the reject message?
[14:07] <didrocks> two things IIRC, same issue with COPYING.LGPL missing and as well some erronous file listing in debian/copyright
[14:09] <jbicha> ok
[14:27] <jbicha> didrocks: ukui-indicators uploaded—that should be the last one for UKUI
[14:27] <gQuigs> do I pretty much always want to run the update-maintainer script when I'm doing an SRU?  (It's one of those things I usually forget to do, and AFAICT even if it's not changed in the source file we still change it somehow - example: http://packages.ubuntu.com/xenial-updates/pcs )
[14:28] <gQuigs> ^for a package from Debian... with a maintainer from Debian
[14:32] <rbasak> gQuigs: yes
[14:32] <rbasak> gQuigs: I think there is an exception in the case of Kubuntu maintained packages and perhaps some others.
[14:32] <gQuigs> rbasak: good to know, thanks
[14:32] <rbasak> Though it would be nice if update-maintainer and the other tooling were taught that.
[14:36] <mardy> morphis: hi! Is bug 1658617 getting near the top of your todo list, or is it still far? If you don't have time to work on it, I could try to give it a shot
[14:36] <ubottu> bug 1658617 in Ubuntu App Platform "webapps crashing - oxide being compiled with wrong libs?" [Undecided,New] https://launchpad.net/bugs/1658617
[14:41] <sil2100> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
[15:05] <nacc> rbasak: looks like it is explicitly set to ignore_nonexistent=True in both cases (lpusip/lpmep)
[15:06] <nacc> rbasak: i wonder if we can also rather than simply raise the CalledProcessError in the case of ignore_nonexistent=False, logging.exception('a useful message') and sys.exit(1)?
=== joedborg_ is now known as joedborg
=== CRogers_________ is now known as CRogers
[15:43] <rbasak> nacc: maybe create a custom exception?
[15:43] <rbasak> I've created CLIError in the past.
[15:45] <nacc> rbasak: yeah taht would be fine with me -- just thinking that the exception backtrace is not going to be that useful to end-users or us, as it's a potentially clear issue (probably a mis-typed srcpkg)
[15:46] <rbasak> nacc: we can catch CLIError at the top level, print the string and exit the exit code only.
[15:46] <rbasak> I don't know what others think of that method. I've used it in the past as it feels the cleanest (eg. with testing).
[15:47] <nacc> rbasak: i think i'd be happy with that
[15:47] <rbasak> assertRaises(CliError...) instead of having to mock out sys.exit, etc.
[15:47] <nacc> rbasak: if you don't have time for it right now, i'd also be happy with ignore_nonexistent=True for lpusip and a bug filed for refactoring :)
[15:52] <rbasak> nacc: created bug 1674740 for now. Sorry for the formatting. I need to figure out a better way to do that :-/
[15:52] <ubottu> bug 1674740 in usd-importer ""usd clone" is not fatal when lpusip is empty" [Undecided,New] https://launchpad.net/bugs/1674740
[15:53] <nacc> rbasak: totally fine, thanks
[15:55] <nacc> cpaelzer: thanks for the effort on that vsftpd/pam-mysql bug. I am wondering if we should just SRU back 0.8 to 16.04 and 16.10? Given the lack of maintenance of the old version -- having 16.04 be on '0.7~RC1' that won't ever exist as 0.7?
[15:55] <nacc> cpaelzer: iiuc, you did not see the issue with 0.8 on 16.04?
[15:59] <cpaelzer> nacc: ack I did not see the issue on my 0.8 test
[15:59] <cpaelzer> nacc: but the code was too different to identify a fix
[15:59] <nacc> cpaelzer: ok, i'm tempted to suggest that is the right fix then -- it's at least maintained now at that version
[15:59] <nacc> cpaelzer: and for an LTS taht seems at least somewhat important
[15:59] <cpaelzer> nacc: backporting the real 0.8 over the non exitstin RC might be a good idea
[16:00] <cpaelzer> nacc: We might make it an MRE then and get an ack of the release Team
[16:00] <cpaelzer> not-so-minor, but still process wise like an MRE a bit
[16:01] <nacc> cpaelzer: yeah
[16:25] <nacc> smb: re: that bug, i got (just now) BUILD_EXCLUSIVE_KERNEL to work, but that means iscistarget-dkms (I think) will return an error for all newer hwe kernels if installed with them.
[16:25] <nacc> smb: i couldn't get OBSOLETE_BY to do anything
[16:27] <smb> nacc, ok. For quick summary the iscsitarget-dkms was an iscsitarget implementation from before the kernel had its own implementation (that existed at least since xenial)
[16:27] <nacc> smb: agreed
[16:27] <smb> nacc, but as you said it does not seem to be maintained any longer and broke around yakkety
[16:27] <nacc> smb: and removed from teh archive in yakkety
[16:28] <nacc> (and in debian)
[16:28] <smb> ah ok
[16:28] <nacc> smb: that's where i think the disconnect is (to me) removing it from yakkety should imply it doesn't dkms build on the hwe stacks that come from yakkety+
[16:28] <nacc> smb: as there's no testing possible of it working at this point
[16:29] <caribou> any archive admin in the room ? I've uploaded nfs-utils to Zesty on friday and I see no trace of it; should I just re-upload ?
[16:29] <smb> nacc, right we have been ignoring the adt failures there
[16:31] <nacc> smb: which i suppose is fine, but we should really fix the package (and have at least that one user having filed a bug on it now)
[16:33] <smb> nacc, Yeah, not sure there is a good way to basically point them to "tgt" (which is the admin tools part that works against the in-kernel iscsi target=
[16:33] <cjwatson> rbasak: sys.exit is implemented by raising an exception anyway ...
[16:33] <nacc> smb: yep, that's what i've documented elsewhere (iirc)
[16:33] <nacc> cjwatson: ah good to know :)
[16:34] <cjwatson> (though for testability I would probably also prefer raising a dedicated exception)
[16:35] <nacc> smb: i mean, in theory, we could put in a dummy package that replaces what we have now, if we're saying don't use it. But it does build (and seems to be used) on 16.04.0/1
[16:37] <smb> nacc, true, so the complete move is only something that would be possible on an upgrade path to yakkety or next lts. For hwe kernels not sure
[16:40] <nacc> smb: and well, for 16.10+, the move was deletion :) so probalby should be in the release notes (esp. in 18.04, i suppose)
[16:40] <nacc> smb: not sure if that has been encountered before, was hoping kernel folks would know :)
[16:42] <sil2100> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[16:42] <smb> nacc, Oh we basically told you (server) and asked whether you would have any idea of how commonly iscsitarget is still used. :-)
[16:42] <smb> nacc, apparently at least "someone"
[16:42] <caribou> cjwatson: sil2100: apw: is there a specific archive admin IRC room ?
[16:43] <sil2100> caribou: not that I know of, usually pinging on #ubuntu-release is what we do
=== Daviey_ is now known as Daviey
[16:50] <apw> caribou: indeed ubuntu-release is best
[16:51] <caribou> apw: yep, got my answer there, thanks!
[16:59] <rbasak> cjwatson: good point, thanks.
[17:00] <nacc> smb: heh
[17:06] <nacc> smb: thanks for the update in the bug -- not sure how best to proceed from here? is there any precedent for this kind of issue in the past that you know of?
[17:07] <nacc> slangasek: --^ maybe you have input, as well, as your RM'd the package in 16.10
[17:07] <nacc> slangasek: iscsitarget-dkms and what to do with it on the 16.04.2 hwe kernel
[17:07] <slangasek> nacc: what was my removal comment? :)
[17:08] <nacc> slangasek: LP: #1613758 "iscsitarget no longer appears to be maintained."
[17:09] <ubottu> Launchpad bug 1613758 in iscsitarget (Ubuntu Yakkety) "[RM] iscsitarget should be removed from Yakkety" [Undecided,Fix released] https://launchpad.net/bugs/1613758
[17:09] <nacc> slangasek: fully agreed with
[17:09] <nacc> slangasek: but the package wasn't fixed in 16.04, so it still builds there against the same kernel it didn't build against in 16.10
[17:35] <nacc> slangasek: the only thing i could get to work was a 'BUILD_EXCLUSIVE' entry in dkms.conf -- but not sure that is a great solution, because it does lead to an 'Error' message from dkms (but is better than failing the build)
=== JanC_ is now known as JanC
[17:59] <slangasek> nacc: right, no opinion on any of this, really; everything I know about this package is just what's in the bug log
[18:01] <nacc> slangasek: sure, but from a pseudo-policy perspective, what would you consider the right thing to do for hwe compatibility? I think clearly we shouldn't be building the dkms modules against newer kernels, but i'm not sure if it should be flagged as an error if a user tries (as it does build against the 16.04.0/1 kernel). But even in 16.04.0/1, I think we'd want to recommend not using it and using hte
[18:01] <nacc> upstream module and tgt.
[18:05] <rbasak> slangasek: would you mind taking a glance at bug 1672099 please? I'm not sure if this could be related or made moot by the systemd-resolved/dnsmasq stuff I think you're driving?
[18:05] <ubottu> bug 1672099 in dnsmasq (Ubuntu) "DNS loop, >5,000 queries per second for minutes at a time" [Undecided,New] https://launchpad.net/bugs/1672099
[18:08] <slangasek> nacc: I thought dkms had a facility for filtering by kernel version, which if straightforward would be non-controversial.  If Linux 4.4 also has a better upstream driver already and we think we should neuter the dkms package entirely in favor of this, that seems ok but requires more regression testing.  Or is there any reason we couldn't just leave the iscsitarget package as-is in 16.04, and users
[18:08] <slangasek> use it if they want to and don't if they don't? it's in universe anyway
[18:13] <nacc> slangasek: yeah, that's what (I think) BUILD_EXCLUSIVE_KERNEL would do. Agreed on the need for testing to ensure (and it's not a no-op migration, as src:iscsitarget itself has some tooling in iscsitarget (ietd, etc) which only works with the dkms module. We can leave the package as-is in 16.04, mark the bug as won't fix. But then there will be (are?) users who were on 16.04.0, installed
[18:13] <nacc> iscistarget-dkms there and it worked fine, and have opted-in to 16.04.2 hwe and the dkms fails to build (and apport will ask to file a bug every time afaict)
[18:15] <slangasek> rbasak: AFAIK dnsmasq is dropped out of the default DNS stack again in 17.04, so that shouldn't be happening?
[18:15] <slangasek> certainly, resolved+networkd+resolvconf+dnsmasq might have bugs like this
[18:15] <slangasek> but that's not the config we're supposed to be shipping
[18:25] <slangasek> nacc: if it fails to build every time, maybe they eventually decide to remove the package? :)
[18:27] <nacc> slangasek: right, I just wasn't sure if that was a desirable user experience in an LTS :)
[18:27] <rbasak> slangasek: I'll note that in the bug. Thanks!
[18:28] <slangasek> nacc: when all available options involve some risk of going badly, I tend to prefer this happening as a result of an explicit action the user has taken, rather than of us trying to be overly clever and compounding the problem
[18:28] <slangasek> explicit action - installing iscsitarget-dkms (which they didn't need to) and then installing the hwe stack
[18:29] <nacc> slangasek: i think (if i had to guess) end users are installing iscitarget-dkms because of the upgrade from 14.04 to 16.04 (but not usre)
[18:29] <nacc> i could also update the release notes for 16.04 (I think) to indicate we don't recommend using the package on 16.04 and see if i can find a good guide on using tgt with the upstream driver
[18:29] <slangasek> cyphermox: ^^ could you easily confirm what I said above about dnsmasq no longer being used by default in 17.04?  I think barry finished the re-revert on n-m
[18:31] <cyphermox> do you mean the re-re-re-revert or just the re-re-revert?
[18:32] <cyphermox> ;)
[18:32] <cyphermox> I check, hold on :)
[18:33] <nacc> slangasek: i think i agree in principle with your stance, just trying to translate it in my head to actionable items for the bug and for end-users to consume
[18:35] <cyphermox> slangasek: nacc: yes right now we're using resolved AFAICT
[18:40] <cyphermox> nacc: sorry, that was meant for rbasak
[18:40] <rbasak> cyphermox: thanks
[18:40] <cyphermox> in any case, it's potentially a real upgrade bug rather than an unsupported mix of features
[18:41] <rbasak> Yeah could be
[18:41] <slangasek> indeed
[18:42] <cyphermox> I haven't checked, but I suppose it could be that either the extra file for dns=resolved isn't installed, or /etc/NetworkManager/NetworkManager.conf didn't get overridden correctly
[18:42] <rbasak> cyphermox: feel free to take over the bug!
[18:42] <rbasak> I was just triaging
[18:43] <cyphermox> should be pretty easy to reproduce if it's the case, I'll try to run that on my X230 once I'm done with shim
[18:45] <slangasek> cyphermox: AFAIK even in 16.10 we already have resolved running by default, but nothing hooks it into /etc/resolv.conf or resolvconf because NM+dnsmasq takes precedence.  So I don't see any practical way for dnsmasq and resolved to see each other
[18:46] <cyphermox> this is 17.04 though
[18:47] <cyphermox> I'm thinking this is a continually upgraded system that has kept some old config
[18:50] <slangasek> I'm thinking it's a user who has manually installed the dnsmasq package in error
[18:52] <cyphermox> oh, you have a point, this one is showing up as 127.0.0.1.
=== dannf` is now known as dannf
[19:16] <nacc> slangasek: fwiw, http://paste.ubuntu.com/24223425/ seems to work, and emits a 'this kernel is marked as not supporting this driver' style message
[19:18] <slangasek> cool
[19:20] <hallyn>  /var/lib/AccountsService?  wtf ppl
[19:21] <cyphermox> hallyn: ?
[19:21] <hallyn> qemu but complaining that qemu user isn't made a system user - in that file
[19:21] <hallyn> s/but/bug
[19:22] <cyphermox> that's... interesting
[19:24] <hallyn> lucky for me cpaelzer will handle it :)  where handle it probably means set it to wontfix
[19:29] <cpaelzer> hallyn: yeah that is an ugly, but not evil bug
[19:29] <cpaelzer> hallyn: I haven't read the history, but this is the one I dup all that to (and analyzed whats going on)
[19:29] <cpaelzer> hallyn: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1667113
[19:29] <ubottu> Launchpad bug 1667113 in netqmail (Ubuntu) "System users appears in Ligthdm and user switcher (Accountsservice has no filter for shell types)" [Undecided,Confirmed]
[19:35] <hallyn> cpaelzer: yeah, right, thanks.  So yeah accountssservice (or anything using it) simply needs to recognize shadow's hints.  libvirt does 'adduser --system', so libvirt is good.
[19:36] <hallyn> also the accountsservice web page says "may be replaced/subsumed by sssd at some point".  well that makes me want to spend time porting to accountsservice api doesn't it :)
=== fo0bar_ is now known as fo0bar
[21:03] <slangasek> rharper: do you think you could put together an SRU test case for LP: #1673860?
[21:03] <ubottu> Launchpad bug 1673860 in systemd (Ubuntu Yakkety) "systemd-resolved unit should run Before=network-online.target" [Undecided,New] https://launchpad.net/bugs/1673860
[21:03] <slangasek> rharper: (the yakkety upload is in the queue)
[21:03] <rharper> slangasek: yes
[21:10] <robru> Laney: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320270 ok I think I addressed all your concerns, please rereview
=== ayd is now known as hggdh
=== sarnold_ is now known as sarnold
[21:44] <nacc> smb: does this look ok to you? http://paste.ubuntu.com/24224511/ (with a corrected version and a bug ref of course)
[21:53] <nacc> smb: i just tested on 16.04.2 and manually installing linux-{image,headers}-generic led to a successful build for the 4.4 kernel and the 4.8 kernel gets skipped.
=== balloons27 is now known as balloons
=== salem_ is now known as _salem
=== acheronuk is now known as acheronUK