[04:38] <cpaelzer> hi, could one of the SRU Team cancel open-iscsi (by smoser) from the Bionic unapproved queue please?
[04:38] <cpaelzer> we want to do some fixup
[04:42] <cpaelzer> infinity: sil2100: ^^ highlighting as i'm seeing your name on for today
[05:39] -queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.2]
[05:46] <slangasek> cpaelzer: ^^ done
[05:46] <cpaelzer> thanks slangasek
[06:43] <acheronuk> slangasek: could I perhaps get an ok for LP: #1791501 ?
[08:59] -queuebot:#ubuntu-release- Unapproved: pcl (bionic-proposed/universe) [1.8.1+dfsg1-2ubuntu2 => 1.8.1+dfsg1-2ubuntu2.18.04.1] (no packageset)
[09:55] -queuebot:#ubuntu-release- New sync: r-cran-mitools (cosmic-proposed/primary) [2.3-1]
[09:59] -queuebot:#ubuntu-release- New sync: r-cran-kmi (cosmic-proposed/primary) [0.5.4-1]
[10:33] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
[12:14] <slashd> o/ sil2100 could you please accept the upload of nginx for Bionic ? (the dependency addition we talked last week)
[12:23] <sil2100> slashd: o/ Looking in a minute!
[12:25] <slashd> sil2100, thanks
[12:32] -queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.1]
[12:34] <slashd> sil2100, thanks again ^
[12:37] <sil2100> yw o/
[15:16] -queuebot:#ubuntu-release- Unapproved: ipxe (bionic-proposed/main) [1.0.0+git-20180124.fbe8c52d-0ubuntu2 => 1.0.0+git-20180124.fbe8c52d-0ubuntu2.1] (ubuntu-desktop, ubuntu-server)
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.26]
[16:44] -queuebot:#ubuntu-release- New binary: gdcm [s390x] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
[16:44] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (trusty-proposed) [2.02~beta2-9ubuntu1.16]
[16:46] -queuebot:#ubuntu-release- New binary: gdcm [ppc64el] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
[17:00] -queuebot:#ubuntu-release- New binary: gdcm [i386] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
[17:29] -queuebot:#ubuntu-release- Unapproved: lxcfs (bionic-proposed/main) [3.0.1-0ubuntu2~18.04.1 => 3.0.2-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
[18:05] <teward> slashd: I forgot I had an autohighlight for 'nginx' in here :|
[18:06] <teward> sil2100: thank you for the assist with the Bionic upload of nginx, and for the FFe for Cosmic.
[18:21] -queuebot:#ubuntu-release- New binary: gdcm [amd64] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
[18:26] <sil2100> teward: yw!
[18:43] <wxl> infinity: looks like the tb needs another re-up? :/
[19:12] <infinity> wxl: Sure does.
[19:12] <wxl> infinity: i'll give you another month then....................
[19:13] -queuebot:#ubuntu-release- Unapproved: lxc (bionic-proposed/main) [3.0.1-0ubuntu1~18.04.2 => 3.0.2-0ubuntu1~18.04.1] (ubuntu-server)
[19:14] <tsimonq2> slangasek: That saods2 failure against libxml2 looks like something you were working with, badtest?
[19:14] <slangasek> saods2 is flaky
[19:14] <slangasek> have you retried?
[19:14] <tsimonq2> ack
[19:14] <tsimonq2> no
[19:17] <acheronuk> infinity or slangasek: if you have a chance, could you maybe ok LP: #1791501 ?
[19:21] <slangasek> can I delegate decisions about Kubuntu-desktop-specific FFes to someone on that team, instead?
[19:25] <acheronuk> slangasek: can you?
[19:25] <slangasek> yes, who wants that responsibility and is trusted by the Kubuntu devs to hold it? :)
[19:28] <acheronuk> slangasek: well, I'm Kubuntu Council and Kubuntu dev, and I hopefully consider the impact of what I request. or if you want someone else, then maybe tsimonq2 ?
[19:29] <acheronuk> s/hopefully/do
[19:30] <infinity> acheronuk: Entirely okay with you and Simon doing it as a committee, so long as you partially recuse yourself when it's a feature you're arguing for.
[19:31] <acheronuk> that seems fair
[19:31] <infinity> acheronuk: But the act of explaining to another human (even one who you're pretty sure will agree) as to why the FFe is needed and what the negative impact might be will tend to lead you both in a sane direction.
[19:31] <acheronuk> indeed
[19:35] -queuebot:#ubuntu-release- Unapproved: lxd (bionic-proposed/main) [3.0.1-0ubuntu1~18.04.1 => 3.0.2-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
[19:37] <acheronuk> ok. I'll double check tsimonq2 is ok with that situation, but assuming he is then I'll take that as the current position. thanks
[19:38] <infinity> acheronuk: Just do remember to not use each other as a rubber stamp, but actually go through the formal process of arguing your case and identifying potential gotchas.
[19:39] <acheronuk> understood
[19:39] <infinity> acheronuk: Don't really care deeply if that's well documented publicly (but FFe bugs are nice for backreference), but the important bit is that you talk about it enough to convince yourself that you're not making version numbers more important than sanity/stability.
[19:40] <infinity> acheronuk: Or, at the very least, that you understand the potential bad and are blocking off time to commit to dealing with it if it all goes sideways. :P
[19:42] <acheronuk> of course
[19:45] <santa_> acheronuk, slangasek: that was in the past the role of the kubuntu release manager i.e. Riddell or am I mistaken?
[19:48] <slangasek> santa_: at various points in time it was handled by Riddell or ScottK, but it was a delegation from the Ubuntu Release Team rather than a result of a particular role within the Kubuntu community alone
[19:48] <tsimonq2> infinity, slangasek: I would argue for the Kubuntu Council to have the permissions, but Rik and I (as a recently elected member) are the only two on the KC with the expertise. I'm fine going through the process, but it will mostly be Rik asking for my signoff because he does most of the KDE-specific work these days. It would be great if you could let Rik sign off on LXQt FFE stuff for me to make
[19:48] <acheronuk> santa_: Riddell was/is at least a core dev and archive admin, as well as perhaps whatever equivalent of release team was then. so I think had fairly blanket autonomy
[19:48] <tsimonq2> it equal. :P
[19:49] <tsimonq2> acheronuk: Right.
[19:50] <acheronuk> that seems a fair balance
[19:50] <tsimonq2> Up to the Release Team though.
[19:50] <tsimonq2> But Qool.
[19:50] <tsimonq2> :P
[19:51] <santa_> slangasek: ack
[19:53] <santa_> tsimonq2: iirc the role of the KC isn't making _technical_ decisions, or am I missing something?
[19:54] <tsimonq2> infinity, slangasek: If it's okay with you both I would like to write something formal and get ratification from the Release Team officially, but I would also like to know if this only applies to FFes or similar freezes like UIFes.
[19:54] <tsimonq2> santa_: Well, which other board do we have?
[19:54] <tsimonq2> The KC is the "catch-all".
[19:54] <tsimonq2> Both of us are in ~kubuntu-dev, so it works out.
[19:55] <santa_> tsimonq2: well, that's not an excuse to give the KC extra powers it shouldn't have
[19:55] <acheronuk> well, I think here it is more important that the release team can delegate to people they see fit, KC or not. the fact that we are both KC is bonus, but not required
[19:55] <santa_> +1
[19:55] <tsimonq2> santa_: The KC is the final catch-all for Kubuntu.
[19:57] <acheronuk> no, it's not. for example KC have no say on membership of Kubuntu devel
[19:57] <acheronuk> s/say/vote
[19:58] <santa_> well, if you want to give the KC extra powers, you can always change the constitution https://kubuntu.org/kubuntu-council-constitution/
[19:58] <santa_> although I have to admit that "The purpose of the council is to make decisions and govern Kubuntu." is a bit vague
[19:59] <tsimonq2> That's why I said catch-all.
[19:59] <tsimonq2> That's already clear in where governance comes from.
[20:00] <tsimonq2> In more vague cases it defaults to the KC.
[20:02] <acheronuk> in cases where it is the release team delegating a decision, it's more important that the recipients of that have the ability and knowledge to assess the case, and is not really appropriate to be left to whoever manages to get elected on the KC
[20:03] <acheronuk> could be a case where KC makeup has no-one who has the required experience
[20:03] <santa_> +1 + I don't think the point 2. should be used as an excuse to get 'unlimited' powers, the KC isn't a "technical board" and many members aren't qualified to make technical decisions
[20:14] <acheronuk> for now I think we should just go with the fact that we have 2 people the release-team are prepared to delegate to, and to not over complicate it more than that
[20:23] -queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.15 => 2.02~beta2-9ubuntu1.16] (core)
[20:27] <slangasek> tsimonq2: well that would be the first time we bothered writing anything up and ratifying it any more officially than agreeing on IRC that you're delegated
[20:28] <slangasek> i.e. I don't think you need to write anything
[20:29] <acheronuk> ^^ I agree
[20:29] <acheronuk> IRC logs with record this very soon ;)
[20:29] <acheronuk> *will
[20:38] <tsimonq2> slangasek: ack
[20:39] <tsimonq2> slangasek: To be clear, is it OK for Rik to ACK lubuntu-desktop FFes?
[20:54] <slangasek> tsimonq2: in what capacity?  I wouldn't ok that as part of a kubuntu delegation
[21:14] <tsimonq2> slangasek: I pinged above with a more verbose answer but tl;dr I don't do much KDE-specific maintenance, so if you're giving both me and him an OK, KDE is 500+ packages and Lubuntu is much less, can he review my FFes?
[21:17] -queuebot:#ubuntu-release- Unapproved: cloud-init (trusty-proposed/main) [0.7.5-0ubuntu1.22 => 0.7.5-0ubuntu1.23] (ubuntu-cloud, ubuntu-server)
[21:22] <tsimonq2> Niiiiiiice, proposed is hovering at 400 packages. \o/
[21:23]  * tsimonq2 goes candidate hunting.
[21:23] <tsimonq2> slangasek: saods9> ., do I just keep retrying until it passes? :P
[21:24] <slangasek> tsimonq2: ayup
[21:24] <tsimonq2> ¯\_(ツ)_/¯
[21:24] <tsimonq2> OK
[21:25] <slangasek> tsimonq2: what was this about a more verbose answer wrt Lubuntu?  I don't seem to see it.  Anyway, I am not delegating to a non-release-team member, non-Lubuntu developer the FFe reviews of Lubuntu changes
[21:25] <tsimonq2> ack
[21:25] <tsimonq2> :P
[21:26] <ginggs> would someone please consider LP: #1791359 ?
[21:32] <slangasek> ginggs: questions added to bug
[21:47] <ginggs> slangasek: thanks. i've asked sebastien, and will reply on the bug, but no, i haven't done rebuilds or autopkgtests
[21:56] <tsimonq2> gtk+3.0 should be candidate once gyoto/1.2.0-4ubuntu4/i386 passes its test (it's just a timeout it seems; I doubt it's related to gtk+3.0).
[21:59] <tsimonq2> I can't seem to tell if breezy/3.0.0~bzr7096-1 is OOM, Python error, both, or just bad code...
[22:00] <tsimonq2> It's throwing OverflowError: Python int too large to convert to C long
[22:03] <ginggs> tsimonq2: gyoto/i386 passed
[22:03] <tsimonq2> ginggs: ack, cool.
[22:05] <tsimonq2> linux/4.18.0-7.8/s390x seems to be flaky; it returns exit code 253 most of the time which makes sense.
[22:07] <ginggs> tsimonq2: i retried gyoto a couple of hours ago, and it looks like you retried again in the delay between the autopkgtest finishing and the results appearing
[22:08] <tsimonq2> ginggs: Ah darn, ack.
[22:09] <mwhudson> i hate that lag
[22:11] <tsimonq2> Is it just a publisher lag?
[22:14] <mwhudson> no idea
[22:15] <tsimonq2> OK.
[22:16] <slangasek> tsimonq2: that's not an OOM; if you've got an int that's too large to convert to a long, that number is not being used as the size of an array on any of our architectures
[22:16] <tsimonq2> slangasek: Could you please remove ruby-compass? It's no longer in Testing (Debian bug 876608) and it's blocking a minor (semver) version bump of ruby-sass. The Debian bug notes that it's dead upstream.
[22:16] <tsimonq2> slangasek: OK.
[23:06] <slangasek> tsimonq2: compass-bootstrap-sass-plugin, ruby-compass-rails?
[23:07] <slangasek> tsimonq2: nanoc which build-depends on ruby-compass?
[23:10] <ginggs> slangasek: i don't expect a reply from sebastien about octave until tomorrow, but I looked, and some symbols were dropped from liboctinterp.so which is shipped along with liboctave.so in liboctave6.  surely this means debian wouldn't (shouldn't) revert the soname bump?
[23:11] <slangasek> ginggs: perhaps. is the soname versioning entirely a Debian thing?
[23:13] <tsimonq2> slangasek: compass-bootstrap-sass-plugin depends on "ruby-compass | ruby-sass" so it's fine.
[23:13] <tsimonq2> slangasek: ruby-compass is a recommends of nanoc and can be removed.
[23:13] <slangasek> tsimonq2: ruby-compass is a build-dependency of nanoc
[23:13] <tsimonq2> O_o
[23:14] <slangasek> alternate depends> cool, wouldn't it be neat if reverse-depends told me that ;)
[23:14] <tsimonq2> nanoc> ack, so now I'm confused as to why Debian thinks that's cool O_o
[23:15] <tsimonq2> ruby-compass-rails probably needs an axe too; Debian bug 875612 caused removal from testing.
[23:15] <tsimonq2> Oh, so the nanoc in -proposed no longer build deps on it apparently.
[23:16] <tsimonq2> Syncing the latest Debian upload over your patch, which includes your patch and fixes some other tests as well (plus std-ver bump etc.)
[23:17] <tsimonq2> .
[23:17] <tsimonq2> I'll chase that to migration and then we *should* be good.
[23:17] <tsimonq2> I'll file a bug on that alternate rdep and ruby-compass-rails can probably go in the meantime unless I'm missing something there.
[23:18] <slangasek> ok
[23:19] <ginggs> slangasek: it doesn't appear so (i checked recent commits in salsa) and at least the Arch packages have the same sonames
[23:20] <slangasek> ginggs: ok. seems strange to me that they would bother bumping the soname upstream for a binary incompatibility only with a pre-release version, but at least that accounts for it.  Anyway, I would want to know about rebuild tests before signing off
[23:22] <ginggs> slangasek: ack, I'll do PPA rebuilds
[23:27] <tsimonq2> slangasek: ftr https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908544