[04:08] <infinity> pitti: And still more disappearing tests...
[04:08] <infinity> pitti: apport (triggered by binutils) went from RUNNING to no longer on the list.
[04:09] <infinity> pitti: And I see no evidence that it ever passed.
[05:25] <Logan_> is it necessary to keep a delta if the only change is libpng12-dev to libpng-dev? it doesn't look like there will be a transition any time soon...
=== infinity changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
[05:37] <infinity> Logan_: The only provide of libpng-dev is libpng12-dev currently.
[05:37] <Logan_> right
[05:37] <infinity> s/provide/provider/
[05:37] <infinity> Logan_: That didn't used to be true, hence some of the deltas.
[05:38] <Logan_> ah, okay
[05:38] <infinity> Logan_: So, yeah, if that's all the delta we have, go ahead and drop it.
[05:38] <Logan_> sweet, will do
[06:01] <infinity> First autosync in progress.  Should take about an hour to sync, and possibly a day or three for the buildds to forgive me.
[09:19] <work_alkisg> ibus wasn't running by default up until 12.04, is there any reason why it's running now, even for locales that don't need it?
[09:19] <work_alkisg> It's causing severe typing issues (e.g. https://bugs.freedesktop.org/show_bug.cgi?id=42244) and it's eating up RAM without any benefit at all.
[09:19] <ubottu> Freedesktop bug 42244 in Server/Input/Core "Multimedia keys become unresponsive in full-screen applications" [Normal,Reopened]
=== work_alkisg is now known as alkisg
[09:19] <alkisg> (it's not about multimedia keys, we can't even change the keyboard layout now)
[13:37] <prepangolin> Hi guys
[13:37] <prepangolin> How to compile compiz?
[16:18] <dupingping_> hello developers.
[16:45] <ScottK> stgraber: I'd like it so edubuntu-server-host used the native ipaddress module instead of ipaddr from python3-ipaddr.  I'm happy to do the changes if you'll be able to test them.  Do you have a requirement to backport prior to saucy?  I'm trying to delete the binary in Debian, so it'll go soon in uptopic.
[17:25] <Unit193> pitti: src:systemd, "- debian/rules: Don't install init.d scripts, only the upstart jobs." you use the no-op '--upstart-only' switch for dh_installinit.  At least one less change needed.
[17:34] <stgraber> ScottK: nope, we require a pretty recent LXC anyway, so we don't care about pre-saucy
[17:37] <pitti> Unit193: oh, how is it a no-op?
[17:38] <Unit193> Changelog of debhelper has '- dh_installinit: Add no-op --upstart-only option for compatibility.' and manpage has the same info.
[17:38] <Unit193> "Deprecated option, ignored for compatibility."
[17:44] <pitti> Unit193: ah, ok; thanks for pointing out!
[17:47] <Unit193> pitti: Any time!
[17:47] <pitti> Unit193: in fact, we'll get rid of a lot of our delta in the next merge
=== orcas333_ is now known as orcas333
[17:47] <pitti> http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=shortlog
[17:47] <pitti> we've been busy today :)
[17:47] <Unit193> That'll be nice.
[17:48] <pitti> and I'll create am ubuntu branch on top of the debian git, so that we finally have an official Vcs
[17:48] <pitti> we went through our delta today, and we pushed the useful bits to Debian, and can drop a lot of other bits
[19:02] <ScottK> stgraber: Thanks.
[19:03] <infinity> 164 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[19:03] <infinity> Looks like the autosync is working. :P
[19:06] <pitti> hehe
[19:23] <Logan_> infinity: lol, I have 260 to upgrade
[19:24] <xnox> Unit193: "--upstart-only" still installs init.d script & the upstart job.
[19:24] <infinity> Logan_: I did some last night too. ;)
[19:24] <Logan_> ah :P
[19:25]  * infinity starts slogging through the NEW queue.
[19:25] <Unit193> xnox: Right.
[19:25] <xnox> Unit193: that option has meant to not install init.d script symlink to an "upstart-job" executable, however that has been obsoleted.
[19:26] <infinity> xnox: Yeah, he knows, he was pointing out to pitti that he could drop the option, since it was a no-op.
[19:26] <Unit193> Yes, that's how I read it.
[19:26] <xnox> infinity: ah, ok. correct.
[19:26] <Mirv> I need to kill 100% CPU eating dnsmasq once after reboot now, hmm (on utopic)
[19:58] <otto> I need help submitting mariadb-5.5 5.5.37 to trusty universe.
[19:59] <otto> I've read the ubuntu wiki pages ForDebianDevelopers and found out about sponsorship requests and sync requests. I however didn't quite figure out what situation applies to me now.
[20:00] <Unit193> otto: I'd think you're looking for a SRU, considering it fixes CVEs.
[20:00] <otto> It is a security update, fixes http://www.ubuntu.com/usn/usn-2170-1/, should I ask security team to pull in mariadb-5.5 5.5.37 from Debian sid?
[20:01] <xnox> otto: security sponsorship is slightly different, there is security documentation on the wiki as well.
[20:01] <otto> yes, I've read https://wiki.ubuntu.com/SecurityTeam/ForDebianDevelopers too, but I still don't quite get what applies to me now
[20:02] <xnox> otto: 5.5.37-1 is already in trusty (well in proposed (~= unstable), not release pocket (~= testing))
[20:02] <otto> this seems to apply (from the wiki): "In stable releases of Ubuntu where the Ubuntu package has the same version as in Debian, the Ubuntu Security team will perform a sync from Debian (called a 'security fake sync'). These are typically performed weekly by a member of the Ubuntu Security for packages that are not officially supported. "
[20:02] <xnox> otto: 5.5.36-1 is in trusty release in universe.
[20:03] <otto> xnox: no, .37 is only proposed for utopic: https://launchpad.net/ubuntu/+source/mariadb-5.5
[20:03] <xnox> otto: i don't see mariadb in stable, thus you have no DSA issued right?
[20:04] <otto> xnox: status overview https://packages.debian.org/search?keywords=mariadb
[20:04] <infinity>  mariadb-5.5 | 5.5.36-1 | trusty/universe          | source
[20:04] <infinity>  mariadb-5.5 | 5.5.36-1 | utopic/universe          | source
[20:04] <infinity>  mariadb-5.5 | 5.5.37-1 | utopic-proposed/universe | source
[20:05] <infinity> So, yeah.  You can't get 5.5.37-1 into trusty, as we don't copy backwards.
[20:05] <infinity> But you should get with the security team and see about pushing a 5.5.37-0ubuntu1 to trusty.
[20:05] <xnox> otto: yeah, and there is no DSA to fakesync either. So just follow https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation open a bug report against maraiadb-5.5 package in ubuntu, nominate for trusty
[20:06] <xnox> otto: and prepare a suitable diff & changelog entry + subscribe ubuntu-security, they should get back to you about it.
[20:06] <xnox> otto: opening bug report which is "public security" with "ubuntu-security" is a first step to push this update to trusty.
[20:20] <otto> xnox: does this look proper? https://bugs.launchpad.net/ubuntu/+source/mariadb-5.5/+bug/1313187
[20:20] <ubottu> Launchpad bug 1313187 in mariadb-5.5 (Ubuntu) "USN-2170-1: MySQL vulnerabilities also applies to MariaDB" [Undecided,New]
[20:21] <otto> should I file for a MRE at this point? where does it come in?
[20:21] <xnox> otto: looks good.
[20:21] <xnox> otto: MRE? no, that's unrelated.
[20:21] <xnox> otto: i've made a comment on that bug report for the security team.
[20:22] <infinity> Maria should probably enjoy the same MRE status that MySQL does, but that would also need a commitment from someomne to update and test it.
[20:22] <xnox> In file included from /usr/include/ruby-2.1.0/ruby.h:33:0,
[20:22] <xnox>                  from qmfengine.cpp:845:
[20:22] <xnox> /usr/include/ruby-2.1.0/ruby/ruby.h:24:25: fatal error: ruby/config.h: No such file or directory
[20:22] <xnox>  #include "ruby/config.h"
[20:22]  * xnox ponders if our ruby is good or not.....
[20:23] <infinity> xnox: Is that package passing an explicit -Iruby2.0 maybe?
[20:24] <xnox> infinity: it does pass explicit -I and they are all 2.1 based.
[20:24] <xnox> infinity: maybe not finding config.h, because multiarch.
[20:24] <otto> infinity: I will anyway update the package for Debian, I could easily maintain it for Ubuntu too. I now already build and test all version on both Debian and Ubuntu
[20:25] <infinity> (utopic-amd64)root@cthulhu:/usr/include# find . -name config.h
[20:25] <infinity> ./x86_64-linux-gnu/ruby-2.1.0/ruby/config.h
[20:25] <infinity> ./x86_64-linux-gnu/ruby-2.0.0/ruby/config.h
[20:25] <infinity> xnox: So, this situation isn't new.  2.0 was set up the same way.
[20:25] <psusi> infinity, hey there... I forwarded a query from someone last month about util-linux... I figured you were a little busy with finalizing trusty but now that it's out... how is that coming?
[20:25] <otto> I am just a bit confused on what the proper process it to push new versions into Ubuntu stable releases
[20:25] <xnox> infinity: quite. yeah. I'm porting qpid-cpp from ruby1.8-dev -> ruby-dev. Cause we somehow removed ruby1.8 without fixing all packages that like explicitely build-depend on ruby1.8-dev.
[20:26] <xnox> infinity: i'm just gonna go la-la-la or possibly propose an SRU for qpid-cpp to be build against ruby2.0
[20:26] <otto> The current wiki pages describe scenarios where somebody patches and existing package, but not really how a Debian release is supposed to be synced/backported into Ubuntu
[20:26] <xnox> actually was qpid-cpp released or not...
[20:27] <infinity> otto: It won't be synced.  And it usually shouldn't be the Debian release being backported either, as we don't want unrelated packaging changes.
[20:27] <xnox> otto: we don't sync/backport into stable/released releases.
[20:27] <infinity> otto: Your best bet is to poke mdeslaur and have him walk you through what the security team would like to see for things like this.
[20:30] <otto> infinity: it's not feasible to cherry-pick security fixes, thus I was thinking if I should now draft a MRE request?
[20:31] <psusi> otto, how is it not feasible to cherry-pick a security fix?
[20:32] <otto> upstream releases on the 5.5 branch maintenance micro releases which contain security and other fixes. When I update the Debian package, e.g. 5.5.36 -> 5.5.37 I just import the whole upstream .37 release
[20:33] <infinity> otto: Like I said, I suspect no one will disagree that maria should enjoy the same MRE status as MySQL does.
[20:33] <psusi> should have no problem cherry picking the security fix, but yea, it does sound like a good candidate for MRE
[20:34] <psusi> infinity, did you miss my question there? ;)
[20:34] <otto> I was just wondering is this the right timing to send a MRE request to technical-board?
[20:34] <infinity> otto: So, we'll probably want you to attend the meeting where it's discussed, or be prepared for a lively mailing list discussion, but please do.
[20:35] <otto> ok
[20:35] <infinity> otto: Like I said, I think that if someone (you?) is willing to commit to doing the updates and testing them, we'll all be happy to grant it based on the fact that MySQL already has an MRE, and the codebases are nearly identical.
[20:35] <infinity> psusi: I might have.
[20:36] <infinity> psusi: So, yeah, working on util-linux this coming week is bubbling up to "very important".  LaMont and I have had a few chats about it, and I'll let you know where things go.
[20:36] <psusi> infinity, wondering how you're doing on util-linux... it has been a month now since I forwarded a query about it to you... some other debian devs were starting to say debian-qa maybe needs to step in to get it updated
[20:37] <infinity> People sure are happy to talk about hijacking a package when it doesn't meet their version number fetish, yes.
[20:37] <psusi> ok.. I'm thinking if you can't get to it in the coming week we really will need to fall back to my version
[20:37] <infinity> It's being worked on.
[20:38] <psusi> it's several years out of date and it's been "update in progress" for a few months now ;)
[20:38] <infinity> Yeah, I know.
[20:39] <infinity> It's just demoralising to have people jump down your throat with every NMU, as if it's a reflection on your worth as a human being. :P
[20:39] <infinity> psusi: Anyhow, I want to get it into jessie in a sane state, and into utopic ASAP, so I'll get cracking this week and keep you posted on progress.
[20:40] <psusi> ok, sounds good
[20:41] <infinity> This NEW processing would go faster if I didn't feel the need to fix every FTBFS I notice along the way.
[20:43] <infinity> pitti: Do you not need a transitional package for systemd-services?  Or are you doing a C/P/R forced removal trick and updating deps?
[20:43] <pitti> infinity: the latter
[20:44] <pitti> infinity: if nothing else, libpam-systemd's changed deps will force the transition already
[20:44] <pitti> as it's not a top-level package
[20:44] <pitti> infinity: I tested this a fair number of times and it worked well
[20:44] <infinity> pitti: Oh, there's the C/P/R at the end of the changelog.  I didn't read far enough.
[20:45] <infinity> pitti: I'm assuming you can get that into Debian too, since it's harmless cruft to carry there.
[20:45] <pitti> infinity: yeah, will try tomorrow
[20:45] <pitti> infinity: we just uploaded 204-9 to Debian which has a lot of our changes, and some others are obsolete
[20:46] <pitti> infinity: I'm currently doing another merge (which should cut down our delta by 2/3 or more :) )
[20:46] <infinity> pitti: \o/
[20:47] <infinity> pitti: While you're in there, care to write cgroups support for FreeBSD and port systemd?  Thanks.
[20:47]  * infinity isn't bitter, though.
[20:47] <pitti> infinity: and what shall I do in the afternoon?
[20:48] <infinity> pitti: The HURD port, of course.
[21:21] <xnox> infinity: well, before util-linux is updated i should double check that d-i is compatible with it first.
[21:22] <xnox> infinity: my fetish is however is more towards reviewing apw's initramfs tools merge ;-)
=== Ursinha is now known as Ursinha-afk
[21:23] <xnox> pitti: what about pulling in 204 stable patch series? is that still planned to happen or should i start the repo to get those included?
[21:23] <pitti> xnox: ah, we can do that
[21:23] <pitti> it's also fairly easy now
[21:23] <xnox> pitti: into debian&ubuntu or just ubuntu?
[21:24] <pitti> xnox: please don't start on a branch right now; I'm in the middle of a rebase-of-doom against 204-9, this time with a proper public ubuntu branch in the debian git
[21:24] <pitti> xnox: probably both (but tomorrow, getting late)
[21:24] <xnox> pitti: cool! will wait after that.
[21:24] <pitti> gbp-pq is awesome
[21:25] <xnox> pitti: also "re: should the shim stay" -> i thought that stgraber was mentioning that cgmanager for 208 logind compat level is getthing there. Thus we'd want to keep shim for now, on linux.
[21:25] <xnox> pitti: cjwatson has convinced me that "git-dpm" is far superior than gbp-pq.
[21:25] <pitti> xnox: yes, I know -- I thought the plan was to teach shim about the systmed d-bus calls to create cgroups
[21:26] <xnox> pitti: cool, i was seeing some agenda items for the debian-systemd sprint that looked a bit inconclusive.
[21:27]  * xnox goes back to untagling transitions
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
[21:41] <xnox> Laney: stole a trivial merge of muffin from you, to unblock cogl20 transition.
[21:48] <pitti> xnox: yay :) http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=shortlog;h=refs/heads/ubuntu
[21:48] <pitti> (still WIP)
[21:48] <xnox> pitti: =))))) keep going.
[21:49] <xnox> pitti: maybe i should start trying out systemd ;-)
[22:15] <psusi> what was the timeframe on the systemd transition again?  we going for it in unicorn?
[22:25] <xnox> psusi: when it's ready.
[22:26] <psusi> so trying for unicorn, but maybe not?
[22:26] <xnox> psusi: it should be available for testing soon in unicorn. no estimates when it will be the default.
[22:27] <psusi> is it going to be in the initramfs?
[22:27] <pitti> I see no reason why it sohuld be
[22:27] <pitti> it's making stuff unnecessarily slow and complicated
[22:28] <psusi> hrm... maybe we can finally get around to fixing the issues with degraded or stacked mdadm/lvm/crypt
[22:28] <psusi> oops, I misread that
[22:28] <pitti> we still have the workaround for bug 1185394
[22:28] <ubottu> bug 1185394 in systemd (Ubuntu) "systemd-udev fails when processing many logical volumes on boot" [High,Fix released] https://launchpad.net/bugs/1185394
[22:29] <pitti> but I think I've seen some Debian bugs / LVM improvements which fixes that more properly than having to settle udev in initramfs with LVM
[22:29] <xnox> psusi: stacked/degraded mdadm/lvm/crypt is not solved in systemd yet either on debian. work with debian folks to sort it out. that would be appreciated.
[22:30] <psusi> well that's why I asked if it was planned to go in the initramfs or not
[22:30] <psusi> if so, it should be possible to use it to sort those issues out that the current scripts have
[22:31] <pitti> it would only make things worse
[22:31] <psusi> say... how about plymouth?  is that going to fit into the systemd picture?
[22:31] <pitti> because then you'd have to restart systemd as well, to use the one from the root fs after initramfs is finished
[22:31] <pitti> yes, the integration needs to be re-done
[22:31] <pitti> ATM, if you boot with systemd it doesn't use plymouth at all
[22:31] <psusi> yea... we had planned on making upstart be able to do that for that reason.. I thoguht systemd was already capable of that?
[22:32] <psusi> what is upstream systemd's solution to that problem?  do they just ignore the issue?
[22:32] <pitti> re-exec itself with keeping state? maybe
[22:32] <infinity> dracut supports initrd with and without systemd.  systemd devs recomment it's in your initrd, sane people recommend against, take your pick.
[22:33] <psusi> that problem being multiplexing boot services interacting with the console
[22:33] <infinity> I'd prefer not, personally, but making initramfs-tools support both modes so people don't make me switch to dracut might also be a decent plan.
[22:34] <infinity> And, IIRC, systemd's "reexec" left something to be desired, I remember a longstanding bug about Fedora systems booted with systemd-in-initrd having open files from boot to shutdown and unclean umounts at shutdown every time.
[22:34] <infinity> But maybe they finally fixed that.
[22:35]  * pitti waves good night
[22:35] <psusi> how do they deal with boot service console interaction?
[22:35] <psusi> if they don't use plymouth?
[22:35] <infinity> They use plymouth, AFAIK...
[22:36] <psusi> ohh, cool
[22:36] <psusi> figured they wouldn't be using something that came from ubuntu ;)
[22:37] <infinity> It didn't come from Ubuntu.
[22:37] <psusi> huh?  yea it did... Scott James Remnant wrote it?
[22:37] <psusi> didn't he?
[22:37] <infinity> Really not.
[22:37] <infinity> Plymouth came from Fedora.
[22:37] <infinity> They had it a year or two before us.
[22:37] <psusi> I could have *sworn* SJR wrote it
[22:38] <infinity> Perhaps you're thinking of usplash, written by mjg59 and others, and replaced by plymouth.
[22:40] <xnox> infinity: can you hint boost-defaults and kdepim together?
[22:40] <xnox> infinity: or am i missing something else for the two to migrate?
[22:40] <infinity> xnox: Is the autohinter not doing that itself?
[22:40] <xnox> infinity: nope.
[22:41]  * infinity tries an easy hint, then.
[22:41] <infinity> Odds are they're caught in another transition.
[22:42] <xnox> infinity: last time Laney did "easy kdepim/4:4.11.2-0ubuntu2 boost-defaults/1.54.0.1ubuntu1" for me
[22:43] <xnox> infinity: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/472
[22:43] <infinity> xnox: Yes, I know how to do it. :P
[22:43] <infinity> xnox: (It's already committed)
[22:44] <xnox> infinity: thanks. just a reference that for some reason autohinter doesn't find it.
[22:44] <infinity> xnox: It could be because it's also caught up with openjpeg?
[22:45] <xnox> infinity: and librtmp1 as well..... i'm sorting out rtmp1 at the moment. didn't look at openjpeg yet.
[22:45] <infinity> And rtmpdump...
[22:45] <xnox> infinity: should have migrated boost-defaults & kdepim pre-freeze.
[22:45] <infinity> So, yeah.  You might be jumping the gun on thinking a hint is necessary. :P
[22:46] <infinity> xnox: It'll shake out.  What's the rush?
[22:46] <infinity> xnox: Did you not read my email about relaxing while the buildds catch up? :)
[22:46] <xnox> infinity: people who use utopic, without proposed, will get boost1.54 - not 1.55 by default.
[22:46] <infinity> xnox: So?
[22:47] <xnox> infinity: i don't know how to relax after a dormant week? =)
[22:47] <infinity> xnox: People who upload to utopic will build against 1.55
[22:47] <infinity> xnox: People running utopic will get things as they transition, which is fine.
=== Ursinha-afk is now known as Ursinha
[23:08] <xnox> infinity: success ;-) final: boost-defaults,kdepim
[23:10] <mdeslaur> xnox: "* No change rebuild against $2."
[23:10] <mdeslaur> xnox: that was cheap :)
[23:10] <xnox> mdeslaur: darn.
[23:11] <xnox> mdeslaur: which uploads?
[23:11] <mdeslaur> gst-plugins-bad1.0 and a few others
[23:11] <infinity> xnox: You don't read your .changes before you upload?
[23:11] <infinity> Or, like, debdiff to make sure your automation isn't crack?
[23:11] <mdeslaur> well, maybe just the gst-* two
[23:12] <mdeslaur> xnox: I suggest bribing at least $5 next time :)
[23:12] <xnox> mdeslaur: =))))
[23:12] <xnox> mdeslaur: yeah just those two. i did fix up the rest.
[23:13] <xnox> infinity: i do read them, but obviously over-skimmed.
[23:13] <xnox> mdeslaur: oh, any opinion on fake-syncing mariadb .37 security release?
[23:13] <xnox> mdeslaur: (similarish to mysql security update)
[23:14] <infinity> Uhh, fakesyncing?  What?
[23:14] <infinity> No.
[23:14] <infinity> There's a proper way to do this, and that's not it.
[23:15] <xnox> infinity: using the term from security-team docs -> called a 'security fake sync'
[23:15] <infinity> xnox: That's not the right thing in this case.
[23:15] <infinity> xnox: Because we don't want to keep pulling in Debian packaging changes through a 5 year LTS.
[23:16] <infinity> xnox: The right way is the same way that MySQL is done, update the tarball and changelog, and not much else.
[23:16] <mdeslaur> yes, what infinity said
[23:16] <xnox> infinity: oh, right. i'm thinking one-time only, not long term. Once mariadb is actually part of stable release in debian, and after that only take if debian security does DSA.
[23:17] <xnox> infinity: mdeslaur: or are you actually proposing to support universe mariadb for 5 years...
[23:17] <infinity> xnox: otto wasn't looking for one-time only.
[23:17] <infinity> xnox: If he wants it updated for today's CVEs, he wasn't the same for the next set. :P
[23:17] <xnox> s/wasn't/wants/
[23:17] <xnox> ack.
[23:18] <infinity> xnox: So, no, *we* (Canonical, and their security team) won't be supporting maria, but if otto wants to, that's how.
[23:18] <xnox> yeah, smells more like MRE indeed then.
[23:18] <mdeslaur> xnox: it needs to get done just like everything else gets done...in this case, he needs to get a couple of updates sponsored by the security team, and then can apply for a MRE
[23:18] <mdeslaur> so he needs to file a bug, propose some updated packages that only touch the tarball, etc.
[23:19] <mdeslaur> if that goes well for a couple of releases, he can get an MRE and then do non-security updates too
[23:35] <xnox> =( gccxml