[11:50] <doko> Laney, or anybody else, please could you set up a transition tracker for ruby2.2? see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789077 for the ben file
[11:57] <Laney> doko: I added you to the team, have fun :)
[11:57] <doko> Laney, go away ;-P
[11:58] <Laney> looks like there were some iterations to the file after the first post in that bug, probably get the one that was actually used
[12:00] <Laney> is this a good idea after feature freeze?
[12:07] <doko> Laney, this is just about *adding* 2.2 support, not making it a default. this is clean-up not made by the server team unfortunately
[12:08] <Laney> doko: Is there a risk it introduces new build failures for example?
[12:08] <Laney> I remember adding python 3.5 as supported :)
[12:09] <doko> Laney, wasn't me who prepared that ;p
[12:10] <doko> but seriously, this happens when people don't do this kind of work before the freeze
[12:11] <Laney> Are you saying it's half done already?
[12:11] <doko> looking at the debian tracker, yes. the outstanding things for debian were the libstdc++6 related packages
[12:12] <Laney> In Ubuntu I mean
[12:12] <doko> well, everything, which was uploaded since June ...
[12:13] <Laney> ah, https://launchpad.net/ubuntu/+source/ruby-defaults/1:2.1.5.1ubuntu1
[15:24] <utlemmin`> slangasek, infinity: any reason why dh-python is a requirement of python3?
[15:24] <slangasek> utlemmin`: it's an annoying crutch for packages that should build-depend on dh-python but don't
[15:24] <slangasek> (which I learned at the DebConf Python BoF)
[15:25] <utlemmin`> slangasek, infinity: we're seeing a massive bloat in our cloud images because dh-python Depends libdpkg-perl, which now has a compiler dependency, so GCC is getting installed on wily cloud images
[15:25] <slangasek> wat
[15:25] <utlemmin`> slangasek: libdpkg-perl recommends libfile-fcntllock-perl which recommends a compiler
[15:26] <utlemming> slangasek: so, I'm pretty sure we don't want that
[15:26] <slangasek> utlemming: that's a horribly broken recommends from libfile-fcntllock-perl then
[15:26] <infinity> Yeah, indeed.
[15:27] <infinity> libdpkg-perl should not be bringing in a compiler, and nor should random perl modules.
[15:27] <infinity> We can fix this.  We have the technology.
[15:28] <utlemming> infinity: shall I file a bug?
[15:28] <infinity> utlemming: Nah, I'm on it.
[15:28] <slangasek> http://bugs.debian.org/783760
[15:29] <infinity> Yeah, that should be a suggests at best, I think.
[15:29] <infinity> Or we should make dpkg use a different perl module. :P
[15:30] <infinity> For now, I'll just drop it to a suggests.
[15:32] <infinity> # Package for file locking with fcntl(2) in which the binary layout of
[15:32] <infinity> # the C flock struct is determined via compiling and running a C program
[15:32] <infinity> # each time the package is loaded
[15:32] <infinity> WAT.
[15:32] <infinity> That's super efficient.
[15:37] <infinity> utlemming: Fix uploaded.
[15:37] <infinity> Well, "fix".
[15:38] <infinity> The proper fix is more involved (guessing the fcntl bits at build time and including that in the package).
[15:43] <infinity> utlemming: Not that I don't also agree that the dh-python thing is somewhat madness, but libdpkg-perl is a thing a lot of people want anyway (say, for debsums), so that makes dh-python irrelevant to the discussion, IMO.
[15:45] <utlemming> infinity: that's fair....the dh-python is the head of the dep chain that caused the bloat, which is why I asked.