| === 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 | ||
| Fudge | is gnome-session responsible for the session-manager logout screen? | 09:06 |
|---|---|---|
| directhex | Laney, tomboy in trusty > in debian - can you handle dbus#2 on it? | 11:05 |
| directhex | baby getting in the eay today | 11:09 |
| === sraue_ is now known as sraue | ||
| dufa | join #ubuntu-on-air | 13:22 |
| dufa | uups | 13:22 |
| === 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 | ||
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| Logan_ | I don't think submittodebian lets me write to maintonly... :/ | 19:08 |
| * 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| Logan_ | Looking. | 19:14 |
| Logan_ | Oh, that's in main. | 19:15 |
| Logan_ | Can't do that. :P | 19:15 |
| 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:24 |
| Noskcaj | ty | 19:25 |
| 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:27 |
| Noskcaj | Stange. I looks like that somehow got deleted. One second | 19:29 |
| 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:32 |
| Noskcaj | correct, one hour. stupid, slow internet | 19:33 |
| 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:49 |
| Noskcaj | Also, meld says it's identical. Try just getting my branch and building from it | 19:52 |
| Logan_ | Noskcaj: Okay, I'll try that. | 19:57 |
| Noskcaj | ty | 19:59 |
| === Guest33318 is now known as Claudinux | ||
| 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:39 |
| Logan_ | cjwatson: Okay, so, automake1.7 for example. Removed from unstable back in August 2012, no rdeps or rbdeps, and not seeded. | 21:40 |
| 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:41 | |
| 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:44 |
| 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:45 |
| 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:55 |
| 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 | 21:56 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| Logan_ | Alright, have a good one! | 22:14 |
| Logan_ | Or maybe it could hook into MultiDistroTools.... Hm. | 22:14 |
| Logan_ | Because the only removals we really care about are the ones that are currently in Ubuntu and not in Sid. | 22:15 |
| Logan_ | That's something maybe you and wgrant could discuss. | 22:18 |
| 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:27 |
| stgraber | win 42 | 22:30 |
| 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:35 |
| 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:36 |
| 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:37 |
| === PaulW2U is now known as pcwhite | ||
| 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:43 |
| 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:44 |
| juliank | I'd like to know before someone introduces support for a new architecture in packages. | 22:45 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| infinity | Seen on m68k too. | 22:53 |
| infinity | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699917 | 22:53 |
| ubottu | 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 |
| infinity | Bizarre. | 22:53 |
| 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:54 |
| 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:55 |
| 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:56 | |
| 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:57 |
| 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:58 |
| 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. | 22:59 |
| 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:00 |
| ubottu | Debian bug 733045 in debhelper "debhelper: Can debhelper make autotools-dev updating default behaviour?" [Wishlist,Open] | 23:00 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:10 |
| Logan_ | I wish the FTBFS report sorted by dependency level. As in, the packages that are most depwaited show up at the top. | 23:11 |
| Logan_ | It would make it easier to clear out this ppc64el mess. | 23:12 |
| 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:34 |
| 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." :( | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!