=== tinoco is now known as Guest95688
=== ubott2 is now known as ubottu
=== bdrung_ is now known as bdrung
=== DrKranz is now known as DktrKranz
=== sgclark_sleeping is now known as sgclark
=== FourDollars_ is now known as FourDollars
=== andyrock_ is now known as andyrock
=== _fortis_ is now known as _fortis
=== DalekSec_ is now known as DalekSec
=== fabo_ is now known as fabo
[07:03] <Mirv> mitya57: it's already March 1st now. I fear it will simply be too late to rush into Ubuntu LTS, but let's see when it's really out and how does it work.
[07:04] <Mirv> but having an upstream .0 release somewhere after FF is not a very good starting point
[07:06] <Mirv> mitya57: so the current real plan is to backport enough patches to 5.5.1 in order to be happy with it
[07:42] <dholbach> good morning
[07:48] <pitti> Good morning
=== ikonia_ is now known as ikonia
[08:19] <ioanm> can I sync this? https://bugs.launchpad.net/ubuntu/+source/cmd2/+bug/1539921
[08:19] <ubottu> Launchpad bug 1539921 in cmd2 (Ubuntu) "Sync cmd2 0.6.8-1 (main) from Debian unstable (main)" [Wishlist,New]
[08:20] <ioanm> i mean package it for ubuntu?
[08:25] <tvoss> xnox, are you around?
[08:26] <tvoss> xnox, I'm looking into boost::coroutine and wondering, why we don't build .so's for it
=== ochosi_ is now known as ochosi
[08:51] <wgrant> doko: Is there meant to no longer be Python 2 support in xenial's vim?
[08:54] <Laney> He disabled it on purpose, so meant to in that sense...
=== davmor2_ is now known as davmor2
=== Zic_ is now known as Zic
[09:22] <doko> wgrant, Laney: my understanding is that having both just won't work. but I may be wrong
[09:22] <doko> reason was to get python2 off the cloud images
[09:23] <Laney> right, you can't have both in the same process I guess
[09:28] <wgrant> I guess it's time to port all my stuff then :(
[09:34] <ginggs> tvoss: see debian bug #802509, that should be fixed in 1.58.0+dfsg-5 currently in NEW
[09:34] <ubottu> Debian bug 802509 in libboost-coroutine-dev "libboost-coroutine-dev: The boost-coroutine library is only compiled as a static library" [Wishlist,Open] http://bugs.debian.org/802509
=== cpaelzer is now known as cpaelzer_afk
[09:57] <Unit193> pitti: Finally filed it, got some time to figure out where it's happening: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1540282 (Which is different than https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1536965, that one might just be lightdm weirdness there.)
[09:57] <ubottu> Launchpad bug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Undecided,New]
[09:57] <ubottu> Launchpad bug 1536965 in dbus (Ubuntu) "System can freeze on restarting dbus" [Undecided,New]
[09:58] <Unit193> So to be clear, the one I reported is directly the Ubuntu delta in dbus.
=== marcusto_ is now known as marcustomlinson
[10:20] <pitti> Unit193: err yes, restarting dbus has never been a supported operation
=== ogra_` is now known as ogra_
=== cpaelzer_afk is now known as cpaelzer
=== ttx_ is now known as ttx
[10:31] <mitya57> Mirv, ok… I was hoping that we can get rid of appmenu-qt5 this cycle, but that requires quite a lot of backporting (some needed patches will be in 5.6.1 and some in 5.8)
[10:34] <mitya57> The main motivations for dropping appmenu-qt5 are its usage of internal QMenu methods (instead of QPlatformMenu public APIs) and bugs like #1378935
[10:37] <doko> pitti, please could you override the ruby-redcarpet autopkg tests? I think we don't care, and they failed in the past as well
[10:44] <Unit193> pitti: Yes, we went over this.  It's not supported, but it shouldn't require you to hard reboot to fix it.  No 'service' or 'systemctl' commands work, when with the same system only in Debian (or, using Debian's dbus), they do.
[10:45] <pitti> doko: yup, done
[10:45] <pitti> Unit193: so I suppose we should just disallow restarting?
[10:45] <pitti> I think we used to in the past, but this might have gotten lost in the move to systemd
[10:46] <Unit193> pitti: Nah, it's part of the Ubuntu delta, looks like something is just off.  I didn't disable patch by patch and recompile though.
[10:46] <pitti> doko: I'll wave through ruby2.2, seems good enough to me; objections?
[10:47] <Mirv> sil2100: ^ see above for appmenu-qt5 notes which you might be interested in
[10:50] <doko> pitti, no, and then we should be ready to remove ruby2.1
[10:53] <sil2100> Mirv, mitya57: I saw Dmitry's proposals on qt/qtbase, didn't have time to look at them but I'm aware of the whole initiative and am +1 in overall :)
[10:54] <dholbach> @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: dholbach
[11:06] <smoser`> pitti, you had a merge of open-iscsi ?
[11:06] <smoser`> right?
=== smoser` is now known as smoser
[11:07] <pitti> smoser: I don't because of debian bug 797112
[11:07] <ubottu> Debian bug 797112 in open-iscsi "open-iscsi: Prevent testing migration" [Serious,Open] http://bugs.debian.org/797112
[11:07] <pitti> smoser: but I did go through the delta and submitted some bits to Debian (and it was applied too)
[11:07] <pitti> smoser: AFAIR our only remaining delta is the addition of that integration autopkgtest now
[11:08] <smoser> ok.. so what to be done ? are you planning on getting through ?
[11:10] <pitti> smoser: if the  Debian maintainer says the current version isn't good for releasing, I'm cautious
[11:11] <pitti> smoser: I don't know the first thing about open-iscsi, so I wouldn't want to push it from my side
[11:11] <smoser> :)
[11:11] <pitti> if someone knowledgeable says that this works for Ubuntu, I'm happy to do the merge
[11:11] <smoser> yeah, i agre on that. i'd be hesitent on the upgrade things too.
[11:12] <pitti> but for now I'm content with knowing that the actual merging will be trivial now as our  delta got sorted out, apart from dropping this testlib.py thingy
=== directhex_ is now known as directhex
[11:12] <Unit193> pitti: You do have http://paste.openstack.org/show/9HuJPkUvl8NhOgMsYMRq to prevent restarts, but it actually only prevents stopping so when you 'restart' it launches another instance causing issues.  I don't know what else seemed to cause irrecoverable problems, though.
=== lifeless_ is now known as lifeless
[11:17] <smoser> pitti, thanks.
[11:18] <smoser> ideally we would have a autopkg test that pushes it through iscsi root. thats the biggest thign that has always been tricky for us.
[11:21] <LocutusOfBorg> hi folks, a while ago dholbach syncd for me fonts-android in main. the new release dropped fonts-droid, because it isn't unsupported anymore upstream
[11:22] <LocutusOfBorg> the replacement is fonts-noto (actually in universe, so it might require a MIR)
[11:22] <LocutusOfBorg> or a fonts-droid-fallback package
[11:22] <LocutusOfBorg> what is your opinion? I even fail to completely understand which package needs a fix for this fonts-android to migrate
[11:23] <ogra_> "it isn't unsupported anymore"
[11:23]  * ogra_ grins
[11:23] <LocutusOfBorg> "
[11:23] <LocutusOfBorg> Since Android upstream stopped shipping Droid fonts and its been
[11:23] <LocutusOfBorg> declared that Noto fonts will be superseding the Droid¹² we in
[11:23] <LocutusOfBorg> "Debian Fonts Task Force" team decided to drop fonts-droid package."
[11:23] <LocutusOfBorg> ² http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20151031/011f4334/attachment.mht
[11:24] <LocutusOfBorg> ¹ https://github.com/googlei18n/noto-fonts/issues/555
[11:26] <LocutusOfBorg> as example you can see the debian bug: #804678
[11:26] <ubottu> Debian bug 804678 in blender "blender: Please switch from fonts-droid to fonts-noto" [Serious,Fixed] http://bugs.debian.org/804678
[11:28] <ginggs> LocutusOfBorg: reverse-depends -r xenial fonts-droid
[11:35] <LocutusOfBorg> ok, so now I have to get in touch with the maintainers and ask them about their favourite font solution
[11:35] <LocutusOfBorg> thanks ginggs
=== damascene is now known as ahmed7
=== ahmed7 is now known as damascene
=== cpaelzer is now known as cpaelzer_afk
=== lool- is now known as lool
[11:53] <cjwatson> wgrant: I had to spend a bit of time beating pyflakes.vim into submission (fortunately not too long; if you're using that, let me know).
[11:54] <cjwatson> neovim can have both Python 2 and 3 at once because it has out-of-process plugins, but that's a bit too raw for the moment.
=== kyrofa_ is now known as kyrofa
=== cpaelzer_afk is now known as cpaelzer
=== ssweeny` is now known as ssweeny
[13:48] <dgadomski> pitti: hey, can I somehow check what is holding the ifupdown release after verification? (bug 1337873)
[13:48] <ubottu> bug 1337873 in ifupdown (Debian) "ifupdown initialization problems caused by race condition" [Unknown,New] https://launchpad.net/bugs/1337873
[13:49] <dgadomski> pitti: are there any regressions reported?
[14:00] <xnox> tvoss, i will check that.
[14:10] <cyphermox> good morning!
[14:14] <pitti> dgadomski: no, I didn't hear about any other regressions
[14:15] <dgadomski> pitti: is the promotion to -updates after verification automatic or manually triggered?
[14:15] <pitti> dgadomski: it's manual; I do it now
[14:15] <dgadomski> pitti: I would appreciate it, thanks!
[14:16] <teward> any of the apport hooks pros around?
[14:17] <seb128> teward, you better just ask your question, maybe some "non-pros" would be able to answer
[14:17] <seb128> or are you interested by having a response only if it comes from a pro? ;-)
[14:18] <teward> seb128: debugging why an apport generic hook in Ubuntu failed for a given bug
[14:18] <teward> i.e. hook errors in the global "ubuntu.py" apport hook
[14:18] <seb128> well, just describe your issue
[14:18] <teward> though i'm not aware of why it *would* have failed
[14:19] <teward> well... in triaging a bug in nginx, neither my nginx package hooks were triggered, and there is an error on the global hooks - https://launchpadlibrarian.net/235605675/HookError_ubuntu.txt
[14:19] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1539316 is the nginx bug, but the issue is that that's the first time i'm seeing hook errors, wasn't sure if there was an issue reported anywhere
[14:19] <ubottu> Launchpad bug 1539316 in nginx (Ubuntu) "package nginx-core (not installed) failed to install/upgrade: il sottoprocesso installato script di post-installation ha restituito lo stato di errore 1" [Undecided,Incomplete]
[14:19] <seb128> teward, looks like python encoding handling issues
[14:19] <teward> hmm
[14:19]  * teward checks the status on his QA Testing VM
[14:20] <teward> oh good that's usable, i think i'll try and replicate this...
[14:20] <teward> maybe there's a bug somewhere
[14:21] <pitti> teward: yes, looks like the "line" there is already a byte array, that can't be encoded again (only strings can)
[14:22] <pitti> I guess it's stumbling over some non-UTF-8 stuff in some log
[14:22] <teward> pitti: then that'd be a bug in the global hooks?
[14:22] <teward> ah
=== wendar_ is now known as wendar
[14:22] <pitti> yes
[14:22] <teward> pitti: has this been reported previously as a bug against apport, or would you like me to file one now?
[14:22] <pitti> cjwatson, infinity_: hm, what did I do wrong in https://launchpad.net/ubuntu/+source/grub2-signed/1.61ubuntu1 ? seems the binary packages get an ubuntu1 twice in the version
[14:22] <pitti> teward: I don't know by heart, but that should be simple enough to search for
[14:23] <teward> ok
[14:25] <pitti> cjwatson, infinity_: hmm, 1.61ubuntu1+2.02~beta2-35ubuntu1 << 1.61+2.02~beta2-35 (that's not very intuitive, but dpkg --compare-version agrees), so I figure I'd somehow need to construct a different version of grub2-signed?
[14:26] <seb128> pitti, seems like that package is not made to have non native versioning?
[14:26] <seb128> just do 1.62?
[14:26] <pitti> grub2 was in sync, I uploaded an ubuntu change and forwarded to Debian, but it didn't get applied yet
[14:27] <pitti> seb128: ah yes, I guess so
[14:27] <pitti> indeed, this is an Ubuntu-only package with Debian version numbers, argh
[14:47] <cjwatson> pitti: yeah, just use 1.62, but it doesn't really matter
=== cpaelzer is now known as cpaelzer_afk
[14:48] <cjwatson> pitti: ah yes, version ordering is a bit counterintuitive here
=== cpaelzer_afk is now known as cpaelzer
=== cpaelzer is now known as cpaelzer_afk
[14:52] <pitti> cjwatson: ack, 1.62 built/uploaded, thanks
[14:53] <pitti> cjwatson: initially I thought they were kind of "in sync", I didn't realize grub2-signed wasn't in debian
[14:56] <cjwatson> pitti: It will be eventually, but infrastructure ...
[14:57] <pitti> yep, just got confused by the version numbers, all good now
=== cpaelzer_afk is now known as cpaelzer
=== dannf` is now known as dannf
[15:21] <seb128> tyhicks, pitti, thanks for landing that schroot ecryptfs umount fix! \o/
[15:21] <pitti> right, sorry for taking so long -- this wasn't in the sponsoring queue
[15:22] <pitti> tyhicks: thanks for the fix!
[15:22] <pitti> seb128: wow, you watch uploads like a hawk :)
[15:22] <tyhicks> pitti: which one did you upload?
[15:22] <seb128> pitti, I get notify-osd bubbles for those when my mailer is open ;-)
[15:24] <pitti> tyhicks: we have 1.6 in xenial, so that patch
[15:24] <kirkland> I think seb128 raised that one a LONG time ago :-)_
[15:28] <tyhicks> seb128: can you confirm that the segfault that you hit earlier this morning was not the fault of ecryptfs?
[15:28] <seb128> tyhicks, yes, it was in libnss3.so and debsums indicates that file was corrupted and reinstalling the lib fixed it
[15:28] <seb128> I might have an issue with the kernel -5 though
[15:29] <tyhicks> odd
[15:29] <seb128> ata error and fs corruption, seems to be fine with -2
[15:29] <seb128> tyhicks, apt and sudo would segfault as well
[15:29] <tyhicks> oof
[15:29] <tyhicks> that's not a good state to be in
[15:29] <seb128> indeed
[15:30] <seb128> well they would segfault after doing their stuff so it's ok
[15:30] <seb128> like I could sudo apt-get install --reinstall libnss3
[15:30] <seb128> and get a segfault
[15:30] <seb128> but the file was valid again
[15:30] <dholbach> @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:32]  * seb128 hugs dholbach
[15:32]  * dholbach hugs seb128 back :)
[15:32] <seb128> dholbach, thanks for sponsoring xdg-utils, it was pending for a while and Chad was waiting for it
[15:32] <dholbach> anytime
[15:56] <mitya57> cjwatson, is there any progress on renaming python-click?
[15:57] <mitya57> It would be nice to get it done before FF
[16:06] <cjwatson> mitya57: https://code.launchpad.net/~cjwatson/click/rename-python-packages/+merge/280575
[16:06] <cjwatson> mvo: ^- could you have a look at that?
[16:11] <mitya57> cjwatson, are there any consumers of click module outside click source?
[16:12] <mitya57> reverse-depends tells me about debocker and mycli but those are synced from Debian so they are probably using the other click
[16:12] <mitya57> If that's true, then maybe you can make the module private and merge it into click binary package…
[16:13] <mitya57> (by private I mean install into /usr/share/clicksomething, not dist-packages)
[16:17] <mvo> cjwatson: sure
[16:36] <cjwatson> mitya57: There are a couple of out-of-archive things I'd prefer not to break.
=== sarnold_ is now known as sarnold
[16:49] <mitya57> cjwatson, ok… though if you add sys.path.insert calls to those out-of-archive things, then they'll work with both old and new versions
[16:51] <cjwatson> mitya57: sure, but I also don't want to have to spend lots of time tracking them all down :)
[16:52] <cjwatson> the above MP is a viable stopgap at least
=== infinity_ is now known as infinity
[17:14] <caribou> xnox: FYI, the server team asked me to look at the clamav merge
[17:20] <xnox> caribou, yes please
[17:34] <bladernr_> Are there any known issues trying to do-release-upgrade -d from Trusty (14.04.3) to Xenial?  I am trying and its choking on Utopic for some reason.  If I omit the -d, it seems happy to update to Vivid though.
[17:34] <bladernr_> http://pastebin.ubuntu.com/14850836/
[17:35] <bladernr_> Should I file a bug for this?
[17:42] <infinity> bladernr_: Is Prompt=lts set in /etc/update-manager/release-upgrades ?
[17:42] <bladernr_> infinity: no, I just changed it to "normal"
[17:42] <bladernr_> ^^ before trying the upgrade
[17:42] <infinity> bladernr_: Well, normal won't get you from trusty to xenial.
[17:44] <bladernr_> How would I get there?  The only docs I could find on updating from Trusty to Xenial via do-release-upgrade are lubuntu related, and they just point to a wiki page on do-release-upgrade itself :/
[17:45] <bladernr_> I can go and update to vivid, then wily, then hopefully xenial... but in theory, I should not have to jump through hoops to jump from LTS to LTS (even if that LTS is an alpha)
[17:45] <bladernr_> hrmmm... damn.
[17:45] <infinity> bladernr_: You should be able to do lts->lts if that's set to =lts, unless we haven't mangled things yet to allow that.
[17:46] <infinity> bdmurray_: Are lts->lts development upgrades set up yet?
[17:46] <bladernr_> infinity: that sound you hear is my beating my head against my keyboard because I completely overlooked the obvious.
[17:47] <bladernr_> sigh... setting it BACK to lts works... I am not sure why I changed it to begin with, but at the time I assure you it made sense to me
[17:47] <infinity> Heh.
[17:47] <infinity> bdmurray_: Unping. :P
[17:47] <bladernr_> I blame Monday
[17:48] <infinity> Monday is a bane to us all.
[17:48] <sarnold> hearhear
=== bdmurray_ is now known as bdmurray
[17:50] <infinity> sarnold: Oh hai.  How do you feel about swapping in state on LP: #1417608 ?
[17:50] <ubottu> Launchpad bug 1417608 in servicelog (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,Confirmed] https://launchpad.net/bugs/1417608
[17:51] <sarnold> infinity: oy ppc64-diag.. there's a blast from the past..
[17:52] <sarnold> wow I forgot how many annoyances I found..
[17:54] <infinity> sarnold: Maybe you're just easily annoyed?
[17:56] <sarnold> infinity: too right you are
=== 64MAAS7IF is now known as ben___
[20:41] <pitti> xnox: ah, I had another systemd fix queued up (and lots of fixes in Debian), but oh well
[20:41]  * pitti commits your change
[21:07] <bladernr_> ok, so the upgrade from Trusty to Xenial failed spectacularly.  It looks to me that it all centers around fontconfig.  that fails to update, and from there is a cascade of 168 other packages that won't install.
[21:07] <bladernr_> http://paste.ubuntu.com/14852379/
[21:08] <bladernr_> ^^ aptlog from the machine.  I can access it directly, so it's running, but just barely.
[21:12] <bladernr_> and this seems to be (according to the error when trying to install fontconfig alone) the issue causing all the grief: http://pastebin.ubuntu.com/14852409/
[21:49] <bladernr_> fwiw, I filed this bug https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1540591
[21:49] <ubottu> Launchpad bug 1540591 in fontconfig (Ubuntu) "fontconfig breaks Trusty - Xenial upgrade" [Undecided,New]
=== _salem` is now known as _salem
[22:14] <Saviq> infinity, hey, can I please bother you to recycle the regression in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8 - it's a known flaky test (bug #1532358)
[22:14] <ubottu> bug 1532358 in unity-scopes-shell (Ubuntu) "flaky autopkgtests cause migration issues" [High,In progress] https://launchpad.net/bugs/1532358
[22:15] <Saviq> oh actually, mterry could you ↑
[22:15]  * Saviq found a core dev on the team, will bother him instead :)
[22:15] <mterry> Saviq, :)
[22:15] <Saviq> infinity, unping
[22:16] <mterry> Saviq, submitting
[22:16] <mterry> Saviq, submitted rather
[22:16] <Saviq> tx