[01:34] <askhl> Hi.  Shouldn't programmes that use gettext depend on gettext?  They generally seem not to.  Is this somehow implicit?
[02:30] <ScottK> askhl: They should.
[02:38] <askhl> ScottK: Thanks
[02:41] <askhl> Hmm... I suppose many packages recursively end up depending on gettext in any case
[02:53] <ScottK> Probably, although one is not supposed to depend on that, packages frequently do.
[02:53] <ScottK> It's a bug in the package, but a minor one.
[02:56] <askhl> The standard gettext stuff though (to just use gettext, not to compile translations), does that not require the actual gettext package?
[02:56] <ScottK> That's correct (AIUI)
[02:57] <askhl> So one would depend on some standard library, and then that's why nobody needs to depend on gettext
[02:57] <askhl> But if actual gettext stuff (like msgfmt) is part of the build procedure, then probably hte source package should depend on gettext
[02:57] <ScottK> You would more likely need to build-depend on gettext.
[02:57] <askhl> Exactly!
[02:58] <askhl> I think I get it now.  Thanks
[09:18] <jtaylor> does debian delete their transition trackers when they are done?
[09:19] <jtaylor> wanted to look up the hdf5 ben line but can't find it :(
[09:54] <tumbleweed> jtaylor: according to https://wiki.debian.org/Teams/ReleaseTeam/TransitionTracker they keep them in config/old on release.d.o, which I can't access. So poke a debian release team member
[10:10] <Laney> jtaylor: tumbleweed: http://release.debian.org/transitions/config/old/
[10:10] <Laney> or ries.debian.org:/srv/release.debian.org/www/transitions/config/old
[10:12] <tumbleweed> ah, that's easy
[10:14] <jtaylor> Laney: bookmarked thanks, if it already makes sense can you set up the tracker for quantal?
[10:19] <Laney> ok
[10:26] <Laney> should be there at the next run
[10:26] <jtaylor> thx
[11:34] <Laney> probably should have trimmed the arch list
[11:35] <Laney> hmm
[12:29] <jtaylor> ubuntu's ben does not know which arches it has?
[12:35] <jtaylor> would libhdf5 be autosynced before its dependencies so we get free rebuilds?
[12:36] <tumbleweed> jtaylor: sync it before the archive opens
[12:36] <tumbleweed> wel,l before autosyncs start
[12:36] <jtaylor> can we already do that?
[12:36] <tumbleweed> if you want it before the archive opens, bring that up in #ubuntu-release
[12:36] <tumbleweed> it's just a freeze, syncs/uploads go to unapproved
[12:36] <Laney> it has an ubuntu delta
[12:38] <jtaylor> that can be dropped
[12:42] <jtaylor> so I do a syncpackage which will be probably be approved before autosyncs?
[12:43] <jtaylor> micahg: you were also interested in hdf5, objections to that ^?
[12:43] <tumbleweed> I think so. I suggest bringing it up in #ubuntu-release to get archive-admin attention
[12:43] <Laney> i don't know why it needs special attention like that
[12:43] <Laney> but it is possible, yes
[12:44] <jtaylor> yes special attention is not required
[12:44] <tumbleweed> it proabbly doesn't, but nice to get it in before the autosyncs
[12:44] <tumbleweed> then again, those usually start a day or two after archive open
[12:45] <jtaylor> afk 20 min
[12:46] <tumbleweed> Laney: when are we getting an index.html for ben?
[12:47] <Laney> that has been ready for ages
[12:47] <tumbleweed> that's what I thought
[12:47] <tumbleweed> oh, hdf5 isn't that big
[18:59] <EvilResistance> if i want to have a fix uploaded to a package currently in `main` what's the procedure to request that fix in the main repositories?  i know the MOTUs govern the Universe repository, but how does one get a (minor) bugfix pushed into main (if ever)
[19:00] <Laney> the process is the same, it's just that the set of sponsors is a bit different
[19:06] <EvilResistance> that'd be the ubuntu-sponsors team, right Laney?
[19:06] <EvilResistance> (for who needs to be subscribed to the corresponding bug)
[19:08] <Laney> right
[19:08] <EvilResistance> assuming its  not *my* bug, but someone else's bug and they attached a patch to the bug for a package, am I still allowed to help the bug poster out by subscribing ubuntu-sponsors to the bug?  (since they asked in #ubuntu-bugs how to get the fix pushed/applied)
[19:10] <Laney> yeah. bonus points if you make it into a debdiff that can be uploaded
[19:10] <Laney> and forward it upstream / to debian if appropriate.
[19:10] <EvilResistance> it'd need to be sent to debian, because its the 'hello' package, but in the last 500 times i've tried to send patches/debdiffs up to Debian its failed
[19:10] <EvilResistance> so getting the fix to Debian would require some...
[19:11] <EvilResistance> help...
[19:11] <Laney> ok, so tell me how it fails
[19:12] <EvilResistance> good question
[19:12] <EvilResistance> it gets sent over to Debian, and then disappears
[19:12]  * EvilResistance isnt sure why
[19:13] <Laney> I bet you don't have local mail (sendmail) working. reportbug assumes that you do by default.
[19:13] <Laney> stick "smtphost reportbug.debian.org" in ~/.reportbugrc
[19:13] <Laney> or another smtp host
[19:16] <EvilResistance> um... small problem, when i generate the debdiff it... kinda adds my information in the debian/changelog to the diff...
[19:16] <EvilResistance> (because i have to build the package to get the .dsc)
[19:16] <Laney> submittodebian filters it out, or you can do it yourself with filterdiff
[19:21] <EvilResistance> hmm, debdiff isnt reading my keys...
[19:21] <EvilResistance> wth is up with that...
[19:23] <EvilResistance> Laney:  debdiff isnt working, stating it cant find my RSA key
[19:23] <EvilResistance> s/rsa/gpg/
[19:25] <Laney> can you paste the error?
[19:26] <EvilResistance> actually its wokring, but its generating this error: https://pastebin.com/x0bfys0y
[19:26] <EvilResistance> and it still outputs the diff ...
[19:26] <EvilResistance> stuff
[19:26] <EvilResistance> problem is it wont let me filterdiff it :/
[19:27] <Laney> debdiff takes a --exclude parameter too
[19:28] <Laney> debdiff --exclude changelog a.dsc b.dsc > foo.debdiff
[19:33] <EvilResistance> thanks
[22:55] <vvv> How do I find out where is the original upstream of some program I want to patch?
[22:56] <jtaylor> mostly there is a homepage tag in debian/control
[22:57] <tumbleweed> otherwise, google
[22:57] <tumbleweed> debian/watch can also be helpful
[22:58] <vvv> http://packages.debian.org/squeeze/cpuid
[22:58] <vvv> It's unclear where is the home page
[22:58] <vvv> And googling CPUID would be no good
[22:58] <tumbleweed> I see: Homepage: http://www.ka9q.net/code/cpuid/
[22:58] <vvv> Ah, here it is
[22:58] <vvv> Last updated 1 Jan 2002 to support AMD Athlon/Duron, and to tighten the code.
[22:58] <vvv>  
[22:58] <jtaylor> 2002 is pretty useless for cpuid ^^
[22:58] <tumbleweed> (that's the old way of doing it, a line in the description)
[22:59] <vvv> Okay, I am not surprised it is ungodly out-of-date
[22:59] <tumbleweed> http://packages.qa.debian.org/c/cpuid.html
[22:59] <tumbleweed> last uploaded in 2006 :)
[23:00] <jtaylor> that thing should be removed
[23:00] <vvv> Where do I submit parches in such case?
[23:00] <jtaylor> it probably causes more harm than good
[23:00] <tumbleweed> I suggest reading debian bug 596110
[23:01] <jtaylor> having cpuid packaged is nevertheless not a good idea, at least in ubuntu
[23:01] <jtaylor> you have to sru it constantly to keep it up to date
[23:01] <vvv> SRU?
[23:02] <jtaylor> stable release update
[23:05] <tumbleweed> not that anyone does
[23:05] <Laney> why is it more or less of a good idea in either distribution?
[23:07] <jtaylor> it may not have a dedicated maintainer in ubuntu
[23:07] <tumbleweed> it appears not to have a dedicated maintainer in debian either
[23:07] <tumbleweed> or upstream
[23:08] <Laney> there is no reason someone couldn't do just as good a job here if they wanted