| === Zeroedout_ is now known as zeroedout | ||
| askhl | Hi. Shouldn't programmes that use gettext depend on gettext? They generally seem not to. Is this somehow implicit? | 01:34 |
|---|---|---|
| ScottK | askhl: They should. | 02:30 |
| askhl | ScottK: Thanks | 02:38 |
| askhl | Hmm... I suppose many packages recursively end up depending on gettext in any case | 02:41 |
| 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:53 |
| 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:56 |
| 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:57 |
| askhl | I think I get it now. Thanks | 02:58 |
| jtaylor | does debian delete their transition trackers when they are done? | 09:18 |
| jtaylor | wanted to look up the hdf5 ben line but can't find it :( | 09:19 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| 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 | 09:54 |
| 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:10 |
| tumbleweed | ah, that's easy | 10:12 |
| jtaylor | Laney: bookmarked thanks, if it already makes sense can you set up the tracker for quantal? | 10:14 |
| Laney | ok | 10:19 |
| === jalcine is now known as jacky | ||
| Laney | should be there at the next run | 10:26 |
| jtaylor | thx | 10:26 |
| === jacky is now known as Jacky | ||
| === yofel_ is now known as yofel | ||
| Laney | probably should have trimmed the arch list | 11:34 |
| Laney | hmm | 11:35 |
| jtaylor | ubuntu's ben does not know which arches it has? | 12:29 |
| jtaylor | would libhdf5 be autosynced before its dependencies so we get free rebuilds? | 12:35 |
| 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:36 |
| jtaylor | that can be dropped | 12:38 |
| jtaylor | so I do a syncpackage which will be probably be approved before autosyncs? | 12:42 |
| 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:43 |
| 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:44 |
| jtaylor | afk 20 min | 12:45 |
| tumbleweed | Laney: when are we getting an index.html for ben? | 12:46 |
| Laney | that has been ready for ages | 12:47 |
| tumbleweed | that's what I thought | 12:47 |
| tumbleweed | oh, hdf5 isn't that big | 12:47 |
| === 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 | ||
| 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) | 18:59 |
| Laney | the process is the same, it's just that the set of sponsors is a bit different | 19:00 |
| EvilResistance | that'd be the ubuntu-sponsors team, right Laney? | 19:06 |
| EvilResistance | (for who needs to be subscribed to the corresponding bug) | 19:06 |
| 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:08 |
| 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:10 |
| EvilResistance | help... | 19:11 |
| Laney | ok, so tell me how it fails | 19:11 |
| EvilResistance | good question | 19:12 |
| EvilResistance | it gets sent over to Debian, and then disappears | 19:12 |
| * EvilResistance isnt sure why | 19:12 | |
| 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:13 |
| 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:16 |
| EvilResistance | hmm, debdiff isnt reading my keys... | 19:21 |
| EvilResistance | wth is up with that... | 19:21 |
| EvilResistance | Laney: debdiff isnt working, stating it cant find my RSA key | 19:23 |
| EvilResistance | s/rsa/gpg/ | 19:23 |
| Laney | can you paste the error? | 19:25 |
| 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:26 |
| Laney | debdiff takes a --exclude parameter too | 19:27 |
| Laney | debdiff --exclude changelog a.dsc b.dsc > foo.debdiff | 19:28 |
| EvilResistance | thanks | 19:33 |
| === Jacky is now known as JackyAlcine | ||
| === JackyAlcine is now known as jacky | ||
| vvv | How do I find out where is the original upstream of some program I want to patch? | 22:55 |
| jtaylor | mostly there is a homepage tag in debian/control | 22:56 |
| tumbleweed | otherwise, google | 22:57 |
| tumbleweed | debian/watch can also be helpful | 22:57 |
| 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:58 |
| 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 :) | 22:59 |
| 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:00 |
| ubottu | Debian bug 596110 in cpuid "Newer, better cpuid available" [Wishlist,Open] http://bugs.debian.org/596110 | 23:00 |
| 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:01 |
| jtaylor | stable release update | 23:02 |
| tumbleweed | not that anyone does | 23:05 |
| Laney | why is it more or less of a good idea in either distribution? | 23:05 |
| 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:07 |
| Laney | there is no reason someone couldn't do just as good a job here if they wanted | 23:08 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!