[07:34] <plashenkov> infinity: Hello, Adam! Could you please tell when https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1574693 will be available in updates?
[08:39] <jamespage> please could a member of the SRU team look at https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1585660
[08:40] <jamespage> I really want to get the latest point release into Xenial before we get to many people using the 10.2.0 from release ...
[09:14] <infinity> plashenkov: Now.
[09:23] <tsimonq2> infinity: thanks a lot for getting those fixes approved, that splash screen one has been annoying ;)
[09:23] <tsimonq2> (teh bug, not the fix)
[10:37] <Trevinho> pitti: hey, could you check the SRU packages that are waiting in SRU queue as per ticket https://requests.ci-train.ubuntu.com/#/ticket/1614 ?
[11:11] <pitti> Trevinho: can you please try to ping some other SRU team members today? I've been doing pretty much all the SRU work recently, and it's taking up too much time, to be brutally honest
[11:12] <pitti> (or I might do some stuff in the evening, but please start with the roster at https://wiki.ubuntu.com/StableReleaseUpdates#Publishing)
[11:19] <Trevinho> pitti: yeah, I undestand... Thanks
[11:21] <Trevinho> bdmurray: hey, can you check the SRU queue for unity7 stack? It's quite important for .1. Changes are in ticket https://requests.ci-train.ubuntu.com/#/ticket/1614
[13:48] <sergiusens> slangasek pitti our snapcraft adt tests on yakkety are being hit by https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 is there a way to tag/comment on update_excuses about this and let it in?
[13:49] <pitti> sergiusens: technically yes, but we don't actually know yet what is broken
[13:50] <pitti> sergiusens: 2.0.2's tests still succeed, and there has not been any investigation yet whether it's the tests that regressed or snapd itself
[13:50] <pitti> and the error suggests the latter, i. e. we should not let a broken version in
[13:50] <sergiusens> pitti yeah, I am sad to be affected by taking the extra mile wrt testing :-P
[13:51] <sergiusens> pitti oh, I don't want snapd in, just snapcraft, one of the adt tests fail on a part of the test where we `snap install/remove`
[13:52] <pitti> sergiusens: oh! so this actually confirms that bug 1599799 is not a test issue, but an actual bug
[13:53] <pitti> sergiusens: OTP, back in 10
[13:53] <pitti> sergiusens: will hint that
[13:55] <pitti> sergiusens: done
[14:03] <sergiusens> thanks
[14:13] <jbicha> infinity: if you're doing sru work today, could you look into accepting drupal7 from unapproved?
[14:29] <apw> jbicha, i believe he is travelling
[14:30] <jbicha> oh, makes sense
[14:30]  * apw hands pitti a gold star to put on ADTs wall
[14:30] <pitti> sergiusens: it landed
[14:30] <pitti> apw: oh, thanks :)
[14:31] <xnox> rtg, thank you! you are amazing =)
[14:32] <rtg> xnox, for what ?
[14:32] <pitti> is it "say thanks to the developer next to you" day or something such? :-)
[14:36] <xnox> rtg, for linux bug updates about qeth driver removal.
[14:37] <davmor2> apw: don't flash shiny things in front of pitti he won't be able to concentrate on anything else for the rest of the day
[14:37] <rtg> xnox, I just did 'qeth: delete napi struct when removing a qeth device'. Is that what you are talking about ?
[14:38] <xnox> yeah =)
[14:38] <pitti> davmor2: you mean like that big yellow hot plasma ball on the sky that has been burning my brains for two weeks now? :-)_
[14:40]  * davmor2 looks outside nope nothing but grey up there I think pitti is obviously at an amusement park and not working at all
[14:41] <pitti> davmor2: I see my prejudices about British weather confirmed :)
[14:45] <ogra_> pitti, the german weather isnt better ...  northern of the weisswurstgrenze at least
[14:45] <davmor2> pitti: http://dailypicksandflicks.com/wp-content/uploads/2012/06/In-the-Bible-it-rained-for-40-days-they-called-it-a-disaster.-In-England-we-call-it-summer..jpg
[14:46] <ogra_> you are just lucky to have that little hole in the clouds sitting above you for a few more hours
[15:36] <davmor2> pitti: https://www.youtube.com/watch?v=r35NSTwOxw4 head for about 2 minutes in :)
[17:32] <bdmurray> Trevinho: so bamf, compiz, libunity, nux, unity, unity-control-center, and unity-lens-applications in the xenial queue?
[17:35] <bdmurray> Trevinho: oh its in the ticket to which you linked
[17:51] <sergiusens> bdmurray mind letting snapcraft into xenial-proposed while at it?
[17:59] <bdmurray> sergiusens: I'll add it to the list
[18:02] <sergiusens> bdmurray ty
[18:36] <bdmurray> Trevinho: bug 1304388 is missing proper SRU information, I'll still let unity-control-center in but would like to see the bug fixed up.
[18:39] <jbicha> bdmurray: if you have time today, could you look into letting drupal7 in for xenial?
[18:41] <jbicha> to be more specific, drupal7 is already in -proposed but I uploaded a new version a few weeks ago with an extra dependency it needs
[20:02] <slangasek> vsearch excuses make no sense; vsearch-data isn't listed in the source package for vsearch in -proposed, it's only present in the yakkety version.  what's going on? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vsearch
[20:05] <nacc_> slangasek: maybe i've always misinterpreted that style of output, but i thought it meant there was a binary package in 1.1.3+dfgs-1 but that is no longer present in 2.0.0-1?
[20:07] <slangasek> nacc_: that should certainly not be the meaning; it's valid for a new version of a source package to drop a binary package, it's only an error if a) the dropped binary package is still present in -proposed at an older version, or b) the maintainer did something wrong in debian/control to imply the package *should* still be built but isn't being built
[20:09] <slangasek> in this case I'll trick proposed-migration by removing vsearch-data early from yakkety, since it has no revdeps
[20:09] <slangasek> but that should not be required
[20:09] <nacc_> slangasek: hrm, your points make sense to me, I've just only seen it for cases like I described -- i defer to your knowledge in this case :)
[20:10] <slangasek> there are other weird things in update_output that I think I need a pitti to help diagnose
[20:31] <slangasek> pitti: ignoring test failures on s390x for something as critical as nova is a false optimization; please escalate this issue to xnox instead of overriding
[20:34] <slangasek> ah, so vsearch has a test dep on vsearch-data, I wonder if that could be it
[23:18] <xnox> slangasek, pitti - wait what where how?
[23:18] <xnox> we are like telling a few people that it is all good and dandy.
[23:18] <xnox> (nova and openstack in general)
[23:18] <slangasek> xnox: nova autopkgtests are flaky (at best) on s390x
[23:19] <slangasek> xnox: so, please fix so that pitti doesn't ignore failures ;)
[23:20] <xnox> i wonder if they are there because of lxd vs kvm runner.
[23:20] <xnox> or because they are indeed flaky
[23:20] <slangasek> they have sometimes succeeded
[23:21] <xnox> not tonight however, as i am about to hit the bed, and only got distracted by the l1cc email =)
[23:21] <xnox> (which imho i should have written whilst in cape town)


