[09:06] <Fudge> is gnome-session responsible for the session-manager logout screen?
[11:05] <directhex> Laney, tomboy in trusty > in debian - can you handle dbus#2 on it?
[11:09] <directhex> baby getting in the eay today
[13:22] <dufa> join #ubuntu-on-air
[13:22] <dufa> uups
[19:04] <juliank> Logan_: I see that you are mass bug filing over in the Debian BTS, (about to) ignore developers reference 7.1.1
[19:04] <Logan_> maintonly?
[19:05] <juliank> Yes, it says you should write to maintonly, at least if you're continuing at that rate, otherwise bug mailing list ends up with many emails from you.
[19:06] <juliank> I don't know how many bugs you are about to report, but if they are more than ten, I'd have expected a mail to debian-devel first.
[19:06] <juliank> If a really large number of packages is affected, it might have made more sense to add a lintian check or something similar first, and wait before reporting the bugs.
[19:07] <Logan_> Hmm, okay. I'm submitting Ubuntu deltas using submittodebian for fixing FTBFSes on ppc64el.
[19:07] <Logan_> I tend to fix a good amount, maybe ten, and then I submit them all to Debian.
[19:08] <Logan_> I don't think submittodebian lets me write to maintonly... :/
[19:10]  * Logan_ pokes bdrung and xnox ^
[19:10] <juliank> Logan_: You could add "maintonly" to your reportbugrc before using it, and remove it when you're done with the batch
[19:11] <Logan_> I'm wondering if there's a way for me to pass options to reportbug with submittodebian.
[19:11] <Logan_> Something like $ submittodebian -- --maintonly
[19:12] <bdrung> you probably have to look at the source code (if the man page does not tell you)
[19:12] <Logan_> Okay, I'll take a look. I'll do what Julian suggested otherwise.
[19:13] <Logan_> juliank: Thanks for the heads up!
[19:13] <Noskcaj> Could someone take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ?
[19:14] <Logan_> Looking.
[19:15] <Logan_> Oh, that's in main.
[19:15] <Logan_> Can't do that. :P
[19:24] <Noskcaj> Logan_, Since you always seem so willing to put up with my requests, xubuntu needs a new terminal version. https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-terminal/0.6.3/+merge/200151
[19:24] <Logan_> Well, I did merge your last xfce4-terminal.
[19:24] <Logan_> So it only seems right.
[19:25] <Noskcaj> ty
[19:27] <Logan_> Noskcaj: dpkg-source: info: local changes detected, the modified files are:
[19:27] <Logan_>  xfce4-terminal-0.6.3/terminal/terminal-encoding-action.c
[19:29] <Noskcaj> Stange. I looks like that somehow got deleted. One second
[19:32] <Logan_> cjwatson: I know I'm not supposed to file bugs for removing Ubuntu packages without deltas that were removed from unstable, but I was going through the list, and there are a number of packages for which I can't figure out why they haven't been removed yet. Mind if I prod you about them?
[19:33] <Noskcaj> correct, one hour. stupid, slow internet
[19:49] <Noskcaj> Logan_, That file is here locally. I think bzr merge might have deleted it for you
[19:49] <Logan_> No, it wasn't deleted. There were changes to it.
[19:52] <Noskcaj> Also, meld says it's identical. Try just getting my branch and building from it
[19:57] <Logan_> Noskcaj: Okay, I'll try that.
[19:59] <Noskcaj> ty
[21:39] <cjwatson> Logan_: process-removals checks for seededness and reverse dependencies, and I'll often defer removals in those cases.  feel free to prod me and I can look into whether it's some kind of systemic problem or what
[21:40] <Logan_> cjwatson: Okay, so, automake1.7 for example. Removed from unstable back in August 2012, no rdeps or rbdeps, and not seeded.
[21:41] <cjwatson> Logan_: oh, that's probably just that it took ages for all the rbdeps to go away and I only very occasionally retry it for removals that far back
[21:41]  * cjwatson runs "process-removals -d 2012-01-01"
[21:44] <cjwatson> also I tend to think a bit harder about anything with Ubuntu modifications (not that that applies in this case), since that might imply specific interest by somebody in Ubuntu
[21:44] <Logan_> Gotcha.
[21:45] <Logan_> ant1.7 is another one on my list that I've been compiling. Has two rbdeps, but they're both alternates.
[21:45] <cjwatson> Yeah, I just got to that.
[21:45] <cjwatson> About to remove it
[21:55] <cjwatson> Logan_: Anyone can run process-removals from lp:ubuntu-archive-tools to see the logic it uses, even if only AAs can do the actual removal; so if you fancy making it less slow and unreliable, and maybe figuring out how we could track the delta better ...
[21:56] <cjwatson> (ant1.7 and automake1.7 removed now)
[21:56] <Logan_> I will look into that. :)
[21:56] <cjwatson> Possibly better than you writing your own thing :)
[21:56] <cjwatson> process-removals really hasn't had more than, um, emergency love
[22:08] <Logan_> cjwatson: Wait so...
[22:08] <Logan_> process-removals goes through all removals from all time?
[22:08] <cjwatson> Logan_: I generally pass -d
[22:08] <cjwatson> for something vaguely recent
[22:09] <Logan_> Yes, but I feel like there are so much more efficient ways to do this.
[22:09]  * Logan_ ponders.
[22:09] <cjwatson> It's not very satisfactory
[22:09] <cjwatson> I've never had the effort to rewrite it
[22:09] <Logan_> I might make this a project for myself.
[22:09] <cjwatson> It'd certainly be great for somebody to improve this; I think I would call it the piece of the archive tools that needs most attention
[22:10] <Logan_> I think it could benefit from some kind of joining of Ubuntu and Debian's removals.
[22:10] <cjwatson> IIRC Scott mostly wrote it while avoiding a team-building event, and then everyone else has just hacked it as they went :-)
[22:11] <Logan_> Also, I feel like Debian has to improve whatever script is generating that list.
[22:11] <cjwatson> Ubuntu's aren't exposed as a stream in the same way
[22:11] <cjwatson> I think Debian actually publishes deb822 removal files nowadays
[22:11] <cjwatson> But I haven't checked whether the data matches up and converted process-removals to it
[22:11] <cjwatson> That alone would be an improvement if possible
[22:12] <Logan_> Okay. I'll look into maybe converting the script to look at those.
[22:12] <Logan_> I have a good amount of Python knowledge, and this would be good practice. :P
[22:13] <cjwatson> It also has a problem where it tries to read the removals files incrementally, but sometimes this means that it times out in the middle of a giant run
[22:13] <cjwatson> It's all rather frustrating
[22:13] <cjwatson> Anyway, must go
[22:14] <Logan_> Alright, have a good one!
[22:14] <Logan_> Or maybe it could hook into MultiDistroTools.... Hm.
[22:15] <Logan_> Because the only removals we really care about are the ones that are currently in Ubuntu and not in Sid.
[22:18] <Logan_> That's something maybe you and wgrant could discuss.
[22:27] <wgrant> My mdt stuff used to do removal checking, but I think that's broken nowadays.
[22:27] <wgrant> Or we're up to date on Debian removals, but that seems unlikely.
[22:30] <stgraber> win 42
[22:35] <infinity> Logan_ / juliank: FWIW, I don't consider bugs with patches attached to be "mass bug filings", even if there are lots of bugs with similar topics.
[22:35] <Logan_> Yeah, that's the way I felt as well. But I'm not sure.
[22:36] <infinity> Logan_ / juliank: A muss bug filing is things like "we ran an automated checker on the archive and found 259 packages to be buggy, yours is one of them".
[22:36] <Logan_> So I shouldn't write to maintonly, right?
[22:36] <infinity> Logan_: IMO, no.  You're just filing bugs rapidly because you're fixing bugs rapidly, that't not the same as reporting en masse without fixes.
[22:37] <infinity> Logan_: And people who watch bugs-dist for patches they could sponsor or NMU might be interested in seeing your bugs, while they probably don't care about seeing 300 identical bugs with no patches.
[22:37] <Logan_> Good point.
[22:43] <juliank> infinity: Well, if he reports let's say 250 bugs in batches of 10 each, I'd consider that a mass bug filing, or at least close too, and I would ask before doing it.
[22:44] <juliank> But I don't really care that much (I only noticed it, because I my IRC client notifies me whenever someone mentions dh-autoreconf somewhere, and the bugs do, and I see them in #debian-devel-changes).
[22:45] <juliank> I'd like to know before someone introduces support for a new architecture in packages.
[22:49] <juliank> At least a short notice would be nice. I also don't see anything on debian-powerpc@l.d.o, and I think it would be reasonable to write something to them before doing this.
[22:50] <Logan_> juliank: I'm afraid I don't understand. Am I supposed to get permission before fixing FTBFSes on new architectures?
[22:50] <infinity> juliank: debian-powerpc has nothing to do with this, really.
[22:51] <infinity> And, yeah, I don't see why anyone would need notice before including support for a new arch.
[22:51] <infinity> (And, in the case of most of these, it's just generic future-proofing, not necessarily just for one arch)
[22:51] <infinity> Logan_: Wow, that dsc-statistics failure is... Weird.
[22:52] <Logan_> Tell me about it.
[22:52] <Logan_> That's the "changed too much" one, right?
[22:52] <infinity> Yeah.
[22:52]  * Logan_ shrugs.
[22:52] <Logan_> I personally would never use wdiff to determine whether or not a package will fail to build. :P
[22:53] <infinity> Seen on m68k too.
[22:53] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699917
[22:53] <infinity> Bizarre.
[22:54] <infinity> I might look at that one later out of sheer curiosity.
[22:54] <juliank> Well, for one thing, it is a bit uncoordinated this way. Now you have multiple bugs adding ppc64el support, and no way to find them. That's why I proposed contacting someone before, so that amongst other thing maybe the bugs can get a proper usertag saying that they are ppc64el bugs.
[22:55] <Logan_> Okay, I see where you're coming from on that side of things.
[22:55] <infinity> juliank: The way to coordinate them would be with usertags.
[22:55] <juliank> That's what I wrote.
[22:55] <infinity> No need to contact anyone in advance to create a tag.
[22:55] <juliank> Right, but clearly nobody thought of this yet...
[22:56] <infinity> But, like I said, most of these are actually generic.
[22:56] <infinity> At least, the autotools-dev and autoreconf ones are.
[22:56] <infinity> It's just generic "please future-proof your packaging" not "please add support for an arch".
[22:56]  * infinity shrugs.
[22:57] <Logan_> For the config.{sub,guess} ones, I just say "please use autotools-dev to update config.{sub,guess} for new arches"
[22:57] <juliank> infinity: Most packages explicitely do not use dh-autoreconf by default, they only use it, when they change files.
[22:57] <Logan_> Because it's not limited to ppc64el and arm64 support. Future rebuilds will allow support for more arches.
[22:57] <infinity> juliank: I know that.  I also tend to agree with Colin on this point that that's wrong.
[22:58] <infinity> juliank: autoreconf on build is a *good* thing.  It makes sure the source actually works.
[22:58] <infinity> (Even outside the new arches argument)
[22:58] <Logan_> infinity: Have you seen the bug in Debian about doing autotools-dev and/or autoreconf by default?
[22:59] <infinity> Logan_: No, but I'd disagree with that.
[22:59] <Logan_> Same here. It creates too much overhead for package maintainers, especially if the package doesn't need libtool and/or config.{sub,guess} updates.
[22:59] <Logan_> But...
[22:59] <infinity> Logan_: Well, not sure I'd disagree with autotools-dev by default, but autoreconf needs fiddling too much to do it without testing.
[22:59] <Logan_> I think that it's not harmful to do autoreconf if it fixes an FTBFS on new arches.
[22:59] <Logan_> And to continue using it into the future until upstream updates its own files.
[23:00] <Logan_> But it should be done on a case-by-case basis.
[23:00] <Logan_> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733045 if you want to jump in. A Debian maintainer sent it to me.
[23:03] <infinity> Logan_: Nah, that report's just about autotools-dev, not autoreconf (despite a short derailing in the conversation), I'm totally fine with that.
[23:04] <infinity> Updating config.{sub,guess} automagically has pretty much proven to be 100% harmless.
[23:04] <infinity> Maintainers should, however, be invovled in choosing to autoreconf, and testing that it works when they do.
[23:04] <Logan_> Especially as new autotools versions come out.
[23:05] <infinity> Well, that too, but I was thinking the part where you might need --foreign, or to feed it a subdir argument, etc.  It's not easily detectable how to do it right automatically without some fiddling.
[23:10] <juliank> Anyway, I'm leaving now.
[23:10] <juliank> I don't want to spend my night discussing things
[23:10] <Logan_> I've clearly wasted every night of my life.
[23:11] <Logan_> I wish the FTBFS report sorted by dependency level. As in, the packages that are most depwaited show up at the top.
[23:12] <Logan_> It would make it easier to clear out this ppc64el mess.
[23:34] <infinity> Logan_: That might be a handy thing to try to create.  Could also be a nightmare. :)
[23:34] <infinity> Logan_: I assume there are still some arm64 dep chains to unwind too (though, most of your fixes are probably getting both at once).
[23:36] <Logan_> I'm targeting all of the lib* packages first because I figure those will be the most depwaited.
[23:36] <Logan_> Although a number of shared libraries don't have source packages that start with "lib." :(