[00:00] persia: sounds easier than it is, cause pygtk throws X Window System errors, after closing a forked process [00:01] tbf: Depends on the app, but please take anything I say with care when applying to anything related to python. [00:02] tbf: 700km by plane wouldn't be so bad [00:03] azeem: car [00:03] ok, that's worse [00:04] oh, that's far indeed [00:04] sistpoty: berlin-stuttgart [00:04] Well, depends on the car and local airport regulations. For distances of <500km in some parts of the world, cars are faster. [00:04] still, it's better to drive 700km on the Autobahn, then through Poland and Ukraine [00:04] than* === kitterma is now known as ScottK2 [00:04] azeem: with a little baby you only can choose between train and car [00:05] heh [00:05] well, and using the car is significantly cheaper... [00:05] why do you have to drive 700km with a little baby? [00:05] Because they're to young to stay at home by themselves. [00:05] azeem: 'cause we prefer visting my parents in law, instead of having them in our flat and bugging us [00:06] heh, fair enough [00:06] my GF's mother is living together with her in some sort of WG [00:07] 700km's probably also cheaper if there were more than 2 or so passengers to get there [00:07] persia: as long as you stay within germany flying is like taking a bus [00:08] persia: you checkin 20 minutes before departure, take your seats.... fly for 90 minutes max., get your stuff back within minutes and leave [00:08] tbf: That being the reason I prefer trains to planes for local travel in Germany. A bus shouldn't fly (and yes, it does feel like a bus) :) [00:09] persia: trains are fskingly expensive in germany [00:09] persia: and odly ICE's aren't half as ecological as deutsche bahn claims [00:10] persia: trains only give you a ecologic benifit, if you stay arround 160 km/h [00:10] which is the case for most ICE tracks... [00:10] tbf: True. I have the luxury of not living in Europe, making trains significantly cheaper for short stays. [00:10] above that barrier they waste as much, or even more energy than cars [00:10] eh, most tracks ICE run on [00:11] azeem: hmm? maybe that's the benifit of living in berlin... but the ice's i used usually went full steam [00:11] * sistpoty needs some sleep [00:11] good night === Martinp24 is now known as Martinp23 [00:52] weeee! [00:52] freedom! [00:52] jdong, see latest debdiff [00:52] vorian: -ENOLINK & -ETOOLAZYTOFINDIT [00:53] s/&/|/ [00:53] bug 192812 [00:53] Launchpad bug 192812 in ktorrent-kde4 "[FF exception] New upstream release ktorrent-kde4 3.0.0 " [Wishlist,Confirmed] https://launchpad.net/bugs/192812 [00:53] new com.ubuntu.irc.ThankYouMessage(net.launchpad.users.get("vorian")) [00:54] (top signs you've been coding in Java for a day) [00:54] jdong, you are nuts [00:54] :P [00:55] vorian: with regards to that debdiff are you SURE that all the changes in the tarball are representable by that debdiff? [00:56] let me just filterdiff -i 'debian/*' [00:56] jdong, uscan then uupdate then debuild [00:56] vorian: so are you giving up on the cdbs method? [00:56] jdong, aye [00:56] kind of [00:58] vorian: elaborate please [01:24] I wonder why the wrapper in kde.mk isn't working [01:42] drwxr-xr-x root/root 0 2008-02-29 19:30 ./usr/bin/ [01:42] -rwxr-xr-x root/root 169 2008-02-29 19:30 ./usr/bin/ktorrent-kde4 [01:42] -rwxr-xr-x root/root 171 2008-02-29 19:30 ./usr/bin/ktupnptest-kde4 [01:42] vorian and jdong: the new debdiff for ktorrent-kde4 does the wrapping it seems..if this was the issue you all were talking about [01:43] note to self: when in Virtualbox, ctrl+alt+backspace doesn't restart X in VBox but restarts the systems X [01:44] nixternal: there is no wrapper in kde.mk, btw [01:45] nixternal: the so-called wrapper seems to just sed the .desktop file to /usr/lib/kde4/bin rather than /usr/bin, which (1) I'm not sure even works with the PATHs (2) isn't friendly to someone who wants to call ktorrent from the CLI [01:48] they would call ktorrent-kde4 from the cli [01:49] jdong: i can run kde4 apps from my gnome menu [01:50] oh, i see what you're saying [01:54] nixternal: right, that's with the wrapper restored from the earlier packaging [01:54] nixternal: that's not something that's availabe if only kde4.mk were used [01:55] the so called wrapper target that I saw in the .mk file was just that sed job [01:55] which, I don't have a kde4 setup to test, I suspect wouldn't even work unless paths were mangled via something automagic that I don't know about [01:55] (grumble which Ubuntu tends to do more often than not :D) [01:55] ahh [01:56] I'd personally feel more comfortable with vorian's latest debdiff (a straight uupdate from our manual wrappered previous revisions) [01:56] ya, I still use the old school wrapper in debian/rules [01:56] just wanted to check that that's okay with everyone [01:56] agreed [01:56] the one in kde.mk seemed to only work when there were multiple binaries in the package [01:56] jdong: ditto [01:56] okay, then let me prepare such for upload :) [02:13] NOOOOOOOOOOOOOOO [02:13] permissions error on my results dir caused that entire ktorrent build to be discarded [02:15] ktorrent doesn't take that long to build tho. you'll be ok. [02:15] DarkMageZ: meh ktorent-kde4 did take the past 15 minutes to build [02:15] jdong, really? [02:15] * vorian checks build logs [02:16] vorian: yeah, in a pbuilder; though I was messing with some other stuff that's disk intensive [02:16] i seeeeee [02:16] namely cloning the rockbox svn repo [02:16] is this 3.0 release for hardy? [02:16] he [02:17] DarkMageZ, aye [02:17] hmm, now i've just got to figure out how to move my 2.2.5 configs to 3.0 [02:31] vorian: ktorrent-kde4 uploaded [02:31] ^5 [02:32] thanks jdong [02:33] :) [02:34] * jdong continues 3-way merging his rockbox-on-steroids === mdomsch_ is now known as mdomsch === vorian is now known as vorian_ === steve__ is now known as vorian [05:57] well that was embarrasing [05:58] just spent an hour figuring out why it was building my package as -0 instead of -1... i forgot that changelog has the latest at the top not bottom >_< [05:58] *facepalm* [05:59] jscinoz: doh :-) [05:59] le sigh [06:25] G'morning. === freeflyi1g is now known as freeflying [06:42] When does next development cycle begin...? [06:43] once Hardy is released [06:44] Probable date of hardy release? [06:45] coolbhavi: https://wiki.ubuntu.com/HardyReleaseSchedule [06:48] Thanks [08:20] superm1: If you're around, please have a look at my comment on your libmime-lite upload bug... [08:20] yeah i am [08:20] ScottK, have the bug number handy? [08:20] Bug #197192 [08:20] Launchpad bug 197192 in mythbuntu "8.04-alpha2 installs bad mail config" [Undecided,Fix committed] https://launchpad.net/bugs/197192 [08:22] whew. that's not cool [08:22] okay i'll get this taken care of further [08:22] (tomorrow morning that is) [08:22] Sure. The bug was just filed against a later version, but I think we ought to make sure ... [08:23] thanks for looking further into it. did you have a particular interest in mime lite, or just that efficient :)? [08:24] I just say it on -changes and got to wondering why it would have been a dependency. [08:24] ah [08:24] Usually stuff is in depends for a reason ... [08:25] well i sent an email to the debian maintainer to ask about it a few days ago [08:25] and he hadn't responded [08:25] in any case, g'night :) [08:25] It took just a minute to see what was in BTS... [08:25] Good night. === doko_ is now known as doko === tritium is now known as HDStrikeOut === kuechengarten is now known as thekorn_ === Gunirus_ is now known as Gunirus [12:13] DktrKranz: yeah starplot got synced but it never build. Despite that I have to omit previous changelog entries. ? [12:14] hellboy195, make a new debdiff on top of the synced version or the one in Debian (since they have a newer one) [12:16] DktrKranz: well my merge is about the new one ;) But I'll make a new debdiff [12:27] DktrKranz: btw, thanks for correcting the lufs changelog xD and thank you for looking at my stuff ^^ [12:28] you're welcome [12:50] If im bumping DH_COMPAT to version 6 what version of debhelper should the build-deps require? [12:51] >=6 i believe [12:51] yup [12:51] ah thanks, didnt know it was that simple [12:52] you do find some islands of simplicity from time to time :-) [13:03] Hi [13:04] RainCT: Hey. [13:04] Hello RainCT [13:04] Anyone bored and want to process some updates? [13:04] bobbo: better to use compat level 4 or 5 if you don't need the features from 6 (see 'man debhelper') [13:05] * persia has a menu available: maintainer mangling, NBS issues, FTBFS issues, user-supplied patches, outdated menu files, and more [13:05] bobbo: and sorry for not looking at it yesterday :) [13:05] heh [13:07] persia: well, give me some URL [13:07] RainCT: Any preference for type of work? [13:07] http://tinyurl.com/2stsyf has user-submitted patches [13:07] bobbo: I recommend using a debian/compat file instead of DH_COMPAT [13:08] `wget -O - http://archive.ubuntu.com/ubuntu/dists/hardy/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintainer -FVersion ubuntu | grep-dctrl -sPackage -FMaintainer -v -n ubuntu | sort -u` need maintainer mangling [13:09] jpatrick: how can I open a URL from konsole without having to copy it? [13:09] http://people.ubuntu.com/~ubuntu-archive/NBS/ has NBS stuff. [13:10] * RainCT wonders what NBS is :) [13:10] Not-Built-from-Source [13:10] Essentially, some binary package names change for certain types of transitions. [13:10] RainCT: gnome-open url [13:10] RainCT: that feature is only in konsole-kde4 [13:10] As a result, packages that depend on those binary packages cannot be installed. [13:11] HighNo: I said without copying it.. [13:11] doh, kde - hmmm [13:11] RainCT: KDE, right? I am a GNOME guy, urls are always clickable there... [13:11] Frequently, a rebuild will cause a selection of new binary dependencies, and the package will work (although sometimes one needs to adjust debian/control, and more rarely, one needs to port the package to work with the new system) [13:12] HighNo: Not always yet. Would you like to help finish the migration to GTK+2? [13:12] HighNo: I use GNOME too, but I switched to irssi now and want to have a hideable terminal, so I'm using yakuake.. (don't like tilda) [13:13] RainCT: I think you could use some kind of strange scripting involving grep http /dev/pts/X ... :-) [13:13] persia: hm, how could I help there? [13:13] persia: allright, I'll look at some.. Thanks :) [13:14] HighNo: Great question :-) [13:15] :-) well, ok - how can I help there? [13:15] HighNo: `apt-cache rdepends libgtk1.2` run against a Hardy apt-cache provides a quick&dirty list of applications that need to be reviewed for porting, removal, etc. [13:16] persia: would that involve installing hardy first? [13:16] Debian is working on getting this done for lenny, so there may be patches available from Debian for some of them. [13:16] New upstream version 2.4.0 of pidgin yesterday [13:17] HighNo: No, just having a hardy apt-cache. You could use a chroot, or generate a hardy apt-cache in a temporary directory (by passing the appropriate apt configuration options). [13:17] Alternately, download a hardy packages file, and use grep-dctrl. [13:18] persia: And what exactly should we do with that list of packages? [13:19] persia: ok, I think I still have a pbuilder hardy environment flying around somewhere so I guess that I could do that... [13:19] * Iulian hides behind HighNo [13:20] persia: errm: apt-cache rdepends libgtk1.2 -> W: Unable to locate package libgtk1.2 [13:21] args, have to setup universe too [13:21] HighNo: Yep. It's MOTU stuff :) Anyway, if you don't want a chroot, http://paste.ubuntu.com/5159/ might help. [13:22] that's too late now - pbuilder login still works... [13:22] (except I forgot a bunch of '$' characters before "USER") [13:22] mok0: pidgin 2.4, nexuiz 2.4 , gimp 2.4.5 ,.. :) [13:22] persia: ok, that's a hell of a list [13:22] persia: so what would be the next step? [13:22] hellboy195: wow [13:23] mok0: and all were released yesterday ^^ [13:23] Iulian: The idea would be to make them not depend on libgtk1.2. The mechanism for doing so depends on the package. [13:23] hellboy195: ah, of course, 29.2 :-) [13:24] persia: Ohh, right. [13:24] persia: so we are into patching the sources, right? [13:24] HighNo: Pick a package. Check Debian to see if there is a patch available. Check upstream to see if there is a patch available. If either is the case, apply and test the patch. If it works cleanly, submit a debdiff. [13:24] If neither is the case, patch the source, and send upstream and to Debian. [13:25] mok0: what do you find. how many will get into hardy? [13:25] Note that the patches have to be small to get in past BetaFreeze, so what doesn't get done this week should be pushed upstream and to Debian so that it doesn't have to be done next cycle. [13:25] hellboy195: 0 :-( [13:25] mok0: no FFE candidates? [13:26] Don't know... from what it looks, pidgin 2.4 fixes a lot of bugs [13:27] Don't know if that's true of the others [13:27] we'll see [13:27] ... but they will tell us to wait for the Debian update [13:29] I've submitted an updated .dsc and .diff.gz for gPodder 0.10.4 in Hardy, can someone please upload the new package? https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/197256 [13:29] Launchpad bug 197256 in gpodder "gpodder crashed with TypeError in show_message()" [Undecided,New] [13:29] For pidgin, check in #ubuntu-desktop. It might be fairly easy to get both updated, if it is indeed only bugfixes. [13:30] persia: I think I didn't really understand that FBS stuff.. Both installing packages from that list and installing packaging depending on packages in that list works.. [13:30] thp: Just as a note, the .dsc doesn't help for sponsoring. Also, for updates that are not new upstream versions, a debdiff against the current package is preferred for review. [13:31] persia: what if packages are like VERY old - I picked gman and it shows the last update is 2006 and had very low changes, being updated 2001 the last time with new features [13:31] thp: Also, you'll want to subscribe ubuntu-universe-sponsors to request the upload. It may be worth reviewing https://wiki.ubuntu.com/MOTU/Contributing. [13:31] HighNo: Then you likely don't have much competition for the patch development :) [13:31] persia: hehe [13:32] RainCT: Would you like to walk through an NBS check together as an example? [13:32] persia: so, I should add the debdiff of the two .dsc files to the bug report? [13:32] thp: Please, and subscribe the sponsors queue. [13:32] persia: if you have time, sure :) [13:33] RainCT: Sure. Essentially, everything currently works because the outdated binary packages haven't been removed yet (to avoid breakage). Once everything is confirmed as ported, the binaries no longer built from source can be removed from the archive, making everything cleaner. [13:34] * persia looks for a good example [13:34] OK. Let's look at libmpich1.0c2 [13:35] thanks, bye [13:35] The current source package for mpich builds a library called libmpich1.0ldbl instead of libmpich1.0c2, for the long-double transition. [13:36] Looking at http://people.ubuntu.com/~ubuntu-archive/NBS/libmpich1.0c2 we can see the reverse dependencies for the outdated libmpich1.0c2 for each supported architecture. [13:36] In this case, we have three binary packages to inspect: illuminator-demo, libluminate7, and libpetsc2.3.2 [13:37] persia: I found aria being abandoned for aria2 which is ok regarding GTK use - should I patch it? [13:38] Looking at a hardy cache, we can discover that those come from two sources: illuminator and petsc [13:38] HighNo: Do we have aria2 in the archives? That might be a big change to do after FeatureFreeze. Would it require a freeze exception? [13:39] RainCT: Are you with me so far? [13:39] persia: Yes :). [13:39] persia: aria2 is in universe [13:39] HighNo: Is there a good reason to have both aria and aria2? [13:40] persia: I downloaded illuminator's source (the other one will take some time) [13:41] RainCT: No rush. Take a look at the binary packages generated by the current petsc source. What do you see? [13:41] * persia is a huge fan of apt-cache, if this hasn't become clear already [13:42] persia: hm, aria has a GUI, aria2 has not but otherwise superceeds aria in functionality [13:42] I need to find to what source package a file "netkit-inetd.prerm" belongs from feisty. How can I do that? [13:42] persia: aria2 is actively developed [13:42] (I don't have a running feisty system) [13:43] mok0: chroot or alternate apt-cache. http://paste.ubuntu.com/5159/ was a little snippet I threw up earlier to give hints on generating alternate apt caches. [13:44] mok0: Anyway, any file in /var/lib/dpkg/info/ is always of the form $(binary-package).$(function) [13:44] persia: thanks!! [13:45] RainCT: hint: `apt-cache showsrc petsc` [13:45] persia: yep, got that [13:45] libpetsc2.3.3-dbg, libpetsc2.3.3-dev, petsc-dev, petsc2.3.3-doc, libpetsc2.3.3 [13:46] OK. Our reverse dependency is libpetsc2.3.2, which means we don't really care, as the new source doesn't use it, but we need to NBS libpetsc2.3.2 before we can NBS libmpich1.0c2 [13:46] (so you can stop the huge download) [13:47] Next step is to inspect the current binary packages to see if they have alternatives defined in the dependencies. I typically use aptitude for that, but other tools work as well. [13:48] In this case, there are hard-dependencies for libmpich1.0c2 for both illuminator-demo and libluuminate7. [13:50] Next thing to try is a rebuild. Update the changelog with a 0.10.0-4build1 entry, reporting the transition you are processing, don't touch any other files in the package, generate a new source candidate, and try a test build. [13:52] mok0: Oh, also, the feisty Contents.gz file ought be available for download, and can be processed by grep if you want a more specific solution :) [13:52] RainCT: Still with me? [13:52] persia: yes, rebuilding [13:53] RainCT: While that rebuild is happening, let's take a look at the libpetsc2.3.2 NBS list, just to start researching the recursion. [13:54] persia: it lists the same packages (illuminator-demo and libluminate7) [13:54] RainCT: Excellent. You might want to mention both transitions in the changelog then. [13:55] persia: Did so. Is the changelog entry OK like this: "Rebuild for transition to new libmpich and libpetsc versions."? [13:57] I like to state the specific versions (e.g. rebuild for libmpich1.0c2 -> libmpich1.0ldbl and libpetsc2.3.2 -> libpetsc2.3.3) just to make it clear that the specific transition is already complete (helps when there are a lot of transitions happening). [13:58] * persia wishes build-depending on tex didn't run mktexlsr so many times [13:59] persia: pbuilder is downloading 171MB and ETA is 3h -.- [14:00] RainCT: Are you still using your phone? I thought you had arranged an alternate connection. You might consider a local mirror (if you have disk space available): that way you only have to download things when they are updated. [14:00] persia: what if packages have a debian bug filed: xxx: should this package be removed ? [14:00] persia: like array-util has [14:01] HighNo: A package removal bug? [14:01] persia: Yes, we tried ADSL with two different providers and none worked... :( [14:01] persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456648 [14:01] Debian bug 456648 in array-util "array-util: should this package be removed?" [Important,Open] [14:04] RainCT: Anyway, the build failed for me: http://paste.ubuntu.com/5160/ [14:05] Next step is to track down the FTBFS issue, port illumintator to the new PetSC, and upload it. [14:05] HighNo: At this point, that's only a request for the Maintainer to consider removal, rather than a request for removal. [14:07] As a result, it's likely premature to remove it from Ubuntu (unless you expect to fix all the other packages first). [14:07] Maybe the next one will be easier to handle... [14:07] persia: too bad, I hoped I could at least drop that one... [14:08] * RainCT is away for a moment [14:09] HighNo: There are generally three reasons we drop packages: 1) Dropped from Debian and nobody wants to save it in Ubuntu, 2) Hopelessly buggy and replaced by a clear better alternative, and 3) Ubuntu has a different package from the same upstream source. [14:09] aria doesn't fall under #1 or #3, so you'd have to apply for #2. [14:10] The part that makes me unsure is you say aria2 doesn't have a GUI. Maybe you can find another replacement, but otherwise removal would be a regression. [14:11] Regressions of this type are sometimes acceptable, but it only makes sense to request an exception if we are removing libgtk1.2. Until the list of reverse dependencies is smaller, better to concentrate on cases where the replacement is more glaringly obvious. [14:19] persia: I need a bit of help resolving a bug, do you have time? [14:20] mok0: A little, but I'm for bed soon. Which bug? [14:20] 120080 [14:20] bug 120080 [14:20] bug #120080 [14:20] Launchpad bug 120080 in netkit-base "dpkg refuses to uninstall netkit-inetd due to script error" [Undecided,New] https://launchpad.net/bugs/120080 [14:20] I've found the problem, but I'm surprised it's still around [14:21] also look at bug 27385 [14:21] Launchpad bug 27385 in netkit-base "invoke-rc.d should be used" [High,Fix released] https://launchpad.net/bugs/27385 [14:21] Not calling update-rc.d properly? [14:22] * RainCT is back [14:22] In netkit-inetd.prerm it just calls /etc/init.d/inetd stop, but that fails if that script is not there [14:22] persia: I assume update-rc.d is more robust [14:23] persia: so it wont fail on a missing script [14:23] No, for this it likely wants invoke-rc.d inetd stop [14:23] mok0: that script is part of netkit-inetd and so it should be there [14:23] persia: exactly. But 27385 claims the problem was solved in dapper [14:23] HighNo: Not necessarily at postrm time [14:24] mok0: or am I missing something [14:24] mok0: that's way it is called .prerm right= [14:24] mok0: TO me it looks like Uekawa-san's patch only handled start and restart, but not stop. [14:24] HighNo: I can't explain the circumstances, but it sometimes fails [14:25] persia: the right construction should be added by dh_installinit [14:28] persia: perhaps I should just get rid of the prerm file and let dh_installinit handle it? (It's commented out in rules) [14:28] mok0: heh. That would be one way to solve it (and stops me from digging further into the installinit source to find out why it was generating inconsistent behaviour) [14:29] Just be sure to compare the autogenerated maintainer scripts with the manually generated ones. There may be some reason why it needs to be special. [14:29] persia: I'll try it. And also see if it's been fixed later [14:30] persia: working on clearing out my own bug submissions from when I was a n00b :-) [14:31] ... now I'm a n11b [14:31] mok0: That's a good plan. I started that once, but ended up getting distracted by trying to close all the bugs in the packages I had uploaded and get most of my diffs back to Debian and upstream, which led to more distractions... [14:32] Closing one's own bugs early and often is definitely ideal. [14:32] persia: the distraction bit... I've been there... [14:33] If you generate more bugs than you solve... that's not good [14:34] Depends. I've been doing that a lot in hardy (although I've been trying to get lists of potential bugs, rather than filing bugs), and I think it has led to a lot of fixes. [14:35] The main rule being that if you are generating a lot of bugs, be sure to also describe how to fix them, and call for volunteers to help fix them. [14:35] persia: heh, that's a good plan [14:36] (a good example would be the libgtk1.2 transition HighNo is looking at: we could file 300 bugs, but better to just have someone with some interest start investigating and proactively fixing them in advance) [14:36] my early bug descriptions actually did not contain enough inofrmation [14:36] mok0: Ah. Yes, generating lots if insufficiently triaged bugs is not as ideal :)( [14:37] Learning by doing is the way to go here. [14:37] And I can't leave my old incomplete bug submissions for others [14:38] Yep. Of course sometimes one gets bugs that one cannot solve yet. In these cases, best to file with as much information as possible, in the hopes it will be easy for someone else, and then work on things one can do, to make sure others have time for the hard ones (we all have different definitions of "hard") [14:39] Well, thanks for your help, persia. Don't let me keep you from getting your rest [14:41] mok0: Thanks for chasing it. Maintainer script failures are currently one of the things we have trouble detecting, and they are painfully visible to users (and appear to have trivial fixes), so it's important work. [14:42] persia: my pleasure :) === asac_ is now known as asac [14:46] persia: when a from the NBS list has no reverse dependencies anymore, is it removed automatically? [14:47] *when a package [14:52] I'm working on https://bugs.launchpad.net/ubuntu/+source/startupmanager/+bug/195028 and I have no idea how those files got there. I would like to add an rm call to the preinst of the package, would that be a good solution? [14:52] I suppose if the user uninstalled the package before upgrading to this proposed version it wouldn't help. [14:52] Launchpad bug 195028 in startupmanager "Upgrade bug gutsy to hardy (python errors)" [Undecided,New] [14:53] RainCT: autonomously, but not automatically. pitti checks every once in a while, but always appreciates when someone reports that a transition is complete in #ubuntu-devel. [14:59] persia: since I was away, I skimmed the log and read your "lesson" about NBS. Our wiki has 0 pages regarding this argument. What about opening a new page and copying the log there? [15:27] I can't debuild package swscanner even with build dependencies installed... I already found one which was missing, but now it complains about KDE headers not being installed; what package do I need for those, kdelibs-dev? [15:30] Iulian: Your patch on bug #196871 won't install the .desktop file; dh_desktop only registers it (you have to install it manually, with dh_install or whatever). [15:30] Launchpad bug 196871 in zblast "No .desktop file; here is one" [Wishlist,In progress] https://launchpad.net/bugs/196871 [15:31] warp10: good call. [15:31] Iulian: also, I think that dh_desktop should be in the binary-arch target (but I'm not really sure as I always work with cdbs) [15:35] Iulian: and if you update the Debian policy version please also move the Homepage to the source stanza === n3xu|laptop is now known as nexu [15:44] persia: I'm kind of stock. I patched cccd so far and it seems to compile build doesn't link. I don't know what to change -lgtk to in the linker command [15:44] brb [15:47] ahh, got it [15:57] hm, anyone - I am no c pro. what about an error like cccd.c: (.text+0x126a): undefined reference to `gtk_tooltips_set_colors' , is that a missing linker directive? [15:57] HighNo: yes [15:57] mok0: could you try to help me with that one? [15:57] HighNo: I can try :-) [15:58] mok0: makefile has this entry (now) LDFLAGS = -L/usr/lib `pkg-config --libs gtk+-2.0` which I thought should include everything needed [15:58] HighNo: most likely, you are linking to a version of the library where that function is not in -- either has been removed/renamed or does not yet exist [15:59] mok0: so I am compiling against a correct one but linking against a wrong one? [15:59] HighNo: Hmm [16:00] mok0: just for the records: CFLAGS = -O2 -Wall `pkg-config --cflags gtk+-2.0` [16:00] HighNo: It could also be a local function of the program that is n not gettting linked in [16:00] HighNo: try grepping the source for it [16:01] HighNo: it could also be mis-spelt [16:02] mok0: I just googled a bit more and found that it seems to be deprecated and not to be used in gtk+2... [16:02] HighNo: Ah. Then you need to figure out what has replaced it [16:02] HighNo: ... but you know that [16:04] mok0: funny thing is that I think it compiled - it should not do that right? [16:04] HighNo: depends on what you mean "compiled" [16:05] the compile will not discover that this routine is not included in the gtk library [16:05] only the linker [16:07] HighNo: It seems you can safely remove the call to gtk_tooltips_set_colors since it appears to not do anything [16:08] mok0: hehe, read the same thing just a few secs ago... [16:08] HighNo: then it must be correct :-) [16:09] HighNo: you know what to do now, right? [16:12] da**, is archive.ubuntu.com down again? [16:13] hm, seems to be ok again, must have been a local issue... [16:14] I need someone to test that package now - I don't have a cd drive :-) [16:24] mok0: persia: probably the funniest problem: I can't test the new package. It starts and acts exactly like the old version but that means it hangs after the start because I don't have a cdrom and it is a cd player package :-) [16:25] HighNo: I haven't followed the discussion... was this the bug you were trying to fix? [16:26] mok0: moving from gtk1.2 to gtk2 [16:27] HighNo: Ah. [16:27] HighNo: I guess the program should just abort with a message [16:28] I hope disk space will be enough for a vm to test it there. sure it would be nice to test it by someone with a real cd drive... [16:28] HighNo: the developers didn't think of a situation with anyone foolish enough to run a cd player program on a machine without a cd device [16:28] mok0: that's true but Ia m not the one to integrate that error message [16:29] HighNo: perhaps you should report it as a bug upstream, though [16:29] mok0: last change was 2006 - I don't think it is in active development :-) [16:30] There isn't yet a "Hardware-Depends:" option in debian/control [16:30] hehe [16:31] HighNo: I can't test it for you either, my machine at home is dead [16:39] Uses gtk1.2 pretty much == not under active development. [16:44] :-) [16:45] ok, I have a running package now, what should I do exactly to create the debdiff and where should I put it? Package is cccd [16:45] (And do I need to add anything to any copyright/control/changelog file?) [16:46] persia: please let me know what to do [16:47] hi RainCT [16:47] soc: hi :) [16:47] just downloading BloGTK ... [16:47] your changelog is impressive :-) [16:47] heh [16:48] if it has to be maintained in Ubuntu at least let's have a nice package :) [16:49] A package depends on libgtk1.2-dev and wont build in pbuilder, what should i replace libgtk1.2-dev with? [16:50] * RainCT is starting to hate telepathy and mono :D [16:51] RainCT: that changelog is almost like a 'what to do to package your stuff' wow- every step...was it more work than the actual change? :-) [16:51] bobbo: I'm just working on those things - use libgtk2.0-dev [16:51] bobbo: you will likely have to change the source and makefiles too [16:51] HighNo; thanks, will try that out === allee_ is now known as allee [16:52] HighNo: heh Might be :P. I'm wondering wheter a "* Repackage this." entry wouldn't have been better :P [16:54] * RainCT is thinking about leaving packaging for today.. [16:55] everything I try to build is failing lol [16:56] RainCT: is there a guide somwhere, how to do packaging right? [16:56] btw, will pidgin 2.4 get into hardy, or is it to late ? [16:56] !packagingguide [16:56] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [16:57] no [16:57] BAD NEXUIZ [16:58] the watchfile now somehow downloads the binary. [16:58] which left me very confused [16:58] thx [16:58] Does anyone know if a package that build-deps on libgtk1.2-dev will build for Hardy? [16:59] it should [16:59] bobbo: libgtk1.2-dev is still available in Hardy, so yes, if there isn't any problem with it it should build [16:59] * bobbo thanks god [17:01] bobbo: what error did you get from your pbuilder? [17:02] geser; http://pastebin.ubuntu.com/5166/ [17:02] top [17:02] geser: I think libgtk1.2 support in hardy is to be dropped? persia lets me work through all old packages and recompile/patch them to be gtk2 [17:03] RainCT: then why am I doing this stupidious work? :-) [17:03] HighNo: because gtk2 is twice as good [17:03] now that's a reason :-) [17:04] HighNo; if you are patching 'gpppon' any time soon i have a whole load of other fixes for it that wont build without gtk2 [17:04] bobbo - I can take that as my next one - no guarantee it works though... [17:04] HighNo: oh, but I guess it's not that easy as Debian would have already done it, gtk1 -> gtk2 needs porting [17:04] anybody help me please woth getting the correct debdiff done? [17:05] HighNo: where got you stuck? [17:06]