=== 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
Fudgeis gnome-session responsible for the session-manager logout screen?09:06
directhexLaney, tomboy in trusty > in debian - can you handle dbus#2 on it?11:05
directhexbaby getting in the eay today11:09
=== sraue_ is now known as sraue
dufajoin #ubuntu-on-air13: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
juliankLogan_: I see that you are mass bug filing over in the Debian BTS, (about to) ignore developers reference 7.1.119:04
juliankYes, 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
juliankI 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
juliankIf 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
juliankLogan_: You could add "maintonly" to your reportbugrc before using it, and remove it when you're done with the batch19: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 -- --maintonly19:11
bdrungyou 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
NoskcajCould someone take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ?19:13
Logan_Oh, that's in main.19:15
Logan_Can't do that. :P19:15
NoskcajLogan_, 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/20015119:24
Logan_Well, I did merge your last xfce4-terminal.19:24
Logan_So it only seems right.19:24
Logan_Noskcaj: dpkg-source: info: local changes detected, the modified files are:19:27
Logan_ xfce4-terminal-0.6.3/terminal/terminal-encoding-action.c19:27
NoskcajStange. I looks like that somehow got deleted. One second19: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
Noskcajcorrect, one hour. stupid, slow internet19:33
NoskcajLogan_, That file is here locally. I think bzr merge might have deleted it for you19:49
Logan_No, it wasn't deleted. There were changes to it.19:49
NoskcajAlso, meld says it's identical. Try just getting my branch and building from it19:52
Logan_Noskcaj: Okay, I'll try that.19:57
=== Guest33318 is now known as Claudinux
cjwatsonLogan_: 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 what21: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
cjwatsonLogan_: 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 back21:41
* cjwatson runs "process-removals -d 2012-01-01"21:41
cjwatsonalso 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 Ubuntu21: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
cjwatsonYeah, I just got to that.21:45
cjwatsonAbout to remove it21:45
cjwatsonLogan_: 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
cjwatsonPossibly better than you writing your own thing :)21:56
cjwatsonprocess-removals really hasn't had more than, um, emergency love21:56
Logan_cjwatson: Wait so...22:08
Logan_process-removals goes through all removals from all time?22:08
cjwatsonLogan_: I generally pass -d22:08
cjwatsonfor something vaguely recent22:08
Logan_Yes, but I feel like there are so much more efficient ways to do this.22:09
* Logan_ ponders.22:09
cjwatsonIt's not very satisfactory22:09
cjwatsonI've never had the effort to rewrite it22:09
Logan_I might make this a project for myself.22:09
cjwatsonIt'd certainly be great for somebody to improve this; I think I would call it the piece of the archive tools that needs most attention22:09
Logan_I think it could benefit from some kind of joining of Ubuntu and Debian's removals.22:10
cjwatsonIIRC 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
cjwatsonUbuntu's aren't exposed as a stream in the same way22:11
cjwatsonI think Debian actually publishes deb822 removal files nowadays22:11
cjwatsonBut I haven't checked whether the data matches up and converted process-removals to it22:11
cjwatsonThat alone would be an improvement if possible22: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. :P22:12
cjwatsonIt 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 run22:13
cjwatsonIt's all rather frustrating22:13
cjwatsonAnyway, must go22: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
wgrantMy mdt stuff used to do removal checking, but I think that's broken nowadays.22:27
wgrantOr we're up to date on Debian removals, but that seems unlikely.22:27
stgraberwin 4222:30
infinityLogan_ / 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
infinityLogan_ / 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
infinityLogan_: 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
infinityLogan_: 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
juliankinfinity: 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
juliankBut 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
juliankI'd like to know before someone introduces support for a new architecture in packages.22:45
juliankAt 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
infinityjuliank: debian-powerpc has nothing to do with this, really.22:50
infinityAnd, 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
infinityLogan_: 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
* Logan_ shrugs.22:52
Logan_I personally would never use wdiff to determine whether or not a package will fail to build. :P22:52
infinitySeen on m68k too.22:53
ubottuDebian 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
infinityI might look at that one later out of sheer curiosity.22:54
juliankWell, 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
infinityjuliank: The way to coordinate them would be with usertags.22:55
juliankThat's what I wrote.22:55
infinityNo need to contact anyone in advance to create a tag.22:55
juliankRight, but clearly nobody thought of this yet...22:55
infinityBut, like I said, most of these are actually generic.22:56
infinityAt least, the autotools-dev and autoreconf ones are.22:56
infinityIt'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
juliankinfinity: 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
infinityjuliank: I know that.  I also tend to agree with Colin on this point that that's wrong.22:57
infinityjuliank: 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
infinityLogan_: 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
infinityLogan_: 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
ubottuDebian bug 733045 in debhelper "debhelper: Can debhelper make autotools-dev updating default behaviour?" [Wishlist,Open]23:00
infinityLogan_: 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
infinityUpdating config.{sub,guess} automagically has pretty much proven to be 100% harmless.23:04
infinityMaintainers 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
infinityWell, 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
juliankAnyway, I'm leaving now.23:10
juliankI don't want to spend my night discussing things23: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
infinityLogan_: That might be a handy thing to try to create.  Could also be a nightmare. :)23:34
infinityLogan_: 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!