=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
=== kickinz1|afk is now known as kickinz1
[07:58] <dholbach> good morning
[08:01] <dholbach> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
[08:07] <seb128> hey dholbach ;-)
[08:07] <dholbach> hey seb128
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[08:40] <dholbach> can somebody from the release team please take a look at https://bugs.launchpad.net/ubuntu/+source/intltool/+bug/953342?
[08:40] <ubottu> Launchpad bug 953342 in intltool (Ubuntu) "[ffe] Add support for Qt Designer UI files" [Medium,New]
[08:42] <dholbach> stgraber, slangasek, tumbleweed, ScottK, Riddell, Laney, Daviey, infinity: ^
[08:42] <dholbach> thanks
[08:57] <infinity> dholbach: I'm a bit confused by the bug log there.  Is the qtdesigner stuff a local Ubuntu patch that requires the new upstream or is the support included upstream in the new release?
[08:57] <dholbach> infinity, the latter
[08:58]  * infinity notes that MPs for merges are entirely useless, so can't really tell.
[08:59] <infinity> Oh, wait, dobey is upstream for intltool?  That clears this up a bit.
[09:01] <infinity> dholbach: Can you grab me a debdiff from current to new, so I can have a quick look at it?
[09:02] <seb128> isn't that the mp diff?
[09:03] <infinity> Oh, I suppose so.
[09:03] <dholbach> infinity, http://paste.ubuntu.com/10608668/ - http://people.canonical.com/~dholbach/tmp/diff
[09:03] <LocutusOfBorg1> hi all
=== kickinz1 is now known as kickinz1|afk
[09:06] <infinity> dholbach: Alright, the "new feature" parts of that look reasonably isolated, go for it.
[09:06] <dholbach> thanks
[09:07] <Laney> dholbach: Looks like we're in sync
[09:07] <dholbach> Laney, mh?
[09:07] <Laney> shall I exp-ise the new upstream release?
[09:07] <Laney> then carry on syncin'
[09:08] <dholbach> as you like it
=== kickinz1|afk is now known as kickinz1
[09:09] <Laney> I surely do
[09:15] <dholbach> https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1430893 needs a review from the release team too.
[09:15] <ubottu> Launchpad bug 1430893 in ubuntu-meta (Ubuntu) "[FFe] Install Fcitx for Chinese users" [Undecided,Confirmed]
[09:15] <dholbach> I guess with the MIR (https://bugs.launchpad.net/ubuntu/+source/fcitx/+bug/1356222) approved, that should be fine?
[09:15] <ubottu> Launchpad bug 1356222 in libgooglepinyin (Ubuntu) "[MIR] fcitx and related packages" [Undecided,Fix committed]
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[10:13] <mlankhorst> infinity: hm with xorg-server 1.17 the xserver-xorg pkg has a depends on xserver-xorg-video-all | xorg-server >= 1.17 | xorg-driver-video, but it also has a depends on xorg-server, can that be changed to Recommends: xserver-xorg-video-all | xorg-driver-video?
[10:14] <dholbach> Riddell: could it be that Aaron's change to ubiquity-slideshow-ubuntu did not make it into lp:ubiquity-slideshow-ubuntu?
[10:15] <mlankhorst> change is because the xorg-server no longer needs a driver to function since modesetting was moved to the core
[10:19] <Odd_Bloke> A CVE (and fix) for requests has been released which affects the versions in trusty onwards; is there value in my preparing debdiffs which address it?
[10:19] <infinity> mlankhorst: I guess that depends on what the intent is.
[10:19] <Riddell> dholbach: let me check
[10:20] <infinity> mlankhorst: If you want people to be able to have no driver installed other than modesetting, removing "xorg-server-core (>=1.17)" and making xorg-server-core Provides: xorg-driver-video is probably correct.
[10:20] <Odd_Bloke> (Or do the security team generally handle such things themselves?)
[10:20] <Riddell> dholbach: pushed
[10:21] <dholbach> thanks Riddell
[10:22] <mlankhorst> infinity: yeah perhaps, but that kills the point of xorg-driver-video..
[10:28] <infinity> mlankhorst: It does indeed.
[10:29] <infinity> mlankhorst: Alternately, reintroduce xserver-xorg-video-modesetting as an empty package that just Provides xorg-driver-video and Depends on xorg-server-core (>=1.17)
[10:29] <infinity> mlankhorst: Makes it more obvious for people to then register their intent.
[10:29] <mlankhorst> hm probably
[10:29] <infinity> mlankhorst: And drop the xserver-xorg alternate dep on xorg-server-core as a driver.
[10:29] <mlankhorst> I think it would be best to depend on = ${binary:Version} then..
[10:30] <infinity> mlankhorst: Why exact version?  On the off chance that it's removed again? :P
[10:30] <infinity> Or broken out, rather.
[10:30] <mlankhorst> dno
[10:30] <infinity> mlankhorst: But yeah, do what works best, but that general idea seems sane.  You get the "driver" package that way.
[10:30] <mlankhorst> oke
[10:31] <infinity> mlankhorst: Also transitions a bit more smoothly for people who were using that package exclusively before, I suspect.
[10:31] <infinity> Or, certainly more obviously.
[10:31] <mlankhorst> more obviously, nothing explicitly depends on modesetting in the archive
[10:31] <infinity> mlankhorst: That does mean that you need to take those Conflicts/Replaces I made you do and change them back to versioned Breaks/Replaces. :P
[10:31] <mlankhorst> ironic, eh?
[10:32] <infinity> Quite.
[10:32] <infinity> No good deed goes unpunished.
[10:32] <mlankhorst> or maybe just move it back to xserver-xorg-video-modesetting altogether, because why not..
[10:32] <mlankhorst> we're bumping 2 epochs anyway :p
[10:33] <mlankhorst> but if I move it back then I do need binary:Version since I can't depend on the normal xsf scripts to take care of it.
[10:34] <infinity> mlankhorst: If bundled is the "right" way, the empty driver package as a hint seems to work okayish.
[10:34] <infinity> mlankhorst: But I don't know why it moved in the first place, so can't make an educated guess there.
[10:37] <mlankhorst> no idea, probably to always have a generic accelerated driver
[10:37] <mlankhorst> when it moved over support for dri2, glamor, and dri3 was added
=== doko__ is now known as doko
[11:14] <doko> Riddell, any news about the libqinfinity update?
[11:16] <Riddell> doko: nothing yet, feel free to remove kte-collaborative and libqinfinity if you need to
[11:17] <doko> Riddell, well, I would demote it to -proposed
[11:18] <Riddell> doko: demote libqinfinity ? what would that do?
[11:19] <doko> Riddell, if it's not in the release pocket, then it doesn't block migration
[11:21] <Riddell> doko: won't it try to migrate together with libinfinity and still fail?
[11:21] <doko> no
[11:21] <doko> block-proposed is your friend
[11:23] <Riddell> ah hah
[11:23] <Riddell> doko: sure go ahead
[12:04] <dholbach> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[12:05]  * Laney hugs dholbach 
[12:05] <Laney> good work
[12:05] <dholbach> thanks
[12:19] <brendand_> anyone know if it's possible to write to a file in /run/ from a python script not running as root?
[12:19] <brendand_> sudo doesn't work of course
[12:19] <brendand_> attempting sudo -s seems to confuse the interpreter
[12:22] <infinity> brendand_: What's the use-case?
[12:23] <infinity> brendand_: If you're running as a logged in user, you probably want /run/user/$UID
[12:23] <ogra_> yeah
[12:24] <ogra_> use $XDG_RUNTIME_DIR/<myfile>
[12:27] <brendand_> infinity, that won't work i don't think - it's autopkgtest, i need to write to /run/adt_reboot_target then run /tmp/autopkgtest-reboot, which i think expects the file to be there
[12:29] <brendand_> the problem is the rest of the script can't be run as root
[12:29] <didrocks> brendand_: why do you let autopkgtest-reboot setting the flag itself?
[12:29] <didrocks> ah
=== MacSlow is now known as MacSlow|lunch
[12:29] <didrocks> brendand_: well, I doubt /tmp/autopkgtest-reboot will work?
=== _salem is now known as salem_
[12:33] <didrocks> ensure you have autopktest 3.11.1 as well, there is a fix to run autopkgtest-reboot with sudo
[12:35] <flexiondotorg_> dholbach, Just seen your comment on #1432439
[12:35] <flexiondotorg_> dholbach, I've checked the new tarball and the relevant file now has the executable bit set.
[12:36] <dholbach> hum
[12:36] <flexiondotorg_> dholbach, When I prepared the debdiff it produced what you see. Is it possible to have debdiff include the file attribute changes?
[12:43] <flexiondotorg_> dholbach, Should I attached ubuntu-mate-settings_0.4.4-1.tar.gz to #1432439?
[12:43] <dholbach> we already have ubuntu-mate-settings_0.4.4.tar.xz
[12:44] <dholbach> maybe call it ubuntu-mate-settings_0.4.4.1.tar.xz or ubuntu-mate-settings_0.4.5.tar.xz?
[12:44] <flexiondotorg_> dholbach, I can change the version. No problem.
[12:44] <flexiondotorg_> dholbach, Should I attached the revised debdiff and tarball to the bug?
[12:44] <dholbach> yeah, it's because ubuntu-mate-settings_0.4.4.tar.xz is alrady known to the archive and we can't just change it
[12:45] <dholbach> maybe the tarball, yes
[12:51] <flexiondotorg_> dholbach, I've attached a new debdiff for 0.4.4.1 and the corresponding tarball.
[12:58] <didrocks> smoser: mvo_: hey, I'm using the alpha2 core image with snappy, each snappy commands ask for "Reboot to use the new ubuntu-core.". Note that I didn't upgrade anything, and that, even after rebooting
[12:59] <didrocks> I then tried to upgrade ubuntu-core (to 145), reboot, snappy versions shows the new version is the current one, but I still have the reboot message
[12:59] <mvo_> didrocks: its a known bug :/ if you have a3, please try snappy-go, it should be much better. or use a daily
[12:59] <mvo_> didrocks: yeah, the reboot message is a known bug, its fixed in snappy-go
[12:59] <mvo_> didrocks: are you using that on a arm system?
[12:59] <didrocks> mvo_: is there a link to alpha3 ubuntu core image (only got alpha2)?
[12:59] <didrocks> mvo_: no, I'm running amd64 for now
[13:00] <didrocks> but I'm happy to switch to whatever is latest and available
[13:01] <didrocks> ah, I guess http://cdimage.ubuntu.com/ubuntu-core/releases/alpha-3/ (doesn't follow the other naming schemes)
[13:03] <mvo_> didrocks: best is probably to just use a daily via ubuntu-device-flash
[13:03] <mvo_> didrocks: but a3 is a step forward, the pace is very very fast, daily is really the best to see where we are
[13:04] <didrocks> mvo_: do you have an handy recipe to go from ubuntu-device-flash daily tar.gz to a .img?
[13:05] <didrocks> seems to be "ubuntu-device-flash core", giving it a try
[13:11] <dholbach> flexiondotorg_, uploaded
[13:11] <flexiondotorg_> dholbach, Many thanks!
[13:20] <didrocks> mvo_: seems to work, thanks! Looking a little bit more in the command difference with snappy go now
[13:21] <mvo_> didrocks: https://lists.ubuntu.com/archives/snappy-devel/2015-March/000334.html <- that might be helpful for that
[13:22] <didrocks> mvo_: excellent, thanks!
[13:23] <mvo_> yw
[13:31] <doko> jamespage, MIR for django-nose needed (horizon)
[13:32] <jamespage> doko, hrm thats odd
[13:32]  * jamespage looks
=== MacSlow|lunch is now known as MacSlow
[13:41] <jamespage> doko, looks like the django bump to 1.7 makes the message compilation for horizon need all dependencies, irrespective of whether they are used or now
[13:41] <jamespage> raising MIR now
[13:42] <jamespage> doko, its been in main in the past - https://bugs.launchpad.net/ubuntu/+source/django-nose/+bug/981100
[13:42] <ubottu> Launchpad bug 981100 in django-nose (Ubuntu) "[MIR] python-django-nose" [Undecided,Fix released]
[13:48] <jamespage> doko, I can re-do the mir but the package lgtm - still executes test etc... - it was pretty light touch from memory
[13:49] <doko> jamespage, no, that's fine then
[14:33] <doko> mvo_, apt boottest regression
[14:33] <mvo_> doko: the adt test?
[14:33] <doko> yes
[14:41] <doko> jibel: some autopkg test failures seen due to qemu issues. is this known? already asked sbeattie who did the last upload
[14:41] <mvo_> doko: thanks, I noticed the mail I need to dig into what went wrong
[14:45] <jibel> doko, do you have an example?
=== salem_ is now known as _salem
[14:46] <doko> jibel, kstars and marble
[14:49] <jibel> doko, latest run of kstars failed because debian/tests/testsuite.xsession: 5: debian/tests/testsuite.xsession: dh_auto_test: not found
[14:49] <jibel> missing dependency maybe
[14:54] <jibel> doko, and last successful run of marble was Oct. 29th. Same test is failing and same failure mode.
[14:56] <jibel> doko, you're talking about autopkgtest in vivid, right?
[14:56] <doko> jibel, yes
[14:57] <jibel> doko, so yeah, nothing in these 2 examples is related to a recent upload of qemu
[15:01] <doko> jibel, I'll try to fix that.
[15:15] <doko> ScottK, Riddell: are you aware of the marble autopkg test failure?
[15:41] <hallyn_> stgraber: bleh, bug 1432683 presumably requires some systemd-fu
[15:41] <ubottu> bug 1432683 in lxc (Ubuntu) "apt-get install lxc doesn't load required apparmor profiles" [Undecided,New] https://launchpad.net/bugs/1432683
[15:47] <doko> kenvandine, ping on the libdbusmenu and signon-ui ftbfs ...
[15:50] <seb128> hallyn_, hey, just checking if you saw that you got subscribed on bug #1427264 for feedback (no hurry to reply, it was to verify that the email reached you rather than going in some launchpad spam box)
[15:50] <ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264
[15:51] <tyhicks> thanks seb128 - pinging serge was on my todo list today :)
[15:51] <seb128> tyhicks, hey, yw :-)
[15:52]  * hallyn_ cringes - why am i being subscribed?
[15:53] <hallyn_> hm.  i probably was subscribed but i hadn't noticed.  will look in a bit, thanks
[15:53] <hallyn_> tyhicks: i'll ping you after i digest it, thx
[15:54] <seb128> hallyn_, thanks :-)
[15:54] <tyhicks> hallyn_: I subscribed you, rather than pinging you directly on IRC, since it wasn't urgent
[15:59] <kenvandine> doko, sorry, we should get tedg to look at libdbusmenu and mardy for signon-ui
[16:02] <tedg> I think that bregma was looking at the dbusmenu one, not sure how far he got.
[16:04] <bregma> yeah, I did the other ones but still need to look into why the libdbusmenu tests are hanging during the build
[16:05] <bregma> bug #1429291
[16:05] <ubottu> bug 1429291 in libdbusmenu (Ubuntu) "FTBFS on Ubuntu Vivid due to hang in test-json-instruction" [Critical,Triaged] https://launchpad.net/bugs/1429291
[16:05] <bregma> nothing to do with GCC 5
[16:06] <bdmurray> stgraber: could you verify bug 1422345?
[16:06] <ubottu> bug 1422345 in unattended-upgrades (Debian) "stop being nice does not work" [Unknown,New] https://launchpad.net/bugs/1422345
[16:07] <stgraber> bdmurray: doing now
[16:07] <doko> mardy, ping on signon-ui
[16:08] <flexiondotorg_> seb128, Regarding daily-images.
[16:08] <flexiondotorg_> seb128, Confirmation from Xubuntu that they have the same issue.
[16:09] <stgraber> bdmurray: tested and tags updated, feel free to release
[16:09] <kenvandine> doko, is there a bug filed for signon-ui?
[16:09] <kenvandine> mardy is probably eod, so if there's a bug just assign it to him
[16:09] <bdmurray> stgraber: great, thanks!
[16:10] <seb128> flexiondotorg_, k, good to know, and that started on the 15?
[16:11] <doko> kenvandine, I have now, yes. lp #1432711
[16:11] <ubottu> Launchpad bug 1432711 in signon-ui (Ubuntu Vivid) "signon-ui fails to build in vivd" [High,Confirmed] https://launchpad.net/bugs/1432711
[16:11] <flexiondotorg_> I can only go back to 15.
[16:11] <flexiondotorg_> seb128, So I don't know it is was broken prior to the 15th.
[16:11] <kenvandine> doko, thanks, i assigned it to mardy
[16:12] <flexiondotorg_> seb128, In case you missed my comment in #ubuntu-desktop
[16:12] <flexiondotorg_> seb128, There is an error about pwconv not being able to set the permission of /etc/passwd- to 0600
[16:12] <seb128> flexiondotorg_, I saw it
[16:12] <seb128> but good to repeat here
[16:12] <seb128> it's a more suitable channel for installer issuers
[16:12] <seb128> issues
=== _salem is now known as salem_
[16:16] <flexiondotorg_> seb128, elfy just posted this in #ubuntu-release
[16:16] <flexiondotorg_> seb128, elfy> good day - really not sure if this is even the right channel to bring these things, but xubuntu daily today, lubuntu and flexiondotorg_ says mate all failing to get far in to a boot, complaining of pwconv not being able to set the permission of /etc/passwd- to 0600 http://i.imgur.com/KaKMeIa.png
[16:29] <flexiondotorg_> When did the new Xorg land in 15.04?
[16:30] <flexiondotorg_> Because Xorg is reporting no screens found on the current daily image.
[16:32] <doko> jamespage, ping on https://bugs.launchpad.net/ubuntu/+source/python-sysv-ipc/+bug/1399581 what is the status? asking because the version in the release pocket ftbfs
[16:32] <ubottu> Launchpad bug 1399581 in python-sysv-ipc (Ubuntu) "[MIR] python-sysv-ipc" [High,New]
[16:33] <flexiondotorg_> infinity, I'm looking into the daily image bug.
[16:33] <jamespage> doko, looking now
[16:33] <flexiondotorg_> See above for my questions about Xorg.
[16:33] <infinity> flexiondotorg_: Ta.  Let me know if you find a scapegoat.
[16:33] <jamespage> doko, I'd better get onto that
[16:34] <infinity> flexiondotorg_: xorg migrated on the 12th.
[16:35] <flexiondotorg_> infinity, Xorg logs show many drivers failing to load.
[16:44] <elfy> re the issue that flexiondotorg_ is seeing with Mate daily, seeing same here on Xubuntu and I grabbed Lubuntu to check, same issue, pastebin of xorg.0.log which is throwing a bunch of errors it seems - http://pastebin.ubuntu.com/10610592/
[16:45] <doko> didrocks, can the two remaining packages in https://bugs.launchpad.net/ubuntu/+source/fcitx/+bug/1356222 be promoted?
[16:45] <ubottu> Launchpad bug 1356222 in libgooglepinyin (Ubuntu) "[MIR] fcitx and related packages" [Undecided,Fix committed]
[16:45] <flexiondotorg_> Changelog is interesting too.
[16:45] <flexiondotorg_> http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg/xorg_7.7+7ubuntu3/changelog
[16:45] <flexiondotorg_> * Modesetting has been removed, remove from vars.
[16:47] <Laney> Looks like a load of drivers dropped out of the image
[16:47] <didrocks> doko: yeah, doing it now
=== JanC_ is now known as JanC
[16:49] <infinity> Laney: If drivers dropped out of the image, I think what mlankhorst and I were discussing earlier might fix that.
[16:50] <Laney> Righto
=== salem_ is now known as _salem
[16:52] <infinity> But, indeed, it looks like xserver-xorg-video-all has fallen out of all the desktop seed because of the whacky xserver-xorg-core alternate dep that shouldn't be there.
[16:52] <infinity> mlankhorst: Were you going to fix that today, or should I implement the thing we discussed?  Seems more urgent than we thought.
[16:52] <Laney> Well, you guys have been looking at this already, so take this here baton from me
[16:52] <Laney> virt-manager continues to work. :)
[16:53] <doko> ScottK, Riddell: kstars autopkg test fixed ... marble remains ...
[16:54] <Riddell> doko: when I asked marble upstream they said it was flakey and to be ignored
[16:54] <Laney> So delete the test?
[16:56] <Riddell> upstream likes to keep it I guess
[16:56] <Laney> The autopkgtest
[16:57] <mlankhorst> infinity: thought it could have happened, bleh I'll look at it later this evening..
[16:58] <doko> Riddell, well, they can keep it, but then please carry a patch to disable it
[16:59] <mlankhorst> I'm probably going to move modesetting to being separately again..
[17:02] <infinity> mlankhorst: Kay.  Whatever you're going to do, it should happen soon, cause all the images are broken right now. :P
[17:04] <lefteris> hello, i am encounter a problem. i have two packages in ours repository and i want to merge these packages into one
[17:04] <cjwatson> Riddell: You could always have it report the output but ignore failures from that test, if the output is useful to upstream.
[17:06] <Riddell> doko, cjwatson: ack
[17:06] <Riddell> will investigate
[17:08] <lefteris> i try with conflict, replace, provide but update-manager in ubutnu 12.04 proposes a partial upgrade?how can do this without proposing partial upgrade?
=== _salem is now known as salem_
[17:09] <infinity> lefteris: For package A taking over package B, you just want A to conflict/replace B, unversioned.  The rest should happen via magic, usually.
[17:11] <lefteris> infinity: to be more specific, already in ours repository exists, package A that depends on package B
[17:12] <lefteris> i want to redistrubute a new one with tha name of package A (merge the two packages)
[17:12] <doko> tumbleweed, can we have python-cffi 0.9.2 please?
[17:12] <infinity> lefteris: Right, so the new A can't depend on B anymore, and should conflict/replace B.
[17:12] <infinity> lefteris: Assuming nothing else depends on B.
[17:12] <infinity> lefteris: If other things depend on B, you need to also provide B.
[17:13] <infinity> lefteris: If other things have *versioned* deps on B, you're out of luck, cause 12.04's dpkg doesn't support versioned provides.
[17:15] <lefteris> infinity: nothing else depends on B, but then package B still remaining to the system. right?
[17:16] <lefteris> but is orphaned so with apt-get purge --auto-remove, the package B should removed
[17:18] <lefteris> can i  send a package A update that upgrades already installed package A and removes package B?
[17:19] <infinity> lefteris: Yes, if the new A doesn't depend on B anymore, and declares a Conflicts/Replaces against B.  Like I said.
[17:25] <doko> didrocks, is there a new gnome coming soonish?
[17:27] <didrocks> doko: we don't really track latest version of gnome for a long time already. So, apart if the ubuntu gnome flavor has some particular applications/components they want latest, if it doesn't break unity and there is a FFe, I would say no
[17:27] <mlankhorst> Eigen berichten
[17:28] <doko> thanks
[17:28] <lefteris> infinity: thanks, conflicts/replaces works with dist-upgrade, but why update-manager still popup partial upgrade?
[17:28] <infinity> lefteris: A bug, if it does.  It's supposed to have code to special-case that the same way apt does.
[17:29] <infinity> lefteris: Or your packages aren't exactly as you described them.  Hard to say without seeing all the control files.
[17:35] <cjwatson> I only added that C+R logic in 13.04's update-manager.  If it's an upgrade within 12.04, rather than an upgrade from 12.04 to 14.04, it probably won't honour that.
[17:37] <infinity> cjwatson: Oh, was it that recently?
[17:37] <infinity> cjwatson: Seemed longer ago.
[17:38] <infinity> lefteris: There's your answer, then.  12.04's update-manager just plain doesn't support package takeovers of that sort.
[17:38] <cjwatson> Yup.
[17:39] <infinity> lefteris: The other option is to make an empty package B that depends on package A, and make A have a versioned Breaks/Replaces on B (<< version_where_you_did_that)
[17:40] <mlankhorst> infinity: I think I'll just degrade xserver-xorg-video-all | xorg-driver to recommends, saves me from reviving modeset :P
[17:40] <infinity> mlankhorst: Err, how does that help?
[17:40] <infinity> mlankhorst: The problem right now is -core being in the alternate list.
[17:41] <mlankhorst> infinity: yeah and lowering it to recommends means I can remove xserver-xorg-core from the alternate list
[17:41] <infinity> mlankhorst: Because core is installed anyway, that means germinate ignores xserver-xorg-video-all, and it goes byebye.
[17:41] <lefteris> infinity, cjwatson: thank you very much for the help
[17:42] <infinity> mlankhorst: I'm not sure I follow, but okay.  I thought the whole point was to guarantee people had at least opted to have one driver installed.
[17:42] <mlankhorst> infinity: yes and modesetting is a driver
[17:42] <infinity> mlankhorst: I guess with core providing a driver, you can pretend they made that choice always now, but...
[17:42] <hallyn_> slangasek: hi, jessie needs another cgmanager update - do you have time to take a look at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc ?
[17:43] <slangasek> hallyn_: not for the next couple of days at least
[17:43] <hallyn_> slangasek: ok, thanks
[17:44] <hallyn_> jamespage: are you dd?
[17:44] <hallyn_> jamespage: would you be able to sponsor http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc ?
[17:44] <lefteris> infinity: I also try the above solution with the dummy package B but then, package B never become orphaned (i also try the oldlibs section but with no success)
[17:45] <infinity> lefteris: No, it won't become orphaned, but it's also wasting little space, so who cares really.
[17:45] <infinity> hallyn_: I was about to offer, and then I started auditing.  That's a hefty set of patches.
[17:46] <infinity> hallyn_: How long has this been in sid/vivid, how well tested, what level of confidence do you have in the backports, can I hit you if it's all wrong and I get yelled at for sponsoring? :P
[17:46] <lefteris> infinity: yeah you are right (just 24kb)... ok... again, thank you very much
[17:47] <hallyn_> infinity: they've been in sid and vivid for about a month
[17:47] <jamespage> hallyn_, I'll leave you in infinity's capable hands...
[17:48] <doko> mlankhorst, ping on #1428083
[17:48] <infinity> hallyn_: Well, it all looks vomitously insane, which I think I expressed the first time we talked about it, but it looks like it does what it says, and a month of battering in vivid gives me some confidence.
[17:49] <hallyn_> infinity: it is somewhat insane, insane enough that i thin kit's worth some time to brainstorm better kernel support fo rthis sort of thing
[17:49] <smoser> systemd kknowledgeable person able to advise ?
[17:49] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1432758
[17:49] <ubottu> Launchpad bug 1432758 in cloud-init (Ubuntu) "cloud-config.service, cloud-final.service do not run if previous cloud-init service failed" [Undecided,New]
[17:50] <infinity> hallyn_: Just build testing and I'll toss it up.
[17:51] <mlankhorst> infinity: uploaded a fix for xorg
[17:51] <mlankhorst> bug 1428083
[17:51] <ubottu> bug 1428083 in python-ttystatus (Ubuntu) "MIR: cmdtest, python-cliapp, python-ttystatus, python-coverage-test-runner" [Undecided,Incomplete] https://launchpad.net/bugs/1428083
[17:51] <hallyn_> infinity: if problems do crop up then i guess it'll be time to just not use a separate mount ns, and try to reuse mouns at startup - but that has its own problems ,sadly
[17:51] <infinity> mlankhorst: Ta.
[17:51] <mlankhorst> oh oops :P
[17:51] <mlankhorst> I guess that was the bug attached
[17:52] <hallyn_> echo "$(date -d "$*" +%Y-%m-%d) infinty" >> ~/gtd/owe_a_beer
[17:52] <infinity> hallyn_: Your debian/libcgmanager0.symbols is out of date, BTW.
[17:52] <infinity> hallyn_: Feel like fixing that to actually be accurate before I upload this?
[17:52] <hallyn_> feh
[17:53] <hallyn_> will do.  always akes me awhile, will ping you when done
[17:53] <infinity> hallyn_: (I find it's best to hard fail on additions too, so you actually get proper shlibdeps)
[17:53] <infinity> hallyn_: It's easy by hand, if you know when the cgmanager_list_keys* symbols appeared upstream.
[17:54] <hallyn_> can that be done in debian/rules?  (hard failing on additions)
[17:55] <infinity> hallyn_: Yeah, see check levels (-c) in dpkg-gensymbols(1)
[17:55] <cjwatson> dh_makeshlibs -- -c4
[17:55] <cjwatson> (is the strictest form)
[17:55] <infinity> hallyn_: Or crib from Colin.
[18:03] <hallyn_> weird that i had added the other two symbols which were added in the same version
[18:04] <hallyn_> cjwatson: thx
[18:09] <hallyn_> k i should do the analogous change for sid then
[18:09] <hallyn_> infinity: new version uploaded to mentors, though it usually takes a minute or two to actually show up there
[18:09] <hallyn_> (show up there updated)
[18:09] <infinity> hallyn_: Sure, just toss me the .dsc URL for both sid and jessie when they're ready.
[18:16] <hallyn_> infinity: d'oh, i'd already done that in sid
[18:16] <hallyn_> jessie's sslow release is just messing with me
[18:20] <hallyn_> infinity: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc is updated
=== roadmr is now known as roadmr_afk
[19:04] <doko> jamespage, ceph regression, resulting in a broken ARM qemu: lp #1432786
[19:04] <ubottu> Launchpad bug 1432786 in libguestfs (Ubuntu Vivid) "upgrade of ceph in vivid breaks qemu-system-arm" [High,Confirmed] https://launchpad.net/bugs/1432786
[19:10] <gQuigs> do I need to request something else for https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1408478,  or will it be demoted from main by some automatic mechanism?
[19:10] <ubottu> Launchpad bug 1408478 in libpam-ldap (Ubuntu) "Removal Request: Move to universe from main" [Medium,Fix committed]
[19:11] <gQuigs> (other items at fix committed in the same repo, are already affecting the distro..)
[19:12] <infinity> gQuigs: libpam-ldap and libnss-ldap are both awaiting demotion.
[19:13] <gQuigs> infinity: thanks for checking!
[19:13] <infinity> and ldap-auth-client too.
[19:13] <infinity> I'll do all three now.
[19:13] <gQuigs> infinity: awesome, thanks!
[19:25] <seb128> cyphermox, do you know why "sudo start bluetooth" doesn't return on upstart/vivid? (doing a stop before)
[19:25] <seb128> is the upstart script buggy?
=== kickinz1 is now known as kickinz1|afk
[19:26] <smoser> anyone able to confirm or refute this for me ..
[19:26] <smoser> it seems that initramfs in vivid is not copying /run from initramfs into the root's /run
[19:26] <smoser> where it previously did
[19:32] <melodie> hello
[19:40] <infinity> smoser: It hasn't changed, but it's possible that systemd is taking it upon itself to wipe /run or remount a fresh one or something.
[19:41] <cyphermox> seb128: buggy I guess; but do you mean vivid on desktop or vivid on the phone?
[19:41] <smoser> i think it must be.
[19:41] <seb128> cyphermox, either
[19:41] <cyphermox> seb128: I think I say that sudo start bluetooth on the phone would break because the bluetooth init jobs need to improve a lot
[19:42] <cyphermox> I don't know why it would hang on desktop
[19:42] <seb128> cyphermox, ok, I was trying to add a script that "start on started bluetooth" and call hciconfig but that doesn't work ...
[19:42] <cyphermox> oh, but on desktop-next you would have some of the jobs from the phone
[19:43] <seb128> cyphermox, it's not desktop next, it's standard vivid desktop
[19:43] <cyphermox> I wouldn't know
[19:43] <cyphermox> it's definitely supposed to return
[19:43] <seb128> cyphermox, no worry, I was asking in case, thanks
[19:44] <arges> smoser: howdy
[19:44] <cyphermox> check any other scripts that start on starting bluetooth
[19:45] <seb128> cyphermox, on starting doesn't sequence though right? they could start before the bluetooth service is working?
[19:45] <arges> smoser: looking at bug 1431473, can't seem to reproduce on this end. Why are you guys using some frankenstein core2duo + vmx machine type?
[19:45] <ubottu> bug 1431473 in linux (Ubuntu Vivid) "kvm_intel (nested) module will not load [Input/output error]" [High,Confirmed] https://launchpad.net/bugs/1431473
[19:47] <smoser> arges, well, thats openstack in both cases doing the host.
[19:48] <arges> smoser: : ) fun. Ok, yea i think joe's comments about getting the XML might help us to isolate this. if we can repro here it will be easy enough to bisect and figure out what changed.
[19:48] <smoser> and oddly, rbasak said it reproduced for him on canonistack. where i had been unable to see it beofre, but i had a system that had a xeon there. (as seen in my report's cpuinf)
[19:48] <smoser> yeah, and we can get host spuc and kernel information too.
[19:48] <arges> smoser: cool. thanks for bringing that up.
[19:49] <arges> *filing the bug that is
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== roadmr_afk is now known as roadmr
[20:22] <Unit193> darkxst: Pingaling.
[20:31] <smoser> infinity, https://bugs.launchpad.net/ubuntu/+bug/1432821 if you were wanting to take a guess :)
[20:31] <ubottu> Launchpad bug 1432821 in Ubuntu "something deleting /run/network after during boot" [Undecided,New]
[20:32] <smoser> xnox, maybe ?  anyone have ideas on what might be removing that directory ?
=== salem_ is now known as _salem
[20:45] <darkxst> ŭ
[20:48] <smoser> stgraber, you're my resident resolvconf expert for bug 1432829
[20:48] <ubottu> bug 1432829 in resolvconf (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [Undecided,New] https://launchpad.net/bugs/1432829
[20:49] <daniel_> file:///home/daniel/textedit.py
[20:49] <darkxst> Unit193, hi
[20:50] <daniel_> Whut is in 15.04
[20:53] <stgraber> smoser: haven't touched resolvconf in a long time and I'm not sure how to debug the systemd side of this
[20:54] <stgraber> smoser: what seems odd is that you're using both ipconfig and dhclient, typically dhclient and ifupdown get pretty unhappy when the interface is already configured, so maybe ifupdown is actually failing to bring the interface up (or never triggered by systemd somehow). In the past it could be that timing meant that our resolvconf upstart job would fix things up for you, but doesn't anymore with systemd.
[20:58] <doko> does an architecture option work in a binary all package?  Depends: not-available-here [armhf] ?
=== _salem is now known as salem_
[22:02] <doko> Riddell, ScottK (and maybe cjwatson): can't figure out why libkdeedu doesn't migrate
[22:02] <cjwatson> doko: arch option / binary all> no, arch options like that work by dpkg-gencontrol processing them at build time, which can't work for arch all
[22:03] <cjwatson> doko: that seems clear enough, it depends: kdelibs5 (>= 4:14.12.3) and vivid has 4:4.14.6-blah
[22:03] <cjwatson> doko: 14 > 4
[22:04] <Riddell> hmm that'll be a hardcoding mistake
[22:08] <doko> oops, to blind .. time to call it a day today. Riddell, can you fix?
[22:16] <Riddell> doko: si, manaña
[22:16] <tumbleweed> doko: yes. Been travelling, but I'll look at it
[22:24] <melodie> good night
[22:54] <basic`> hi there, I'm one of the maintainers of http://ftp.drupal.org and we've noticed loganberry.canonical.com and breadfruit.canonical.com appear to be crawling the entire tree of Drupal projects.
[22:54] <basic`> does anyone know what this would be?
[22:56] <ScottK> basic`: You probably want #canonical-is (I think it is).  No one here is likely to know.
[22:56] <basic`> ScottK: thanks!
[22:57] <basic`> ScottK: nobody in there, another network ?
[22:57] <Unit193> -sysadmin
[22:57] <basic`> thanks!
[22:59] <ScottK> That was it.
[22:59] <ScottK> Thanks Unit193
[22:59] <Unit193> Sure.