[00:00] <tbf> persia: sounds easier than it is, cause pygtk throws X Window System errors, after closing a forked process
[00:01] <persia> tbf: Depends on the app, but please take anything I say with care when applying to anything related to python.
[00:02] <azeem> tbf: 700km by plane wouldn't be so bad
[00:03] <tbf> azeem: car
[00:03] <azeem> ok, that's worse
[00:04] <sistpoty> oh, that's far indeed
[00:04] <tbf> sistpoty: berlin-stuttgart
[00:04] <persia> Well, depends on the car and local airport regulations.  For distances of <500km in some parts of the world, cars are faster.
[00:04] <azeem> still, it's better to drive 700km on the Autobahn, then through Poland and Ukraine
[00:04] <azeem> than*
[00:04] <tbf> azeem: with a little baby you only can choose between train and car
[00:05] <azeem> heh
[00:05] <tbf> well, and using the car is significantly cheaper...
[00:05] <azeem> why do you have to drive 700km with a little baby?
[00:05] <ScottK2> Because they're to young to stay at home by themselves.
[00:05] <tbf> azeem: 'cause we prefer visting my parents in law, instead of having them in our flat and bugging us
[00:06] <azeem> heh, fair enough
[00:06] <azeem> my GF's mother is living together with her in some sort of WG
[00:07] <jdong> 700km's probably also cheaper if there were more than 2 or so passengers to get there
[00:07] <tbf> persia: as long as you stay within germany flying is like taking a bus
[00:08] <tbf> 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] <persia> 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] <tbf> persia: trains are fskingly expensive in germany
[00:09] <tbf> persia: and odly ICE's aren't half as ecological as deutsche bahn claims
[00:10] <tbf> persia: trains only give you a ecologic benifit, if you stay arround 160 km/h
[00:10] <azeem> which is the case for most ICE tracks...
[00:10] <persia> tbf: True.  I have the luxury of not living in Europe, making trains significantly cheaper for short stays.
[00:10] <tbf> above that barrier they waste as much, or even more energy than cars
[00:10] <azeem> eh, most tracks ICE run on
[00:11] <tbf> 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] <sistpoty> good night
[00:52] <vorian> weeee!
[00:52] <vorian> freedom!
[00:52] <vorian> jdong, see latest debdiff
[00:52] <jdong> vorian: -ENOLINK & -ETOOLAZYTOFINDIT
[00:53] <jdong> s/&/|/
[00:53] <vorian> bug 192812
[00:53] <ubotu> 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] <jdong> new com.ubuntu.irc.ThankYouMessage(net.launchpad.users.get("vorian"))
[00:54] <jdong> (top signs you've been coding in Java for a day)
[00:54] <vorian> jdong, you are nuts
[00:54] <vorian> :P
[00:55] <jdong> vorian: with regards to that debdiff are you SURE that all the changes in the tarball are representable by that debdiff?
[00:56] <jdong> let me just filterdiff -i 'debian/*'
[00:56] <vorian> jdong, uscan then uupdate then debuild
[00:56] <jdong> vorian: so are you giving up on the cdbs method?
[00:56] <vorian> jdong, aye
[00:56] <vorian> kind of
[00:58] <jdong> vorian: elaborate please
[01:24] <nixternal> I wonder why the wrapper in kde.mk isn't working
[01:42] <nixternal> drwxr-xr-x root/root         0 2008-02-29 19:30 ./usr/bin/
[01:42] <nixternal> -rwxr-xr-x root/root       169 2008-02-29 19:30 ./usr/bin/ktorrent-kde4
[01:42] <nixternal> -rwxr-xr-x root/root       171 2008-02-29 19:30 ./usr/bin/ktupnptest-kde4
[01:42] <nixternal> 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] <nixternal> note to self: when in Virtualbox, ctrl+alt+backspace doesn't restart X in VBox but restarts the systems X
[01:44] <jdong> nixternal: there is no wrapper in kde.mk, btw
[01:45] <jdong> 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] <nixternal> they would call ktorrent-kde4 from the cli
[01:49] <Amaranth> jdong: i can run kde4 apps from my gnome menu
[01:50] <Amaranth> oh, i see what you're saying
[01:54] <jdong> nixternal: right, that's with the wrapper restored from the earlier packaging
[01:54] <jdong> nixternal: that's not something that's availabe if only kde4.mk were used
[01:55] <jdong> the so called wrapper target that I saw in the .mk file was just that sed job
[01:55] <jdong> 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] <jdong> (grumble which Ubuntu tends to do more often than not :D)
[01:55] <nixternal> ahh
[01:56] <jdong> I'd personally feel more comfortable with vorian's latest debdiff (a straight uupdate from our manual wrappered previous revisions)
[01:56] <nixternal> ya, I still use the old school wrapper in debian/rules
[01:56] <jdong> just wanted to check that that's okay with everyone
[01:56] <vorian> agreed
[01:56] <nixternal> the one in kde.mk seemed to only work when there were multiple binaries in the package
[01:56] <nixternal> jdong: ditto
[01:56] <jdong> okay, then let me prepare such for upload :)
[02:13] <jdong> NOOOOOOOOOOOOOOO
[02:13] <jdong> permissions error on my results dir caused that entire ktorrent build to be discarded
[02:15] <DarkMageZ> ktorrent doesn't take that long to build tho. you'll be ok.
[02:15] <jdong> DarkMageZ: meh ktorent-kde4 did take the past 15 minutes to build
[02:15] <vorian> jdong, really?
[02:15]  * vorian checks build logs
[02:16] <jdong> vorian: yeah, in a pbuilder; though I was messing with some other stuff that's disk intensive
[02:16] <vorian> i seeeeee
[02:16] <jdong> namely cloning the rockbox svn repo
[02:16] <DarkMageZ> is this 3.0 release for hardy?
[02:16] <vorian> he
[02:17] <vorian> DarkMageZ, aye
[02:17] <DarkMageZ> hmm, now i've just got to figure out how to move my 2.2.5 configs to 3.0
[02:31] <jdong> vorian: ktorrent-kde4 uploaded
[02:31] <vorian> ^5
[02:32] <vorian> thanks jdong
[02:33] <jdong> :)
[02:34]  * jdong continues 3-way merging his rockbox-on-steroids
[05:57] <jscinoz> well that was embarrasing
[05:58] <jscinoz> 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] <jscinoz> *facepalm*
[05:59] <LaserJock> jscinoz: doh :-)
[05:59] <jscinoz> le sigh
[06:25] <Iulian> G'morning.
[06:42] <coolbhavi> When does next development cycle begin...?
[06:43] <LaserJock> once Hardy is released
[06:44] <coolbhavi> Probable date of hardy release?
[06:45] <Iulian> coolbhavi: https://wiki.ubuntu.com/HardyReleaseSchedule
[06:48] <coolbhavi> Thanks
[08:20] <ScottK> superm1: If you're around, please have a look at my comment on your libmime-lite upload bug...
[08:20] <superm1> yeah i am
[08:20] <superm1> ScottK, have the bug number handy?
[08:20] <ScottK> Bug #197192
[08:20] <ubotu> Launchpad bug 197192 in mythbuntu "8.04-alpha2 installs bad mail config" [Undecided,Fix committed] https://launchpad.net/bugs/197192
[08:22] <superm1> whew.  that's not cool
[08:22] <superm1> okay i'll get this taken care of further
[08:22] <superm1> (tomorrow morning that is)
[08:22] <ScottK> Sure.  The bug was just filed against a later version, but I think we ought to make sure ...
[08:23] <superm1> thanks for looking further into it.  did you have a particular interest in mime lite, or just that efficient :)?
[08:24] <ScottK> I just say it on -changes and got to wondering why it would have been a dependency.
[08:24] <superm1> ah
[08:24] <ScottK> Usually stuff is in depends for a reason ...
[08:25] <superm1> well i sent an email to the debian maintainer to ask about it a few days ago
[08:25] <superm1> and he hadn't responded
[08:25] <superm1> in any case, g'night :)
[08:25] <ScottK> It took just a minute to see what was in BTS...
[08:25] <ScottK> Good night.
[12:13] <hellboy195> DktrKranz: yeah starplot got synced but it never build. Despite that I have to omit previous changelog entries. ?
[12:14] <DktrKranz> hellboy195, make a new debdiff on top of the synced version or the one in Debian (since they have a newer one)
[12:16] <hellboy195> DktrKranz: well my merge is about the new one ;) But I'll make a new debdiff
[12:27] <hellboy195> DktrKranz: btw, thanks for correcting the lufs changelog xD and thank you for looking at my stuff ^^
[12:28] <DktrKranz> you're welcome
[12:50] <bobbo> If im bumping DH_COMPAT to version 6 what version of debhelper should the build-deps require?
[12:51] <HighNo> >=6 i believe
[12:51] <james_w> yup
[12:51] <bobbo> ah thanks, didnt know it was that simple
[12:52] <james_w> you do find some islands of simplicity from time to time :-)
[13:03] <RainCT> Hi
[13:04] <persia> RainCT: Hey.
[13:04] <Iulian> Hello RainCT
[13:04] <persia> Anyone bored and want to process some updates?
[13:04] <RainCT> 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] <RainCT> bobbo: and sorry for not looking at it yesterday :)
[13:05] <RainCT> heh
[13:07] <RainCT> persia: well, give me some URL
[13:07] <persia> RainCT: Any preference for type of work?
[13:07] <persia> http://tinyurl.com/2stsyf has user-submitted patches
[13:07] <jpatrick> bobbo: I recommend using a debian/compat file instead of DH_COMPAT
[13:08] <persia> `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] <RainCT> jpatrick: how can I open a URL from konsole without having to copy it?
[13:09] <persia> http://people.ubuntu.com/~ubuntu-archive/NBS/ has NBS stuff.
[13:10]  * RainCT wonders what NBS is :)
[13:10] <persia> Not-Built-from-Source
[13:10] <persia> Essentially, some binary package names change for certain types of transitions.
[13:10] <HighNo> RainCT: gnome-open url
[13:10] <jpatrick> RainCT: that feature is only in konsole-kde4
[13:10] <persia> As a result, packages that depend on those binary packages cannot be installed.
[13:11] <RainCT> HighNo: I said without copying it..
[13:11] <HighNo> doh, kde - hmmm
[13:11] <HighNo> RainCT: KDE, right? I am a GNOME guy, urls are always clickable there...
[13:11] <persia> 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] <persia> HighNo: Not always yet.  Would you like to help finish the migration to GTK+2?
[13:12] <RainCT> 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] <HighNo> RainCT: I think you could use some kind of strange scripting involving grep http /dev/pts/X ... :-)
[13:13] <HighNo> persia: hm, how could I help there?
[13:13] <RainCT> persia: allright, I'll look at some.. Thanks :)
[13:14] <Iulian> HighNo: Great question :-)
[13:15] <HighNo> :-) well, ok - how can I help there?
[13:15] <persia> 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] <HighNo> persia: would that involve installing hardy first?
[13:16] <persia> Debian is working on getting this done for lenny, so there may be patches available from Debian for some of them.
[13:16] <mok0> New upstream version 2.4.0 of pidgin yesterday
[13:17] <persia> 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] <persia> Alternately, download a hardy packages file, and use grep-dctrl.
[13:18] <Iulian> persia: And what exactly should we do with that list of packages?
[13:19] <HighNo> 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] <HighNo> persia: errm: apt-cache rdepends libgtk1.2 -> W: Unable to locate package libgtk1.2
[13:21] <HighNo> args, have to setup universe too
[13:21] <persia> HighNo: Yep.  It's MOTU stuff :)  Anyway, if you don't want a chroot, http://paste.ubuntu.com/5159/ might help.
[13:22] <HighNo> that's too late now - pbuilder login still works...
[13:22] <persia> (except I forgot a bunch of '$' characters before "USER")
[13:22] <hellboy195> mok0: pidgin 2.4, nexuiz 2.4 , gimp 2.4.5 ,.. :)
[13:22] <HighNo> persia: ok, that's a hell of a list
[13:22] <HighNo> persia: so what would be the next step?
[13:22] <mok0> hellboy195: wow
[13:23] <hellboy195> mok0: and all were released yesterday ^^
[13:23] <persia> Iulian: The idea would be to make them not depend on libgtk1.2.  The mechanism for doing so depends on the package.
[13:23] <mok0> hellboy195: ah, of course, 29.2 :-)
[13:24] <Iulian> persia: Ohh, right.
[13:24] <HighNo> persia: so we are into patching the sources, right?
[13:24] <persia> 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] <persia> If neither is the case, patch the source, and send upstream and to Debian.
[13:25] <hellboy195> mok0: what do you find. how many will get into hardy?
[13:25] <persia> 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] <mok0> hellboy195: 0 :-(
[13:25] <hellboy195> mok0: no FFE candidates?
[13:26] <mok0> Don't know... from what it looks, pidgin 2.4 fixes a lot of bugs
[13:27] <mok0> Don't know if that's true of the others
[13:27] <hellboy195> we'll see
[13:27] <mok0> ... but they will tell us to wait for the Debian update
[13:29] <thp> 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] <ubotu> Launchpad bug 197256 in gpodder "gpodder crashed with TypeError in show_message()" [Undecided,New]
[13:29] <persia> For pidgin, check in #ubuntu-desktop.  It might be fairly easy to get both updated, if it is indeed only bugfixes.
[13:30] <RainCT> 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] <persia> 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] <HighNo> 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] <persia> 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] <persia> HighNo: Then you likely don't have much competition for the patch development :)
[13:31] <HighNo> persia: hehe
[13:32] <persia> RainCT: Would you like to walk through an NBS check together as an example?
[13:32] <thp> persia: so, I should add the debdiff of the two .dsc files to the bug report?
[13:32] <persia> thp: Please, and subscribe the sponsors queue.
[13:32] <RainCT> persia: if you have time, sure :)
[13:33] <persia> 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] <persia> OK.  Let's look at libmpich1.0c2
[13:35] <thp> thanks, bye
[13:35] <persia> The current source package for mpich builds a library called libmpich1.0ldbl instead of libmpich1.0c2, for the long-double transition.
[13:36] <persia> 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] <persia> In this case, we have three binary packages to inspect: illuminator-demo, libluminate7, and libpetsc2.3.2
[13:37] <HighNo> persia: I found aria being abandoned for aria2 which is ok regarding GTK use - should I patch it?
[13:38] <persia> Looking at a hardy cache, we can discover that those come from two sources: illuminator and petsc
[13:38] <persia> 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] <persia> RainCT: Are you with me so far?
[13:39] <RainCT> persia: Yes :).
[13:39] <HighNo> persia: aria2 is in universe
[13:39] <persia> HighNo: Is there a good reason to have both aria and aria2?
[13:40] <RainCT> persia: I downloaded illuminator's source (the other one will take some time)
[13:41] <persia> 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] <HighNo> persia: hm, aria has a GUI, aria2 has not but otherwise superceeds aria in functionality
[13:42] <mok0> I need to find to what source package a file "netkit-inetd.prerm" belongs from feisty. How can I do that?
[13:42] <HighNo> persia: aria2 is actively developed
[13:42] <mok0> (I don't have a running feisty system)
[13:43] <persia> 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] <persia> mok0: Anyway, any file in /var/lib/dpkg/info/ is always of the form $(binary-package).$(function)
[13:44] <mok0> persia: thanks!!
[13:45] <persia> RainCT: hint: `apt-cache showsrc petsc`
[13:45] <RainCT> persia: yep, got that
[13:45] <RainCT> libpetsc2.3.3-dbg, libpetsc2.3.3-dev, petsc-dev, petsc2.3.3-doc, libpetsc2.3.3
[13:46] <persia> 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] <persia> (so you can stop the huge download)
[13:47] <persia> 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] <persia> In this case, there are hard-dependencies for libmpich1.0c2 for both illuminator-demo and libluuminate7.
[13:50] <persia> 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] <persia> 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] <persia> RainCT: Still with me?
[13:52] <RainCT> persia: yes, rebuilding
[13:53] <persia> 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] <RainCT> persia: it lists the same packages (illuminator-demo and libluminate7)
[13:54] <persia> RainCT: Excellent.  You might want to mention both transitions in the changelog then.
[13:55] <RainCT> persia: Did so. Is the changelog entry OK like this: "Rebuild for transition to new libmpich and libpetsc versions."?
[13:57] <persia> 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] <RainCT> persia: pbuilder is downloading 171MB and ETA is 3h -.-
[14:00] <persia> 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] <HighNo> persia: what if packages have a debian bug filed: xxx: should this package be removed ?
[14:00] <HighNo> persia: like array-util has
[14:01] <persia> HighNo: A package removal bug?
[14:01] <RainCT> persia: Yes, we tried ADSL with two different providers and none worked... :(
[14:01] <HighNo> persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456648
[14:01] <ubotu> Debian bug 456648 in array-util "array-util: should this package be removed?" [Important,Open]
[14:04] <persia> RainCT: Anyway, the build failed for me: http://paste.ubuntu.com/5160/
[14:05] <persia> Next step is to track down the FTBFS issue, port illumintator to the new PetSC, and upload it.
[14:05] <persia> HighNo: At this point, that's only a request for the Maintainer to consider removal, rather than a request for removal.
[14:07] <persia> As a result, it's likely premature to remove it from Ubuntu (unless you expect to fix all the other packages first).
[14:07] <persia> Maybe the next one will be easier to handle...
[14:07] <HighNo> persia: too bad, I hoped I could at least drop that one...
[14:08]  * RainCT is away for a moment
[14:09] <persia> 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] <persia> aria doesn't fall under #1 or #3, so you'd have to apply for #2.
[14:10] <persia> 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] <persia> 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] <mok0> persia: I need a bit of help resolving a bug, do you have time?
[14:20] <persia> mok0: A little, but I'm for bed soon.  Which bug?
[14:20] <mok0> 120080
[14:20] <mok0> bug 120080
[14:20] <persia> bug #120080
[14:20] <ubotu> 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] <mok0> I've found the problem, but I'm surprised it's still around
[14:21] <mok0> also look at bug 27385
[14:21] <ubotu> Launchpad bug 27385 in netkit-base "invoke-rc.d should be used" [High,Fix released] https://launchpad.net/bugs/27385
[14:21] <persia> Not calling update-rc.d properly?
[14:22]  * RainCT is back
[14:22] <mok0> In netkit-inetd.prerm it just calls /etc/init.d/inetd stop, but that fails if that script is not there
[14:22] <mok0> persia: I assume update-rc.d is more robust
[14:23] <mok0> persia: so it wont fail on a missing script
[14:23] <persia> No, for this it likely wants invoke-rc.d inetd stop
[14:23] <HighNo> mok0: that script is part of netkit-inetd and so it should be there
[14:23] <mok0> persia: exactly. But 27385 claims the problem was solved in dapper
[14:23] <persia> HighNo: Not necessarily at postrm time
[14:24] <HighNo> mok0: or am I missing something
[14:24] <HighNo> mok0: that's way it is called .prerm right=
[14:24] <persia> mok0: TO me it looks like Uekawa-san's patch only handled start and restart, but not stop.
[14:24] <mok0> HighNo: I can't explain the circumstances, but it sometimes fails
[14:25] <mok0> persia: the right construction should be added by dh_installinit
[14:28] <mok0> 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] <persia> 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] <persia> 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] <mok0> persia: I'll try it. And also see if it's been fixed later
[14:30] <mok0> persia: working on clearing out my own bug submissions from when I was a n00b :-)
[14:31] <mok0> ... now I'm a n11b
[14:31] <persia> 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] <persia> Closing one's own bugs early and often is definitely ideal.
[14:32] <mok0> persia: the distraction bit... I've been there...
[14:33] <mok0> If you generate more bugs than you solve... that's not good
[14:34] <persia> 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] <persia> 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] <mok0> persia: heh, that's a good plan
[14:36] <persia> (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] <mok0> my early bug descriptions actually did not contain enough inofrmation
[14:36] <persia> mok0: Ah.  Yes, generating lots if insufficiently triaged bugs is not as ideal :)(
[14:37] <mok0> Learning by doing is the way to go here.
[14:37] <mok0> And I can't leave my old incomplete bug submissions for others
[14:38] <persia> 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] <mok0> Well, thanks for your help, persia. Don't let me keep you from getting your rest
[14:41] <persia> 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] <mok0> persia: my pleasure :)
[14:46] <RainCT> persia: when a from the NBS list has no reverse dependencies anymore, is it removed automatically?
[14:47] <RainCT> *when a package
[14:52] <james_w> 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] <james_w> I suppose if the user uninstalled the package before upgrading to this proposed version it wouldn't help.
[14:52] <ubotu> Launchpad bug 195028 in startupmanager "Upgrade bug gutsy to hardy (python errors)" [Undecided,New]
[14:53] <persia> 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] <warp10> 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] <RainCT> 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] <RainCT> 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] <ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Wishlist,In progress] https://launchpad.net/bugs/196871
[15:31] <james_w> warp10: good call.
[15:31] <RainCT> 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] <RainCT> Iulian: and if you update the Debian policy version please also move the Homepage to the source stanza
[15:44] <HighNo> 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] <HighNo> brb
[15:47] <HighNo> ahh, got it
[15:57] <HighNo> 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] <mok0> HighNo: yes
[15:57] <HighNo> mok0: could you try to help me with that one?
[15:57] <mok0> HighNo: I can try :-)
[15:58] <HighNo> 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] <mok0> 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] <HighNo> mok0: so I am compiling against a correct one but linking against a wrong one?
[15:59] <mok0> HighNo: Hmm
[16:00] <HighNo> mok0: just for the records:  CFLAGS = -O2 -Wall `pkg-config --cflags gtk+-2.0`
[16:00] <mok0> HighNo: It could also be a local function of the program that is n not gettting linked in
[16:00] <mok0> HighNo: try grepping the source for it
[16:01] <mok0> HighNo: it could also be mis-spelt
[16:02] <HighNo> 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] <mok0> HighNo: Ah. Then you need to figure out what has replaced it
[16:02] <mok0> HighNo: ... but you know that
[16:04] <HighNo> mok0: funny thing is that I think it compiled - it should not do that  right?
[16:04] <mok0> HighNo: depends on what you mean "compiled"
[16:05] <mok0> the compile will not discover that this routine is not included in the gtk library
[16:05] <mok0> only the linker
[16:07] <mok0> HighNo: It seems you can safely remove the call to gtk_tooltips_set_colors since it appears to not do anything
[16:08] <HighNo> mok0: hehe, read the same thing just a few secs ago...
[16:08] <mok0> HighNo: then it must be correct :-)
[16:09] <mok0> HighNo: you know what to do now, right?
[16:12] <HighNo> da**, is archive.ubuntu.com down again?
[16:13] <HighNo> hm, seems to be ok again, must have been a local issue...
[16:14] <HighNo> I need someone to test that package now - I don't have a cd drive :-)
[16:24] <HighNo> 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] <mok0> HighNo: I haven't followed the discussion... was this the bug you were trying to fix?
[16:26] <HighNo> mok0: moving from gtk1.2 to gtk2
[16:27] <mok0> HighNo: Ah.
[16:27] <mok0> HighNo: I guess the program should  just abort with a message
[16:28] <HighNo> 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] <mok0> 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] <HighNo> mok0: that's true but Ia m not the one to integrate that error message
[16:29] <mok0> HighNo: perhaps you should report it as a bug upstream, though
[16:29] <HighNo> mok0: last change was 2006 - I don't think it is in active development :-)
[16:30] <mok0> There isn't yet a "Hardware-Depends:" option in debian/control
[16:30] <HighNo> hehe
[16:31] <mok0> HighNo: I can't test it for you either, my machine at home is dead
[16:39] <ScottK2> Uses gtk1.2 pretty much == not under active development.
[16:44] <HighNo> :-)
[16:45] <HighNo> 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] <HighNo> (And do I need to add anything to any copyright/control/changelog file?)
[16:46] <HighNo> persia: please let me know what to do
[16:47] <soc> hi RainCT
[16:47] <RainCT> soc: hi :)
[16:47] <soc> just downloading BloGTK ...
[16:47] <soc> your changelog is impressive :-)
[16:47] <RainCT> heh
[16:48] <RainCT> if it has to be maintained in Ubuntu at least let's have a nice package :)
[16:49] <bobbo> 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] <HighNo> 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] <HighNo> bobbo: I'm just working on those things - use libgtk2.0-dev
[16:51] <HighNo> bobbo: you will likely have to change the source and makefiles too
[16:51] <bobbo> HighNo; thanks, will try that out
[16:52] <RainCT> 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] <RainCT> everything I try to build is failing lol
[16:56] <soc> RainCT: is there a guide somwhere, how to do packaging right?
[16:56] <soc> btw, will pidgin 2.4 get into hardy, or is it to late ?
[16:56] <RainCT> !packagingguide
[16:56] <ubotu> 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] <jdong> no
[16:57] <jdong> BAD NEXUIZ
[16:58] <jdong> the watchfile now somehow downloads the binary.
[16:58] <jdong> which left me very confused
[16:58] <soc> thx
[16:58] <bobbo> Does anyone know if a package that build-deps on libgtk1.2-dev will build for Hardy?
[16:59] <geser> it should
[16:59] <RainCT> 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] <geser> bobbo: what error did you get from your pbuilder?
[17:02] <bobbo> geser; http://pastebin.ubuntu.com/5166/
[17:02] <jdong> top
[17:02] <HighNo> 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] <HighNo> RainCT: then why am I doing this stupidious work? :-)
[17:03] <jdong> HighNo: because gtk2 is twice as good
[17:03] <HighNo> now that's a reason :-)
[17:04] <bobbo> 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] <HighNo> bobbo - I can take that as my next one - no guarantee it works though...
[17:04] <geser> HighNo: oh, but I guess it's not that easy as Debian would have already done it, gtk1 -> gtk2 needs porting
[17:04] <HighNo> anybody help me please woth getting the correct debdiff done?
[17:05] <geser> HighNo: where got you stuck?
[17:06] <RainCT> HighNo: lol yes, because gtk2 is better and because it would be good to removed it somewhen soon
[17:06] <HighNo> geser: I made the following steps: apt-get source cccd, modified it where needed, it compiles and builds now. which files in debian should I touch in addition to my change and should I make a patch from it and where should I put it?
[17:06] <RainCT> HighNo: add a new changelog entry with  dch -D hardy -i
[17:07] <RainCT> (you'll need to export DEBFULLNAME and DEBEMAIL for this to work)
[17:07] <geser> HighNo: dch -i (comment your changes), debuild -S
[17:07] <HighNo> RainCT: what should be in that entry exactly
[17:07] <HighNo> RainCT: ok, keep going
[17:07] <RainCT> HighNo: explain briefly what you changed
[17:08] <RainCT> HighNo: once you have added the changelog entry  debuild -S  as geser just said
[17:09] <RainCT> HighNo: then  cd ..  , download the source from Hardy again (.dsc and .diff.gz) as you probably have overwritten them
[17:09] <RainCT> HighNo: and then run:  debdiff packagename_oldversion.dsc packagename_newversion.dsc > packagename_newversion.debdiff
[17:09] <RainCT> HighNo: and check that everything ending up in packagename_newversion.debdiff was changed by you; if there are other changes you'll need to filter them out
[17:10] <bobbo> RainCT; You can unsubscribe yourself from Bug #196870 if you want as nothing can be done until it is ported to GTK2
[17:10] <ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,In progress] https://launchpad.net/bugs/196870
[17:11] <RainCT> HighNo: ah, if the previous version didn't end with "ubuntuX" you'll have to run "update-maintainer" (from package ubuntu-dev-tools) before debuild -S
[17:11] <RainCT> HighNo: ok, and after you have the .debdiff file just attach it to your bug report and subscribe ubuntu-universe-sponsors
[17:12] <soc> HighNo: doesn't gftp use gtk1?
[17:12] <RainCT> soc: no, gtk2
[17:12] <HighNo> sorry, busy doing the dch entry - now done with that.
[17:13] <HighNo> soc: RainCT is right, it's not on my list
[17:13] <soc> ah ok ..
[17:14] <soc> i always thought, because it's such a pita usability-wise
[17:15] <RainCT> soc: on that I agree
[17:16] <RainCT> soc: I switched to sftp (command line) because of gftp :P
[17:18] <HighNo> apart from my problems - some people tend to have a wiki based homepage - would they put it on wiki.ubuntu.com? cause I did (as I have found others to do it too) and on every change I get the note of a change notice sent to dholbach & co... that does not sound ok. Yes, I have used TemplateHomepage
[17:18] <RainCT> bobbo: gtk1.2 is still in hardy, theoretically gpppon should build
[17:18] <bobbo> RainCT; so the build farms will build it just pbuilder wont?
[17:18] <RainCT> HighNo: that's normal, they are subscribed to the entire wiki
[17:19] <RainCT> HighNo: probably with some fake mail because that has to be a lot of SPAM :/
[17:19] <RainCT> bobbo: ah, it fails in pbuilder?
[17:20]  * RainCT checks the backlog
[17:20] <bobbo> RainCT; yeah http://pastebin.ubuntu.com/5166/
[17:22] <RainCT> apt-cache should really have a -t option..
[17:23] <RainCT> bobbo: strange..
[17:23] <RainCT> well, I'm away for a while..
[17:24] <bobbo> bye
[17:26] <lorenzo> I have created a package and need docs or other info on how to get it into Universe. I'm new to the process and need a starting point.
[17:30] <HighNo> geser: so I have to create the bug report myself?
[17:33] <HighNo> bobbo: do you have a .desktop file to gpppon?
[17:34] <HighNo> bobbo: I could include it into the patch
[17:34] <bobbo> HighNo; yeah ive got a pile of other patches aswell
[17:34] <geser> HighNo: yes, if no one exists
[17:34] <bobbo> Hattory; i had to bump DH_COMPAT etc. for dh_desktop to work
[17:35] <bobbo> sorry i meant HighNo,
[17:35] <Hattory> ;)
[17:36] <HighNo> bobbo: I have patched gpppon for gtk2.0 and it works
[17:37] <bobbo> HighNo; Do you want me to send you all the changes i have so far?
[17:37] <HighNo> geser: could you guide me through my first bug report for this then?
[17:37] <bobbo> or do you want to send your changes here as i have a pile of other fixes i could do as Lintian is having a field day on this package
[17:38] <HighNo> bobbo: sounds good
[17:38] <HighNo> I'll make a debdiff for it and send it to you
[17:38] <geser> HighNo: there are no requirements how the bug should look like
[17:38] <bobbo> HighNo; thanks :)
[17:41] <HighNo> bobbo: I'll leave the maintainer-change to you
[17:41] <bobbo> HighNo; yeah ive already got that my end
[17:45] <bobbo> HighNo; pastebin it ;)
[17:45] <HighNo> true
[17:45] <HighNo> forgot about it
[17:46] <HighNo> bobbo: http://pastebin.com/d6a72a809
[17:47] <bobbo> HighNo; brilliant thanks
[17:52] <HighNo> geser: what should I change bug status to?
[17:55] <HighNo> geser: the patch is already attached and uus is subscribed
[17:55] <geser> HighNo: to "Confirmed" according to https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[17:56] <HighNo> geser: assign it to me?
[17:56] <geser> Assign to "nobody"
[17:59] <HighNo> geser: can you check LP #197358 please. If that is ok I can do it that way for the other packages too
[17:59] <ubotu> Launchpad bug 197358 in cccd "patch for use of gtk2.0" [Undecided,Confirmed] https://launchpad.net/bugs/197358
[18:03] <bobbo> HighNo; thanks for that gtk2 patch for gpppon. https://bugs.edge.launchpad.net/ubuntu/+source/gpppon/+bug/196870/comments/7 <-- Changelog/Final debdiff for it
[18:03] <ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,In progress]
[18:03] <geser> HighNo: almost correct: the version is wrong and the maintainer changes seems to be missing
[18:03] <geser> HighNo: -XbuildY is only used for no-change rebuild but as you added changes the version should be -6ubuntu1
[18:07] <HighNo> geser: hm, can you do that on your own or would I have to change that in the debdiff again?
[18:08] <geser> depends on the sponsor of your bug
[19:07] <bobbo> I know its a bit off topic but do any MOTU's know how big (in gigabytes) Universe is?
[19:15] <HighNo> bobbo: just download every package and count :-)
[19:15] <bobbo> HighNo; if only i had a good internet connection
[19:16] <mok0> bobbo: That information might be on Ubuntu's "want to mirror" page
[19:16] <HighNo> bobbo: honestly - there are different ways to count. universe is also an archive for older versions so it is much bigger than the size of all installed versions of e.g. hardy
[19:17] <bobbo> mok0; genius, Edgy Eft was 25gb, thought it would be larger
[19:18] <mok0> bobbo: ok. I estimate hardy would be > 25% larger
[19:18] <HighNo> "At this writing, the Ubuntu Archive takes up about 215 GB of space." -> https://help.ubuntu.com/community/Rsyncmirror
[19:18] <bobbo> wow
[19:18] <HighNo> that was when feisty was newest
[19:18] <mok0> Still well within a smallish disk :-)
[19:19] <HighNo> mok0: I am surprised too
[19:19] <bobbo> i was thinking of trying it on a 100gb disk i run my Hardy partition off, thank god i didnt start it
[19:19] <mok0> But that includes binaries for several archs
[19:20] <mok0> bobbo: The sources would likely fit on that disk
[19:20]  * bobbo might give it a go if he gets a better Internet connection
[19:20] <HighNo> hm, it might be enough if debmirror is used. that one only mirrors the hardy packages
[19:22] <mok0> bobbo: what is the purpose of mirroring?
[19:22] <HighNo> The page reads funny as it seems to be the most normal thing in the world to have a mirror... :-)
[19:22] <bobbo> mok0; to see what would happen really :)
[19:22] <Nafallo> ehrm
[19:22] <mok0> bobbo: hehe. You'd get a huge bill from your ISP
[19:22] <Nafallo> I can tell you what would happen :-P
[19:22] <bobbo> Nafallo; you tried it?
[19:23] <Nafallo> bobbo: you would get local copies of the entire space you mirror.
[19:23] <Nafallo> I thinks that's pretty obvious actually :-)
[19:24] <bobbo> someone suggested it on Ubuntuforums, was just curious :)
[19:24]  * mok0 finds that there are so many mirrors it's not worth the bother
[19:25] <Nafallo> mok0: not true :-)
[19:25] <Nafallo> mok0: people with 200 servers in the network would benefit from a local server :-)
[19:25] <mok0> Nafallo: depends where you are, perhaps
[19:26] <Nafallo> one machine pulling at the transit instead of all of them
[19:26] <mok0> Nafallo: true. I don't think bobbo has 200 local installations
[19:26] <Nafallo> apparently not :-)
[19:27] <Nafallo> I was responding to the 'not worth the bother' part ;-)
[19:27] <mok0> Hmm. Perhaps there is a need for a "cache" like system, where you could set up at local "cache"
[19:27] <mok0> The cache server would just keep a copy of requested packages, not the whole caboodle
[19:28] <Nafallo> that would work as well.
[19:38] <RainCT> hi again
[19:38] <Nafallo> hi RainCT
[19:46] <RainCT> bobbo: hm.. why does gpppon need a .desktop file if it's an applet?
[19:47] <RainCT> or is the description wrong?
[19:56] <hellboy195> hoi jono :)
[19:56] <jono> hey hellboy195
[19:59] <vorian_> nope
[21:05] <AnAnt> man-di: hello
[21:16] <Iulian> RainCT: Sorry, I was afk, I'm looking to it right now.
[21:16] <Iulian> Thanks
[21:23] <man-di> AnAnt: contentless ping...
[21:23] <AnAnt> man-di: oh,
[21:24] <AnAnt> man-di: I remember some months ago you said you're going to do icedtea package for Debian
[21:24] <AnAnt> man-di: I wonder what happened
[21:24] <man-di> AnAnt: in the works
[21:24] <AnAnt> man-di: I see
[21:25] <AnAnt> man-di: couldn't the Ubuntu package be used for Debian ?
[21:25] <man-di> AnAnt: was uploaded, got rejected with some requests from FTP-MAster and these are not all solved yet.
[21:25] <AnAnt> oh ic
[21:26] <man-di> AnAnt: This was the Ubuntu package
[21:29] <AnAnt> ok
[21:29] <AnAnt> man-di: can I help ?
[21:29] <man-di> AnAnt: if you can tell me why that package doesnt build on debian sid currently...
[21:59] <AnAnt> man-di: did you get build log ?
[22:01] <man-di> AnAnt: libgcj.so not found because gcc is 4.2 and gcj is 4.3 on Debian
[22:11] <AnAnt> i see
[22:11] <AnAnt> so you are waiting till gcc becomes 4.3 in sid
[22:12] <AnAnt> ok, later
[22:12] <man-di> I would have answered 'no' ...
[22:13] <persia> HIghNo: Sorry.  Sleeping.  Looks like you got your help.  libgtk1.2 removal won't be finished for hardy, but work towards that goal, and patches uploaded and sent to Debian will be very helpful towards making things look nice (and dropping libgtk1.2 later).
[22:13] <persia> warp10: Putting an NBS guide on the wiki is an excellent idea.  Would you mind drafting it?  I'm happy to review.
[22:17] <persia> man-di: Just for fun, icedtea FTBFS in Ubuntu for i386 in a recent test :)
[22:19] <man-di> persia: do you have a link to the build log?
[22:19] <warp10> persia: What about MOTU/School/NBS ?
[22:19] <HighNo> persia: ok, will try to keep on. will be a longer run though. about 180 packages to do
[22:20] <persia> warp10: It's not officially MOTU/School, but I'm happy with that if james_w agrees.
[22:21] <james_w> persia: I don't really mind, but I don't think it's the right place, how about packaging guide, or processes doc?
[22:22] <persia> HighNo: Yep.  It's a huge bit of work.  From what I understand, Debian hopes to finish it by June or July, so you might expect more people chasing it soon.  Just be sure to get things pushed back and forth with Debian to avoid duplicate effort.  Also, sending patches to upstream MLs or bugtrackers (even when upstream is dead) is a good way to share your patches with any other distribution that might also want to make the change.
[22:22] <james_w> or just /NBS perhaps? Or MOTU/NBS?
[22:22] <james_w> I don't think it matters too much, just get it down somewhere and start linking.
[22:23] <warp10> MOTU/NBS should be fine too
[22:23] <persia> james_w: I don't think the packaging guide is the right place, as it's local process.  Maybe somewhere in processes.  Also, it needs doing for both main and universe, so I'm reluctant to use MOTU/
[22:23] <hellboy195> persia: hi, I'm currently merging new gaphor revision from debian. now I discovered a bug report from 2007-09-24 where somebody complains that gaphor depends on zope3 because that slows down everything.  bug #144377 . That has been ignored so far. Should I take care about it or not?
[22:23] <persia> (and yes, starting anywhere is good, and we can put it in the right place later)
[22:23] <ubotu> Launchpad bug 144377 in gaphor "gaphor depends on zope3" [Wishlist,Confirmed] https://launchpad.net/bugs/144377
[22:24] <persia> hellboy195: No.  The new upstream doesn't do that cleanly, and it would be new feature, so you can hide behind FeatureFreeze.
[22:25] <hellboy195> persia: good. thank you :)
[22:25] <warp10> persia, james_w: ok, I will open MOTU/NBS, we will choose a better place later
[22:25] <HighNo> persia: geser mentioned on the first one I finished that I should change the maintainer. That could be done by simply running update-maintainer?
[22:25] <persia> Also, the Debian really-avoid-cheeseshop patch is better than mine.  The only outstanding change should be to force the use of python2.4 in all cases (assuming zope3 still uses python2.4).
[22:26] <RainCT> warp10: what's about https://wiki.ubuntu.com/PackagingGuide/Howtos/
[22:26] <persia> HighNo: I believe so, although I always just paste "Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" manually (the string is in a small text window on my desktop)
[22:26] <james_w> warp10: while I remember, it would be great to mail u-motu and -motu-mentors when you have something to get some more people working on it.
[22:27] <james_w> HighNo: yeah, update-maintainer does all you need.
[22:27] <james_w> HighNo: just make sure you run dch first to get a new version stanza, otherwise it goes in the one before you want.
[22:27] <warp10> RainCT: well, NBS are not really related with packaging, I don't think PackagingGuide would be the right place, IMHO
[22:27] <persia> RainCT: I'm not sure it's "packaging", so much as "maintenance".  I don't remember where the guide of how to generate a debdiff lives, but I would think that would be the right namespace.
[22:28] <RainCT> ah yes, right
[22:28] <HighNo> great. btw, where does popcon get its Maintainer from- from the package? cause it declares my package as 'unknown' which is uncool as it shoudl either be myself or motu-devs
[22:29] <HighNo> james_w: thanks for the correct order
[22:29] <RainCT> persia: the debdiff guide is there (well, or at least there is a debdiff guide there)
[22:29] <RainCT> https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff
[22:29] <warp10> james_w: I will write an e-mail once a first draft is ready to be worked on.
[22:29]  * persia fails to understand, and puts "Read the wiki" near the bottom of the TODO list
[22:29] <hellboy195> persia: it's just strange that debian has python-nose as build depend and we als build-dep-indep
[22:30] <hellboy195> persia: ah nvm. found the reason ^^
[22:30] <james_w> warp10: thanks.
[22:30] <persia> warp10: Thanks for that.  I tend to just walk through specifics, and really appreciate it when someone generates a guide.
[22:31] <persia> hellboy195: It should be build-depend.  Everything but the python2.4 forcing is better in Debian (and all the interesting patches have been absorbed).
[22:31] <james_w> HighNo: what package do you refer to with popcon?
[22:32] <HighNo> blueproximity
[22:32] <james_w> HighNo: where does Ubuntu's popcon data live?
[22:32] <james_w> or rather, where can I query it?
[22:32] <RainCT> james_w: popcon.ubuntu.com
[22:34] <james_w> RainCT: ah, thanks, should have guessed that.
[22:35] <james_w> HighNo: that is odd, I don't know why that happens.
[22:41] <persia> vorian: regarding upstream releases after a FFe exception approval and before upload: I suspect this requires another FFe, but you might be able to reuse the bug.  Best ask here or by an email to ubuntu-motu@.
[22:45] <ScottK> vorian: Ask again in the same bug.
[22:46] <persia> ScottK: And resubscribe motu-release?
[22:46] <ScottK> Yes
[22:48] <persia> hellboy195: double-check, but I think the better disable_ez_install patch might make the rm -rf for .egg no longer required.
[22:49] <hellboy195> persia: well debian also applied the rm -rf I think but I can't run debuild because it complains about this patch ^^
[22:51] <persia> hellboy195: Odd.  I didn't think there was a new upstream, and Piotr's patches are typically perfect.  You aren't trusting MoM or anything, are you?
[22:51] <bobbo> RainCT; have you have a chance to look at bug #196870 yet? HighNo ported it to GTK2 so it actually builds
[22:51] <ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Low,Confirmed] https://launchpad.net/bugs/196870
[22:53] <hellboy195> persia: well trust or not. I only see http://pastebin.com/m7773dc33
[22:54] <hellboy195> persia: wtf? the patches are in patches and not in patched O_O
[22:54] <persia> hellboy195: Are they in series?
[22:54] <RainCT> bobbo: 20:46:41 < RainCT> bobbo: hm.. why does gpppon need a .desktop file if it's an applet? or is the description wrong?
[22:55] <bobbo> RainCT; never read the description of the package but its definately not an applet
[22:55] <hellboy195> persia: hellboy@ubuntu:~/merges/gaphor/gaphor-0.12.5/debian/patches$ ls
[22:55] <hellboy195> 00list  disable_ez_setup.dpatch  remove_shebangs.dpatch
[22:55] <persia> hellboy195: Check 00list then
[22:56] <RainCT> bobbo: then please fix the description
[22:56] <hellboy195> persia: disable_ez_setup.dpatch *\n* remove_shebangs.dpatch
[22:56] <bobbo> RainCT; ok :)
[22:56] <RainCT> bobbo: beside this, good work :)
[22:56] <bobbo> RainCT; thankyou
[22:57] <persia> hellboy195: Very odd indeed.  Is dpatch called in debian/rules?
[22:57] <hellboy195> persia: yes : include /usr/share/dpatch/dpatch.make
[22:58] <persia> hellboy195: Can you paste a source build log?
[22:58] <hellboy195> persia: ehm. sry. source build log?
[22:59] <persia> hellboy195: You should have a foo_source.build in the parent directory after running `debuild -S -v0.12.5-1ubuntu1`.
[22:59] <persia> (you were having trouble generating source, right?)
[23:00] <hellboy195> persia: yeah. I pasted the log already :) http://pastebin.com/m7773dc33
[23:01] <persia> hellboy195: Sorry.  Didn't see that.
[23:01] <hellboy195> persia: np
[23:01] <HighNo> persia: have you taken a look at my first shot? LP #197358 - just wanted to check further before going to make my process a template...
[23:01] <ubotu> Launchpad bug 197358 in cccd "patch for use of gtk2.0" [Undecided,Confirmed] https://launchpad.net/bugs/197358
[23:01] <POX__> hehe, "Piotr's patches are typically perfect"
[23:01]  * persia defers to POX__ to debug disable_ez_setup
[23:02] <hellboy195> hrhr
[23:02] <POX__> hellboy195: unpack it again
[23:02] <POX__> my guess: your setup.py is already patched
[23:02] <HighNo> persia: I am not quite sure if I have to create my changes as a patch or just change the source (and debian stuff) and do the debdiff...
[23:02] <POX__> or changed
[23:03] <persia> HighNo: I'd suggest changing the description to say something about GTK1.2 being obsolete, and porting to new libraries, rather than referencing a semi-random IRC comment :)  Looking at the debdiff now.
[23:03] <hellboy195> POX__: /me is checking that
[23:04] <POX__> hellboy195: disable_ez_setup patch doesn't disable Eggs, it just prevents setup.py from downloading newer (but not required) setuptools
[23:04] <persia> HighNo: Your patch ought have maintainer mangling for the debdiff for upload, and drop changes to changelog and control for submission to Debian.
[23:04] <POX__> Egg is installed (not as normaand both systems are doing )
[23:04] <POX__> err, ignore my last msg
[23:04] <hellboy195> POX__: you have 100 points
[23:04] <hellboy195> damn grab-merge ^^
[23:05] <persia> HighNo: Regarding application of the patch in debian/patches vs. inline, I find running lsdiff -z foo.diff.gz to be the best way to determine how previous patches in the package have been done.
[23:05] <POX__> so ""Piotr's patches are typically perfect" is still valid ;)
[23:05] <HighNo> persia: hm, I was told to document my changes in the changelog. hmmm - now am I doing this for ubuntu in the first line or for debian, waiting for them to integrate the patch and afterwards synching it?
[23:05] <hellboy195> POX__: ^^
[23:05] <persia> If that doesn't provide a hint, you get to choose the patch system (although checking other packages from that maintainer to try to use their preference will make merging simpler later)
[23:07] <bobbo> RainCT; Fixed the descriptions, new debdiff; http://launchpadlibrarian.net/12345384/gpppon_0.2-4ubuntu1.debdiff
[23:07] <HighNo> persia: my problem is mainly that I don't know if I could break existing patches by patching the source before they do their magic...
[23:07] <persia> HighNo: For any gtk1.2 -> gtk2.0, you want to generate two patches: one for Ubuntu that is a complete debdiff (including changelog and control) to be uploaded, and one for Debian that is just the required changes to the source (and be sure to send to the BTS).  There's no need to wait for the sync, but Debian QA will be lots happier if the BTS already has patches for the GTK1.2 bugs (I think the mass bug filing already happened)
[23:08] <persia> HighNo: If there are existing patches, you want to patch in the same manner.  If they are in debian/patches, it is often safest to apply your patch last.
[23:08] <HighNo> persia: ahh, so I can always create the debdiff and afterwards strip the parts for debian dir and send those to the debian maintainer?
[23:09] <persia> hellboy195: grab-merge is a handy way to collect the sources, but MoM doesn't always know best about merging, especially when the Debian package has many of the same changes (only implemented in a superior fashion)
[23:09] <HighNo> persia: hm, that leaves the question how I should work on the source. So I should run all patches first and do my work afterwards?
[23:09] <persia> HighNo: Yes, except send the patch to the BTS, rather than to the maintainer.
[23:09] <HighNo> BTS= Bug Tracking System?
[23:10]  * HighNo admits this is a nooby question...
[23:10] <hellboy195> persia: true. btw. why sometimes brings grab-merge sometimes *ubuntu*.patch which only show the new changelog entry? So I have to edit debian/control ,.. manuelly
[23:10] <ScottK> HighNo: Yes
[23:10] <bobbo> HighNo; yep
[23:10] <persia> HighNo: If debian/patches is populated, you typically want to use cdbs-edit-patch, dpatch-edit-patch, or apply all the quilt patches before you make your patch.
[23:11] <persia> hellboy195: That happens when the Ubuntu changes went back to Debian without improvement.  In those cases, you need to double check, but it is usually a sync.
[23:11] <HighNo> cdbs-edit-patch will apply all prior patches, right?
[23:12] <hellboy195> persia: well I had 2-3 of that merges in past ...
[23:12] <ScottK> Yes
[23:12] <persia> HighNo: For simple-patchsys.  I'm not sure if it works properly for other patch systems.
[23:12] <persia> hellboy195: changelog only?  I don't see the point of such a merge, but maybe it's just me.
[23:13] <hellboy195> persia: no I mean the autogenerated patch vom grab-merge only showed that new changelog entry. I had to do the other things manually
[23:14] <persia> hellboy195: Ah.  That makes more sense.  Personally, I only use MoM as a convenient source of the common ancestor package: I've not had good experience with MoM patches.
[23:15] <hellboy195> persia: me too, so I'm double checking ^^
[23:16] <hellboy195> persia: argh. damn it! applying patch remove_shebangs to ./ ... failed.
[23:17] <persia> hellboy195: You're working from the Debian source or the MoM source?
[23:17] <hellboy195> persia: unfortunately the MoM one.
[23:18] <persia> For this one, I'd just take the Debian source, force python2.4 in debian/control and debian/rules, and verify the shebangs in /usr/bin from the build.
[23:19] <hellboy195> persia: yeah. nvm. I did my first 40 merges without grab-merge so this isn't a problem for me :)
[23:22] <warp10> persia: https://wiki.ubuntu.com/MOTU/NBS Mostly, I have just rearranged your lession on -motu, but probably another rebuild example would be nice, maybe an easier one (this one has a double transition, not really appropriated for a new contributor)
[23:22] <persia> hellboy195: That's good volume.  Thanks a lot for helping integrate all the fixes from Debian.  I'm expecting the RC list to be much smaller than usual when it gets published :)
[23:23] <persia> warp10: Actually, double and triple transitions are not uncommon, especially for core libraries.  Given that tracking that down is just a couple links, I think it's better than pretending each library can be NBS'd independently.
[23:23] <warp10> persia: I will work a little more on it tomorrow and send an e-mail to the lists. It's bed-time now on this side of the world :)
[23:24] <hellboy195> persia: fine :) btw, bug #197425  I suppose I'm right and he not ;)
[23:24] <ubotu> Launchpad bug 197425 in streamtuner "Merge streamtuner 0.99.99-11 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/197425
[23:24] <persia> hellboy195: For that, yes.
[23:25] <RainCT> bobbo: http://paste.ubuntu.com/5175/plain/
[23:25] <warp10> persia: indeed, but a very plain example could be useful to get familiarity with the topic, and then the double transition one is great to see a "real-world" transition.
[23:25] <hellboy195> persia: and with that confirm thing. I learned that after I uploaded the debdiff I should set "Confirmed" and unassign me. So this was false?
[23:26] <RainCT> bobbo: of those only the 2nd one is important
[23:26] <persia> hellboy195: Workflow bugs are awkward.  If you open a bug you want someone else to fix, please don't confirm.  If you open a bug and supply the fix, and subscribe the sponsors, please confirm.
[23:26] <bobbo> RainCT; ok, will fix later :)
[23:27] <hellboy195> persia: I always set to confirmed *after* I uploaded the debdiff ...
[23:27] <RainCT> bobbo: Okay. Also, I still don't like the description (if you don't mind please remove the "A" from the start, and the "small tool that is.." isn't really ideal, I'd prefer somewhat more direct).
[23:28] <bobbo> RainCT; ive never been good with descriptions ;)
[23:28] <RainCT> :)
[23:28] <RainCT> well, good night all
[23:29] <persia> warp10: Sounds reasonable.  Would you like to try to find one on the NBS page?  I'd be happy to verify it.
[23:29] <persia> hellboy195: confirming after uploading the patch is good practice.  Personally, I recommend using "In-Progress" while you are working on the patch.
[23:30] <HighNo> hmpf, I've learned not much so far but already forgotten half of it.... -XubuntuY - is that for the first release 0ubuntu1 or the other way around?
[23:30] <RainCT> HighNo: 0ubuntu1 is the first release of a upstream version which isn't in Debian
[23:30] <warp10> persia: at a first glance, http://people.ubuntu.com/~ubuntu-archive/NBS/libminc0 could be one. I'm going to bed now, so I will check more carefully tomorrow
[23:31] <hellboy195> persia: well, true but mostly a merge is done in ~10 minutes
[23:31] <HighNo> RainCT: thanks
[23:31] <persia> warp10: That's a good example (appears to be caused by a FTBFS).  Have a good night.
[23:31] <vorian> ScottK: thanks
[23:32] <warp10> good night persia and all.
[23:34] <HighNo> persia: if version is 0.1.3-3, should my version be 0.1.3-3ubuntu1 or 0.1.3-4ubuntu1 ?
[23:35] <hellboy195> persia: I like debuild. dpkg-source: building gaphor in gaphor_0.12.5-2ubuntu1.dsc
[23:35] <hellboy195> debuild: fatal error at line 1247:
[23:35] <hellboy195> dpkg-source -b gaphor-0.12.5 failed
[23:35] <hellboy195>   BUT I have the .dsc xD
[23:35] <persia> HighNo: -3ubuntu1.  When your patch goes back to Debian, it gets merged with other things into -4, and that can be a sync.  If you upload -4ubuntu1, it needs to wait for -5.  I made that mistake once, and had to manually check a package as a merge candidate for 2 releases.
[23:37]  * vorian needs to scroll up more
[23:37] <vorian> thanks persia
[23:37] <vorian> should be ready in a few
[23:38] <persia> vorian: Thanks for chasing it.  You've been working on that bug for a while, and it didn't make sense to me to wait until it reached least-recently-touched in the queue before you were redirected.
[23:39] <geser> persia: have we currently a location where we collect links to our QA tools till qa.ubuntuwire.com comes back?
[23:39] <geser> I've setup the FTBFS list on an other host for now
[23:39] <vorian> agreed
[23:40] <hellboy195> persia: I have a .dsc, a nice looking debdiff, a built deb and /usr/bin/gaphor has a python2.4 shebang. I'm happy :)
[23:40] <persia> geser: https://wiki.ubuntu.com/MOTU/TODO seems the appropriate place, but it's not currently in use.  I think Fujitsu has a DNS mirror that we could use to show the qa homepage from BZR.
[23:40] <persia> hellboy195: Next question, does it work?
[23:41] <hellboy195> persia: gaphor? sure :)
[23:41] <persia> hellboy195: Great then.  Thanks for chasing it.
[23:42] <hellboy195> persia: well, thx for your endurance and support :)
[23:42] <HighNo> am I right that changes to the control file are not to be made in a patch as debuild does not see them at the right time?
[23:43] <persia> HighNo: Yes.  No patch should ever update anything in debian/
[23:43]  * hellboy195 is cleaning up the debdiff :)
[23:43] <geser> persia: I'll add the temporary location to the TODO page
[23:43] <persia> geser: This is the FTBFS report?
[23:45] <TheMuso> Can anybody make sense of this mplayer FTBFs? http://www.pastebin.ca/925082
[23:45] <HighNo> hm, and signing - can it be left out for creating the debdiff? I have not setup a gpg-agent and my passphrase is rather long...
[23:46] <geser> persia: yes, it's now available at http://members.ping.de/~mb/buildstatus_hardy/
[23:46] <persia> HighNo: Yes, you don't need to sign a debdiff
[23:46] <hellboy195> persia: form 11k lines to 174. I'm loving it xD
[23:46] <hellboy195> *from
[23:48] <persia> geser: Have you also seen http://builder.ubuntuwire.qeuni.net:9998/dist/hardy/arch/i386?  Still 1500 or so packages to go, but includes things not yet known to LP.
[23:50] <geser> persia: yes, I'm looking right now at it :) And also working on fixing the easy ones (see hardy-changes).
[23:50] <persia> geser: Ah.  Excellent :)
[23:55] <hellboy195> So. Here in Austria it's pretty late (geser don't work too long ;) ) Gn8 folks :)
[23:56] <HighNo> hellboy195: it's no later than in Germany :-)
[23:57] <hellboy195> HighNo: I know so I said to geser that he shouldn't work too long ^^
[23:57] <hellboy195> nvm. gn8 :)