robert_ancellogasawara, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/149866701:24
ubottuLaunchpad bug 1498667 in linux (Ubuntu) "[Toshiba P50W-B00F] Touchscreen no longer working" [Low,Confirmed]01:24
pittiGood morning06:22
=== zsombi_ is now known as zsombi
dokopitti, promoting the python-systemd source (binaries were already in main), subscribed foundations-bugs06:28
pittidoko: ah, thanks; it got split out of the systemd source some time ago06:28
pittidoko: I subscribe myself as well06:28
pittidoko: 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
pittidoko: i. e. I wonder whether to NBS-remove it from -proposed to unstick it06:57
dokopitti, python-pip builds it on its own now06:59
pittidoko: 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
dokohowever virtualenv breaks tox tests and doesn't migrate07:00
pittiah no, setuptools-whl vs. pip-whl07:00
pittiso virtualenv needs to drop its python-setuptools-whl dep07:01
pittidoko: tox is something for barry, I suppose07:02
pittidoko: I'll look at the apport failure with gdb, apparently it slightly changed behaviour07:02
dokota, just wanted to have the new upstream there before FF07:02
pittiapparently a null pointer does not show "Cannot access memory at address 0x0" any more07:03
dokohttp://people.canonical.com/~ubuntu-archive/component-mismatches.svg  looks interesting ...07:03
dokoso what should we do with php? including the 7.0 transition?07:03
pittidoko: server team started too look at it, but no followup to https://lists.ubuntu.com/archives/ubuntu-devel/2016-January/039117.html yet07:09
cyphermoxgood morning pitti, doko :)07:23
pittisalut cyphermox, comment ça va ?07:24
cyphermoxca va bien07:24
cyphermoxil est tres tard :)07:24
cyphermox(or very early, depends on the viewpoint :)07:24
highvoltagelate night ubiquity hacking eh? :)07:29
cyphermoxI was in the zone.07:29
cyphermoxexcept now too many ideas for refactoring that I can't do07:29
dholbachgood morning07:37
=== kickinz1|afk is now known as kickinz1
dokocyphermox, working in parallel n libnftl?08:12
dokohmm, big endian targets fail08:14
cyphermoxdoko: want to fix the tests?08:24
cyphermoxdoko: or I'd disable them again and file a bug in debian :/08:25
dokocyphermox, who touched the package last? ;) no, just ignore the results on these targets then, if we can't fix it08:25
cyphermoxah, that too08:25
cyphermoxit's not that we couldn't fix it, but that it would take time and I've been awake for too many hours08:27
mardyseb128: hi! I need some ubuntu/kde dev to look at bug 1451728, do you have some names handy?09:12
ubottubug 1451728 in ktp-accounts-kcm (Ubuntu Wily) "[master] kde-config-telepathy-accounts package install error" [Critical,Triaged] https://launchpad.net/bugs/145172809:12
seb128mardy, hey, not really, maybe Laney or dholbach can help though09:15
Laney#kubuntu-devel ?09:16
dholbachyofel, ^ can you suggest somebody?09:17
seb128Laney, dholbach, thanks09:17
* Laney would just go ask in there09:17
mardyLaney: good idea09:18
dholbach^ debfx, Quintasan should maybe able to help with that as well - they're in ~kubuntu-dev09:18
flexiondotorgLaney, morning.09:37
flexiondotorgLaney, I've merged the changes we were discussing.09:37
flexiondotorgLaney, But have one issue.09:37
flexiondotorgLaney, an existing patch, in both the Debian and Ubuntu packages, is slightly modified in the updated Debian packaging.09:37
flexiondotorgI've read how to use quilt to update an existing patch, but I can't get the patch to update.09:38
flexiondotorgLaney, some help with that?09:38
LaneyCan't we use the new version from Debian?09:40
caribourbasak: just uploaded clamav with the (unsigned long) cast added & kept the armhf exception as it doesn't build on armhf w/o it09:41
rbasakcaribou: OK. Thank you!09:41
caribourbasak: trying to upload the git repo now09:42
flexiondotorgLaney, that is what I want to do.09:44
LaneyThen there's no need to quilt update anything09:44
Laneyor am I missing something?09:44
flexiondotorgBut when I just copy the revised patch from Debian building the package says the a new changes.09:44
flexiondotorg*there are new changes.09:45
Laneydid you add it to debian/patches/series?09:45
Laneyor use quilt import to copy it in09:45
flexiondotorgLaney, 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
flexiondotorgI could not get quilt to import it.09:48
flexiondotorgI am not sure exactly how to use quilt to import.09:49
flexiondotorgI read about using quilt to update an existing patch but it didn't work.09:49
LaneyStart from the Debian package and import the *Ubuntu* ones from our old package09:49
LaneyYou don't need to touch this new one09:49
flexiondotorgSo, I was going the other way. Taking the existing Ubuntu and adding the new bits form Debian.09:50
flexiondotorgRight. I'll try what you suggested. Thanks.09:50
Laneyflexiondotorg: I would do something like that09:53
Laneythen at the end you look at the debdiff to see if it is just the things we need to keep from the old package09:53
Laney(the version change and the patches?)09:54
caribourbasak: do you think that I got the proper rights to upload to lpusdp: Y09:54
Laneythe epoch thing messes up merge-changelog - that's annoying09:54
LaneyMaybe don't merge-changelog then09:54
rbasakcaribou: you should do I think.09:54
caribourbasak: I'll try09:54
rbasakcaribou: you're a member of ~ubuntu-server-dev by virtue of being a core dev.09:55
rbasakcpaelzer: 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
rbasakcpaelzer: I don't think we need to bother until we have some tooling though.10:00
rbasakcpaelzer: perhaps we should have something to wrap update-maintainer and also both sets of Vcs-* changes and put that into ubuntu-git-tools?10:01
cpaelzerrbasak: I can surely add our VCS field10:06
cpaelzerdo you want me to do that and resubmit, or just for the next upload?10:07
rbasakcpaelzer: next upload is fine.10:08
rbasakNot worth redoing10:08
rbasakcpaelzer: I'm also fine with delaying until we have tooling. No need to spend extra effort until then IMHO.10:08
mardyLaney: 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
ubottubug 1546020 in telepathy-mission-control-5 (Ubuntu) "Relax apparmor confinement for KDE account files" [Undecided,New] https://launchpad.net/bugs/154602010:19
caribourbasak: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/clamav10:20
caribouworks fine !10:20
Laneymardy: You could send the patch to the Debian BTS https://www.debian.org/Bugs/Reporting10:23
seb128Laney, mardy, Debian doesn't ship that apparmor profile so it doesn't make sense to forward the patch10:26
seb128we could try to get them to include the profile though10:27
Laneyok I didn't check10:27
seb128urg sorry10:27
seb128they do10:27
seb128I looked at the wrong dir10:27
seb128bigon added it in decembre10:27
rbasakcaribou: thanks!10:29
rbasakcaribou: a couple of notes for next time10:29
rbasakcaribou: 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:30
rbasakInstead it should be an orphan commit in this case, or have a parent of the previous Debian import next time.10:31
rbasakcaribou: with that, I'm trying to keep the "debian/sid" branch pointer pointing to the latest Debian import.10:31
caribourbasak: ok, noted10:31
caribourbasak: another question about your workflow :10:46
caribourbasak: what I just pushed in the ubuntu/devel branch only has one tag; all the working tags are in my lpmep: personal branch10:47
caribouhow is the next person doing the merge going to get the working environment ?10:47
mardyLaney, seb128: so the correct thing to do is to open a bug in the debian BTS?10:56
rbasakcaribou: please see https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/logwatch as an example of what I intend.10:56
caribourbasak: k10:56
rbasakcaribou: 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:56
Laneymardy: if you want to forward something there then yes10:57
Laneymardy: could also be uploaded in ubuntu of course if necessary10:57
caribourbasak: ok, I see10:59
caribourbasak: 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:00
rbasakcaribou: you'd check out the debian/sid branch, git-dsc-commit the new Debian upload, tag it import/<version> instead of just <version> (the tooling needs a bit of tweaking here) then push the branch back with the tag.11:01
rbasakcaribou: 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
rbasakcaribou: the logical/<version> tag that is.11:02
rbasakcaribou: you'd be able to push or otherwise share the logical/<version> tag (without pushing the local logical branch) at this stage.11:02
rbasakcaribou: then you'd branch the logical/<version> tag as a local "merge" branch, and rebase --onto debian/sid.11:03
rbasakcaribou: then you have the same MP capability as current.11:03
rbasakA 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
caribouok, I'll guess it'll become clearer the next time11:03
caribourbasak: that will happen with SRU since debdiffs are used most of the time11:04
rbasakEventually LP will deprecate dput and require a git push instead. Then that'll go away :)11:05
caribouLaney: thanks for the backport !11:06
=== _salem is now known as salem_
flexiondotorgLaney, could you cast an eye over this diff please? - http://paste.ubuntu.com/15090421/11:37
flexiondotorgLaney, I haven't used merge-changelog in this diff.11:38
flexiondotorgIf is looks good to you, is I bug with this debdiff attached the correct way to proceed?11:38
Laneyflexiondotorg: Fix the versions in the .symbols file to have the epoch11:39
LaneySay which changes you kept in the changelog (Merge with Debian. Remaining Ubuntu changes - a - b - c)11:39
Laneyand please give the diff on top of Debian too11:39
flexiondotorgI've found another version requiring epoch in debian/control too.11:43
flexiondotorgLaney, This the the merge from Debian diff - http://paste.ubuntu.com/15090488/11:51
Laneyflexiondotorg: lies11:51
Laneythat's a diff from the old ubuntu version11:51
flexiondotorgLaney, Bad explanation from me.11:55
flexiondotorgThis is the intended merge - http://paste.ubuntu.com/15090488/11:55
flexiondotorgThis is the comparison with current Debian - http://paste.ubuntu.com/15090498/11:56
Laneyflexiondotorg: cool, looks plausible right now11:57
Laneytoss them on a sponsnoring bug?11:57
flexiondotorgBoth diff in the bug?11:58
* flexiondotorg is doing it...12:01
flexiondotorgLaney, https://bugs.launchpad.net/ubuntu/+source/libwnck/+bug/154606612:07
ubottuLaunchpad bug 1546066 in libwnck (Ubuntu) "Request merge with Debian for libwnck" [Undecided,New]12:07
LaneyI am supposed to sponsor later (although I've got to leave early), will try to look12:07
flexiondotorgLaney, many thanks for your help and tutoring.12:10
flexiondotorgI really appreciate it.12:10
Laneyflexiondotorg: no worries12:25
inaddyslangasek: 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:37
inaddy(LP: #1470167) btw. i was working on SRU instead of a request for inclusion (probably the needed step now)12:38
ubottuLaunchpad bug 1470167 in mstflint (Ubuntu Wily) "mstflint doesn't support Mellanox ConnectX-4 HCAs" [Low,In progress] https://launchpad.net/bugs/147016712:38
inaddyhum. slangasek is away, if anyone else can help ^12:39
inaddycaribou: ^12:39
rbasakinaddy: 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
rbasak(and detail the exception in the bug)12:45
inaddyrbasak: cool. will do. tks12:46
rbasakkickinz1: 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:05
kickinz1rbasak, sorry.13:06
kickinz1rbasak, You want me to redo the MP?13:06
rbasakNo, it's fine.13:07
rbasakkickinz1: also, I expect you to have a tag called logical/1_2.10.1-1ubuntu113:08
rbasakkickinz1: is this what you called logical/ubuntu-2.10.1-1?13:09
kickinz1rbasak, yes.13:09
coreycbbdmurray, I commented on bug 131872113:23
ubottubug 1318721 in neutron (Ubuntu Trusty) "RPC timeout in all neutron agents" [High,Fix committed] https://launchpad.net/bugs/131872113:23
mdeslaur@pilot in13:29
=== 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
pittididrocks: ~, sweet ~!13:39
* didrocks hugs pitti13:39
* pitti hugs didrocks back13:39
Odd_Blokexnox: 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:11
xnoxOdd_Bloke, it's weird as nothing should depend on python3.4 anymore.14:32
xnoxOdd_Bloke, yet it clearly is.14:33
xnoxOdd_Bloke, let me analyze the scope here.14:33
jdstrandpitti: re apparmor merge-- sure, we'll figure it out. not sure if I personally will do it, but we can get someone on it14:33
xnoxOdd_Bloke, we have a few http://paste.ubuntu.com/15091848/14:41
xnoxdoko, pre-mature removal of python3.4 ^14:41
xnoxactually less.14:50
xnoxdoko, Odd_Bloke: uploaded 7 packages, which should resolve python3.4, or lack of, for good.14:51
Odd_Blokexnox: Thanks. :)14:52
caribouDoes someone have a few spare cycles to review the mstflint -> mstflint4 package creation for me ? Rather simple leaf package14:55
rharperrbasak: 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
dokoxnox, ta, reverse-depends didn't show any ...14:56
xnoxdoko, yeah, weird. Usually things like that are picked up by the transition tracker, but that too has false positives/negatives.14:56
xnoxdoko, 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
dokothe only one I saw was sigil, but a recommends only14:57
xnoxat first i have suspected an arch-skew (given that s390x was a bootstrapped one)14:57
rbasakrharper: 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
rharperrbasak: ok; I don't think anything is blocking; they've all been easy fixes or updates.15:00
rbasakrharper: OK that's fine - just add extra commits and extra top level bullet points in d/changelog for each change.15:04
ginggsdoko, xnox: one i happened to see on that list is mine, python-ase, FTBFS with new numpy15:05
rbasak(d/changelog probably via git-reconstruct-changelog)15:05
xnoxginggs, oh.15:05
xnoxginggs, well.15:05
* rbasak wonders if that should be renamed to git-construct-changelog as it's not really redoing anything15:05
xnoxginggs, if it's uninstallable and FTBFS we will need to demote it to -proposed, such that it is not uninstallable in release.15:06
ginggsxnox: remove it if you must, i'll upload it when it is fixed (waiting for response from upstream)15:06
xnoxuntil fixesd.15:06
ginggsxnox: ack15:06
xnoxginggs, demote to proposed is the new "remove from release"15:06
xnoxdoko, do you have powers to demote-to-proposed python-ase?15:07
xnoxthere is a script to do that in archive-tools repository i think.15:07
rharperrbasak: thanks15:08
mdeslaur@pilot out15:17
=== 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:
dokoxnox, gpaw still depends on it15:20
xnoxdoko, it's python2 only?15:24
dokoxnox, both demoted15:24
xnoxdoko, 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.gz15:26
xnoxit build-depends on python3 but i don't see it building python3 anything.15:27
damascenehi, this packagefonts-hosny-amiri have been updated but I find the old version in 16.04 https://github.com/khaledhosny/amiri-font/releases15:29
damascenefonts-hosny-amiri how to get it in 16.04 before feature freeze?15:29
rharperquestion 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:30
ginggsrharper: just change the bug title15:32
rharperginggs: ok15:32
ginggsrharper: and edit the bug description to include the justification15:34
rharpergotcha; no need for a new bug, update title and include the justification .  Thanks!15:34
seb128pitti, 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 together15:58
Laneyvila: flexiondotorg: I didn't make it to sponsoring today, sorry - will start with that tomorrow so I don't get on to anything else16:04
* Laney waves16:04
vilaLaney: looks like mdeslaur did ! Thanks to both !16:06
smoserpitti, around ?16:07
pittiseb128: 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
pittismoser: Im' back16:18
smoserpitti, so the open-iscsi... you thought our delta had all been taken into debian ?16:19
seb128pitti, thanks16:19
pittismoser: yes, except the autopkgtest16:19
smosersuch that we should re-sync with much smaller delta16:19
smoserbut sync woudl still be necessary, right ? for the auto pkg test16:20
smoserannoying that we have to carry package delta for that, but seemingly fairly easiliy synced if that is in fact it16:20
pittismoser: right, "re-merge"16:21
smoserok. i will look to see if i can't get that merged.16:21
Odd_BlokeAre there any plans to replace bzr packaging branches (i.e. UDD) with git equivalents?16:22
cjwatsonOdd_Bloke: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html   but not much in the way of updates since then unfortunately16:23
pittiOdd_Bloke: note that it's fairly easy to create your own (or better yet, branch from Debian's) for packages you work on often16:24
pittiOdd_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 one16:25
Odd_Blokecjwatson: 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
pittiit's most convenient to have an ubuntu git branch in the Debian git repo, or at least mirror it in LP16:25
cjwatsonOdd_Bloke: I really hope to manage it this year but realistically can't promise anything definite16:25
pittibut if not, "gbp import-dsc foo.dsc" et voilà :)16:26
rbasakOdd_Bloke: the server team is doing it now. We'll have an interim importer for packages we follow soon.16:26
rbasak(not using gbp import-dsc as not doing an upstream/debian split)16:26
Odd_Blokecjwatson: 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:26
rbasakOdd_Bloke: once we have the importer, perhaps we can track your packages for you too.16:27
pittiOdd_Bloke: so the thing you want to work on has no VCS in debian?16:27
Odd_Blokepitti: The thing we want is livecd-rootfs. :)16:27
pittiasrcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk16:27
pittieek, s/ssrc/V/16:28
pittiOdd_Bloke: perhaps it's  time to convert that to git and use that from now on?16:28
Odd_BlokeWe have been using that.16:28
pittithen you have all the history, and not just the coarse-grained one from auto-imports16:29
Odd_BlokeBut 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
pittiI don't want to diminish cjwatson's work, but I've never found such synthetic VCSes particularly useful16:29
Odd_Bloke(b) once xenial is released, we will want to track xenial's livecd-rootfs for xenial.16:29
pittiOdd_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 well16:30
Odd_Bloke(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
pitti(in both bzr and git)16:30
cjwatsonpitti: dgit actually looks like it could be a much better compromise there than UDD ever was16:30
Odd_Blokepitti: But /xenial branches weren't created a la cjwatson's email above (right?).16:31
cjwatsonpitti: because it's easier to stitch in history from different places, and we don't have the file-id problem16:31
pittiOdd_Bloke: the above Vcs-Bzr: is a manually maintained "real" branch, it's got nothing to do with UDD or the above Launchpad work16:31
cjwatsonI tend to agree we should just convert livecd-rootfs to git and be done16:31
pitticjwatson: yeah, true16:31
pittiI guess it'd be polite to ask ogra_ if he's okay with git migration16:31
pittias he's working on it a lot, and it's also his birthday :)16:32
pitti(so don't make him grumpy today)16:32
ogra_eek, git ?!?16:32
Odd_Blokepitti: Ack, but if I s/trunk/wily/ that URL, there isn't anything there.16:32
pittibut it's hard to avoid git these days :)16:32
rbasakpitti: synthetic VCS is better than no VCS, which is the situation with many Ubuntu-deltified packages right now.16:32
ogra_pitti, up to now i managed to :)16:32
pittiOdd_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 version16:32
pittiogra_: wow, congrats16:32
rbasakThat'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:32
Odd_BlokeYeah, this ^16:33
pittirbasak: right, but branching off Debian's VCS is still better IMHO :)16:33
pittiright for the "catch up with dput"16:33
rbasakpitti: unfortunately that's really tricky to do reliably, _and_ have a single workflow across all the packages we look after.16:33
ogra_pitti, i dont really want to be the blocker though ...16:33
pittiwell, I just wanted to mention gbp import-dsc, which might speed things up until this lands in LP16:34
cjwatsonrbasak: you could probably use bits of dgit as the importer16:34
pittior that ^16:34
rbasakHow 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
rbasaknacc: ^16:34
cjwatsonsince its raison d'être is doing repeatable imports16:34
pittiogra_: I'm truly amazed that you managed to stay away from git until now :)16:34
rbasakCurrently 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
cjwatsonrbasak: the point of dgit for that is that it doesn't matter, it'll construct an appropriate commit on the fly16:35
ogra_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
cjwatsonin a deterministic way so that if different people do it they get the same answer16:35
rbasakThat sounds neat.16:35
naccdgit does look handy16:36
smoserTrevinho, just curious... bug 1521302 is terribly annoying to me.  do you think this is something fixed sometime soon ?16:37
ubottubug 1521302 in unity (Ubuntu) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed] https://launchpad.net/bugs/152130216:37
Trevinhosmoser: yes, but it's something we can delay for now...16:37
Trevinhowillcooke: can you please add that to our list ^16:38
smoseris there some work around ?16:38
Trevinhosmoser: not that I know, maybe you can force with soemthing like wnckprop or other scripts, but... Nothing inside compiz AFAIK16:39
willcookehrm, odd.  Doesn't do it it 14.04, does in 16.0416:41
willcookeI'll add it to the backlog now16:41
Odd_Blokerbasak: What time frame are you looking at for your importer work?16:45
rbasaknacc: ^16:46
naccOdd_Bloke: i'll hopefully get it done/working next week16:46
Odd_BlokeOK, nice.16:47
pittistgraber, kees, infinity, mdeslaur: TB meeting now? (or not?)17:00
mdeslaurpitti: thanks17:01
stgrabercyphermox: hey, how am I supposed to talk to for NM nowadays?17:01
stgraberjust installed a clean Xenial box and opened the connection editor, I see lxcbr0 in there...17:02
stgraberI thought we made it so that NM would stop messing with this...17:02
stgraberdoesn'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
stgraber(did I mention I hate Network Manager)17:03
cyphermoxI suppose it's still me17:03
cyphermoxstgraber: NM will always show the devices in nmcli17:05
cyphermoxor in the connection editor device list for that matter17:05
cyphermoxthat doesn't mean nm-applet will show anything17:05
smoserinfinity, around ?17:07
smoserwe'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
smoserthat seem to match up time-wise with at least your debian-installer upload https://lists.ubuntu.com/archives/trusty-changes/2016-February/021231.html17:07
smoserthe 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
stgrabercyphermox: 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:08
infinitysmoser: What log am I looking at?17:09
cyphermoxsure there is17:09
stgrabercyphermox: last I checked there was something close to it, but any key set in there would fully overwrite the previous value17:09
cyphermoxstgraber: /etc/NetworkManager/conf.d17:09
stgrabercyphermox: 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 it17:09
stgraberright, that's the broken thing I looked at last time17:09
smoserthat test above (platform-qa-jenkins) . tries to seed installation of linux-virtual metapackage via:17:09
cyphermoxI don't think you can have NM never show the devices17:10
smoser d-i base-installer/kernel/override-image string linux-virtual17:10
cyphermoxit'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-applet17:10
smoserand then basically verifiesd that it got installed. it did not when that test ran with media17:10
smoser Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212)17:10
smosererr.. ^ it passed17:10
cyphermoxstgraber: but it should still show devices, just like ifconfig should.17:10
smoserfailed with: Ubuntu-Server 14.04.4 LTS Trusty Tahr - Beta amd64 (20160212)17:10
cyphermoxstgraber: ie. if someone goes out of their way to do something stupid, too bad.17:11
stgrabercyphermox: I seem to remember I tried using keyfile with unmanaged-devices and it kinda worked except that it couldn't be appended to, just overriden17:11
cyphermoxit's already unmanaged17:11
cyphermoxwe patched that in17:12
stgraberok, kinda weird that unmanaged means that NM still lets you manage it though :)17:12
cyphermoxstgraber: unmanaged means NM won't touch it automatically17:12
stgraberanyway, 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 it17:13
cyphermoxstgraber: you can still poke things if you really wanted to17:13
stgrabermost of them get fixed by asking the user to "grep -r lxcbr0 /etc/NetworkManager" and remove any file that turns up17:13
infinitysmoser: Okay, but I'm not seeing a log that tells me what happened.17:13
cyphermoxI 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 do17:13
smoserinfinity, well, yeah, they're burried in the artifcats17:14
cyphermoxstgraber: that sounds a lot like someone going in to edit random things without knowing what they're for17:14
stgraberthere'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:14
stgrabercyphermox: my best guess so far si: connection editor -> edit lxcbr0 -> don't change anything -> save17:15
cyphermoxstgraber: 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 files17:15
stgraberwhich isn't obviously wrong, they didn't change anything, they just went to look at it clicked save instead of close17:15
cyphermoxI would suggest filing bugs upstream for some of these17:16
infinitysmoser: 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:17
stgraberyeah, 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
smoserinfinity, well, we pre-seed installation of linux-virtual with:17:18
cyphermoxstgraber: well, that won't work17:18
smoserinfinity, well, we pre-seed installation of linux-virtual with:17:18
smoser d-i base-installer/kernel/override-image string linux-virtual17:18
stgrabercyphermox: 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* version17:18
cyphermoxstgraber: connections are separate from devices17:18
stgrabercyphermox: how was it done in the applet then?17:19
smoserthat used to result in installation of linux-virtual and then durint a stable release, that behavior changed.17:19
cyphermoxstgraber: per-device, not connections17:19
cyphermoxstgraber: I suppose what could be done is to explicitly hide connections that start in /lxc.*/17:19
smoseri'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
xnoxcyphermox, couldn't udev rules, or some such set variables on the NIC to hint to network manager "don't touch this"?17:20
cyphermoxbut even that is bound to fail at some point, people might actually want to create a connection named "lxc" for some other reason17:20
cyphermoxxnox: devices are already being unmanaged, that is already fine.17:20
cyphermoxxnox: I think there is a udev rule, but this isn't the problem17:20
xnoxcyphermox, that way, e.g. autocreated/managed things can do "NETWORK_MANAGER_HIDE_ME_HARDER=1" =)17:20
cyphermoxstgraber: I suppose we could probably already update the VPN plugins17:21
smoseri 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
cyphermoxstgraber: as for NM 1.1, it's always a huge thing to update... I'll look a bit see if that could go with a FFE17:22
cyphermoxmorphis: did you look at updating NM yet?17:22
stgrabercyphermox: I did try building the 1.1 openvpn plugin last night against current xenial and it wasn't very happy with our NM version. May be doable with more work though.17:25
cyphermoxthere isn't a 1.117:26
stgraberDebian has NM 1.1.90-6 and nm-openvpn 1.1.90-317:27
stgraberI tried building the latter against Ubuntu's NM 1.0.417:27
cyphermoxok that might be 1.2-beta1 I suppose17:28
stgraberoh, why didn't they call it that? kinda confusing when looking at the version number :)17:32
cyphermoxthat was upstream's doing17:32
cyphermoxI think the minimum version is wrong, this should already build17:32
* cyphermox tries updating n-m-openvpn17:33
=== kickinz1 is now known as kickinz1|afk
Odd_Blokenacc: rbasak: Would your importer give us a trusty tag/branch that would point at what's released in trusty?  (Or s/trusty/trusty-updates/g maybe)17:37
naccOdd_Bloke: initially it's only targetted at merges, but it'd be relatively easy to do that, i think17:37
Odd_Blokenacc: OK, cool.17:38
cyphermoxstgraber: ok, yeah, we'll need to update just about everything for it to work17:43
infinitysmoser: The difference between the working one and the failing one is that the failing one doesn't have archive.ubuntu.com available.17:43
smoserwhere'd you see that infinity  ?17:44
xnoxdoko, python3.4 rebuilds appear to have all migrated and/or you demoted borked things, so release is looking good now.17:44
infinitysmoser: Search both syslogs for configure_apt and see the update there hits archive *and* the CD on the working one, and only the CD on the failing one.17:45
infinityNow to sort out why that might be...17:45
smoserhm.. so possibly related, i started seeing very bad network performance on a system we use for qa tests.17:49
smoserwhere download of a 18M kernel package would take > 180 seconds17:49
infinitysmoser: Probably doesn't relate, but I can't see why this would break either.  We didn't change any of these bits.17:49
* infinity runs a test here.17:49
smoserinfinity, thanks. i'll leave you to poke at it17:50
rbasakOdd_Bloke: yeah, our scheme will allow us to do that when the importer can support it. Not an initial goal, but I don't imagine it'll be particularly hard to get the importer to do that too when it's ready, since it'd use mostly the same code and logic.17:54
Odd_Blokerbasak: Ack.  Thanks for all the info!  (You too, nacc :)17:55
EmanuelThere are only 2 days left https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule until https://wiki.ubuntu.com/FeatureFreeze18:15
EmanuelAnd no one step up to solve the lz4 situation.18:16
Emanuelbug 153192318:17
ubottubug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/153192318:17
rbasakEmanuel: MIRs aren't dependent on FF. A new apt release might be though.18:22
xnoxtedg, you did read the docs prior to like hacking your own unique solution right?18:23
xnoxtedg, looks like https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols documents how to do dual-landing symbols et.al.18:23
tedgxnox: Eh, I just went with shlibs for everything. After I found the Debian docs for C++ and symbols that basically said "give up and use shlibs"18:27
Emanuelrbasak: lz4 is in debian, how hard cant it be to import ?18:27
juliankEmanuel: It's waiting for sarnold's security review18:28
tedgAfter the abigail stuff is done for scopes-api I'll probably steal that as a in tree test.18:29
juliankIt's not only APT that is affected, squashfs-tools has not been updated since October18:29
rbasakEmanuel: it is imported. It's just not in main.18:31
dasjoecking: cmiller tries to fix grub not finding a zpool's devices by adding some script to search for pools. I proposed to parse zdb's output, this may be of interest to you: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727/comments/1518:31
ubottuLaunchpad bug 1527727 in grub2 (Ubuntu) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,In progress]18:31
juliankIt's hilarious that the inclusion of lz4 takes such a long time, given the modified copy/copies swirling around in main already (at least one in Linux)18:34
dasjoe(zfs comes with lz4, too)18:35
juliankmvo: It's feature freeze and the lz4 MIR request is still not through, meaning APT 1.2 continues to wait in proposed :(18:36
juliank1.2.3 now detects I/O errors in rred18:37
mvojuliank: nice!18:37
mvojuliank: I'm at a sprint right now, but I will poke some people about the lz4 MIR request18:38
=== enrico_ is now known as enrico
ubottu** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)19:37
ubottu** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)19:38
sladenCVEs are going to need 5 digits shortly19:39
sarnoldin fact mitre plans on issuing a CVE with five digits potentially before it's needed just to ensure that tooling has adapted19:40
Emanueljust read it19:40
sladenhttps://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html  was what I read earlier in the day19:41
ubottu** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)19:41
sladensarnold: I think we can start with ubottu...19:42
kirklandokay, I'm at a loss...  can someone help me identify why this keeps failing to build?  https://launchpadlibrarian.net/239090418/buildlog_ubuntu-xenial-amd64.ssh-import-id_5.2-0ubuntu1_BUILDING.txt.gz19:44
nacckirkland: "file ssh_import_id.py (for module ssh_import_id) not found" ?19:46
nacckirkland: just a guess19:46
kirklandnacc: hmm19:46
sarnold__version__ = pkg_resources.get_distribution('ssh_import_id').version   -- you've got an odd one on your hands, that's for sure :)19:47
kirklandsarnold: is there a better way to print the current version a python package, from within the code of the package itself?19:49
sarnoldkirkland: no idea :/19:50
=== dax is now known as rww
=== rww is now known as dax
=== DevBox|2 is now known as DevBox
naccinfinity: would you ahve time after (my) lunch to go over the php7 stuff?20:17
barrykirkland: there are several approaches that won't require pkg_resources, but it depends on whether you want to do an import to get the version number or not.  for a lot of simple packages, they put the __version__ in a separate module (or mypkg/__init__.py) and you can just import it from there.  another popular non-import alternative is to put the version number in a .txt file and parse it out of there.  i have a common helper for20:22
barrythat, but it's also fairly easy to write.  to avoid putting a version number in multiple places, you'd use the same parse-or-import scheme in your setup.py and in whatever prints --version20:22
kirklandbarry: I think I might have found it...20:24
barrykirkland: cool20:24
kirklandbarry: maybe :-)  new build sent20:24
kirklandbarry: what's odd is it builds fine here, on my xenial desktop, in a clean sandbox20:24
kirklandbarry: but not on LP20:24
barrykirkland: in an sbuild?20:25
kirklandbarry: no, a pristine lxd container :-)20:25
kirklandbarry: the new sbuild :-)20:25
barrykirkland: neat!  unfortunately lp is still the old sbuild :)20:25
kirklandbarry: :-D20:26
=== salem_ is now known as _salem
infinitynacc: Possibly, I'm in the middle of a sprint right now, so it depends on if I can get away.21:31
smoserpitti, if your'e still around. would you do the merge of open-iscsi?21:43
smoseri'm quite loaded before thursday and would like to see that land before FF rather htan after.21:44
naccinfinity: ok, so maybe it's best for you to ping me if/when you're free22:41
* tsimonq2 still can't figure out what sprint infinity is at :)23:19
naccjamespage: how do correclty update, e.g., eclipse's dependencyManifests directory? to point at the tomcat8 versions of the jars, etc.23:34
nacchow do *I*, rather :)23:34
=== neunon_ is now known as neunon
=== mapreri_ is now known as mapreri
=== psivaa_ is now known as psivaa
=== tedg_ is now known as tedg
=== alecu_ is now known as alecu
=== dkessel_ is now known as dkessel
=== Trevinho_ is now known as Trevinho
=== tgm4883_ is now known as tgm4883
=== elijah__ is now known as elijah
=== pitti is now known as Guest82926
=== stgraber_ is now known as stgraber
=== ximion1 is now known as ximion

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!