[03:24] -queuebot:#ubuntu-release- Unapproved: pikopixel.app (cosmic-proposed/universe) [1.0-b9c-1 => 1.0-b9d-1] (no packageset) (sync)
[03:27] -queuebot:#ubuntu-release- Unapproved: javabeans-activation-framework (cosmic-proposed/universe) [1.2.0-1ubuntu1 => 1.2.0-2] (no packageset) (sync)
[03:27] -queuebot:#ubuntu-release- Unapproved: accepted javabeans-activation-framework [sync] (cosmic-proposed) [1.2.0-2]
[07:15] -queuebot:#ubuntu-release- Unapproved: fflas-ffpack (cosmic-proposed/universe) [2.3.2-2 => 2.3.2-3] (no packageset) (sync)
[07:15] -queuebot:#ubuntu-release- Unapproved: accepted fflas-ffpack [sync] (cosmic-proposed) [2.3.2-3]
[11:15] -queuebot:#ubuntu-release- Unapproved: cups-filters (cosmic-proposed/main) [1.21.2-1 => 1.21.3-1] (desktop-core, ubuntu-server) (sync)
[13:14] -queuebot:#ubuntu-release- Unapproved: meta-gnome3 (cosmic-proposed/universe) [1:3.22+9 => 1:3.22+10] (no packageset) (sync)
[13:14] -queuebot:#ubuntu-release- Unapproved: accepted meta-gnome3 [sync] (cosmic-proposed) [1:3.22+10]
[13:15] -queuebot:#ubuntu-release- Unapproved: sword (cosmic-proposed/universe) [1.7.3+dfsg-9.1build2 => <IP_ADDRESS>+dfsg-2] (no packageset) (sync)
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted sword [sync] (cosmic-proposed) [<IP_ADDRESS>+dfsg-2]
[13:23] -queuebot:#ubuntu-release- Unapproved: anki (bionic-proposed/universe) [2.1.0+dfsg~b36-1 => 2.1.0+dfsg~b36-1ubuntu0.1] (no packageset)
[14:20] -queuebot:#ubuntu-release- Unapproved: linux-meta (cosmic-proposed/main) [<IP_ADDRESS>.9 => <IP_ADDRESS>.10] (core, kernel) (sync)
[14:20] -queuebot:#ubuntu-release- Unapproved: linux (cosmic-proposed/main) [4.18.0-8.9 => 4.18.0-9.10] (core, kernel) (sync)
[14:20] -queuebot:#ubuntu-release- Unapproved: linux-signed (cosmic-proposed/main) [4.18.0-8.9 => 4.18.0-9.10] (core, kernel) (sync)
[14:58] -queuebot:#ubuntu-release- Unapproved: pikopixel.app (cosmic-proposed/universe) [1.0-b9c-1 => 1.0-b9d-1] (no packageset) (sync)
[18:05] -queuebot:#ubuntu-release- Unapproved: spectre-meltdown-checker (cosmic-proposed/universe) [0.39-1 => 0.40-1] (no packageset) (sync)
[18:05] -queuebot:#ubuntu-release- Unapproved: accepted spectre-meltdown-checker [sync] (cosmic-proposed) [0.40-1]
[20:39] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-controls (cosmic-proposed/universe) [1.5 => 1.6] (ubuntustudio)
[20:54] -queuebot:#ubuntu-release- New source: trojita (cosmic-proposed/primary) [0.7-0ubuntu1]
[21:17] -queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (cosmic-proposed/universe) [1.15 => 1.16] (lubuntu)
[21:21] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (cosmic-proposed/universe) [1.7.6 => <IP_ADDRESS>] (ubuntukylin)
[21:24] <wxl> vorlon: tsimonq2 just uploaded trojita for lubuntu. if you could review that, i'd greatly appreciate it.
[21:32] -queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [21 => 22] (lubuntu)
[21:38] -queuebot:#ubuntu-release- Unapproved: lxqt-config (cosmic-proposed/universe) [0.13.0-0ubuntu4 => 0.13.0-0ubuntu5] (lubuntu)
[22:01] -queuebot:#ubuntu-release- Unapproved: nm-tray (cosmic-proposed/universe) [0.4.0-0ubuntu3 => 0.4.1-0ubuntu1] (lubuntu)
[22:27] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (cosmic-proposed/universe) [18.04.0 => 18.10.1] (ubuntukylin)
[22:37] -queuebot:#ubuntu-release- Unapproved: libfm-qt (cosmic-proposed/universe) [0.13.1-5ubuntu4 => 0.13.1-5ubuntu5] (lubuntu)
[22:52] -queuebot:#ubuntu-release- Unapproved: node-tap (bionic-proposed/universe) [11.0.0+ds1-2 => 11.0.0+ds1-2ubuntu0.1] (no packageset)
[23:13] -queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.12 => 1.13] (lubuntu)


