[00:01] hi folks [00:01] Hi sistpoty [00:01] hi geser [00:02] hm... ghc6 is building now for over 20 hours on spooky [00:02] hoi sistpoty [00:02] hi hellboy195 [00:02] sistpoty: congratulation to the new *working* sensors release ;) [00:02] hellboy195: thanks... took me some time to figure that LDFLAGS were in the way to make it work *g+ [00:03] sistpoty: ^^ [00:04] heya [00:05] good night :) [00:05] gn8 hellboy195 [00:09] slangasek: thanks for the rebuild and http://members.ping.de/~mb/buildstatus_hardy/ has now a list without hppa (and a cronjob) [00:12] geser: cheers === _stefan_ is now known as sistpoty [00:51] How do I easily get apt to look in a particular directory for debs? Or any other way to install a deb whilst looking in a given directory for debs that provide needed dependencies. === luisbg_ is now known as luisbg [00:56] soto: There's no simple way. Creating a local repository is likely easiest. I used apt-ftparchive last time I did that, but dpkg-scanpackages or dpkg-scansources may do as well. [00:57] persia: Can you tell me the directory structure I need and what files (Packages.gz, Release.gz, Contents.gz?) [00:58] soto: I don't remember the structure exactly, but the docs for either apt-ftparchive or dpkg-scanpackages should help. Both of those would generate Packages.gz, which is what you want. [00:58] * sistpoty uses mini-dinstall, but setting that up was quite some time ago [01:00] soto: http://blog.madism.org/index.php/2006/06 is quite an easy way to set this up for pbuilder if that is what you are doing. [01:00] go into the directory where you local .deb files are, and run -> dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz [01:00] then edit your sources.list and add -> deb file:///where/ever/the/dir/is ./ [01:00] had to search my history for that one [01:01] nixternal: Thanks [01:01] james_w: thanks for that linke...I just got all of that through history, now I can bookmark it for the future :) [01:01] nixternal: no problem [01:01] soto: if you want to use it inside a pbuilder make sure that the dir gets bind-mounted in your pbuilder [01:02] geser, james_w It's not for pbuilder [01:04] Thanks though [01:59] siretart: Yes it should, but I was on my phone and couldn't remember the proper LP email incantation for that. === santiago-php is now known as santiago-ve [02:35] heya everybody [02:36] hi Toadstool [02:37] hi sistpoty! [02:37] how's it going? [02:37] * sistpoty is plaing^W testing ufoai *g+ [02:38] :) [02:51] does anyone has sporatic problems with ppa rejecting uploads due to a key mismatch (although its obviously not) ? [02:59] macd: no... but I don't use PPA... maybe you could try asking on #launchpad? [03:01] thats my next stop :) [03:19] oh... ufoai is sooo buggy... I lost yet anoher round *g* [05:15] DktrKranz2: Hey [06:20] superm1: any news for packaging gmyth-* [06:20] superm1: ? :) [08:07] oy [08:59] YokoZar, ping [09:07] Hi [09:10] DktrKranz: pong [09:12] YokoZar, I've a solution for bug 185513. I thought it solved bug 191575 too (since I didn't notice any segfault after the build), but additional tests showed me I was wrong. [09:12] Launchpad bug 185513 in wine "Wine packages overly large" [Low,Confirmed] https://launchpad.net/bugs/185513 [09:12] Launchpad bug 191575 in wine "wine segfaults on winecfg" [High,Confirmed] https://launchpad.net/bugs/191575 [09:13] have you a amd64 box to test it out? [09:13] DktrKranz: Yeah [09:14] Good, I'll publish on my PPA since I've only a i386 builder here and point you to them once ready [09:15] mh... PPA is bad... no pkg-create-dbgsym [09:22] DktrKranz: hmmm [09:24] YokoZar, source package is here: http://packages.linuxdc.it/. Mind give it a build test in pbuilder with pkg-create-dbgsym installed? [09:24] I'm doing it for i386 [09:25] DktrKranz: Sure, but I need to go to sleep now. Give me like 16 hours or so when I get back tomorrow. [09:25] no worry [11:04] hi everybody. [11:05] Anyone around who could explain my package's depends line on me? :-) It's a python thinggy... [11:17] HighNo: I could try [11:33] geser: thanks. I was wondering why my package 'blueproximity' does have a dependency on python-support (>=0.7.1) while it only has a build dep on it and only on version 0.5.3... [11:33] geser: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text=blueproximity [11:36] HighNo: because it was build with python-support 0.7.5 which puts it into ${Depends:Python} [11:51] geser: hm, so if backports-team will try to debuild it it will work out of the box? [11:52] yes, as the python-support from the other versions will fill in the correct dependency for it [11:53] cool [11:53] unless you want to backport to dapper where the python-support is too old to satisfy your versioned build-dependency on python-support [11:56] geser: yes, I know. For dapper the dependency must be fixed but feisty and gutsy won't need a single change - that should speed things up [11:57] could someone please give me the backporting guide wiki please? [11:58] https://help.ubuntu.com/community/UbuntuBackports [11:58] thx [12:01] geser: one more... where can I find Prevu? [12:02] HighNo: in the archive [12:08] jeromeg: thx [12:09] HighNo: np [12:10] Hey [12:14] RainCT: hey [12:41] root@mupp:~# lsb_release -c [12:41] Codename: hardy [12:59] if debhelper>=5 then echo 5 > debian/compat ? [13:00] use 6 [13:00] we have debhelper 6 now [13:00] even though it is a backport for feisty? [13:00] * persia notes that this doesn't help with backporting [13:00] ah, right [13:00] then 5 [13:00] ok [13:00] is gutsy 5 or 6? [13:01] 5 [13:01] (6 came during hardy, so even lots of hardy is 5) [13:01] so 5 doesn't really hurt, it's just old? [13:02] HighNo: Check the changelog. 6 introduces a few new features and behaviour changes that are not available under 5. [13:03] Someone should introduce a deb-traffic which highlights new changes to the packaging system. There's a lot of undocumented things in there which become black magic. [13:05] slicer: Most of it is in the dpkg, debhelper, and CDBS changelogs. [13:06] Hm. Is there a service to subscribe to changelog changes? :) [13:06] apt-listchangelogs? [13:06] hardy-changes@l.u.c? [13:06] Subscribe to hardy-changes? :-P [13:06] * StevenK high fives persia [13:07] There's also some RSS feed, but I don't remember the address. [13:07] * slicer goes to investigate :) [13:07] Does LP have a changelog subscription feature in the style of packages.qa.debian.org? [13:08] persia: No. [13:08] Fujitsu: Thanks. [13:08] RSS feed for hardy-changes: http://media.ubuntu-nl.org/rss/hardy.xml [13:08] slicer: If the options above don't meet your needs, please file a feature request to enable a changelog subscription feature in LP. [13:08] when doing a backport, I have to add another changelog entry, right? If all I did was to change the deps - and of course the according files like debian/compat - what of all this should I enter at the changelog entry? and should I include the backport bug entry? [13:10] I try to find that in the backports wiki but couldn't... [13:10] * RainCT doesn't understand the hurry to switch to compat level 6 if even level 4 isn't deprecated yet [13:11] * persia recommends selecting the minimum supported compat level that provides the desired feature set [13:11] RainCT: I think it is now with the introduction of 6 :) [13:12] pochu: 'man debhelper'; it isn't, only 1, 2 and 3 [13:13] heya [13:13] RainCT: right. then I can stick with v4 in aMule :) [13:14] pochu: You may safely. I suspect 4 will become deprecated in Debian right around the lenny release (as sooner is a lot of package bumps), so you are likely looking at a loss of support for intrepid+1 (depending on freeze cycles, etc.) [13:14] hm, no backporter arround that could help me on my changelog entry? [13:15] bddebian: I hate circular dependencies, and you should too :p [13:16] HighNo: if there is a backport bug then I expect that you include that yes. [13:16] HighNo: you should also explain everything that you did in order to do the backport. [13:18] james_w: that's what the wiki says - but does that include every tiny change to files in debian/ dir or just the 'source' (or is the original debian/ also considered source here?) === ogra_cmpc_ is now known as ogra_cmpc [13:23] HighNo: every change, so that someone looking back can easily see what changes were necessary. [13:27] persia: how many acks are required for a uvfe? [13:28] persia: ffe? 2 for now [13:29] james_w: hm, I'm puzzled. I did rebuild the new backported package with prevu which creates a nice new .deb file that installs perfectly on feisty. I changed the changelog and so on. I now should upload a debdiff, right? If I debdiff both binary packages, I only get differences in the control file ?! [13:30] Is "old version only builds on i386 and new one should work on all" a good rationale for a FFe? [13:30] HighNo: you should debdiff the source package, not the binary. [13:30] HighNo: debdiff the .dsc files [13:30] RainCT: Depends if it's in Packages-arch-specific, and if it has FTBFS on the other arches [13:30] hm, where does prevu generate them? [13:31] StevenK: it was "architecture: i386", but had a RC bug in Debian because of this [13:32] Which means it could be either, and needs you to check. :-) [13:32] what do you mean? [13:33] RainCT: which package is it? [13:33] Okay, so check if the package is in Packages-arch-specific, or if just FTBFS on the other arches [13:33] StevenK: it didn't FTBFS as it has "architecture: i386" (and not any) in debian/control [13:33] s/has/had [13:34] (well, has in Ubuntu and had in Debian :P) [13:34] RainCT: It didn't FTBFS on i386. amd64 would have refused to build it [13:34] If there are no amd64 builds at all, it's in Packages-arch-specific. [13:34] geser: open-invaders [13:34] geser: james_w: do you know where prevu creates the dsc file? [13:36] HighNo: don't know, try /var/cache/pbuilder/result, or somewhere else under there if it uses pbuilder. [13:37] RainCT: is it already fixed in Debian? because http://packages.qa.debian.org/o/open-invaders.html still lists i386 only [13:37] geser: it's in NEW because arch independent stuff has been moved into a -data package now [13:38] ah [13:38] RainCT: open-invaders isn't listed in P-a-s [13:39] HighNo: /var/cache/prevu/source/package/result/ by looking at the script. [13:39] RainCT: so the buildds should pick it up with the new arch line [13:39] HighNo: actually not /package/ /some-pid/ [13:41] find /var/cache/prevu/ -iname \*.dsc -> no files [13:42] HighNo: I don't know prevu but you give it only the package name you want backported? [13:45] geser: I had to change some files (in debian/ dir) so I got the source via apt-get source blueproximity and then changed into that directory, changed my files and did a 'prevu' call. That is what the wiki tells me to do. But all I get is the complete package built in /var/cache/prevu/feisty-debs [13:46] it does not seem to use pbuilder as /var/cache/pbuilder/result/ only shows those packages I had built with pbuilder [13:46] HighNo: try then to build a new source package with debuild -S [13:47] you should then have the "old" and the "new" source package which you can debdiff [13:47] geser - I'll try but then i will still have the problem when doing the backport for gutsy as I don't have it installed... [13:47] hm.. has Ubuntu popcon stats? [13:47] RainCT: Yup [13:48] RainCT: http://popcon.ubuntu.com/ [13:48] thanks [13:53] uh.. but those are for Dapper or what? [13:54] RainCT: I was also disappointed when looking at popcon [13:54] RainCT: there's nothing interesting there to see [13:56] * RainCT is not sure if he wants open-invaders in Hardy [13:59] mok0_: there isn't ? one can see how often people install certain packages and how often (approx.) the are using it. What else do you want to see from a popcon? [14:00] HighNo: I am just disappointed at the lack of a UI to browse the data. There's no meaningful statistics, all you can do it click and download the raw data [14:01] mok0_: ok, that's a point [14:01] mok0_: who's in charge? I guess building one is not that hard... [14:02] HighNo: I'd expect to find info on the popularity of a certain package, how it develops in time, etc. [14:02] HighNo: I don't know. [14:03] HighNo: I guess you could wget all the data files and give it a go :-) [14:03] mok0_: OK, the time frame seems to be a nice thing - therefore one is to have a database with timestamps. [14:03] HighNo: ... and perhaps even geographical location? That would require access to the server logs of course [14:03] mok0_: hehe - tried to find a person in charge for it - README and FAQ are 404's [14:04] HighNo: yeah, popcon is in a sorry state... could do with some love and affection :-) [14:05] mok0_: OK, another good point - looks like it should be possible though, as it states 'each day the server anonymizes and publishes' so the results on the serve rare not anonymized and could be useful for such things... [14:06] HighNo: interesting [14:07] HighNo: I wonder how you vote [14:08] mok0_: you don't vote; it's explained below. vote means that the user uses the package regularly [14:09] mok0_: funny thing - my package is in the 'raw popularity contest results' but in none of the other results as far as I can see it [14:11] mok0_: hm, ok, it is in the 'all' list but not in one of the section lists... [14:11] HighNo: Hmm [14:12] RainCT: thanks for asking for these stats - I didn't even know they were online somewhere. It looks nice as one can have a litte more insight in how many people are actually using your stuff... [14:13] * mok0_ wonders how to interpret these numbers [14:14] HighNo: blueproximity, right? [14:14] mok0_: right [14:15] 540 inst, 76 vote [14:16] mok0_: I would say 540 people were interested and at least 76 really use it. 383 people are either not running it via session manager and therefore not regularly or they disabled atimes on they filesystems which could be some as it is probably used more on laptops than on desktops. [14:16] persia: still around? [14:17] 383 old, 80 old ??? [14:17] mok0_: one could map that up to a userbase IF one knew how many users are using ubuntu totally... [14:17] HighNo: You could normalize using one of the mandated packages [14:17] mok0_: 80 is the number that made an update on it [14:18] HighNo: that number is identical for a lot of the packages [14:18] mok0_: that only gives a relation on how many are using it, not a total number as we don't know how many of the users are really voting. [14:19] HighNo: true [14:19] HighNo: we must know how many have install popcon [14:20] in what order are the numbers in all-popcon-results.tar.gz? [14:20] mok0_: hm, not really, as we can guess how many that would be from the topmost package. what we really need is the secret number: the total ubuntu user base [14:21] RainCT: they have an order? :- [14:21] ) [14:21] Package: gbrainy 245 463 282 2 [14:22] RainCT: actually they are: use regularly, don't use regularly (both should sume up to the installed base), updated recently, no-files [14:22] ok, thanks [14:23] * HighNo thinks of actually activating his popcon - statistics are interesting for maintainers [14:25] Package: open-invaders 117 745 96 0 hm.. open-invaders has some more users in Ubuntu than in Debian (850 installs vs 30) :P [14:26] RainCT: that could mean anything - like debian's popcon is much less demanding or inviting for users... [14:27] HighNo: true, or just that people haven't used it because it isn't in testing [14:27] RainCT: that's what I was discussing with mok0_ - you don't get absolute values unless you know how many users are there in total [14:27] RainCT: that would still imply less users... [14:28] HighNo: well, Debian's popcon page at least gives a % [14:28] are there statistics for the update servers as with fedora? [14:28] RainCT: % on what? people who use popcon or total install base? [14:28] (above amount of users with popcon activate) [14:29] RainCT: see - now the question is - since you know on how many people use popcon - you still don't use the ratio of total users/ popcon users [14:29] RainCT: the update server stats could give at least a hint on that [14:31] sabdfl said an aprox. amount of users some time ago.. I think it was 5 million or something like that [14:31] * RainCT is not sure though [14:33] ok, from Wikipedia: "Mark Shuttleworth indicates that there were at least 8 million Ubuntu users at the end of 2006" [14:36] RainCT: that means now ~10 million? at least after hardy release :) [14:37] RainCT: ok, so if you think about 10mio people using ubuntu and about 500000 entries in popcon you could multiply your results with 20 to get an absolute value with is very vague. (Due to the absence of exact number of users and popcon users not being statistically representative...) [14:38] I guess they count all installed packages, not only official ones. (I think that because I found packages like blueproximity-kde and blueproximity-gtk which are not part of ubuntu) [14:39] oy [14:42] Hi bddebian === asac_ is now known as asac [14:45] Heya geser [14:46] anyone @fosdem ? [14:46] yes, me, debian room [14:46] how can I check if a package is in a certain distribution from the command line (ie, if it's in gutsy/hardy/etc.)? [14:46] lucas: accessibility talk ? [14:47] yup [14:47] RainCT: apt-cache madison package_name ? [14:47] RainCT: with the deb-src lines in your sources.list [14:48] lucas: @crossdesktop, hearing about GEGL, and about basic debian packaging soon [14:48] oh, they are late? I think deb packaging was earlier [14:48] bye people, later. [14:48] jeromeg: ah, right. thanks :) [14:48] lucas: seems that they have switched the schedul [14:48] RainCT: np :) [14:54] RainCT: rmadison from devscripts [14:57] When are uploaded packages actually rebuilt? [14:58] Laney: what do you mean? [14:59] geser: I had a patch accepted a few days ago and launchpad still says "Not yet built" on my +packages page [14:59] s/a few/2 [14:59] Laney: which package is it? [14:59] geser: darcs [15:00] Laney: https://edge.launchpad.net/ubuntu/hardy/+source/darcs/+builds [15:00] geser: Aha. I wonder why +packages doesn't show this.. [15:00] persia: New newpki-client patch sent to BTS... [15:01] Laney: the +packages is not accurate when the package didn't build on one arch [15:01] Hm, ok [15:01] Laney: I use always the page for the source package [15:03] geser: Right. What about in the official repos then? Does it have to build on all arches to get there? [15:05] Laney: no, it gets published on the archs where it build (but ideally it should build on every arch) [15:05] geser: Oh, well it doesn't seem to have updated yet. I guess that takes a while longer? [15:07] Laney: packages.ubuntu.com reports the last uploaded version for hardy [15:08] Oh, whoops. Must just be my mirror then [15:08] Sorry! [15:08] geser: well but it's not always up to date [15:09] hellboy195: have you examples? [15:09] Laney: you can also check if the files are on archive.ubuntu.com [15:10] geser: no, I mean in generel. It takes some time to update the entries. [15:11] hellboy195: true [15:15] geser: have a second for me? [15:15] it depends [15:15] geser: on? [15:16] on what you want to know [15:18] geser: ^^, k. so I'm mergin wxwidgets and now I have a debdiff but I think it can delete the things under line 256. what do you think? http://pastebin.com/m6830e444 [15:20] can someone remind what '101' means? As in 'Packaging 101'? [15:21] jpatrick: i think its like a starter class/course [15:21] Packaging 101 is your entry point to the world of packaging. [15:21] 101 are beginner classes [15:21] hellboy195: yes, you can drop the translation changes if there are done on purpose [15:21] geser: k, thx :) [15:21] thanks guys [15:21] Could a MOTU with some spare time check my fix for Bug #195068 [15:21] Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Undecided,In progress] https://launchpad.net/bugs/195068 [15:22] geser: btw, I forgot you are german. nice ^^ [15:22] hellboy195: check lines 281-288 if it needs to be kept [15:23] geser: I suppose so because latest ubuntu deleted line and debian evidently not [15:23] hellboy195: small note: I wouldn't undo the line wrapping in Build-Depends and simply add bc to the last line. This makes the diff a little bit smaller and also easier to check what exactly have changed in Build-Depends [15:24] geser: well, Debian did it so also grab-merge. but I'll do it :) [15:24] hellboy195: argh, happens to often that I forget the 'not' [15:25] geser: ?? [15:26] hellboy195: "hellboy195: yes, you can drop the translation changes if there are done on purpose", there is a 'not' missing. It should be: ... if there are not done on purpose [15:26] geser: ah. didn't noticed that :) [15:26] s/there/they/ too [15:26] geser: no stress ^^ [15:27] geser: ah stupid question. adjust the build-deps in control file or is it enough to do it in the debdiff [15:28] it would break the debdiff if you'd do it there directly [15:28] afflux: :) [15:28] hellboy195: if you know how to edit a diff that it doesn't break, you can do it there, but I guess in debian/control and regenerate the debdiff is easier [15:29] now my stupid question: is there a reason to merge after FF? Maybe the changelog should reference a LP bug [15:29] * geser should re-read what he types before hitting the Enter-key [15:31] afflux: it's also a good idea to merge important bug fixes from Debian that aren't reported in LP yet [15:31] right. Didn't check them [15:33] afflux: me neither, I hope hellboy195 checked before starting to work on the merge [15:33] geser: wxwidgets? [15:33] persia: will you take care of bug #181494? [15:33] Launchpad bug 181494 in xnetcardconfig "Depends on obsolete xsu package" [Undecided,In progress] https://launchpad.net/bugs/181494 [15:34] hellboy195: yes [15:35] but also in general case [15:35] geser: well mostly I do merges because they are *worth* it [15:35] bobbo: was the Maintainer already MOTU in dx? [15:36] RainCT: ill just check [15:37] RainCT: the maintainer (Daniel Kobras) doesnt use Launchpad (no account) so im guessing no [15:40] bobbo: you have to set the MOTU Team as the maintainer and move the Debian Maintainer to a XSBC-Original-Maintainer field (running update-maintainer -from package ubuntu-dev-tools- in the source directory will do it automatically) [15:40] RainCT: ok, thought you would ask me to do that :) [15:42] bobbo: heh. Ping me when there's a new debdiff. [15:42] RainCT: what should i add to the changelog for that change? [15:43] bobbo: if you use update-maintainer it'll add an entry to the changelog automatically [15:43] bobbo: if not: "Update Maintainer field to match the DebianMaintainerField specification." or something like that [15:44] bobbo: sorry, didn't refresh that page, so I have just submitted a debdiff for the same issue. [15:45] RainCT: The debian standards is 3.6.2, should i bump it aswell? [15:45] bobbo: you also need to use a ubuntu version number to avoid the autosync overriding your changes. [15:46] james_w: thanks :D, so thats ubuntu1 instead of build1? [15:46] right [15:47] bobbo: about the standards version, do what you want. I'm happy with bumping it but other sponsors might not be. [15:50] RainCT: you should always keep SV up-to-date [15:51] jpatrick: I said I'm happy with it, but I found sponsors who didn't like such changes [15:51] RainCT: :/ [15:51] as in, unecessary diff to Debian [15:51] RainCT: thats the new debdiff up [15:52] RainCT: xnetcardconfig was never in Debian, so there is no unnessary diff to Debian [15:52] RainCT: Debian should update to then (file bug) :) [15:52] I guess the package could use a overhaul [15:53] xnetcardconfig was uploaded in Dec 2005 and never touched since then [15:54] geser: xnetcardconfig? [15:54] are we talking about an other package? [15:55] geser: ah. I ment bobbo's bug now :) [15:55] heya people :) [15:55] bug #195068 in dx [15:55] Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Undecided,In progress] https://launchpad.net/bugs/195068 [15:56] ah [15:57] argh.. I always use dget when I want to download a debdiff -.- [15:57] * RainCT is thinking about creating a function that chooses between wget and dget depending on the extension and aliasing both to it :P [15:58] RainCT: does dget work on a debdiff? [15:58] RainCT: doesn't dget work on a debdiff? [15:59] oh, it works :P [15:59] * RainCT blames Ctrl+C :P [15:59] thanks geser [16:03] bobbo: you could also add a Homepage field [16:04] http://www.opendx.org [16:06] RainCT: building now :D [16:08] >>> v = subprocess.Popen('apt-cache show firefox-3.0 | grep -m 1 ^Depends', shell=True, stdout=subprocess.PIPE).stdout.read() [16:08] E: Handler silently failed [16:08] anyone has an idea on why this sometimes fails (Python)? [16:09] RainCT: new debdiff: http://launchpadlibrarian.net/12173715/dx_4.4.0-3ubuntu1.debdiff [16:09] RainCT: no idea, but you can use the python apt module to do that, can't you? [16:09] pochu: do you know if there are examples somewhere? [16:09] RainCT: sec [16:10] RainCT: there are at /usr/share/doc/python-apt [16:11] RainCT: >>> c = apt.Cache() [16:11] >>> c.__getitem__('firefox-3.0').candidateDependencies [16:13] apt.Cache() is slow :/ [16:14] well, thanks pochu [16:15] * RainCT will look at it once he finishes exams [16:20] bobbo: if you bump standards version it is preferred to say what changed, and if nothing then "No changes required". [16:21] bobbo: could you also forward the homepage change to Debian please? [16:22] james_w: how would i go about forwarding to debian? Only ever worked on a few small Ubuntu bugs so far [16:23] bobbo: you can either use submittodebian in ubuntu-dev-tools (though I think that may fail here due to a bug I need to fix there). [16:24] bobbo: or you can use reportbug -B Debian and attach the patch. [16:24] bobbo: or you can just compose a mail to submit@bugs.debian.org and include some headers. [16:24] james_w: ok thanks [16:25] bobbo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467301 shows you what I did for the typo change. [16:25] Debian bug 467301 in libdx4 "libdx4: Typo in short desription" [Minor,Open] [16:25] You might find that a simple diff has the maintainer change and homepage addition in the same hunk, so you might have to do a little more to get a clean patch. [16:26] or you could omit the patch, and just ask them to add a header, and point to the page. [16:26] if you do that omit the patch tag and the ubuntu-patch usertag. [16:26] * RainCT doesn't think it's necessary to forward the patch, just reporting the issue is enough [16:28] james_w, RainCT will just report, pretty new to Ubuntu/Debian [16:30] RainCT: is my debdiff going to be uploaded? [16:30] yeah, for something like this just reporting it is enough, as if you add a patch they will probably still just do it by hand. [16:30] bobbo: I'm uploading it :) [16:30] I like to include patches most of the time, just for the image of it. [16:34] hi, is there a way to get projectm included in *buntu hardy [16:34] Ahmuck: currently, no, we are under feature freeze and new packages are no longer accepted [16:34] :-( [16:35] is there someone that might be willing to create a *buntu-deb for it? [16:35] E: dx source: build-depends-on-obsolete-package build-depends: xlibs-dev [16:35] will this fail to build? [16:36] RainCT: yes, at least on my gutsy system it does [16:36] E: Package xlibs-dev has no installation candidate [16:37] in hardy too [16:37] do you know what package replaces it? [16:37] RainCT: it got split in several packages [16:37] hey guys. i'm having some problems i had never run into. dput hangs uploading at the last kb [16:38] RainCT: there's a new upload of dx in Debian [16:39] RainCT: it fixes the xlibs-dev dependency, and also the typo. [16:45] RainCT: want me to prepare a debdiff that backports the stuff from the new upload to the current hardy upstream? [16:45] or would a sync be better? [16:47] nixternal: heh, I might as well talk to you here [16:47] (less noise on twitter) [16:47] james_w: has #195068 been fixed in Debian? [16:48] bobbo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195068 ? [16:48] Debian bug 195068 in uw-imapd-ssl "mutt-1.5.4i: imap in config file generates errors" [Normal,Open] [16:49] Nah our Bug #195068 ;) dx, you submitted it to debian [16:49] Launchpad bug 195068 in dx "[typo] in package description: Currently Exploror" [Wishlist,In progress] https://launchpad.net/bugs/195068 [16:49] hm, it won't fail to build [16:49] ah, sorry, yeah, it was fixed in the same upload. [16:49] bonjour Zic [16:50] as xlibs-dev is an alternative dependency [16:50] bobbo: http://packages.qa.debian.org/d/dx/news/20080216T210206Z.html [16:50] bobbo: it doesn't add the homepage though by the look of it. [16:51] james_w: Hardy crashed when i was about to submit the bug to debian, its up there now though but they musnt have seen it before upload [16:52] bobbo: the upload was about a week ago, so that's not surprising :). I should have looked a little harder before filing. [16:52] james_w: ah! ok [16:54] * xhaker tries dput -P [16:55] bobbo, james_w: hm.. So should I upload bobbo's changes, or will you request a sync and a feature freeze exception? [16:56] RainCT: I don't care enough to request an FFe. I also think the severity of the bug we started with doesn't warrant much effort on this package before release. [16:57] However, the other changes in the upload look like they may be worthwhile, but I don't really want to pick through them. [16:57] nm, i see projectm is in the hardy repositiories [16:57] I'd be in favour of just letting them add the Homepage field, and then taking the autosync after hardy. However, bobbo may be interested in doing the work, I'm not sure. [16:58] james_w, RainCT: I wouldnt have a clue how to do a sync and get an FFe [16:59] i learnt how to do a debdiff about a month ago :) [16:59] bobbo: syncs are easy. FFe, not so, but we can help you to do it if you are interested. [17:00]