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