=== Kow_ is now known as Kow === _salem is now known as salem_ === salem_ is now known as _salem === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === doko_ is now known as doko === j_f-f_ is now known as j_f-f [09:06] is gnome-session responsible for the session-manager logout screen? [11:05] Laney, tomboy in trusty > in debian - can you handle dbus#2 on it? [11:09] baby getting in the eay today === sraue_ is now known as sraue [13:22] join #ubuntu-on-air [13:22] uups === tkamppeter_ is now known as tkamppeter === timrc is now known as timrc-afk === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === Ursinha-afk is now known as Ursinha === jono is now known as Guest51977 [19:04] Logan_: I see that you are mass bug filing over in the Debian BTS, (about to) ignore developers reference 7.1.1 [19:04] maintonly? [19:05] 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] 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] 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] Hmm, okay. I'm submitting Ubuntu deltas using submittodebian for fixing FTBFSes on ppc64el. [19:07] I tend to fix a good amount, maybe ten, and then I submit them all to Debian. [19:08] I don't think submittodebian lets me write to maintonly... :/ [19:10] * Logan_ pokes bdrung and xnox ^ [19:10] Logan_: You could add "maintonly" to your reportbugrc before using it, and remove it when you're done with the batch [19:11] I'm wondering if there's a way for me to pass options to reportbug with submittodebian. [19:11] Something like $ submittodebian -- --maintonly [19:12] you probably have to look at the source code (if the man page does not tell you) [19:12] Okay, I'll take a look. I'll do what Julian suggested otherwise. [19:13] juliank: Thanks for the heads up! [19:13] Could someone take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ? [19:14] Looking. [19:15] Oh, that's in main. [19:15] Can't do that. :P [19:24] 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] Well, I did merge your last xfce4-terminal. [19:24] So it only seems right. [19:25] ty [19:27] Noskcaj: dpkg-source: info: local changes detected, the modified files are: [19:27] xfce4-terminal-0.6.3/terminal/terminal-encoding-action.c [19:29] Stange. I looks like that somehow got deleted. One second [19:32] 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] correct, one hour. stupid, slow internet [19:49] Logan_, That file is here locally. I think bzr merge might have deleted it for you [19:49] No, it wasn't deleted. There were changes to it. [19:52] Also, meld says it's identical. Try just getting my branch and building from it [19:57] Noskcaj: Okay, I'll try that. [19:59] ty === Guest33318 is now known as Claudinux [21:39] 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] cjwatson: Okay, so, automake1.7 for example. Removed from unstable back in August 2012, no rdeps or rbdeps, and not seeded. [21:41] 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] 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] Gotcha. [21:45] ant1.7 is another one on my list that I've been compiling. Has two rbdeps, but they're both alternates. [21:45] Yeah, I just got to that. [21:45] About to remove it [21:55] 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] (ant1.7 and automake1.7 removed now) [21:56] I will look into that. :) [21:56] Possibly better than you writing your own thing :) [21:56] process-removals really hasn't had more than, um, emergency love [22:08] cjwatson: Wait so... [22:08] process-removals goes through all removals from all time? [22:08] Logan_: I generally pass -d [22:08] for something vaguely recent [22:09] Yes, but I feel like there are so much more efficient ways to do this. [22:09] * Logan_ ponders. [22:09] It's not very satisfactory [22:09] I've never had the effort to rewrite it [22:09] I might make this a project for myself. [22:09] 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] I think it could benefit from some kind of joining of Ubuntu and Debian's removals. [22:10] IIRC Scott mostly wrote it while avoiding a team-building event, and then everyone else has just hacked it as they went :-) [22:11] Also, I feel like Debian has to improve whatever script is generating that list. [22:11] Ubuntu's aren't exposed as a stream in the same way [22:11] I think Debian actually publishes deb822 removal files nowadays [22:11] But I haven't checked whether the data matches up and converted process-removals to it [22:11] That alone would be an improvement if possible [22:12] Okay. I'll look into maybe converting the script to look at those. [22:12] I have a good amount of Python knowledge, and this would be good practice. :P [22:13] 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] It's all rather frustrating [22:13] Anyway, must go [22:14] Alright, have a good one! [22:14] Or maybe it could hook into MultiDistroTools.... Hm. [22:15] Because the only removals we really care about are the ones that are currently in Ubuntu and not in Sid. [22:18] That's something maybe you and wgrant could discuss. [22:27] My mdt stuff used to do removal checking, but I think that's broken nowadays. [22:27] Or we're up to date on Debian removals, but that seems unlikely. [22:30] win 42 [22:35] 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] Yeah, that's the way I felt as well. But I'm not sure. [22:36] 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] So I shouldn't write to maintonly, right? [22:36] 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] 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] Good point. === PaulW2U is now known as pcwhite [22:43] 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] 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] I'd like to know before someone introduces support for a new architecture in packages. [22:49] 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] juliank: I'm afraid I don't understand. Am I supposed to get permission before fixing FTBFSes on new architectures? [22:50] juliank: debian-powerpc has nothing to do with this, really. [22:51] And, yeah, I don't see why anyone would need notice before including support for a new arch. [22:51] (And, in the case of most of these, it's just generic future-proofing, not necessarily just for one arch) [22:51] Logan_: Wow, that dsc-statistics failure is... Weird. [22:52] Tell me about it. [22:52] That's the "changed too much" one, right? [22:52] Yeah. [22:52] * Logan_ shrugs. [22:52] I personally would never use wdiff to determine whether or not a package will fail to build. :P [22:53] Seen on m68k too. [22:53] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699917 [22:53] Debian bug 699917 in src:dsc-statistics "dsc-statistics: FTBFS: too many changes in docs since release, .orig.tar.gz repackaging needed" [Important,Open] [22:53] Bizarre. [22:54] I might look at that one later out of sheer curiosity. [22:54] 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] Okay, I see where you're coming from on that side of things. [22:55] juliank: The way to coordinate them would be with usertags. [22:55] That's what I wrote. [22:55] No need to contact anyone in advance to create a tag. [22:55] Right, but clearly nobody thought of this yet... [22:56] But, like I said, most of these are actually generic. [22:56] At least, the autotools-dev and autoreconf ones are. [22:56] It's just generic "please future-proof your packaging" not "please add support for an arch". [22:56] * infinity shrugs. [22:57] For the config.{sub,guess} ones, I just say "please use autotools-dev to update config.{sub,guess} for new arches" [22:57] infinity: Most packages explicitely do not use dh-autoreconf by default, they only use it, when they change files. [22:57] Because it's not limited to ppc64el and arm64 support. Future rebuilds will allow support for more arches. [22:57] juliank: I know that. I also tend to agree with Colin on this point that that's wrong. [22:58] juliank: autoreconf on build is a *good* thing. It makes sure the source actually works. [22:58] (Even outside the new arches argument) [22:58] infinity: Have you seen the bug in Debian about doing autotools-dev and/or autoreconf by default? [22:59] Logan_: No, but I'd disagree with that. [22:59] 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] But... [22:59] 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] I think that it's not harmful to do autoreconf if it fixes an FTBFS on new arches. [22:59] And to continue using it into the future until upstream updates its own files. [23:00] But it should be done on a case-by-case basis. [23:00] 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:00] Debian bug 733045 in debhelper "debhelper: Can debhelper make autotools-dev updating default behaviour?" [Wishlist,Open] [23:03] 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] Updating config.{sub,guess} automagically has pretty much proven to be 100% harmless. [23:04] Maintainers should, however, be invovled in choosing to autoreconf, and testing that it works when they do. [23:04] Especially as new autotools versions come out. [23:05] 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] Anyway, I'm leaving now. [23:10] I don't want to spend my night discussing things [23:10] I've clearly wasted every night of my life. [23:11] I wish the FTBFS report sorted by dependency level. As in, the packages that are most depwaited show up at the top. [23:12] It would make it easier to clear out this ppc64el mess. [23:34] Logan_: That might be a handy thing to try to create. Could also be a nightmare. :) [23:34] 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] I'm targeting all of the lib* packages first because I figure those will be the most depwaited. [23:36] Although a number of shared libraries don't have source packages that start with "lib." :(