[06:40] <dholbach> good morning
[06:41] <vlad205> good morning
[06:58] <geser> good morning
[06:59]  * iulian waves.
[08:51] <pipedream> help.ubuntu.com certificate expired?
[08:51] <pipedream> help.ubuntu.com uses an invalid security certificate.
[08:51] <pipedream> The certificate expired on 17/06/2013 23:08. The current time is 25/06/2013 10:51.
[08:52] <Laney> not here
[08:52] <Laney> 17/06/14
[08:58] <hyperair> it says 18/6/2014 here
[08:58] <hyperair> probably due to timezone differences.
[10:47] <pipedream> help.ubuntu.com working again


[00:57] <stgraber> that one is mine, diff should be fairly straightforward. I mostly noticed the crash on Ubuntu Touch, though I've had reports (by e-mail, no bug report) of it also happening on standard machines that have weird network devices.
[00:57] <stgraber> (and yes, I fixed the patch name in the previous changelog entry because it was bugging me)
[02:31] <infinity> stgraber: Accepted.
[02:31] <stgraber> thanks
[10:59] <didrocks> Laney: I guess the qtsystems-opensource-src is easy (and pinned by the lubuntu discussion we had, I didn't check, but that's what Mirv told in term of rdepends)
[11:05] <Laney> +Forwarded: no
[11:07] <Laney> Mirv: know why that's the case?
[11:08] <didrocks> Laney: when I read the diff, I guess it was because it's an hack
[11:09] <Laney> The kernel part got wontfixed
[11:20] <Mirv> Laney: it got wontfixed, but I'm not sure if it's something that wouldn't be fixed later on since it's clear the driver has stubbed functions.
[11:37] <Laney> Mirv: I think that means we'll end up carrying the patch indefinitely until someone else gets around to fixing it
[11:37] <Laney> I'm worried that we change the specification of the function for everyone unilaterally without seeking upstream's input
[11:38] <Laney> ScottK: thoughts?
[11:38] <Laney> Some kind of whitelist of known-broken devices might be ok
[11:48] <ScottK> Laney: I agree with you.
[11:48] <ScottK> Upstream review should be sought before something like this is done.
[11:50] <ScottK> I'll be offline mostly today, so I can't provide much help.
[11:50] <Mirv> Laney: ok, I'll file an upstream bug about it. there's not much people looking at qtsystems though, so there may not be a quick answer. but we essentially took over qtpim development already, so if we need qtsystems a lot we can start pushing that too.
[11:51] <Laney> Mirv: took over upstream?
[11:52] <Mirv> Laney: wrong wording, but I mean renato from our side has become the only upstream contributor pushing changes at the moment.
[11:52] <Laney> ah
[11:52] <Laney> well, having upstream commit is great and the way things should work
[11:53] <Laney> Mainly I think changing behaviour in Ubuntu-specific ways indefinitely is a bad idea
[11:58] <Laney> Mirv: Could you check if it's feasible to do the whitelist?
[11:58] <Laney> QtSystems has API to get the device at least
[11:58] <Laney> (Not sure if it works in this case though)
[12:04] <Mirv> Laney: I now proposed the rsalveti's patch as is to upstream and added the links to the packaging branch. rsalveti may comment on the feasibility of the whitelisting.
[12:04] <Mirv> so both filed a bug https://bugreports.qt-project.org/browse/QTBUG-33748 and a branch fixing it
[12:04] <Laney> Mirv: thanks
[12:21] <Mirv> those ido + indicators miscellaneous small fixes ^ tested by me on desktop (autopilot unity7 + manual tinkering with the indicators) and psivaa on touch
[13:42] <stgraber> oh looks like the queue grew quite a bit overnight, I'll finish to deal with something then go through all of those (in 20min-ish)
[13:53] <rsalveti> Mirv: you probably know more about qtsystems internals than me :-) All I gave at that bug was a workaround to disconnect signal from actually knowing if the device is valid
[13:53] <rsalveti> Mirv: we might just ask help from renato then, as he seems the only one changing it lately
[13:54] <rsalveti> whitelist sounds a better idea, but need to check what api to use, and -enotime this week
[14:00] <Laney> what is the point of that libfriends upload?
[14:00]  * Laney asks in The Other Place
[14:12] <diwic> uhm, are we frozen? We usually unfreeze between "Final Beta" and "Final Freeze"
[14:13]  * diwic just uploaded a PulseAudio to fix a few crashes
[14:14] <smartboyhw> diwic, see https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html
[14:14] <apw> diwic, actually we normally are in this half way not frozen but everything gets looked at phase in between
[14:15] <stgraber> diwic: so the dbus part of the upload seems like a feature change to me (removal of dbus support). Can you confirm that nothing in any of our supported images (all flavours) use that module?
[14:15] <cjwatson> diwic: We haven't unfrozen in this phase since at least the quantal release cycle.
[14:16] <cjwatson> Compare e.g. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-April/001030.html
[14:16] <diwic> stgraber, it was not used in 13.04, experimentally enabled in 13.10 because I thought upstream has fixed things, but it still causes crashes.
[14:17] <stgraber> diwic: Based on the changelog it looks like you neabled the module around a month ago, is that right?
[14:17] <diwic> stgraber, so no, I can't give you a guarantee, just that I would be surprised of something in our official flavours actually used it.
[14:18] <cjwatson> diwic: IIRC pulseaudio is in touch images; doesn't this need landing approval from the touch people?
[14:18] <diwic> cjwatson, I asked didrocks on friday if it was okay to upload a PulseAudio with stuff that only touches things that we don't make use of on the phone and he said ok
[14:19] <diwic> stgraber, something like that. If you ask me to verify, I would look into the same changelog to do that :-)
[14:19] <didrocks> yeah, it was okay (and it's still)
[14:20] <cjwatson> diwic: OK, cool
[14:20]  * cjwatson lets stgraber carry on reviewing ...
[14:20] <stgraber> ok, so based on the limited time in the archive (so unlikely that anyone actually noticed and made use of it) and the fact that it's causing a segfault in some cases, I'm granting an FFe on that and will let it through
[14:20] <diwic> stgraber, ok, do I need to do any paperwork for the FFe?
[14:21] <stgraber> diwic: nope, paperwork is the past 10 lines of IRC log
[14:21] <diwic> stgraber, ok, thanks :-)
[14:22] <stgraber> ^ what happened there? :)
[14:24] <Riddell> stgraber: my scripts got ahead of themselves, it's not released upstream yet
[14:24] <stgraber> Riddell: ok :)
[14:24] <Laney> stgraber: btw I queried the libfriends upload, maybe leave that one for now
[14:25] <stgraber> Laney: ok, will do
[14:25] <Laney> (appears to do nothing)
[14:25] <stgraber> seb128: is the Uploaders change intentional in that gtk upload?
[14:25] <diwic> the "Unpacking replacement friends ..." line in my log was slightly amusing. :-)
[14:25] <Laney> stgraber: that is automatic
[14:26] <stgraber> Laney: ah? does it somehow sync that with Debian when generating the source package?
[14:26] <seb128> stgraber, that's control.in->control from the pkg-gnome tools
[14:26] <cjwatson> It's an intersection of a list in pkg-gnome-tools with the last N entries in the changelog, IIRC
[14:26] <seb128> stgraber, it builds the upload list from the changelog most recent entries
[14:26] <Laney> It takes the last x uploaders and intersec
[14:26] <Laney> yeah
[14:26] <stgraber> ah, interesting, ok.
[14:28] <Laney> Mirv: looks like QtSystems can't give you the model on N4
[14:31] <stgraber> hmm, weird that click didn't get auto-accepted, let me quickly check why
[14:31] <stgraber> ok, that's because it's in ubuntu: supported (and as a result in the packageset), alright, waiving through
[14:32] <Laney> there's 10-ish outstanding FFes too
[14:33] <seb128> Laney, it reads the model from /sys/devices/virtual/dmi/id/product_name ... is that available on the n4?
[14:33] <Laney> seb128: nope
[14:34] <seb128> Laney, then it should fallback to libhybris
[14:34] <cjwatson> stgraber: thanks
[14:34] <seb128> Laney, getprop ro.product.model
[14:34] <Laney> seb128: in qtsystems itself?
[14:35] <seb128> Laney, no, u-s-s
[14:35] <Laney> not talking about that
[14:35] <seb128> oh, ok
[14:35] <seb128> sorry, ignore me then
[14:35] <Laney> :P
[14:35] <seb128> qtsystems only knows to read /sys/devices/virtual/dmi/id/product_name
[14:35] <seb128> Laney, that's https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1197542
[14:36] <seb128> Laney, see comment #10 there
[14:36] <stgraber> looking at all those indicator related uploads now
[14:36]  * Laney nods
[14:36] <Laney> so I don't know if this whitelist idea can be implemented in qtsystems
[14:37] <seb128> Laney, I didn't follow the discussion, what's the whitelist for?
[14:38] <Laney> seb128: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1231196
[14:38] <Laney> it got accepted anyway (should have rejected if I wanted to block it)
[14:38] <seb128> ok
[14:47] <stgraber> and back to an empty queue!
[14:48] <Laney> nice
[14:49] <Laney> Riddell: bug #1222128 might interest you
[14:49] <Laney> (the bot has been irritatingly broken for ages)
[14:50] <Riddell> 15:50 < ubottu> bug 1222128 in Ubuntu "[FFe] [needs-packaging] kqoauth" [Wishlist,New] https://launchpad.net/bugs/1222128
[15:15] <czajkowski> slangasek: ello :)
[15:16] <slangasek> czajkowski: hey there
[15:16] <Laney> I imagine someone other than me would be more qualified to look at http://pad.lv/1218530
[15:22] <slangasek> Laney: ok, done
[15:22] <Laney> ta
[15:27] <czajkowski> slangasek: re the workspace not working and it was last week and now no longer isn't the regression tag a useful tag ?
[15:27] <slangasek> czajkowski: that tag is for regressions in stable updates
[15:28] <czajkowski> ahh
[15:28] <czajkowski> ok
[15:28] <czajkowski> thanks for clearing it up
[15:29] <slangasek> not that your bug shouldn't be fixed, but the SRU team doesn't want to receive bug mail about it ;)
[15:30] <czajkowski> slangasek: good to know :)
[17:58] <stgraber> seb128: what happened to that poor evolution-data-server changelog?
[17:58] <stgraber> (if that's even you who uploaded that one, the diff is pretty confusing ;))
[18:00] <stgraber> Riddell: hmm, that user-manager upload looks like it has new features...
[18:01] <stgraber> Riddell: (if you say it doesn't, I'll read much closer but added dependencies and a bunch of new files isn't usually a very good sign)
[18:02] <infinity> stgraber: That eds looks like an almost-sync-but-not-quite.
[18:03] <infinity> Diff looks fine but, yeah, losing all the Ubuntu history/context in the changelog is a bit irksome.
[18:03] <stgraber> infinity: yeah, looked like a sync at first but not quite, I guess I should pull the resulting changelog to see what's the end result :)
[18:04] <stgraber> it also does say "sync with Debian" and then "remaining changes" which to me sounds wrong, that's a merge and a merge should keep the changelog history (merge-changelog is usually pretty good at that so why not use it...)
[18:06] <infinity> Wait, there's a tool for that?  I always do it by hand when MoM can't do it for me.
[18:10] <stgraber> merge-changelog 1 2 > 3 :)
[18:10] <infinity> Does someone still have a hardy chroot kicking around?
[18:12] <infinity> Oh, nevermind.  I was going to ask if tar's compression autodetection works in hardy, but that was apparently added in 2004...
[18:19] <pleia2> infinity: heads up, http://www.ubuntu.com/community/participate included in release announcements is a 404, I submitted a bug to have them redirect to community.ubuntu.com (it's private, I can sub you if you'd like)
[18:21] <stgraber> pleia2: why is it private?
[18:21] <stgraber> (I don't really care about the bug, just wondeirng why a bug about an existing problem on a public website is private)
[18:21] <infinity> pleia2: Oh, fun.  It should perhaps redirect to http://community.ubuntu.com/contribute/
[18:21] <infinity> Maybe.
[18:22] <pleia2> stgraber: all website content bugs are by default
[18:22] <infinity> Or maybe just to the root.
[18:22] <infinity> I don't remember what was on the old page.
[18:22] <infinity> Yeah, probably best to send it to /contribute/
[18:23] <stgraber> pleia2: that seems wrong, but ok...
[18:24] <balloons> does anyone have an insight on who is doing signoff for the server images?
[18:24] <infinity> balloons: I did for the beta, but we probably want someone from the server team to do it for final.
[18:24] <infinity> rbasak: ^
[18:25] <balloons> infinity, I figured it was you :-) I was hitting a dead end on trying to track someone from the server team down who knew enough to handle this.
[18:26] <infinity> balloons: Well, we could escalate all the way to robbiew if we can't find anyone to take responsibility, but let's see if rbasak responds first. :P
[18:28] <seb128> stgraber, what's wrong with it?
[18:28] <infinity> seb128: It dropped all the Ubuntu changelog entries.
[18:28] <seb128> yeah, we never keep old changelog entries when merging desktop packages
[18:29] <seb128> it's annoying to merge back, it wastes space and it's not useful
[18:29] <seb128> we have launchpad for a record of uploads
[18:29] <seb128> think about it as a direct sync and then, oh, we have a diff again there ;-)
[18:30] <seb128> infinity, stgraber: jbicha has a "sync on debian" stacked in the vcs so I included that rather than having to play revert (the actual diff out of the changelog is quite small)
[18:36] <infinity> It loses history if one wants to know when something was changed.  Digging through all revisions on LP is a pain.
[18:37] <apw> did we say there was a handy tool for the merge
[18:37] <infinity> apw: merge-changelog, apparently.
[18:38] <apw> oh yeah thats the baby, seems to be pretty simple
[18:38] <seb128> infinity, so what do you do when a package can be synced and then has ubuntu diff again?
[18:38] <seb128> infinity, do you go add back all the previous ubuntu diff history to the changelog?
[18:38] <infinity> seb128: That's different.  If it can be synced, one assumes that the Ubuntu bits have ended up in Debian, thus are represented in the Debian changelog.
[18:38] <seb128> well, they are represented in the merge summary the same way they would be in a debian changelog entry
[18:38] <infinity> (including some sort of attribution, perhaps, which one loses if you remove history)
[18:39] <seb128> well, anyway, we have been dropping changelog history consistently for desktop stuff for over 9 years
[18:39] <stgraber> seb128: I don't think your merge summary contains the name of who added the individual bits and when those were introduced, and it turns out it's pretty useful information when debugging stuff
[18:39] <seb128> ^
[18:39] <seb128> that's what we do accross desktop for ever
[18:40] <seb128> you liking it or not doesn't seem a release team topic
[18:40] <seb128> if you want us to change that go to the TB
[18:40] <stgraber> doesn't necessairly make it right ;)
[18:40] <seb128> (sorry, not wanting to be harsh, just trying to not start an endless argument on who prefers what)
[18:40] <seb128> sure
[18:40] <seb128> but let's agree to disagree
[18:40] <seb128> if you care enough, take it to the TB
[18:40] <rbasak> infinity, balloons: I'll raise it in the server team irc meeting tomorrow. Thanks for asking - it'll be nice to have someone lined up and scheduled to do it rather than a last minute scramble to find someone.
[18:41] <stgraber> and have the TB say what? please respect the existing procedures on merges? because I'm pretty sure what infinity and I are saying is what's been documented for ages as the procedure to make merges
[18:41] <stgraber> we've even wrote tools to do just that ;)
[18:41] <rbasak> I wonder how we could make sure that someone is nominated each release for this without you having to chase.
[18:41] <balloons> rbasak, if you can, please let me know who you pick
[18:41] <rbasak> balloons: will do.
[18:41] <infinity> rbasak: Well, it would have been fine if the person who "owned" the product hadn't quit. :P
[18:42] <seb128> stgraber, recommended != required
[18:42] <stgraber> rbasak: so we have a sign-off contact entered next to the product name on the tracker. If you let me know ahead of time I can update the field to reflect reality
[18:42] <rbasak> OK - thanks!
[18:42] <balloons> rbasak, infinity yes, basically we need someone to take over the reins from Daviey on this one :-)
[18:42] <seb128> stgraber, that's a pretty stupid rule imho, because as said, sync loose changelog history anyway and we have full history in launchpad in any case
[18:43] <infinity> seb128: It's not worth arguing about.  My biggest concern is actually just attribution, nothing else.  A sync should retain attribution because the Debian maintainer should mention the patch contributor when he takes the patch.
[18:43] <infinity> seb128: A merge without history makes it look like the last uploader "owns" all the modifications.
[18:44] <infinity> (Proper DEP-3 headers in patches fixes that, but not everyone uses quilt, and not everyone uses proper headers when they do use quilt)
[18:44] <seb128> infinity, would you be happy if we put the author in the merge summary?
[18:44] <infinity> seb128: Or in the patches, if you're doing quilty things (and maybe you already do that religiously).  In which case, meh.  Lost history is annoying, but not world-ending.
[18:45] <infinity> Either way, this isn't worth having a debate about on a Monday.
[18:45] <infinity> Cause, well.  Monday.
[18:45] <infinity> Screw Monday.
[18:45] <seb128> infinity, we tend to do tag patches yes, and as said, launchpad has the history
[18:45] <seb128> -changes lists as well
[18:46] <infinity> LP's history isn't meaningful for someone who downloads a source package.  But properly tagged patches works for me for the blame/attribution game.
[18:46] <seb128> infinity, we have vcses for history as well
[18:47] <seb128> or bzr blame
[20:48] <rsalveti> can someone approve libhybris? adding another functional call needed by gstreamer to fix an issue with playbin/platform-api in touch
[20:48] <stgraber> I'll take a look
[20:49] <rsalveti> thanks
[20:49] <stgraber> done
[21:10] <rsalveti> thanks
[22:36] <cjwatson> infinity: fakeroot/critcl> well spotted
[22:39] <cjwatson> oho, lilypond/i386 stuck to the wall this time
[22:39] <cjwatson> I'm working on a Debian QA upload for kinput2
[22:44]  * infinity is fixing openmpi1.6
[22:45] <infinity> Man, I'd give good money for the new apt-cacher-ng to stop randomly stalling...
[22:46] <infinity> Or maybe I'll just give up on clever caches and run squid on my laptop.
[22:52]  * cjwatson shaves yaks.  Need to QA-upload wnn6-sdk first
[23:03] <infinity> That mpfr4 testsuite hang on armhf isn't making me the happiest of campers.
[23:04] <infinity> 20-to-1 odds say that switching to gcc-4.7 "fixes" it.  And then doko hits me.


[20:56] <pleia2> hopefully the lp poll closes on its own...
[20:56] <pleia2> either way, I won't be around during the meeting, will be on a train going through northern Indiana, and internet access on this trip hasn't been 100% ;)
[22:33] <pleia2> also, instead of the awful self-signed cert, I installed a letsencrypt one for our domain (also emailed Eric to see if he can sort out our currently messed up dns records, www goes to the wrong place...)