[01:24] ogasawara, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498667 [01:24] Launchpad bug 1498667 in linux (Ubuntu) "[Toshiba P50W-B00F] Touchscreen no longer working" [Low,Confirmed] [06:22] Good morning === zsombi_ is now known as zsombi [06:28] pitti, promoting the python-systemd source (binaries were already in main), subscribed foundations-bugs [06:28] doko: ah, thanks; it got split out of the systemd source some time ago [06:28] doko: I subscribe myself as well [06:57] doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-setuptools → python-setuptools-whl still has rdepends, will that now built by another source or will virtualenv and python-pip stop using it? [06:57] doko: i. e. I wonder whether to NBS-remove it from -proposed to unstick it [06:59] pitti, python-pip builds it on its own now [07:00] doko: oh! then I guess it's because the current version from -setuptools is higher (20.0-2) than the one now built from -pip (8.0.2-7) [07:00] however virtualenv breaks tox tests and doesn't migrate [07:00] ah no, setuptools-whl vs. pip-whl [07:01] so virtualenv needs to drop its python-setuptools-whl dep [07:02] doko: tox is something for barry, I suppose [07:02] yes [07:02] doko: I'll look at the apport failure with gdb, apparently it slightly changed behaviour [07:02] ta, just wanted to have the new upstream there before FF [07:03] apparently a null pointer does not show "Cannot access memory at address 0x0" any more [07:03] http://people.canonical.com/~ubuntu-archive/component-mismatches.svg looks interesting ... [07:03] so what should we do with php? including the 7.0 transition? [07:09] doko: server team started too look at it, but no followup to https://lists.ubuntu.com/archives/ubuntu-devel/2016-January/039117.html yet [07:23] good morning pitti, doko :) [07:24] salut cyphermox, comment ça va ? [07:24] ca va bien [07:24] il est tres tard :) [07:24] (or very early, depends on the viewpoint :) [07:29] late night ubiquity hacking eh? :) [07:29] ja [07:29] I was in the zone. [07:29] ^_^ [07:29] except now too many ideas for refactoring that I can't do [07:37] good morning === kickinz1|afk is now known as kickinz1 [08:12] cyphermox, working in parallel n libnftl? [08:14] hmm, big endian targets fail [08:20] ugh [08:24] doko: want to fix the tests? [08:25] doko: or I'd disable them again and file a bug in debian :/ [08:25] cyphermox, who touched the package last? ;) no, just ignore the results on these targets then, if we can't fix it [08:25] ah, that too [08:27] it's not that we couldn't fix it, but that it would take time and I've been awake for too many hours [09:12] seb128: hi! I need some ubuntu/kde dev to look at bug 1451728, do you have some names handy? [09:12] bug 1451728 in ktp-accounts-kcm (Ubuntu Wily) "[master] kde-config-telepathy-accounts package install error" [Critical,Triaged] https://launchpad.net/bugs/1451728 [09:15] mardy, hey, not really, maybe Laney or dholbach can help though [09:16] #kubuntu-devel ? [09:17] yofel, ^ can you suggest somebody? [09:17] Laney, dholbach, thanks [09:17] * Laney would just go ask in there [09:18] Laney: good idea [09:18] ^ debfx, Quintasan should maybe able to help with that as well - they're in ~kubuntu-dev [09:18] hm [09:37] Laney, morning. [09:37] hello [09:37] Laney, I've merged the changes we were discussing. [09:37] Laney, But have one issue. [09:37] Laney, an existing patch, in both the Debian and Ubuntu packages, is slightly modified in the updated Debian packaging. [09:38] I've read how to use quilt to update an existing patch, but I can't get the patch to update. [09:38] Laney, some help with that? [09:40] Can't we use the new version from Debian? [09:41] rbasak: just uploaded clamav with the (unsigned long) cast added & kept the armhf exception as it doesn't build on armhf w/o it [09:41] caribou: OK. Thank you! [09:42] rbasak: trying to upload the git repo now [09:44] Laney, that is what I want to do. [09:44] Then there's no need to quilt update anything [09:44] or am I missing something? [09:44] But when I just copy the revised patch from Debian building the package says the a new changes. [09:45] *there are new changes. [09:45] did you add it to debian/patches/series? [09:45] or use quilt import to copy it in [09:48] Laney, The patch (by name) already exists in the existing Ubuntu and new Debian packaging. The new Debian package has a revised version of the patch. [09:48] I could not get quilt to import it. [09:49] I am not sure exactly how to use quilt to import. [09:49] I read about using quilt to update an existing patch but it didn't work. [09:49] Start from the Debian package and import the *Ubuntu* ones from our old package [09:49] You don't need to touch this new one [09:49] Ahhh. [09:50] So, I was going the other way. Taking the existing Ubuntu and adding the new bits form Debian. [09:50] Right. I'll try what you suggested. Thanks. [09:53] https://paste.debian.net/391176/ [09:53] flexiondotorg: I would do something like that [09:53] then at the end you look at the debdiff to see if it is just the things we need to keep from the old package [09:54] (the version change and the patches?) [09:54] rbasak: do you think that I got the proper rights to upload to lpusdp: Y [09:54] ? [09:54] the epoch thing messes up merge-changelog - that's annoying [09:54] Maybe don't merge-changelog then [09:54] caribou: you should do I think. [09:54] rbasak: I'll try [09:55] caribou: you're a member of ~ubuntu-server-dev by virtue of being a core dev. [10:00] cpaelzer: I noticed in your vblade merge that you renamed the Vcs field. This leads me to think - we can also put in our own Vcs field now, poitning to https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/vblade?h=ubuntu%2Fdevel for example now, since that's where we're maintaining it. [10:00] cpaelzer: I don't think we need to bother until we have some tooling though. [10:01] cpaelzer: perhaps we should have something to wrap update-maintainer and also both sets of Vcs-* changes and put that into ubuntu-git-tools? [10:06] rbasak: I can surely add our VCS field [10:07] do you want me to do that and resubmit, or just for the next upload? [10:08] cpaelzer: next upload is fine. [10:08] Not worth redoing [10:08] cpaelzer: I'm also fine with delaying until we have tooling. No need to spend extra effort until then IMHO. [10:19] Laney: sorry to bother you again :-) I've filed bug 1546020 and attached a patch, but AFAIU the package is maintained in debian; how should I proceed? [10:19] bug 1546020 in telepathy-mission-control-5 (Ubuntu) "Relax apparmor confinement for KDE account files" [Undecided,New] https://launchpad.net/bugs/1546020 [10:20] rbasak: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/clamav [10:20] works fine ! [10:23] mardy: You could send the patch to the Debian BTS https://www.debian.org/Bugs/Reporting [10:26] Laney, mardy, Debian doesn't ship that apparmor profile so it doesn't make sense to forward the patch [10:27] we could try to get them to include the profile though [10:27] ok I didn't check [10:27] urg sorry [10:27] they do [10:27] what [10:27] I looked at the wrong dir [10:27] http://anonscm.debian.org/cgit/pkg-telepathy/telepathy-mission-control-5.git/tree/debian/apparmor-profile [10:27] haha [10:27] bigon added it in decembre [10:29] caribou: thanks! [10:29] caribou: a couple of notes for next time [10:30] caribou: I'm trying to keep the imports clean parent-wise. So "Import version 0.99+dfsg-1" shouldn't have "Import version 0.98.7+dfsg-0ubuntu5" as its parent, since it doesn't have any connection to that. [10:31] Instead it should be an orphan commit in this case, or have a parent of the previous Debian import next time. [10:31] caribou: with that, I'm trying to keep the "debian/sid" branch pointer pointing to the latest Debian import. [10:31] rbasak: ok, noted [10:46] rbasak: another question about your workflow : [10:47] rbasak: what I just pushed in the ubuntu/devel branch only has one tag; all the working tags are in my lpmep: personal branch [10:47] how is the next person doing the merge going to get the working environment ? [10:56] Laney, seb128: so the correct thing to do is to open a bug in the debian BTS? [10:56] caribou: please see https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/logwatch as an example of what I intend. [10:56] rbasak: k [10:56] caribou: when a new logwatch arrives in sid, either a sponsor or a future automatic importer will dsc-commit the new Debian upload to the debian/sid branch and tag it. [10:57] mardy: if you want to forward something there then yes [10:57] mardy: could also be uploaded in ubuntu of course if necessary [10:59] rbasak: ok, I see [11:00] rbasak: In my case, I could push a new debian/sid branch that points to the new/debian tag of my git-dsc-commit import ? [11:01] caribou: you'd check out the debian/sid branch, git-dsc-commit the new Debian upload, tag it import/ instead of just (the tooling needs a bit of tweaking here) then push the branch back with the tag. [11:02] caribou: then you'd check out the ubuntu/devel branch, branch that as local "logical" branch or something, and rebase to squash to come up with the logical tag. [11:02] caribou: the logical/ tag that is. [11:02] caribou: you'd be able to push or otherwise share the logical/ tag (without pushing the local logical branch) at this stage. [11:03] caribou: then you'd branch the logical/ tag as a local "merge" branch, and rebase --onto debian/sid. [11:03] caribou: then you have the same MP capability as current. [11:03] A complication is that others might upload without pushing to ubuntu/devel, so we'd need to dsc-commit to catch that up too if necessary. [11:03] ok, I'll guess it'll become clearer the next time [11:04] rbasak: that will happen with SRU since debdiffs are used most of the time [11:05] Yeah [11:05] Eventually LP will deprecate dput and require a git push instead. Then that'll go away :) [11:06] Laney: thanks for the backport ! === _salem is now known as salem_ [11:37] Laney, could you cast an eye over this diff please? - http://paste.ubuntu.com/15090421/ [11:38] Laney, I haven't used merge-changelog in this diff. [11:38] If is looks good to you, is I bug with this debdiff attached the correct way to proceed? [11:39] flexiondotorg: Fix the versions in the .symbols file to have the epoch [11:39] Wilco [11:39] Say which changes you kept in the changelog (Merge with Debian. Remaining Ubuntu changes - a - b - c) [11:39] and please give the diff on top of Debian too [11:43] OK [11:43] I've found another version requiring epoch in debian/control too. [11:51] Laney, This the the merge from Debian diff - http://paste.ubuntu.com/15090488/ [11:51] flexiondotorg: lies [11:51] that's a diff from the old ubuntu version [11:52] s/old/current/ [11:52] Ag. [11:52] Sec... [11:55] Laney, Bad explanation from me. [11:55] This is the intended merge - http://paste.ubuntu.com/15090488/ [11:56] This is the comparison with current Debian - http://paste.ubuntu.com/15090498/ [11:57] flexiondotorg: cool, looks plausible right now [11:57] toss them on a sponsnoring bug? [11:58] Both diff in the bug? [12:00] ye [12:01] * flexiondotorg is doing it... [12:07] Laney, https://bugs.launchpad.net/ubuntu/+source/libwnck/+bug/1546066 [12:07] Launchpad bug 1546066 in libwnck (Ubuntu) "Request merge with Debian for libwnck" [Undecided,New] [12:07] ty [12:07] I am supposed to sponsor later (although I've got to leave early), will try to look [12:10] Laney, many thanks for your help and tutoring. [12:10] I really appreciate it. [12:25] flexiondotorg: no worries [12:37] slangasek: you mentioned that instead of merging/sync mstflint for trusty we should create a mstflint4 package (probably universe). what is the best procedure for this ? to follow the request for inclusion (as described in [MIR] procedure) ? creating a PPA with full source + bzr branch ? [12:38] (LP: #1470167) btw. i was working on SRU instead of a request for inclusion (probably the needed step now) [12:38] Launchpad bug 1470167 in mstflint (Ubuntu Wily) "mstflint doesn't support Mellanox ConnectX-4 HCAs" [Low,In progress] https://launchpad.net/bugs/1470167 [12:39] hum. slangasek is away, if anyone else can help ^ [12:39] caribou: ^ [12:45] inaddy: an uploader will be able to upload any source package. I suggest you follow normal SRU procedure and link to a source package upload from the bug somehow. A PPA would be fine. [12:45] (and detail the exception in the bug) [12:46] rbasak: cool. will do. tks [13:05] kickinz1: the merge target is meant to be ubuntu/devel, not debian/sid. Then when the uploader uploads and pushes to ubuntu/devel, the MP conveniently notices. [13:06] rbasak, sorry. [13:06] rbasak, You want me to redo the MP? [13:07] No, it's fine. [13:08] kickinz1: also, I expect you to have a tag called logical/1_2.10.1-1ubuntu1 [13:09] kickinz1: is this what you called logical/ubuntu-2.10.1-1? [13:09] rbasak, yes. [13:09] OK [13:23] bdmurray, I commented on bug 1318721 [13:23] bug 1318721 in neutron (Ubuntu Trusty) "RPC timeout in all neutron agents" [High,Fix committed] https://launchpad.net/bugs/1318721 [13:29] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [13:37] cd [13:38] ~ [13:39] didrocks: ~, sweet ~! [13:39] * didrocks hugs pitti [13:39] * pitti hugs didrocks back [14:11] xnox: We just saw "sosreport : Depends: python3.4:any but it is not installable" in a livefs build for s390x cloud images (but other arches seem to be happy); any ideas? [14:32] Odd_Bloke, it's weird as nothing should depend on python3.4 anymore. [14:33] Odd_Bloke, yet it clearly is. [14:33] Odd_Bloke, let me analyze the scope here. [14:33] pitti: re apparmor merge-- sure, we'll figure it out. not sure if I personally will do it, but we can get someone on it [14:41] Odd_Bloke, we have a few http://paste.ubuntu.com/15091848/ [14:41] doko, pre-mature removal of python3.4 ^ [14:50] actually less. [14:51] doko, Odd_Bloke: uploaded 7 packages, which should resolve python3.4, or lack of, for good. [14:52] xnox: Thanks. :) [14:55] Does someone have a few spare cycles to review the mstflint -> mstflint4 package creation for me ? Rather simple leaf package [14:55] http://paste.ubuntu.com/15092039/ [14:56] rbasak: hoping to wrap up the strongswan stuff today but I've a general question; as we've been testing the proposed package we've identified a number of fixes and some features that are helpful; should I leave those to the side of the merge and apply them after the merge or is it OK to bring in the additional bug fixes and ubuntu changes in the merge itself (as part of the new ubuntu delta) ? [14:56] xnox, ta, reverse-depends didn't show any ... [14:56] doko, yeah, weird. Usually things like that are picked up by the transition tracker, but that too has false positives/negatives. [14:57] doko, anyway, i've dputed the remaining 7 packages, and will rerun the chdist test ones they migrate, across all 7 arches, to check that we are all good. [14:57] the only one I saw was sigil, but a recommends only [14:57] at first i have suspected an arch-skew (given that s390x was a bootstrapped one) [15:00] rharper: up to you. It's fine to add them to the merge upload if you wish. Or do it later if you think it's unnecessarily blocking the merge. We probably shouldn't regress anything big that is known in the merge upload though. [15:00] rbasak: ok; I don't think anything is blocking; they've all been easy fixes or updates. [15:04] rharper: OK that's fine - just add extra commits and extra top level bullet points in d/changelog for each change. [15:05] doko, xnox: one i happened to see on that list is mine, python-ase, FTBFS with new numpy [15:05] (d/changelog probably via git-reconstruct-changelog) [15:05] ginggs, oh. [15:05] ginggs, well. [15:05] * rbasak wonders if that should be renamed to git-construct-changelog as it's not really redoing anything [15:06] ginggs, if it's uninstallable and FTBFS we will need to demote it to -proposed, such that it is not uninstallable in release. [15:06] xnox: remove it if you must, i'll upload it when it is fixed (waiting for response from upstream) [15:06] until fixesd. [15:06] xnox: ack [15:06] ginggs, demote to proposed is the new "remove from release" [15:07] doko, do you have powers to demote-to-proposed python-ase? [15:07] there is a script to do that in archive-tools repository i think. [15:08] rbasak: thanks [15:17] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:20] xnox, gpaw still depends on it [15:24] doko, it's python2 only? [15:24] xnox, both demoted [15:26] doko, i don't see gpaw using python3 at all. So if it's demoted it will probably just migrate back. https://launchpadlibrarian.net/236788889/buildlog_ubuntu-xenial-amd64.gpaw_0.11.0.13004-3build2_BUILDING.txt.gz [15:27] it build-depends on python3 but i don't see it building python3 anything. [15:29] hi, this packagefonts-hosny-amiri have been updated but I find the old version in 16.04 https://github.com/khaledhosny/amiri-font/releases [15:29] fonts-hosny-amiri how to get it in 16.04 before feature freeze? [15:30] question on FFEs since it's that time and I've never filed one; if there is an existing merge bug, would I just add the justification to the existing merge bug or file a new bug just for the FFE and reference the merge bug ? [15:32] rharper: just change the bug title [15:32] ginggs: ok [15:34] rharper: and edit the bug description to include the justification [15:34] gotcha; no need for a new bug, update title and include the justification . Thanks! [15:58] pitti, can you override the libreoffice-l10n autopkg as well? it seems to still be grumpy about libreoffice which blocks libreoffice itself because they need to go together [16:04] vila: flexiondotorg: I didn't make it to sponsoring today, sorry - will start with that tomorrow so I don't get on to anything else [16:04] * Laney waves [16:06] Laney: looks like mdeslaur did ! Thanks to both ! [16:07] pitti, around ? [16:18] seb128: hm, I actually did, but britney doesn't get along with hints with multiple versions apparently; I'll apply a +1 force then :) [16:18] smoser: Im' back [16:19] pitti, so the open-iscsi... you thought our delta had all been taken into debian ? [16:19] pitti, thanks [16:19] smoser: yes, except the autopkgtest [16:19] such that we should re-sync with much smaller delta [16:20] but sync woudl still be necessary, right ? for the auto pkg test [16:20] annoying that we have to carry package delta for that, but seemingly fairly easiliy synced if that is in fact it [16:21] smoser: right, "re-merge" [16:21] ok. i will look to see if i can't get that merged. [16:22] Are there any plans to replace bzr packaging branches (i.e. UDD) with git equivalents? [16:23] Odd_Bloke: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html but not much in the way of updates since then unfortunately [16:24] Odd_Bloke: note that it's fairly easy to create your own (or better yet, branch from Debian's) for packages you work on often [16:25] Odd_Bloke: I find that the vast majority of packages I happen to look at in Debian already have a git, and that will always be better than some synthetically imported one [16:25] cjwatson: Aha, cool, I thought I had seen something about it. Any sense of when it might end up happening, or is it a someday thing for now? [16:25] it's most convenient to have an ubuntu git branch in the Debian git repo, or at least mirror it in LP [16:25] Odd_Bloke: I really hope to manage it this year but realistically can't promise anything definite [16:26] but if not, "gbp import-dsc foo.dsc" et voilà :) [16:26] Odd_Bloke: the server team is doing it now. We'll have an interim importer for packages we follow soon. [16:26] (not using gbp import-dsc as not doing an upstream/debian split) [16:26] cjwatson: Ack; we just didn't want to spend time working on something that would be easier with it if it were right around the corner. :) [16:27] Odd_Bloke: once we have the importer, perhaps we can track your packages for you too. [16:27] Odd_Bloke: so the thing you want to work on has no VCS in debian? [16:27] pitti: The thing we want is livecd-rootfs. :) [16:27] asrcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk [16:28] eek, s/ssrc/V/ [16:28] Odd_Bloke: perhaps it's time to convert that to git and use that from now on? [16:28] We have been using that. [16:29] then you have all the history, and not just the coarse-grained one from auto-imports [16:29] But ran in to problems for two reasons: (a) a refactor happened over multiple commits (without a release, so not an actual problem) and we started a build in the middle, breaking our images. [16:29] I don't want to diminish cjwatson's work, but I've never found such synthetic VCSes particularly useful [16:29] (b) once xenial is released, we will want to track xenial's livecd-rootfs for xenial. [16:30] Odd_Bloke: right, so for (b) you'd branch off /xenial (instad of /trunk) at some appropriate point, and for (a) you'd use a branch as well [16:30] (The use-case here is building a private livecd-rootfs package which contains private bits for partner clouds; we want to build on top of whatever the latest _released_ version of livecd-rootfs package is in a specific suite) [16:30] (in both bzr and git) [16:30] pitti: dgit actually looks like it could be a much better compromise there than UDD ever was [16:31] pitti: But /xenial branches weren't created a la cjwatson's email above (right?). [16:31] pitti: because it's easier to stitch in history from different places, and we don't have the file-id problem [16:31] Odd_Bloke: the above Vcs-Bzr: is a manually maintained "real" branch, it's got nothing to do with UDD or the above Launchpad work [16:31] I tend to agree we should just convert livecd-rootfs to git and be done [16:31] cjwatson: yeah, true [16:31] I guess it'd be polite to ask ogra_ if he's okay with git migration [16:32] as he's working on it a lot, and it's also his birthday :) [16:32] (so don't make him grumpy today) [16:32] eek, git ?!? [16:32] pitti: Ack, but if I s/trunk/wily/ that URL, there isn't anything there. [16:32] but it's hard to avoid git these days :) [16:32] pitti: synthetic VCS is better than no VCS, which is the situation with many Ubuntu-deltified packages right now. [16:32] pitti, up to now i managed to :) [16:32] Odd_Bloke: right, as long as nobody makes those branches they won't :) but easy enough to create it once you need it, by branching off the tag corresponding to the wily version [16:32] ogra_: wow, congrats [16:32] That's why an importer is useful. As long as Ubuntu uploaders aren't required to commit to VCS, we need an importer if we want to use VCS tooling to help us with our work. [16:33] Yeah, this ^ [16:33] rbasak: right, but branching off Debian's VCS is still better IMHO :) [16:33] right for the "catch up with dput" [16:33] pitti: unfortunately that's really tricky to do reliably, _and_ have a single workflow across all the packages we look after. [16:33] pitti, i dont really want to be the blocker though ... [16:34] well, I just wanted to mention gbp import-dsc, which might speed things up until this lands in LP [16:34] rbasak: you could probably use bits of dgit as the importer [16:34] or that ^ [16:34] How do we match up the Debian VCS commit with a Debian upload, for example. What if a Debian NMU means that the VCS is missing an upload? [16:34] Etc. [16:34] nacc: ^ [16:34] since its raison d'être is doing repeatable imports [16:34] ogra_: I'm truly amazed that you managed to stay away from git until now :) [16:35] Currently we're using https://github.com/basak/ubuntu-git-tools/blob/master/git-dsc-commit, which just blats a .dsc as a commit. [16:35] rbasak: the point of dgit for that is that it doesn't matter, it'll construct an appropriate commit on the fly [16:35] pitti, well, beyond git clone indeed ... the majority of stuff i work on is still using bzr ... and upstreams i work with are often enough fine with patches :) [16:35] in a deterministic way so that if different people do it they get the same answer [16:35] That sounds neat. [16:36] dgit does look handy [16:37] Trevinho, just curious... bug 1521302 is terribly annoying to me. do you think this is something fixed sometime soon ? [16:37] bug 1521302 in unity (Ubuntu) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed] https://launchpad.net/bugs/1521302 [16:37] smoser: yes, but it's something we can delay for now... [16:38] willcooke: can you please add that to our list ^ [16:38] is there some work around ? [16:39] smoser: not that I know, maybe you can force with soemthing like wnckprop or other scripts, but... Nothing inside compiz AFAIK [16:41] hrm, odd. Doesn't do it it 14.04, does in 16.04 [16:41] I'll add it to the backlog now [16:41] thanks. [16:45] rbasak: What time frame are you looking at for your importer work? [16:46] nacc: ^ [16:46] Odd_Bloke: i'll hopefully get it done/working next week [16:47] OK, nice. [17:00] stgraber, kees, infinity, mdeslaur: TB meeting now? (or not?) [17:01] pitti: thanks [17:01] cyphermox: hey, how am I supposed to talk to for NM nowadays? [17:02] just installed a clean Xenial box and opened the connection editor, I see lxcbr0 in there... [17:02] I thought we made it so that NM would stop messing with this... [17:03] doesn't look like it actually generated any config in /etc/NetworkManager but it's one click away from breaking lxcbr0 and having confused users waste hours of my team's time again... [17:03] (did I mention I hate Network Manager) [17:03] I suppose it's still me [17:05] stgraber: NM will always show the devices in nmcli [17:05] or in the connection editor device list for that matter [17:05] that doesn't mean nm-applet will show anything [17:07] infinity, around ? [17:07] we're seeing regressed behavior (tests started failing) https://platform-qa-jenkins.ubuntu.com/user/smoser/my-views/view/trusty%20amd64/job/ubuntu-trusty-server-amd64-smoke-minimal-virtual/ [17:07] that seem to match up time-wise with at least your debian-installer upload https://lists.ubuntu.com/archives/trusty-changes/2016-February/021231.html [17:08] the point of that test is to install linux-virtual and then verifiy that the installed system is generally smaller (and that it has linux-virtual) installed. [17:08] cyphermox: and there's still no magic .d directory I can have lxc dump a file into to make sure our stuff never shows in NM is there? [17:09] smoser: What log am I looking at? [17:09] sure there is [17:09] cyphermox: last I checked there was something close to it, but any key set in there would fully overwrite the previous value [17:09] stgraber: /etc/NetworkManager/conf.d [17:09] cyphermox: so if I was to ship one with the lxc and lxd package, the lxd one (alphabetical order) would override the key set by the lxc one, not append to it [17:09] *shrugs( [17:09] right, that's the broken thing I looked at last time [17:09] that test above (platform-qa-jenkins) . tries to seed installation of linux-virtual metapackage via: [17:10] I don't think you can have NM never show the devices [17:10] d-i base-installer/kernel/override-image string linux-virtual [17:10] it's doing what it's supposed to do, let you handle network devices. we already go out of our way to make sure people can't break lxc by clicking in nm-applet [17:10] and then basically verifiesd that it got installed. it did not when that test ran with media [17:10] Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212) [17:10] err.. ^ it passed [17:10] stgraber: but it should still show devices, just like ifconfig should. [17:10] failed with: Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212) [17:11] stgraber: ie. if someone goes out of their way to do something stupid, too bad. [17:11] cyphermox: I seem to remember I tried using keyfile with unmanaged-devices and it kinda worked except that it couldn't be appended to, just overriden [17:11] it's already unmanaged [17:12] we patched that in [17:12] ok, kinda weird that unmanaged means that NM still lets you manage it though :) [17:12] stgraber: unmanaged means NM won't touch it automatically [17:13] anyway, I guess we'll see how things turn out with 16.04, but I'm getting 2-3 reports of broken lxcbr0 a day due to NM and I'm getting sick of it [17:13] stgraber: you can still poke things if you really wanted to [17:13] most of them get fixed by asking the user to "grep -r lxcbr0 /etc/NetworkManager" and remove any file that turns up [17:13] smoser: Okay, but I'm not seeing a log that tells me what happened. [17:13] I think we should take another look at the reports, and make sure it's not people doing something that should be pretty obvious one shouldn't do [17:14] infinity, well, yeah, they're burried in the artifcats [17:14] stgraber: that sounds a lot like someone going in to edit random things without knowing what they're for [17:14] there's also still a race somewhere in there where NM yanks the IPv4 address from our bridge at cration time. We fixed the most obvious one of those back in Wily (was hitting 90% of the time) but there still seems to be one (hits < 1%), still trying to get some kind of reproducer though... [17:15] cyphermox: my best guess so far si: connection editor -> edit lxcbr0 -> don't change anything -> save [17:15] stgraber: I'm not against apply a patch to hide things if the patch makes sense and isn't going to break stuff, but people can already break things by editing random files [17:15] which isn't obviously wrong, they didn't change anything, they just went to look at it clicked save instead of close [17:16] right [17:16] I would suggest filing bugs upstream for some of these [17:17] smoser: Right, can you tell me what bug you're reporting? "I have a test that does a thing and my test fails" isn't a bug, unless you can tell me *why* your test is failing. [17:18] yeah, will look into that at some point after FF I guess, or just distro patch nm-connection-editor and the gnome control center components to hide unmanaged devices too (so they match nm-applet) [17:18] infinity, well, we pre-seed installation of linux-virtual with: [17:18] stgraber: well, that won't work [17:18] infinity, well, we pre-seed installation of linux-virtual with: [17:18] d-i base-installer/kernel/override-image string linux-virtual [17:18] cyphermox: btw, any chance of getting 1.1 in xenial? I'd really like the 1.1 openvpn plugin, seems to fix a ton of stuff compared to our broken 0.9* version [17:18] stgraber: connections are separate from devices [17:19] cyphermox: how was it done in the applet then? [17:19] that used to result in installation of linux-virtual and then durint a stable release, that behavior changed. [17:19] stgraber: per-device, not connections [17:19] stgraber: I suppose what could be done is to explicitly hide connections that start in /lxc.*/ [17:20] i'm not 100% certain that the 'base-installer/kernel/override-image' actually did anything (rather than something realizing we're "virtual" and installing -virtual magically) , but even without that... we changed behavior in a stable release. [17:20] cyphermox, couldn't udev rules, or some such set variables on the NIC to hint to network manager "don't touch this"? [17:20] but even that is bound to fail at some point, people might actually want to create a connection named "lxc" for some other reason [17:20] xnox: devices are already being unmanaged, that is already fine. [17:20] xnox: I think there is a udev rule, but this isn't the problem [17:20] cyphermox, that way, e.g. autocreated/managed things can do "NETWORK_MANAGER_HIDE_ME_HARDER=1" =) [17:21] stgraber: I suppose we could probably already update the VPN plugins [17:22] i dont really understand how the change i'm pointing to there could have caused this by looking at its diff, but something worked on the 20160212 and started failing on 20160215. [17:22]