[00:00] <slangasek> which is a poorly-named package; if it were being done from scratch, it should be libgtkglext-1.0-0 or libgtkglext-x11-1.0-0, according to taste
[00:00] <DaveMorris> so surely the c++ bindings should be similar
[00:00] <sistpoty> DaveMorris: now you've completely confused me, as I can't find a gutsy package (only an edgy one)#
[00:00] <slangasek> sistpoty: he's referring to gtkglext, not gtkglextmm
[00:00] <HighNo> thanks to DaveMorris and the other reviewer there is a new version at revu: http://revu.tauware.de/details.py?package=blueproximity - Reviewers wanted :-)
[00:00] <sistpoty> ah, ok
[00:01] <DaveMorris> slangasek: yeah, the C package should also be sorted out at the same time IMO (and poss the other bindings available )
[00:02] <slangasek> DaveMorris: it shouldn't; once a library runtime package name has been chosen, even if it's poorly chosen, changing it is worse than leaving it alone
[00:02] <DaveMorris> then shouldn't we stick with the name that was in dapper/edgy ?
[00:02] <slangasek> DaveMorris: but if the soname changes (are you packaging a new version of gtkglext with a new soname, too?), then the package name can be fixed in the process since the name has to change anyway
[00:02] <slangasek> DaveMorris: no, because it's *not* the same version of the library. sistpoty just pointed out the difference in soname
[00:03] <DaveMorris> the version just changes from -1.0 to -1.2
[00:03] <slangasek> yes
[00:03] <slangasek> so the package name *must* be changed, and therefore it can be fixed however is most appropriate as long as it doesn't collide with another package name
[00:04] <slangasek> therefore, libgtkglextmm-x11-1.2-0 or libgtkglextmm-1.2-0, whichever you find more acceptable
[00:04] <slangasek> but gtkglext's package name should change *only* if a new version is being packaged that changes the ABI
[00:04] <geser> HighNo: you need a verbatim copy of the license in the orig.tar.gz (just listing it in debian/copyright is not enough). without a license file it will be rejected by the archive admins.
[00:05] <DaveMorris> slangasek: but the others have jumped to 1.2 in the gutsy->hardy change
[00:05] <DaveMorris> from 1.0
[00:05] <DaveMorris> or is it to late to fix that now
[00:06] <HighNo> geser: so upstream has to include it? If so what would be the quickest and easiest way?
[00:06] <slangasek> DaveMorris: in that case, the gtkglext binary package names are currently wrong and must be changed
[00:07] <slangasek> (and, who uploaded a new upstream version of this library without understanding that?)
[00:07] <DaveMorris> which will cause alot of dependices to break
[00:07] <DaveMorris> sounds fun
[00:07] <sistpoty> DaveMorris: apart from the soname stuff, your debian/copyright doesn't name all licenses used (e.g. ./examples/trackball.c)
[00:08] <DaveMorris> thanks sistpoty
[00:08] <slangasek> DaveMorris: uh, no - gtkglext has an upstream version bump to 1.2, but the soname did not change
[00:09] <DaveMorris> my mistake,
[00:09] <geser> HighNo: yes, as somebody who just downloads the .orig.tar.gz has to know the license.
[00:10] <DaveMorris> so you want 2 binaries
[00:10] <geser> HighNo: can you easily redo a new upstream tarball with the added license file?
[00:10] <HighNo> geser: yepp
[00:11] <HighNo> geser: Can I do that without a version number change in upstream?
[00:12] <geser> HighNo: I guess so, but I'm not sure if it might confuse others.
[00:12] <geser> and I also don't know if sourceforge let you
[00:12] <slangasek> DaveMorris: what do you mean, two binaries?
[00:13] <DaveMorris> one for each so object
[00:13] <slangasek> that's not absolutely necessary
[00:13]  * DaveMorris makes my job easier :)
[00:14] <slangasek> it's the "safer" way to package it, but there are plenty of other library packages that include multiple libraries from the same upstream source
[00:14] <slangasek> gtk+2.0 is one of those, gtkglext is another...
[00:15] <sistpoty> which means that one ABI version certainly won't change with the ABI version of the other shared object, right?
[00:17] <geser> HighNo: about the "/usr/bin/env python/" vs. "/usr/bin/python" issue: I've seen several upstream use env but it has the disadvantage that you can't add addtional options to the shebang. So it is usually changed in Debian/Ubuntu packages.
[00:17] <HighNo> geser: ok, thanks for the info
[00:17] <slangasek> sistpoty: that's what it implies if you package them together that way, yes
[00:19] <geser> HighNo: what problems did you have with blueproxmity being a python script and the desktop file?
[00:19] <HighNo> geser: the proximity.py mentions the GPL - but that's not enough I guess?
[00:20] <geser> HighNo: unless you put there the whole GPL, I guess it's not
[00:21] <HighNo> geser: don't know anymore, I think that was an old problem where I had to find out the directory with the data files that was formerly solved via the startup script. Now the path is included in the path, so that won't count against it anymore.
[00:22] <HighNo> geser: so all I should do is include the complete GPL source? wouldn't I have to remove that file for packaging again since there should be a reference to the license files as in control(?)
[00:23] <sistpoty> HighNo: the GPL (at least 2, haven't checked 3 yet) has the restriction, that the complete license text must accompany the source
[00:24] <sistpoty> HighNo: hence a source package (which s.o. can download individually) must contain the GPL
[00:24] <geser> HighNo: the .orig.tar.gz must have a verbatim copy of the GPL (in the right version) but you shouldn't install it in the binary package (there is the reference to /usr/share/common-licenses enough)
[00:24] <HighNo> sistpoty: ouch, I did not know that. but again - wouldn't I have to delete it when packaged?
[00:25] <HighNo> geser: ok, can I do the file deletion with a patch?
[00:25] <sistpoty> HighNo: for a *binary* package: yes. there you can refer simply to the already installed version of the GPL under /usr/share/common-licenses
[00:26] <geser> HighNo: a file deletion isn't needed, simply don't list it in debian/blueproximity.install (you don't have to put all files from a source package into binary package)
[00:27] <HighNo> geser: ah, I forgot that - has been to long ago I created it I guess
[00:28] <HighNo> would that license file need a starter like "all package contents is licensed by this license: ...GPL2 original text..."
[00:30] <geser> HighNo: just look how the others package on revu do it, e.g. http://revu.ubuntuwire.com/revu1-incoming/termlauncher-applet-0802021100/termlauncher-applet-0.0.3/
[00:30] <geser> COPYING is the GPL license
[00:31] <geser> HighNo: or http://revu.ubuntuwire.com/revu1-incoming/libini4j-java-0802011440/libini4j-java-0.2.6/ where License.txt is the Apache license
[00:32] <geser> HighNo: there is no requirement on how the file is named
[00:35] <HighNo> geser: OK, I'll stick to the examples
[00:52] <DaveMorris> sistpoty: if you had 5 mins spare, I've uploaded a new version
[00:52] <DaveMorris> but I'm off to bed now.
[00:52] <sistpoty> DaveMorris: give me a few minutes, and I'll take a look
[00:52] <sistpoty> good night DaveMorris
[00:53] <HighNo> gn and thx DaveMorris
[00:59] <HighNo> geser: a new version is on the way, just the usual ten minute delay...
[01:00] <HighNo> geser: I would like to hold the new upstream version until we hav all upstream problems eliminated
[01:01] <HighNo> geser: so once upstream seems allright I'll upload it to sourceforge
[01:02] <HighNo> does anybody know how big the userbase for feisty and gutsy still is?
[01:02] <HighNo> or should I let backports handle the old versions?
[01:03] <HighNo> backporting should be a breeze...
[01:04] <RAOF> Backports is the only way that new packages get into older releases.
[01:05] <jdong> why was I just pinged 3 times within the past minute?
[01:05]  * jdong looks up
[01:06] <sistpoty> jdong: you're getting pinged if s.o. mentions backports?
[01:06] <jdong> sistpoty: I must.
[01:06] <sistpoty> heh
[01:06] <jdong> sistpoty: I had a lot of fun with regex one day
[01:07]  * sistpoty imagines
[01:07] <HighNo> so you  are the backports man? :-)
[01:07] <Pici> 'fun'
[01:07] <HighNo> *pling*
[01:07] <jdong> Pici: not that kind of fun.
[01:07] <jdong> Pici: that kind of fun encourages me to fix flashplugin-nonfree
[01:08] <HighNo> anybody up for a hopefully final review: http://revu.tauware.de/details.py?package=blueproximity
[01:13] <pochu> stgraber: libfprint is now in debian experimental. You may want to request a sync for it ;) http://packages.debian.org/source/libfprint
[01:18] <dcordero> hi
[01:18] <somerville32> hi
[01:18]  * sistpoty goes to bed now
[01:18] <sistpoty> gn8 everoyne
[01:58] <blueyed> Is it ok to push changes to http://bazaar.launchpad.net/%7Eubuntu-dev/ubuntu-dev-tools/trunk/ directly - or should I offer the branch? These are changes/improvements to requestsync.. (bug 190351)
[01:58] <ubotu> Launchpad bug 190351 in ubuntu-dev-tools "requestsync crashed with EOFError, when ending input with ctrl-d" [Undecided,New] https://launchpad.net/bugs/190351
[01:59] <blueyed> The branch is locked currently anyway (since > 200 hours).. :/
[02:40] <bddebian> Heya gang
[02:40] <RAOF> Howdie bddebian.
[02:41] <persia> hey bddebian
[02:41] <emgent> heya people :)
[02:42] <bddebian> Hi RAOF, persia, emgent
[02:55]  * ScottK cheers.
[02:56] <ScottK> mok0 now TIL courier.
[02:57] <bddebian> Heya ScottK
[02:57] <ScottK> heya bddebian
[02:58] <ScottK> So I decided to go ahead and sync your testresources nmu over my fix.  You fixed it upstream, so you win.
[02:58] <bddebian> mwuhahaha ;-P
[02:58] <emgent> :)
[03:10] <RAOF> What do people think of the Debian machine-readable copyright format proposed here?  http://wiki.debian.org/Proposals/CopyrightFormat
[03:11] <blueyed> RAOF: I like it and have used it for the two packages I've created (jedit and tvbrowser on revu)
[03:12] <RAOF> In particular; I think it looks like a reasonable idea, but I'd like to know how people would react to packages hitting the archive with deban/copyright in that format.
[03:12] <ScottK> RAOF: No one I know of has objected to it.
[03:12]  * ScottK would get grumpy if people started insisting on it though.  It's not policy.
[03:13] <bddebian> heh
[03:16] <RAOF> debian/copyright should be partially automateable.  Does anyone have scripts in that direction (scraping headers for copyright holders, etc)?
[03:17]  * jdong kneels in front of the confessions window.
[03:17] <jdong> Dear MOTU deities, I have sinned.
[03:17] <jdong> Someone was trying to add a launcher for gnome-terminal that starts irssi with a custom profile
[03:18] <jdong> --window-with-profile looks promising but starts an empty window along with the desired one
[03:18] <jdong> I suggested the hack: gnome-terminal -e /bin/true --window-with-profile=irssi -x irssi
[03:18]  * jdong gets up and waits for enlightenment
[03:18] <jdong> (i.e. a valid solution)
[03:25] <persia> RAOF: You might start looking at suspicious-source to see if that might help.  On the other hand, licensing is hard, especially because of whitespace issues.
[04:08] <tuxmaniac> heya. morning all
[06:49] <slytherin> Hi, I want to make a sync request for libxstream-java, but it's dependency is still stuck in 'new' queue so I can't test if it builds. And libxstream-java is needed by groovy which is in depwait.
[06:52] <persia> slytherin: You might try manually building in a chroot to test the build.  Alternately, wait a bit (although only a few more archive-admin days before feature freeze).
[07:07] <Iulian> G'morning
[07:23] <HighNo> good morning!
[09:05] <pochu> jdong: will you forward the irssi manpage patch upstream? :)
[09:44] <proppy> oy
[10:02] <persia> So glancing at REVU, I'm seeing an explosion in package updates.  Packagers packaging updates should submit the diff.gz in a bug to the sponsors teams.
[10:17] <LucidFox> So once again, my attempt to migrate from KMail to Thunderbird got botched...
[10:19] <persia> LucidFox: Which were the packages on REVU you wanted to advocate again?
[10:20] <Hobbsee> LucidFox: why?
[10:20] <HighNo> oh, you wanted to advocate blueproximity, right?
[10:20] <HighNo> (sorry, just a try :-) )
[10:21] <LucidFox> persia> I didn't review them, so I wouldn't advocate them on the spot - but those are qdevelop and gtkglextmm
[10:22] <Hobbsee> blueproximity looked reasonably good to me, although the lack of python-{central/support} stuff looked suspicious
[10:22] <persia> LucidFox: OK.  If you happen to review them, complain here looking for an advocate.
[10:23] <persia> Hobbsee: ?  It lists python-support.
[10:23] <geser> good morning
[10:24] <Hobbsee> persia: it didnt when i looked, i didn't think
[10:24] <Hobbsee> or i missed it
[10:24] <persia> morning geser
[10:24] <persia> Hobbsee: Ah.  That might be it.
[10:24] <HighNo> Hobbsee: right, python-support - but there's not too much stuff in there as it does not create seperate modules for other python stuff...
[10:24] <HighNo> Hobbsee: might be, I uploaded it several times as one can see...
[10:24] <Hobbsee> ah right
[10:24]  * Hobbsee only saw the first, iirc
[10:27] <persia> Nightrose: Do you happen to use 2ch, or were you just providing advice for kita2?
[10:28] <Nightrose> persia: ? are you sure you mean me?
[10:28] <HighNo> Just another question regarding updated translations. If my package is being approved, is there a quick way to update the translations only? I mean I could implement them as a patch and note then when puting the package on revu. Would that be the correct way? Feature Freeze means there will be no more packages accepted right?
[10:29] <persia> Nightrose: No.  The pointer is second hand (from comments in http://revu.ubuntuwire.com/details.py?package=kita2).  Based on your response, I suspect you don't use 2ch :)
[10:30] <geser> HighNo: FF means that no new packages and no new upstream version will be accepted without an exception
[10:30] <persia> HighNo: Once a package is accepted, updates are submitted as patches in bugs.  Translation updates are welcome until quite late in the cycle.
[10:30] <Nightrose> persia: hehe ok ;-) he just asked me to have a look at the description and check for problems
[10:31] <persia> Nightrose: OK.  I just was hoping you were both a KDE user and 2ch user, as while I think the package should be in the archives, this is from altruism, and I haven't actually tested in the ideal target environment :)
[10:32] <Nightrose> well I am a kde user but hinestly have no idea what ch2 is ;-)
[10:32] <Nightrose> *honestly
[10:35] <persia> http://2ch.net/ but it's optimised for use on phones, so the interface leaves something to be desired.  No worries :)
[10:37] <HighNo> persia: that's good news as I started a translation day on many channels and got some new interesting languages.
[10:38] <persia> HighNo: Great!  More languages is better :)
[10:39] <LucidFox> persia> commented on qdevelop
[10:40] <persia> LucidFox: Added to my queue.  I'll likely ACK then.  Thanks.
[10:57] <LucidFox> persia> and speaking of DEB_DH_INSTALL_SOURCEDIR, I now understand the point - it has the same effect as the --sourcedir parameter of dh_install. Basically, it allows to drop debian/tmp/ prefixes from debian/*.install.
[10:59] <persia> LucidFox: Yes, precisely.  Personally, I don't like it because it's not an easy trick to learn, and only saves a few keystrokes, without gaining the advantages of cross-package utility that the use of something like CDBS or debhelper provides.
[11:12]  * DaveMorris requests are review of http://revu.tauware.de/details.py?package=gtkglextmm (should be there now)
[11:14] <crevette> hello there
[11:14] <crevette> I need some help with a package I'm building
[11:15] <crevette> lintian returns "W: obex-data-server: package-contains-empty-directory usr/sbin/" and a dpkg -c my.deb shows me it creates an empty /usr/sbin
[11:15] <crevette> why ?
[11:16] <persia> crevette: Because you used dh-make, and didn't clean up all the template files.  Your issue is with debian/dirs
[11:16] <crevette> ah thanks
[11:19] <persia> crevette: Getting that error typically means that there are other issues with the templates as well.  Please check carefully to make sure you've edited all the files, removed any you don't need, and are sure you want to keep the parts remaining.
[11:20] <crevette> persia: okay thanks, I'm running over the other files
[11:39] <pochu> Anyone from the MOTU Science team? You might be interested in bug 105473
[11:39] <ubotu> Launchpad bug 105473 in ubuntu "[needs-packaging] Extrema" [Wishlist,Confirmed] https://launchpad.net/bugs/105473
[11:52] <afflux> libotr (main) has a hidden dependency on libgcrypt11-dev, which was fixed in debian. Is a missing dependency sufficient for a sync request?
[11:53] <Georgex96j15qi4g> available they it's come is part VR of and be completely the could its ultimate in concept likely
[11:53] <Georgex96j15qi4g> never experience part time. they that term fancy helmet of used than why be you're to and could
[11:53] <Georgex96j15qi4g> has helmet after now. doesn't surge VR in available, popular they is user the can there", of films,
[11:53] <Georgex96j15qi4g> unable made more from more in the than its had still reality but virtual that the actually actually
[11:53] <Georgex96j15qi4g> and the basic to all vision hard way Demise they saw that budget? the of stereoscopic industry on
[11:53] <jpatrick> !ops | Georgex96j15qi4g
[11:53] <Georgex96j15qi4g> helmet. imagine, association tell virtual or with pop virtual a be this culture without virtual handshake get watching
[11:53] <ubotu> Georgex96j15qi4g: Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu or PriceChild!
[11:53] <Georgex96j15qi4g> you of may virtual their idea term so have technology even it, a that As include 1990s, watching
[11:53] <Georgex96j15qi4g> a commercially up helmets It It's senses term's reason so the of can close they the So course,
[11:53] <Georgex96j15qi4g> goal without senses helmets a the systems didn't available much let's take even reason embracing Of in us
[11:53] <LucidFox> o_O
[11:54] <persia> afflux: Depends.  If there are other useful fixes as well, surely.  If there are other things that you don't think should sync, then just a patch would work.  Generally syncs are preferred if they don't cause any issues.
[11:54] <afflux> persia: there were no other changes
[11:54] <Hobbsee> Seveas: them again?
[11:54] <persia> afflux: Sounds like a sync then.
[11:54] <Hobbsee> Seveas: they need a kline
[11:55] <Hobbsee> Seveas: thta nick looks similar to #kubuntu
[11:55] <afflux> persia: we'll, yes, but I wonder if it's enough for a sync after debian-import-freeze
[11:55] <Seveas> Hobbsee, tor should be shot. Like any improperly implemented privacy thing it's abuse too much
[11:55] <Hobbsee> Seveas: this is true
[11:56] <persia> afflux: Unless I'm mistaken, there's a bug in Ubuntu libotr that needs fixing.  As it's already fixed in Debian and there were no other changes in Debian, a sync is the easiest way to fix it.  DIF only means "Don't sync stuff just because it's updated in Debian: think about it first".
[11:57] <afflux> okay, good
[11:58] <jpatrick> persia: ah, it does work
[12:06] <Hobbsee> jpatrick: they're being killed
[12:06] <jpatrick> Hobbsee: they better
[12:07] <persia> LucidFox: qdevelop rejection ACK'd.
[12:09] <LucidFox> persia> just commented on gtkglextmm as well
[12:09] <persia> DaveMorris: Do you need explicit rejection, or are you on that?
[12:10] <DaveMorris> just gonna read it
[12:10] <sboden> Is there a way to check what happened when you upload something to revu, but you don't see it appearing on the website?
[12:11] <persia> sboden: Ask here.  Which package?
[12:11] <sboden> kmess
[12:11] <sboden> It's a first try, maybe I miss permissions somewhere
[12:11] <persia> sboden: What is your LP id?
[12:12] <sboden> same ... sboden
[12:12] <sboden> I can see what dput puts in the /incoming directory but after that it gets "erased"
[12:13] <persia> sboden: https://launchpad.net/~sboden doesn't show much.  Are you sure?
[12:13] <sboden> my bad : https://launchpad.net/~svenboden
[12:13] <sboden> too many userid's
[12:14] <persia> sboden: You just joined the team, and the keyring sync hasn't happened yet.  Please try again in about half an hour.
[12:14] <sboden> k thx
[12:16] <DaveMorris> LucidFox: it is currently arch independent, I guess nearly all dev packages could be arch all as well then, I've never realised that
[12:17] <LucidFox> DaveMorris> Well, some -dev packages include .a files
[12:17] <LucidFox> or utilities, like libqt4-dev
[12:18] <DaveMorris> yeah, I've been told that new packages shouldn't include static libs
[12:18] <DaveMorris> so basically my last 3 packages (all libs) could of done this as well
[12:21]  * HighNo wonders how fast you guys are. You look/create tens to hundreds of packages per day. kudos!
[12:23] <HighNo> just getting my first package done seem like a full time job to me...
[12:23] <persia> HighNo: teamwork.  Lots of people spending lots of time, each doing one thing.
[12:24] <Hobbsee> or whinging, as the case may be
[12:26]  * persia suspects whinging doesn't lead to package updates or new packages, but might be considered part of "teamwork" in some special cases.
[12:31] <persia> sboden: Should be good now.  Try again.  Please note that the last official REVU day for hardy has passed, so your package may not get reviewed until May.
[12:33] <DaveMorris> LucidFox: linda gives me one warning I don't understand when using arch all on the dev package - W: libgtkglextmm-x11-dev; File /usr/lib/pkgconfig/gdkglextmm-x11-1.2.pc contained in /usr/lib of Architecture: all package.
[12:34] <pef> hello
[12:34] <webwolf_27> does anybody have any idea where I can find an example debian/rules file for a bin-only package
[12:35] <LucidFox> DaveMorris> I think this isn't a blocker.
[12:36] <DaveMorris> I've checked the file created and it doesn't contain any arch specfic stuff, I'll upload it
[12:37] <pef> webwolf_27: *firmware packages ?
[12:38] <webwolf_27> pef, no binary-only drivers
[12:39] <pef> webwolf_27: they behave the same way, don't they ?
[12:39] <webwolf_27> pef, also a point
[12:40] <pef> webwolf_27: check opera package
[12:40] <pef> or unrar non free
[12:40] <webwolf_27> ok
[12:41] <LucidFox> I don't frankly understand the point of the Opera package
[12:41] <LucidFox> I can understand proprietary drivers with no free replacement, but a web browser?
[12:42] <webwolf_27> LucidFox, I installed opera for the sole purpose of testing webpages with opera
[12:44] <HighNo> persia: when as the "last official REVU day" been?
[12:44] <webwolf_27> pef, thanks for the tip. The unrar-nonfree looks promising
[12:45] <persia> HighNo: For hardy, REVU Days were every Monday (all timezones) from 5th November to 4th February.  The schedule for the next release has yet to be determined.
[12:46] <persia> As a very rough guess, I suspect the first REVU Day to happen sometime during the week containing May 29th, but there are many factors that could adjust that significantly.
[12:47] <HighNo> gosh  - so there's not even a slightest chance my package will make it into hardy?
[12:48] <DaveMorris> LucidFox: it's updated, thanks for looking at the package
[12:48] <persia> HighNo: Basically, no.  Maybe if some MOTU happens not to be busy with last minute things for Feature Freeze and needs your package for something, they might grab it, but it's a slim chance indeed.
[12:50] <Hobbsee> persia: another option, then, is presumably debian-mentors, then sync after our feature freeze
[12:51] <persia> Hobbsee: If the package is important enough to allow a FeatureFreeze exception, I'm not sure how pushing through mentors is different from pushing through REVU, unless someone is planning to maintain the package for Debian.
[12:52] <Hobbsee> this is true - but new packages from debian carry little risk, and little time taken
[12:52]  * HighNo thinks of a hopelessly overworked MOTU often leaving his/her Notebook or computer unlocked in a possibly insecure environment so that he/she needs my package to lock the pc whenever he leaves it. (Or as DaveMorris put it: You could use it to see your boss coming before he's in your room so you can quickly move from the 'must finish MOTU work desktop' over to the 'work desktop')
[12:52] <LucidFox> HighNo> lol
[12:53] <LucidFox> DaveMorris> Thanks. I'm sorry for not looking at the debian dir first, or I would have brought more things to your attention at once. I'll post some more objections, but these are trivial to fix.
[12:53] <persia> Hobbsee: Maybe, but I'd think two ACKs from REVU to be similar to a pass into Debian.  Also, adjusting the build and test environment completely is often more work for the packager.
[12:53] <paas> persia: thanks for reviewing my package. I've fixed your comments and uploaded a new version http://revu.tauware.de/details.py?package=libtuxcap cheers
[12:54] <Hobbsee> persia: mmm, true.
[12:54] <persia> paas: You've made it impossible for me to review it, but thanks for the quick response.  Good luck!
[12:54] <LucidFox> DaveMorris> commented
[12:54] <DaveMorris> thanks
[12:54] <Hobbsee> HighNo: that's when you train to autolock your machine whenever you walk away
[12:55]  * Hobbsee can't seem to do that under gnome
[12:55] <paas> persia: why's that?
[12:55] <persia> paas: architecture limitations
[12:55] <paas> persia: I see
[12:56] <HighNo> Hobbsee: see - you need it :-)
[12:56]  * DaveMorris likes commented out deb calls, as it's easier to re-implement them, and for new people to learn from IMO
[12:56] <Hobbsee> HighNo: no, now i just make sure i flip the cube, then lcok the screen via the mouse, whenever i go away :)
[12:56] <HighNo> Hobbsee: you could save that precious time :-)
[12:57] <StevenK> Hobbsee: Or use a screensaver that doesn't show the contents of the desktop
[12:57]  * persia thinks it's not a cube, and that is still a manual action, and admires HighNo's imaginative advertisement
[12:57] <HighNo> :-)
[12:57] <Hobbsee> HighNo: :)
[12:57] <Hobbsee> StevenK: i don't.  it's blank
[12:57]  * StevenK uses electric sheep
[12:58] <LucidFox> persia> please explain to DaveMorris why commented out dh_ calls are bad :)
[12:59] <StevenK> Because it bloats the rules file and makes it hard to read
[12:59] <persia> DaveMorris: It makes debian/rules longer, and therefore is more troublesome to read.  It also looks ugly, and can be confusing to people working on their first patch when they fix a bug.
[13:00] <LucidFox> StevenK, are you the upstream developer of linda or just its Debian maintainer?
[13:00] <StevenK> Upstream
[13:00] <LucidFox> Awesome. When can we expect a version that doesn't complain about Standards-Version 3.7.3? :)
[13:00] <HighNo> right - that's the last warning on my list too :-)
[13:01] <StevenK> A week after the last person asked
[13:01] <LucidFox> lol
[13:01] <LucidFox> I get the hint, thanks
[13:01] <Hobbsee> maybe someone should just nmu
[13:02] <HighNo> nmu?
[13:02] <StevenK> You know, I'm very close to asking for it's removal.
[13:02] <Hobbsee> see if StevenK gets angry
[13:02] <Hobbsee> oh?  why?
[13:02] <LucidFox> well, linda is ubuntuX anyway, so someone could patch it for Ubuntu
[13:02] <StevenK> Because it didn't serve it's purpose, and everybody has pulled my ideas from it and put it into lintian
[13:03]  * StevenK sighs
[13:03] <Hobbsee> argh!
[13:03] <Hobbsee> the fade to black screensaver, when you have stuff inverted, is white!
[13:03] <StevenK> Err, yeah. That's what invert means :-P
[13:04] <Hobbsee> yeah, but i didn't think it'd go for screensavers too
[13:04] <Hobbsee> it doesn't go for desktop backgrounds, for eg
[13:04] <StevenK> Because compiz doesn't draw it
[13:04] <StevenK> Nautilus does
[13:04] <Hobbsee> ahh
[13:05] <Hobbsee> this reminds me of why i should go back to kde
[13:05] <StevenK> It takes every RGB value it draws, and minuses it from (255, 255, 255)
[13:06] <StevenK> Since it has all of the GL textures it draws in memory, inverting colour maps is trivial
[13:06] <StevenK> (Geez compiz doesn't seem like magic when you can figure out how it does its crack)
[13:07] <LucidFox> heh
[13:07] <LucidFox> Hobbsee> Go back to KDE? Why?
[13:07] <Hobbsee> missng bits in gnome
[13:08] <StevenK> Such as?
[13:08] <Hobbsee> hmmm
[13:08] <Hobbsee> a world clock that works
[13:08] <HighNo> I'm at GNOME because I think it's missing the missing bits :-)
[13:09] <Hobbsee> running kde/qt apps natively
[13:09] <LucidFox> the one in Hardy doesn't?
[13:09] <Hobbsee> not really
[13:09] <Hobbsee> it doesn't actually show the times atm
[13:09] <Hobbsee> yay for bugs
[13:09] <StevenK> So patch it? :-P
[13:09] <Hobbsee> StevenK: that would requrie being active
[13:09] <Hobbsee> but this is true
[13:10] <Hobbsee> it's a known bug
[13:10] <StevenK> I'm fairly certain that bug is because it always check the local time, not the time for that row
[13:10]  * Hobbsee nods
[13:10] <Hobbsee> various bits of config missing in gnome
[13:10] <persia> Hobbsee: Fixing things that annoy you is good.  Fixing things that annoy other people is nice, but not fixing things that annoy you just compounds it.
[13:10] <Hobbsee> persia: true
[13:11] <DaveMorris> LucidFox: updated
[13:11] <geser> Hi bddebian!
[13:11] <HighNo> persia: If I would have done that all my life I'd have no windows experience at all...
[13:11] <bddebian> Heya gang
[13:11] <bddebian> Hi geser
[13:12] <persia> HighNo: No reason not to start now :)
[13:12] <persia> bddebian: Hey
[13:12] <bddebian> Hi persia
[13:12] <LucidFox> DaveMorris> Thanks. I have no more objections. (But IANAMOTU.)
[13:13] <HighNo> persia: true. I should even not be here at the moment. I got another exam on monday and I've learned about - ehm - like 2 hours...
[13:13] <DaveMorris> your still waiting then
[13:13] <persia> which package?
[13:13] <LucidFox> persia> https://launchpad.net/ubuntu/+source/gtkglextmm
[13:13] <LucidFox> oops
[13:14] <LucidFox> http://revu.tauware.de/details.py?package=gtkglextmm
[13:14] <persia> heh
[13:17] <smarter> hi
[13:18] <smarter> Is it normal that CDBS symlinks things in /usr/share/doc/<pkg>?
[13:18] <LucidFox> smarter> I've commented on qdevelop
[13:18] <LucidFox> smarter> yes, it's normal
[13:19] <smarter> LucidFox: thanks
[13:19] <LucidFox> you can ignore lintian warnings about it
[13:19] <smarter> ok
[13:20] <smarter> but I've three binary packages(extremetuxracer extremetuxracer-data and extremetuxracer-gimp-dev), extremetuxracer doc files link to extremetuxracer-data but extremetuxracer-gimp-dev has its own docs files
[13:21] <LucidFox> but CDBS only symlinks identical files present in hard dependencies, ne?
[13:21] <persia> smarter: Wasn't it just -data that got hit by the CDBS symlink attack?  You can make the warning go away by manually linking the directory as advised by lintian, but it's not typically important.
[13:23] <smarter> persia: how can I do this?
[13:25] <persia> smarter: delete the contents of /usr/share/doc/extremetuxracer-data/ and symlink it to /usr/share/doc/extremetuxracer in debian/rules.  I'm not telling you that you should do this, only that it makes lintian quiet.
[13:26] <smarter> that seems a bit overkill for a lintian warning ;)
[13:26] <smarter> I'll let cdbs do his stuff
[13:32] <smarter> QDevelop fixed and uploaded ;)
[13:33] <smarter> If I use a .menu file, should I build-dep on menu?
[13:37] <persia> DaveMorris: s/binary:Version/source:Version/, also, might it be good to but the library names in a shlibs file for packages that later build-depend on libgtkglextmm-x11-dev?
[13:37] <persia> smarter: You don't need to build-dep, and dh_installmenu maintainer script bits disable silently if the menu package is not installed.
[13:38] <DaveMorris> persia: ok
[13:43] <aquo> what is the difference between dput and dupload? i want to upload something to ppa
[13:46] <mok0> aquo: same thing
[13:46] <mok0> dput is written in Python, dupload in Perl...
[13:48] <aquo> are there any reasons to prefer one over another?
[13:57] <mok0> aquo: no
[14:04] <dcordero> hi
[14:52] <frafu> Hello, I am reading the wiki documentation about syncing packages and I wonder what UpstreamVersionFreeze means. Maybe the upstream Feature Freeze?
[14:53] <tonyyarusso> frafu: Upstream Version Freeze means that is the deadline for incorporating any upstream versions, ie OpenOffice.org version 2.3.1.
[14:55] <persia> frafu: Before hardy, there were separate freezes for "FeatureFreeze", "UpstreamVersionFreeze", and "UniverseNewPackagesFreeze".  Now, they are all "FeatureFreeze".
[14:55] <persia> frafu: Please update the outdated page :)
[14:58] <frafu> persia: so I have to replace UpstreamVersionFreeze with FeatureFreeze on that page!? By the way, thanks to both of you for the explanation.
[14:59] <persia> frafu: Exactly.  Thanks for helping to keep the documentation up to date.
[14:59] <frafu> ok; I will do it
[15:04] <LucidFox> persia> qdevelop looks good to me now
[15:04] <persia> LucidFox: Best get someone else to ACK for the next bit: it's getting late here.
[15:04] <LucidFox> Okay.
[15:11] <LifeHacker> hi. there has been a package sync from debian unstable but it FTBFS
[15:12] <LifeHacker> I have changed a few missing build-deps. How do I go about submitting the patch?
[15:14] <geser> tuxmaniac: create a debdiff (see https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and attach it to a bug
[15:15] <tuxmaniac> geser, ok. the bug is already created in Debian BTS. I recreate it in LP also?
[15:15] <geser> tuxmaniac: yes
[15:15] <geser> but you can link the LP bug to the BTS one
[15:44] <DaveMorris> hmm, with an shlibs file.  Lintian complains if it's done one way, I change to fix that way and then Linda complains.
[15:44] <DaveMorris> I can't make both of them happy, so which one is wrong?
[15:50] <webwolf_27> an somebody please tell me what "dpkg-genchanges: failure: cannot read files list file: No such file or directory" means and evtl. how to fix it
[15:53] <geser> webwolf_27: my guess is that you try to build a (binary) package on an arch where it shouldn't be build
[15:55] <webwolf_27> geser, yes it's a binary package but the arch is set correctly
[15:55] <crevette> where should I propose new soft to package in ubuntu ?
[15:55] <rZr> hippu: hi thx for taking care of tuxguitar
[15:55] <rZr> hippu: I'll try to port it to icedtea soon
[15:56] <hippu> thanks
[15:56] <geser> webwolf_27: can you make the package somewhere available to look at?
[15:56] <webwolf_27> geser, I can paste the rules file in pastebin
[15:57] <webwolf_27> geser, or I can upload a tared package
[15:58] <vemon> does simple-patchsys need anything else for patching than the patch file in debian/patches directory?
[15:59] <geser> vemon: afaik no
[15:59] <vemon> i've seen a "series" file used in some packages. is that required for sps?
[15:59] <geser> series is used by quilt
[15:59] <vemon> seems like the package i'm creating at the moment doesn't patch up even though i've included the simple-patchsys.mk in rules and added the patch to debian/patches
[16:00] <kdub> when i run debuild on a package i'm trying to create, it fails, saying i do not have a secret pgp key. i do indeed have a secret pgp key, so why isnt debuild finding it?
[16:01] <webwolf_27> geser, which would you prefer
[16:01] <geser> webwolf_27: let's try first with rules
[16:02] <geser> vemon: perhaps the naming of the patches (file extension)
[16:02] <webwolf_27> geser, ok just a sec
[16:03] <vemon> geser, you're probably right. i don't have any extension there atm
[16:03] <vemon> maybe i'll try to use .patch
[16:04] <webwolf_27> geser, http://pastebin.org/18822 not much too it though
[16:04] <geser> kdub: does the changed-by field from the .changes file match your key uid (including any comments)?
[16:05] <geser> webwolf_27: that's a very short rules file. what are you trying to do?
[16:06] <webwolf_27> geser, I'm package the closed-source brother-lpr printer drivers
[16:07] <geser> webwolf_27: even then you will need some dh_* calls in binary-arch
[16:07] <webwolf_27> geser, ok
[16:08] <kdub> geser: it detected my name as "Kevin" when the name on my key id is my full name, and when i change it in the .changes file, it gets overwritten to the wrong value
[16:08] <vemon> should the get-orig-source target download the same upstream version as the package version implies or the newest (use watch file & uscan)
[16:08] <vemon> ?'
[16:10] <geser> kdub: the value is taken from your changelog entry (in debian/changelog)
[16:11] <kdub> geser: there it goes, thanks!
[16:11] <ScottK> DaveMorris: If you have to pick, keep lintian happy.  It's more current.
[16:14] <protonchris> ScottK: thanks for answering my question the other day.  You said that I should use postgresql-8.3 | postgresql-8.2 .  However, the package requires a configure option to point to the postgresql bin directory.  What is the best way to handle this?
[16:14] <DaveMorris> ScottK: thanks, did you want me to file a bug on it?  I think it's because the soname is libgtkglextmm-x11-1.2 Linda seems to want libgtkglextmm-x11
[16:15] <webwolf_27> geser, thanks it got built
[16:17] <kdub> should pbuilder generate a .deb file?
[16:17] <ScottK> DaveMorris: Linda is currently unmaintained. I wouldn't worry about it.  If it gets picked up again I think the author knows what he needs to do.
[16:17] <webwolf_27> geser, now it's only missing the included files list
[16:18] <ScottK> protonchris: I'm not a postgresql expert, but there is a postgresql-common package that deals with multiple versions installed side by side.  I'd look into that.
[16:18] <protonchris> ScottK: thanks.
[16:18] <geser> webwolf_27: you should copy the files to the correct location below debian/<pkgname>/ so they got included in the binary deb
[16:19] <webwolf_27> geser, thanks. you probably noticed that this is my first deb ( I used to build RPMs but this is a little different
[16:20] <ScottK> mok0: Thanks for the courier merge.  Was that fun (I uploaded it last night)?
[16:27] <crevette> how can I create an ITP on debian from a ubuntu system as reportbug was patched ?
[16:28] <spectie> crevette, email submit@bugs.debian.org
[16:29] <crevette> okay I found
[16:29] <crevette> :)
[16:29] <crevette> thanks
[16:29] <spectie> np
[16:29] <jdong> pochu: my original reporter was planning on doing that... I don't know if he's still doing so. If not, I'll do it :)
[16:30] <pochu> jdong: cool :)
[16:31] <geser> crevette: tell reportbug to use the Debian BTS and use reportbug then
[16:34] <asantoni> hi all
[16:35] <asantoni> Can I prod someone to review my updated Mixxx package sometime? http://revu.tauware.de/details.py?package=mixxx
[16:36] <asantoni> (please) :)
[16:36] <jdong> How can we get people to stop using Launchpad as a discussion board?
[16:36] <Seveas> jdong, with a hammer
[16:37] <jdong> I'm increasingly seeing bugs where it turns into a forum thread of people telling each other to grab stuff from git, compile vanilla kernels....
[16:37] <asantoni> jdong: in bug report comments?
[16:37] <jdong> asantoni: right.
[16:37] <asantoni> hmmm
[16:37] <jdong> or confirm/say exactly what the person above said
[16:37] <asantoni> it's a consequence of having an open bug tracker
[16:37] <jdong> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/177570
[16:37] <ubotu> Launchpad bug 177570 in hal "[hardy] two batteries display when left clicking on g-p-m" [Medium,Confirmed]
[16:38] <jdong> for example, on that bug, only about 25% of those comments were actually necessary
[16:38] <asantoni> (not that that sheds any light on a solution)
[16:38] <jdong> comment #23 was what ultimately set me off.
[16:38] <asantoni> yeah, I've seen it happen tons of times too.... the nautilus/file-roller drag-and-drop bug was a circus
[16:39] <jdong> I don't know if providing a way for LP to link to a discussion medium would help
[16:39] <jdong> like linking a bug to a forum thread and being able to move posts back and forth?
[16:39] <asantoni> Yeah, perhaps
[16:39] <jdong> there was a backports bug too where by the time I saw it there were 50+ replies and I was really tempted to just say "file it again"
[16:40] <asantoni> People (including myself at times, I admit) like looking at bugreports for "the quick fix"
[16:40] <asantoni> It's kind of a bastardized use case
[16:40] <jdong> asantoni: I don't blame you. As a user, that's all you really care about when you see a bug.
[16:40] <asantoni> :)
[16:40] <jdong> asantoni: I'm not here to discourage people from doing that, I just want to find a better medium for it
[16:40] <asantoni> right, so the question is, what's the best way to address that use case
[16:40] <jdong> because the way it's being done now *gets in the way* of developers trying to fix the bug
[16:40] <asantoni> yeah
[16:41] <asantoni> oh yeah, I understand completely
[16:42] <asantoni> I don't know if adding something like a "temporary workaround" link would help at all
[16:42] <asantoni> because while that would make it easy for people to find the quick fix, it probably wouldn't stop LP from becoming a forum
[16:42] <jdong> probably something like "Link this to a {discussion}"
[16:42] <jdong> where Discussion can be a forum thread, mailing list, launchad answer ticket....
[16:43] <asantoni> Yeah, that might work
[16:43] <jdong> and also, for posts to be migrate-able by the QA team across that link
[16:43] <asantoni> Perhaps there could be some streamlined way to add a "temporary workaround" Launchpad answer
[16:43] <asantoni> yeah
[16:45] <geser> jdong: in your comment on that bug you forgot to tell that those who try this workaround will have to fix their system themselves if the workaround breaks something now or in the future
[16:45] <jdong> geser: I dodn't want to open that can of worms, but yeah, that workaround can cause real hell
[16:46] <asantoni> haha
[16:46] <asantoni> it's true
[16:46] <vemon> any motus could advocate & upload this: http://revu.tauware.de/details.py?package=lashwrap
[16:46] <jdong> randomly grabbing the moment's hal from git and overwriting the local installation with it
[16:46] <jdong> is it kosher to depend on libc6-dev (>= foo) to force a rebuild against a newer libc6?
[16:48] <geser> jdong: afaik yes
[16:49] <jdong> mmmkay :)
[16:49] <jdong> and I'd like to vent some anger at mldonkey
[16:49] <jdong> which seems to need the entire ocaml stack to just debian/rules clean.
[16:51] <geser> jdong: in such cases I use dpkg-source -b to get a new source package (and dpkg-genchanges if I need also the .changes file)
[16:54] <jdong> geser: good idea
[16:54] <tuxmaniac> debdiff -v old dsc_old dsc_new should be sufficent for submitting patches?
[16:55] <tuxmaniac> * debdiff -v dsc_old dsc_new
[16:56] <ScottK> tuxmaniac: Yes
[16:56] <ScottK> However look at it to make sure it's sane.
[16:56] <stani> pochu & scottk: I'll continue here as it is ubuntu specific... I see that ubuntu hardy still ships winpdb 1.3.2, while debian ships 1.3.4. Any chance of updating that as well? Probably only a sync.
[16:58] <ScottK> Shouldn't be a problem.
[16:58] <crevette> where should I submit ITP for ubuntu ?
[16:59] <stani> Thanks
[17:01] <tuxmaniac> ScottK, no diff is generated
[17:01] <tuxmaniac> ScottK, only if the control file is changed?
[17:03] <kdub> can anyone help me with my pbuilder problem? http://pastebin.ca/897503
[17:04] <ScottK> stani: winpdb sync requested.
[17:04] <ScottK> tuxmaniac: You did build the new source package, right?
[17:05] <asantoni> kdub: The "make install" is failing
[17:05] <ScottK> dpkg-buildpackage/debuild -S
[17:05] <tuxmaniac> ScottK, aah wdiff is not available it seems
[17:05] <kdub> i did do debuild -S, but i can try again
[17:05] <asantoni> kdub: Does running "make install" in the entropy source directory work normally?
[17:05] <ScottK> kdub: I was talking to tuxmaniac.  Sorry for the confusion.
[17:06] <tuxmaniac> ScottK, I did this. pbuilder --debbuildopts -sa
[17:06] <tuxmaniac> *pdebuild
[17:06] <kdub> asantoni: make install does not work
[17:07] <tuxmaniac> ScottK, I meant s/pbuilder/pdebuild
[17:07] <ScottK> stani and pochu: pychecker still FTBFS in Ubuntu.
[17:07] <asantoni> kdub: ok, so... is that the correct directory to be executing "make install" in?
[17:07] <ScottK> (with python 2.5)
[17:09] <geser> crevette: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages and in case of an ITP assign it to you
[17:09] <crevette> okay thanks
[17:11] <kdub> it is the correct directory, however, this particular configure script is doing funny things (i.e. not working right) so i'll look into that now
[17:13] <asantoni> ok
[17:15] <crevette> if someone is interested to review this http://revu.tauware.de/details.py?package=obex-data-server
[17:27] <tuxmaniac> can somone check bug 190473 and ack the diff? Its the first one that is much better
[17:27] <ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Confirmed] https://launchpad.net/bugs/190473
[17:31] <geser> tuxmaniac: your last debdiff misses a changelog entry (0.1.2-1ubuntu1) with your changes
[17:32] <geser> tuxmaniac: you need to change also the maintainer field in debian/control
[17:32] <tuxmaniac> geser, I know. But the previous one which peter has uploaded contains them
[17:35] <geser> tuxmaniac: but not a quite correct one: wrong version, wrong distribution
[17:35] <geser> tuxmaniac: and the maintainer change is also missing there
[17:35] <mok0> When writing the lintian overrides file, do you need to include the entire lintian message, or just a regexp?
[17:35] <tuxmaniac> geser, aah yes. if we are taking this for ubuntu then we need to update all those
[17:36] <tuxmaniac> geser, I guess he uploaded the same one as for debian bts bug
[17:36] <tuxmaniac> geser, do we wait for debian to upload the changes or make local changes?
[17:36] <geser> tuxmaniac: we can fix it now for Ubuntu
[17:36] <tuxmaniac> geser, ok
[17:37] <geser> tuxmaniac: if you want to fix this bug, could you prepare a debdiff with all needed changes and subscribe then the ubuntu-universe-sponsors team for sponsoring?
[17:37] <tuxmaniac> geser, am doing that already :)
[17:38] <geser> thanks
[17:48] <webwolf_27> geser, Sorry to bother you again. I created the dirs and copied the files into debian/packname but the deb still doesn't include the files
[17:52] <tuxmaniac> geser, mainatiner field will be MOTU right?
[17:53] <DaveMorris> tuxmaniac: yeah
[17:53] <geser> tuxmaniac: yes, you can use the updatemaintainer script from ubuntu-dev-tools to do it
[17:56] <kdub> the package i'm trying to build turns out to use an "install.sh" script, not a make install. can i tell pbuilder about this somehow?
[17:56] <tuxmaniac> geser, oh cool. thanks
[17:56] <geser> kdub: sure, replace the make install call in your debian/rules with the correct call of that install.sh script
[17:57] <kdub> geser: thanks, for some reason i didnt think of that...
[18:00] <linux__alien> hi people
[18:00] <linux__alien> hey mok0
[18:00] <linux__alien> hey LucidFox
[18:00] <mok0> Hey linux__alien
[18:00] <linux__alien> thanks for your help yesterday finally got the package :)
[18:01] <linux__alien> i will now try doing an other package . those given in the recipe
[18:01] <linux__alien> i am interested in fixing bugs and packaging too so how do i go about it
[18:02] <linux__alien> so much interested in contributing to Ubuntu in either of these 2 forms but the former would be the better :)
[18:02] <LucidFox> linux__alien> Fixing bugs is great and always welcome. New packages may be too late to submit at this point, we're very near feature freeze
[18:03] <linux__alien> yes i agree very true . Fixing bugs the smallest bug would be a real good experience for me dont you think so /
[18:03] <linux__alien> ?
[18:04] <linux__alien> hence it would be really good if someone could take me as part of their team and mentor me and i could do all and everything to help them too
[18:04] <linux__alien> thats my humble request
[18:05] <linux__alien> so that if someone to help me comfortable can start assigning me or rather telling me hey you could do this first and then fix this bug #some number and let me know something like this
[18:05] <linux__alien> i would try my level best to fix it and if any issues i would ask my doubts .
[18:05] <linux__alien> can someone here help me in this regard
[18:06] <rZr> hi linux__alien , havent you an account on livejournal ?
[18:06] <vemon> if i have one advocation for my package in revu then will it "go away" if i upload a new version?
[18:06] <linux__alien> rZr, i dont have an account in livejournal
[18:07] <linux__alien> rZr, why
[18:07] <linux__alien> ?
[18:07] <rZr> some guy use the same nick i think
[18:07] <rZr> nevermind
[18:08] <linux__alien> LucidFox, any help please?
[18:09] <tuxmaniac> please can someone check bug 190473 's debdiff whether they are proper? subscribing universe sponsors
[18:09] <ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Confirmed] https://launchpad.net/bugs/190473
[18:09] <LucidFox> vemon> yes
[18:10] <LucidFox> vemon> you can ask that MOTU to readvocate it
[18:10] <LucidFox> linux__alien> what kind of help?
[18:11] <linux__alien> LucidFox, a person who could help me in going forward in terms of bug fixing. i would parallely look into packaging i am already doing it so i would like to start some fixing of small issues
[18:11] <linux__alien> to start with
[18:11] <LucidFox> Okay
[18:12] <linux__alien> but i wouldnt know which is small and which wouldnt so if someone could tell me where to look at or something like that
[18:12] <linux__alien> LucidFox, to be frank i would need a mentor for this :)
[18:12] <dcordero> hi
[18:12] <linux__alien> LucidFox, i was happy that i had joined one team as i had told you couple of days back but not able to contact the mentor in any manner at all
[18:12] <linux__alien> its all become silene
[18:12] <linux__alien> silent
[18:12] <rZr> hippu: if it's not too late before uploading tuxguitar, i'd like to make some tests
[18:13] <LucidFox> What team was it?
[18:13] <linux__alien> LucidFox, https://launchpad.net/~gnome-uis
[18:14] <hippu> what do you mean?
[18:15] <linux__alien> LucidFox, i am in need of a real help and i ve subscribed to the MOTU mailing list too
[18:15] <geser> linux__alien: are you still looking for an easy bug to work on?
[18:15] <linux__alien> geser, yes very much to start with yes
[18:16] <linux__alien> geser, i am completely new to this so something to start with so that if i get stuck i could contact the person so i was thrilled when i saw the word Mentor in launchpad so joined immediately
[18:16] <linux__alien> but didnt happen unfortunately :(
[18:16] <geser> linux__alien: unmet dependencies (unmetdeps) are often quite easy to fix (often only a rebuild is needed for a library transition)
[18:17] <geser> linux__alien: see the output of "apt-cache unmet -i" (preferable from a hardy environment)
[18:17] <dcordero> i have a warning from lintian, that say me that an image name license.png of my package is and extra-license-file, but it's only an image that the application use. Must be the file renamed or can i ignore this warning message
[18:17] <geser> Package siproxd version 1:0.5.13-1ubuntu2 has an unmet dep:
[18:17] <linux__alien> geser, i dont have that currently installed
[18:17] <geser>  Depends: libosip2-3"
[18:17] <tuxmaniac> geser, did you check the latest debdiff that I uploaded. Hope its all right.
[18:19] <geser> linux__alien: it would be good if you did have one hardy environment available as all development happens in hardy. A hardy pbuilder or hardy chroot will be enough (no need to update your system to hardy if you don't want to).
[18:20]  * LucidFox is angry at LP being slow
[18:21] <geser> tuxmaniac: almost there: XSBC-Original-Maintainer should be the old value from Maintainer (the Debian maintainer)
[18:21] <linux__alien> geser, i see lot of unmet depends in gutsy itself
[18:22] <ScottK> linux__alien: It's best to concentrate on Hardy.
[18:22] <geser> linux__alien: yes, we never happen to fix all, but it's to late to fix them for gutsy
[18:22] <linux__alien> geser, so i ve to update my system to gutsy ?
[18:23] <geser> tuxmaniac: what about the comment on python-gtk2-dev from Peter?
[18:23] <linux__alien> i dont have that amount of bandwidth :(
[18:23] <linux__alien> to download it so if there are some standalone packages i can download them and try fixing bugs in that and upload it again
[18:24] <LucidFox> linux__alien> I think the easiest bugs are cosmetic stuff like errors in package descriptions and missing desktop files
[18:24] <linux__alien> LucidFox, ok how do i do that
[18:24] <linux__alien> i dont know where to look for and what to look for too ?
[18:24] <LucidFox> here's an easy one, which can also give you some experience in cooperating with upstream:
[18:24] <LucidFox> bug #190054
[18:24] <geser> linux__alien: no, but access to a hardy environment is really helpful (a hardy pbuilder should be sufficient for most cases).
[18:24] <ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Undecided,New] https://launchpad.net/bugs/190054
[18:25] <LucidFox> you will need to modify the desktop file and put the modified one into the debian/ directory, and add it to the installation rules
[18:25] <linux__alien> LucidFox, went through the bug and it says this is deprecated
[18:25] <geser> linux__alien: but for hardy some bandwitdh helps as hardy updates very often (and you need to download the source package and often also do a test-build in a pbuilder and download also the build-depends).
[18:26] <linux__alien> geser, so i ve to update my system to hardy is it?
[18:26] <LucidFox> you don't have to have your primary system as hardy
[18:26] <ScottK> No.  You can do your testing in a chroot or vm.
[18:27] <LucidFox> although, as ScottK says, having an isolated environment helps - like a chroot environment for building packages in pbuilder
[18:27] <linux__alien> LucidFox, i ve only one system . A laptop which is very new and installed 7.10
[18:27] <tuxmaniac> geser, apart from the XSBC-Original maintainer is there any other issue?
[18:28] <geser> tuxmaniac: the only other issue I've is, who is right about the addition python depends?
[18:29] <LucidFox> As for the bug: you will need to make it so that it installs a desktop file that does not contain an encoding field
[18:29] <geser> linux__alien: with a chroot you can have a hardy environment inside your gutsy installation
[18:29] <linux__alien> so i can use both ?
[18:29] <geser> linux__alien: yes
[18:29] <linux__alien> so nothing would happen to the 7.10 setup which i ve currently ?
[18:30] <geser> exactly
[18:30] <linux__alien> if you say nothing would happen i am ready for it . how do i do it and what should i install
[18:30] <linux__alien> so if i install that i can contribute to hardy is it?
[18:30] <linux__alien> and fix bugs in that environment ?
[18:30] <geser> linux__alien: if you have the option you could install hardy into a separate partition and select at boot time if you want hardy or gutsy
[18:31]  * LucidFox pauses speaking about the bug for now
[18:31] <ScottK> What's the python depends question?
[18:31] <linux__alien> i dont have that too
[18:31] <linux__alien> if i install the chroot what all could i do
[18:31] <linux__alien> for hardy
[18:32] <geser> ScottK: bug #190473
[18:32] <ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Fix committed] https://launchpad.net/bugs/190473
[18:33] <LucidFox> linux__alien> see https://wiki.ubuntu.com/PbuilderHowto
[18:33] <geser> ScottK: there are two different debdiffs
[18:33]  * ScottK looks
[18:33] <LucidFox> that page contains information about setting up a chroot environment to build packages in Hardy
[18:34] <LucidFox> while you can continue to run Gutsy as your main OS
[18:34] <tuxmaniac> geser, peter is right
[18:34]  * tuxmaniac apologises for so much confusion
[18:34] <linux__alien> LucidFox, oh so this would be used only for packaging or could also be used for fixing bugs and compiling them ?
[18:35] <geser> linux__alien: for both, you can login into a pbuilder (pbuilder login) and work then inside the hardy pbuilder
[18:36] <ScottK> tuxmaniac: Then would you please update your debdiff with his version (credit him in debian/changelog).  Your debdiff is more comprehensive (maintainer change and all that).
[18:36] <tuxmaniac> ScottK, ok
[18:36] <geser> linux__alien: there is also https://wiki.ubuntu.com/DebootstrapChroot but this is a little bit harder so setup (for a newcomer) and also not updated for hardy
[18:36] <linux__alien> ok
[18:37] <linux__alien> so if i install that i could start fixing issues for hardy is it?
[18:37] <linux__alien> that would be only in packaging right ?
[18:38] <LucidFox> yes, you can then test-build your modified packages for hardy in that environment
[18:39] <geser> linux__alien: pbuilder is always used to test that your modified package still builds, so it's not only used for packaging but also after bug fixes
[18:39] <LucidFox> linux__alien> When you're preparing a fix for a bug, you prepare a new version of the package. For example, if the previous version was X.Y-0ubuntu1, your modified version will be X.Y-0ubuntu2.
[18:39] <linux__alien> but for testing i cannot use that i would need the complete Hardy environment
[18:39] <linux__alien> yes true LucidFox
[18:40] <LucidFox> You then create a debdiff between the original and modified versions, and attach it to the bug report.
[18:40] <linux__alien> fine but to test whether that bug has got fixed or not ?
[18:40] <linux__alien> i would need Hardy right?
[18:41] <LucidFox> As for testing, in simple cases, you can also build the packages for Gutsy and test them there.
[18:41] <tuxmaniac> ScottK, updated
[18:41] <geser> linux__alien: it depends on the bug you want to fix: if you want to fix a typo in the package description then you don't need a complete hardy environment, but e.g. for fixing a crash that can be different
[18:41] <linux__alien> geser, hmmm ok
[18:41] <linux__alien> get it
[18:42] <tuxmaniac> ScottK, geser let me know whether things are Ok now.
[18:42] <tuxmaniac> thanks a lot for the help ScottK and geser
[18:42] <LucidFox> linux__alien> so, would you like to try and prepare a fix for bug #190054?
[18:42] <ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Low,Triaged] https://launchpad.net/bugs/190054
[18:42] <linux__alien> LucidFox, yes sure
[18:43] <LucidFox> Great.
[18:43] <linux__alien> LucidFox, how do i do that
[18:43] <linux__alien> LucidFox, it says deprecated
[18:43] <LucidFox> Allow me to explain.
[18:43] <linux__alien> LucidFox, sure :) sorry
[18:43] <LucidFox> The problem with this package is that the desktop file that upstream ships contains a deprecated field, which should be removed.
[18:43] <LucidFox> Desktop files can be provided in two different ways.
[18:44]  * tuxmaniac can go to sleep a happy man
[18:44] <ScottK> tuxmaniac: What do you think python-gtk2 (>=2.8), python-gtk2 (<<2.10) | python-gobject is going to do?
[18:44] <LucidFox> First, as part of upstream distribution - and second, as part of the packaging, in which case they go to the debian/ directory.
[18:44] <LucidFox> In the second case, the packager generally tries to push the changes to desktop files upstream.
[18:45] <LucidFox> Your goal is to create a modified desktop file with the Encoding field removed, and modify the package so that it installs instead of the original desktop file which does contain this field.
[18:45] <LucidFox> Am I being clear so far? :)
[18:45] <linux__alien> yes
[18:45] <tuxmaniac> ScottK, the version should be greater than 2.8 but less than 2.10?
[18:45] <linux__alien> the goal is very clear :)
[18:46] <LucidFox> So, you have two options.
[18:46] <linux__alien> how about option 1?
[18:46] <LucidFox> 1. Put the modified desktop file in the debian directory, and modify debian/install so that it is installed into /usr/share/applications - thus overwriting the upstream desktop file.
[18:46] <ScottK> tuxmaniac: And then python-gobject?  When is that wanted?
[18:47] <linux__alien> Ok where should i download the package from
[18:47] <LucidFox> or 2. Place a patch in debian/patches that would modify the file in place during build.
[18:47] <linux__alien> since this is the first thing i might ask you the silliest question too so please forgive me for that
[18:47] <LucidFox> heh
[18:48] <linux__alien> so where do i download the package from ?
[18:48] <LucidFox> linux__alien> To download the source package, you can use apt-get source, but that requires that your deb-src in sources.list is set to Hardy. Since your main installation doesn't run Hardy, here's an alternative option.
[18:48] <linux__alien> ok....
[18:48] <LucidFox> The bug report has a link that says "Overview".
[18:48] <linux__alien> ok..
[18:48] <linux__alien> yes
[18:48] <LucidFox> Clicking it will bring you to the source package overview page, which contains the upload history.
[18:48] <tuxmaniac> ScottK, without python-gobject also it builds :S
[18:49] <tuxmaniac> let me check once again.
[18:49] <linux__alien> yes i see some comments
[18:49] <LucidFox> those are debian/changelog entries.
[18:49] <linux__alien> and i see the published versions too
[18:49] <LucidFox> in the Version history area, click the link to the most recent version.
[18:50] <LucidFox> In our case, 1.3-1ubuntu1.
[18:50] <LucidFox> you will see links to 3 files: dsc, orig.tar.gz and diff.gz.
[18:50]  * tuxmaniac will look into it tomorrow.
[18:50] <linux__alien> LucidFox, i clicked on that pencil icon
[18:50] <linux__alien> right?
[18:50] <linux__alien> oh sorry
[18:50] <LucidFox> no, not the pencil icon - it's for upstream links
[18:50] <linux__alien> got it
[18:51] <linux__alien> yes i see
[18:51] <linux__alien> i get to see those files as you said
[18:51] <LucidFox> These files constitute the source package. Save them to the directory in which you'll be working on that package.
[18:51] <linux__alien> all 3 of them ?
[18:51] <LucidFox> yes
[18:52] <linux__alien> ok
[18:52] <LucidFox> alternatively, you can use dget, but this is the simpler approach - I'll tell you about dget later
[18:53] <linux__alien> sure
[18:53] <linux__alien> but one question i ve
[18:53] <LucidFox> linux_alien> tell me when the downloads finish :)
[18:53] <linux__alien> can i update my existing system to Hardy is that possible and advisable?
[18:53] <linux__alien> sure
[18:53] <LucidFox> linux__alien> If you even raise this question, then no.
[18:54] <LucidFox> The point of unstable releases is that something may break.
[18:54] <LucidFox> So they aren't recommended for everyday use.
[18:54] <linux__alien> oh ok
[18:54] <warp10> Hi all!
[18:54] <LucidFox> hi warp10
[18:54] <linux__alien> then how do people here do it
[18:54] <warp10> Hey LucidFox
[18:55] <linux__alien> assume a person has only one system and wants to contribute and he does not have another partition too
[18:55] <linux__alien> in that case how does he manage to do it
[18:55] <LucidFox> those who do run a full hardy installation (I don't) run it as a secondary system for testing and development only
[18:55] <LucidFox> this can be done on a separate partition or in a virtual machine
[18:55] <linux__alien> how do you run it ?
[18:55] <LucidFox> like qemu or VirtualBox
[18:56] <linux__alien> oh ok
[18:56] <linux__alien> ok got it now what do i do its downloaded
[18:56] <linux__alien> ve got all downloaded
[18:56] <jdong> linux__alien: for most times, testing stuff on hardy can be done in a chroot environment or a pbuilder login
[18:56] <linux__alien> oh ok then let me install that and do that
[18:56] <jdong> linux__alien: the only things you can't do in it are test very hardy specific things, like kernel or X bugs.
[18:56] <jdong> linux__alien: but for that, you can just rely on other hardy testers to provide that feedback
[18:57] <linux__alien> jdong, other GTK related bugs, Gnome bugs can be done is it ?
[18:57] <jdong> I don't think ANY of us here would complain about someone not running Hardy
[18:57] <linux__alien> with chroot ?
[18:57] <jdong> linux__alien: depends on what kind. You can launch even GNOME apps from inside that chroot with a bind-mounted /tmp
[18:57] <jdong> linux__alien: but if the bug is a specific interaction bewteen the app and Hardy's X or kernel, then you're out of luck
[18:57] <jdong> but that's a minority of bugs
[18:58] <jdong> I can only think of a handful of times where I actually needed a hardy environment
[18:58] <jdong> and even for that, I could just boot a LiveCD and test from there
[18:58] <linux__alien> then its fantastic i would do that . Thats fine with me let me look into those bugs which wouldnt need a complete hardy environment
[18:58] <LucidFox> To be completely honest, I don't even run Hardy in chroot (expensive traffic): I run Gutsy with a lot of backported tools and libraries
[18:58] <LucidFox> if there's something _really_ hardy-specific, I test-build it in PPA
[18:58] <jdong> LucidFox: yeah, once you have enough experience/judgement to know the limitations of your test environment, that works totally fine :)
[18:59] <LucidFox> linux__alien> Now your goal is to unpack the source, work on it to prepare the new version, and then create a new source package.
[18:59] <linux__alien> LucidFox, you are gonna be my mentor ;-)
[18:59] <LucidFox> Which will be 1.3-0ubuntu2 because the current version is ubuntu1
[18:59] <linux__alien> ok..
[18:59] <LucidFox> linux__alien> do you use mc in the console?
[19:00] <linux__alien> no
[19:00] <linux__alien> you want me to use it ?
[19:00] <LucidFox> no, it's optional, just would be more convenient than a plain console... it's a console file manager
[19:01] <linux__alien> LucidFox, i ve opened the file
[19:01] <linux__alien> which has the problem
[19:01] <LucidFox> what file?
[19:01] <LucidFox> so you've already unpacked the source?
[19:01] <linux__alien> x-tellico.desktop
[19:01] <linux__alien> yes
[19:01] <LucidFox> ah
[19:01] <LucidFox> don't modify the file in place
[19:01] <linux__alien> ok...
[19:01] <LucidFox> because direct changes to the upstream source are unwelcome
[19:02] <linux__alien> so what do i do
[19:02] <LucidFox> instead, copy the desktop file to the debian directory, and edit it there
[19:02] <linux__alien> ok since i am gonna create a new package i should create a debian directory and copy this file there and edit there right?
[19:03] <LucidFox> There's an already existing debian directory
[19:03] <LucidFox> from the existing packaging
[19:03] <LucidFox> linux__alien> did you use dpkg-source to unpack?
[19:03] <linux__alien> i unpacked the orig.tar.gz
[19:03] <linux__alien> i used tar -zxvf
[19:03] <LucidFox> no, that's not how it should be
[19:03] <LucidFox> remove the resulting source directory
[19:03] <linux__alien> ok
[19:04] <LucidFox> and use dpkg-source -x (dsc file)
[19:04] <linux__alien> ok got it
[19:04] <LucidFox> this will unpack the orig.tar.gz _and_ apply the diff.gz, so you end up with a source tree and the debian directory
[19:04] <linux__alien> oh ok
[19:05] <linux__alien> now i ve copied the file to debian
[19:05] <linux__alien> and i ve opened the file
[19:05] <linux__alien> too now ve a question
[19:05] <LucidFox> now, edit the desktop file in debian and remove the line that shouldn't be there
[19:05] <linux__alien> the bug report says This item is deprecated in Version=1.0 of freedesktop standards, so please remove it.
[19:05] <LucidFox> yes
[19:06] <linux__alien> there are 3 comments in that file
[19:07] <linux__alien> they are talking about those comments ?
[19:07] <LucidFox> leave the comments alone
[19:07] <LucidFox> just remove the Encoding line
[19:07] <LucidFox> comments are harmless :)
[19:07] <jdong> LucidFox: except when put there by the TA on my english paper
[19:07] <jdong> then it costs me points :)
[19:08] <linux__alien> fine but where does the bug say that the encoding is extra
[19:08] <LucidFox> lol
[19:08] <LucidFox> linux__alien> what do you mean, encoding is extra?
[19:08] <linux__alien> i mean for a person who has been working on this might know but for quite a new comer does the bug show that encoding shouldnt be there ?
[19:09] <LucidFox> linux__alien> the bug report contains a diff which lists the necessary changes
[19:09] <linux__alien> -Encoding=UTF-8
[19:09] <linux__alien> there is a small hyphen before it
[19:09] <LucidFox> yes; it means that this line should be removed
[19:09] <LucidFox> it's a minus sign :)
[19:10] <linux__alien> ok .. got it first time i didnt notice that
[19:10] <linux__alien> :)
[19:10] <linux__alien> thanks
[19:10] <linux__alien> ok removed it
[19:10] <linux__alien> and now i see that the control, copyright, rules file are already in place
[19:10] <LucidFox> if the line was supposed to be added, it would have been +Encoding=UTF-8
[19:10] <linux__alien> ok .... got it
[19:10] <linux__alien> :)
[19:10] <LucidFox> yes, but there are two more things to do
[19:10] <LucidFox> first, you need to make this file install
[19:10] <LucidFox> you can do that by editing debian/install
[19:10] <linux__alien> so how do i package without generating those files agin
[19:11] <LucidFox> you aren't done editing the package files yet :)
[19:11] <linux__alien> there is no install file in debian
[19:11] <LucidFox> tellico.install?
[19:11] <linux__alien> ok...
[19:11] <linux__alien> yes
[19:12] <LucidFox> there is a line there: debian/tmp/usr/share/applications/*; it is responsible for installing the original, upstream desktop file (because this is where it resides)
[19:12] <LucidFox> you, therefore, should remove it, and instead add a line to install your modified desktop file
[19:12] <LucidFox> which would be:
[19:13] <LucidFox> debian/(desktop file).desktop usr/share/application
[19:13] <linux__alien> debian/tmp/usr/share/apps has to be removed
[19:13] <LucidFox> actually
[19:13] <LucidFox> no, not usr/share/apps
[19:13] <LucidFox> debian/tmp/usr/share/applications/*
[19:13] <LucidFox> this is what the line says
[19:14] <linux__alien> i dont have that in that file
[19:14] <LucidFox> wait a minute
[19:14] <linux__alien> ok..
[19:14] <LucidFox> how come I did? o_O
[19:14] <LucidFox> ah, two slashes
[19:14] <LucidFox> debian/tmp//usr/share/applications/*
[19:15] <linux__alien> i dont have applications at all
[19:15] <linux__alien> in that file
[19:15] <LucidFox> it's tellico.install, you're probably looking at tellico-data.install
[19:15] <linux__alien> oh
[19:15] <linux__alien> yes
[19:15] <linux__alien> got it sorry
[19:15] <linux__alien> deleted that
[19:16] <LucidFox> now, you will have to add a line to install your new desktop file
[19:16] <LucidFox> debian/(desktopfile).desktop usr/share/applications/kde
[19:16] <LucidFox> the part before the space tells where the file is, the part after the space tells where to install
[19:18] <linux__alien> debian(x-tellico.desktop).desktop usr/share/applications/kde
[19:18] <LucidFox> wait
[19:19] <linux__alien> oh sorry
[19:19] <LucidFox> first, without the parentheses
[19:19] <linux__alien> two desktops are there
[19:19] <LucidFox> second
[19:19] <LucidFox> the bug is about tellico.desktop
[19:19] <LucidFox> not x-tellico.desktop
[19:19] <LucidFox> so you worked on the wrong desktop file :)
[19:20] <linux__alien> oh :(
[19:20] <linux__alien> am sorry
[19:20] <linux__alien> really sorry
[19:20] <LucidFox> so it should be
[19:20] <LucidFox> debian/tellico.desktop usr/share/applications/kde
[19:20] <linux__alien> but that file does not have Encoding line in that file
[19:22] <LucidFox> How come...?!
[19:22] <linux__alien> :)
[19:22] <linux__alien> i guess the bug report is wrong :)
[19:22] <LucidFox> indeed...
[19:22] <LucidFox> wait a second
[19:22] <linux__alien> ok
[19:24] <LucidFox> linux__alien> yes, the bug report is indeed invalid :((((
[19:24] <LucidFox> I'm terribly sorry
[19:24] <LucidFox> however
[19:25] <linux__alien> i am happy that i ve found out something so youo gave me an opportunity to find that so thanks to you :)
[19:25] <LucidFox> wait
[19:25] <linux__alien> ok..
[19:25] <LucidFox> while you won't get the honor of closing the bug, you can finish your experience by pretending that the issue did exist :)
[19:25] <LucidFox> just instead of LP, you'll upload your debdiff to pastebin
[19:25] <LucidFox> for me to review
[19:26] <linux__alien> whats LP ?
[19:26] <LucidFox> Launchpad
[19:26] <LucidFox> just copy the desktop file unmodified (pretend that the original one had an encoding field and you removed it :))
[19:26] <LucidFox> and make the change to the install file
[19:27] <LucidFox> (as I said, I'm really sorry, and will give you a real bug the next time around)
[19:27] <linux__alien> you want me to copy the tellico.desktop file contents and paste it in launchpad ?
[19:27] <LucidFox> no, not Launchpad
[19:27] <LucidFox> and don't take action just yet
[19:27] <LucidFox> I want you to prepare a debdiff just like you would if you were actually fixing a bug
[19:28] <linux__alien> ok so how do i prepare that i ve not used that :(
[19:28] <linux__alien> i am sorry i guess i am irritating you :(
[19:28] <LucidFox> you're not :)
[19:28] <LucidFox> did you modify the install file?
[19:28] <linux__alien> yes
[19:29] <linux__alien> its half baked
[19:29] <linux__alien> :)
[19:29] <linux__alien> let me delete this source tree and again untar it ?
[19:29] <LucidFox> no
[19:29] <LucidFox> wait
[19:29] <linux__alien> ok
[19:29] <LucidFox> Okay, so now the (fictional) bug is squashed and you're almost there. Now you'll need to bump the version from -0ubuntu1 to -0ubuntu2.
[19:29] <LucidFox> to do this, you will need to add a new entry to debian/changelog.
[19:30] <linux__alien> so what should i do now
[19:30] <linux__alien> the install file is half  baked
[19:30] <LucidFox> to do this, move to the source directory and type dch -i
[19:30] <linux__alien> ok
[19:30] <LucidFox> this will open a text editor with a new debian/changelog entry
[19:30] <linux__alien> It opens some file and it shows me lot of entries
[19:31] <linux__alien> yes
[19:31] <LucidFox> you will edit the top entry
[19:31] <LucidFox> first, the distribution is gutsy, you have to change it to hardy
[19:31] <linux__alien> yes the cursor is in that area
[19:31] <LucidFox> and second, you'll need to actually describe your changes
[19:31] <LucidFox> so make the list of changes something like:
[19:31] <linux__alien> if i want to close it and reopen it again
[19:32] <linux__alien> how do i do it
[19:32] <linux__alien> ok
[19:32] <linux__alien> one sec
[19:32] <linux__alien> the cursor blinks near to * and top of it i ve gutsy written with urgency - low
[19:32] <LucidFox> * Removed deprecated encoding field from desktop file (LP: #190054)
[19:32] <linux__alien> so have to change that ?
[19:33] <LucidFox> first, you have to change gutsy to hardy
[19:33] <linux__alien> yes
[19:33] <linux__alien> did that
[19:33] <LucidFox> and second, write some actual meaningful text describing your changes
[19:33] <linux__alien> tellico (1.3-1ubuntu2) hardy; urgency=low
[19:33] <linux__alien>   * Removed deprecated encoding field from desktop file (LP #190054)
[19:33] <ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Low,Invalid] https://launchpad.net/bugs/190054
[19:33] <LucidFox> the magical LP: # field contains the number of the bug you're fixing, and it will ensure tha the bug is autoclosed
[19:34] <LucidFox> when this version is uploaded
[19:34] <LucidFox> now you're set - save the file
[19:34] <linux__alien> but the email address is wrong in that file
[19:34] <linux__alien> i mean my email address
[19:34] <linux__alien> change that too ?
[19:34] <linux__alien> can i ?
[19:34] <LucidFox> is it the one used in your PGP key?
[19:34] <linux__alien> no
[19:35] <LucidFox> the signature should be of the form "Name <email>" exactly as in the PGP key
[19:35] <LucidFox> so yes, edit it
[19:35] <linux__alien> ok changed it
[19:35] <LucidFox> now save
[19:35] <linux__alien> yes done
[19:36] <LucidFox> and finally, you can build the modified source package
[19:36] <LucidFox> debuild -S
[19:36] <linux__alien> but that install file is half baked
[19:36] <linux__alien> is that ok ?
[19:36] <LucidFox> what do you mean, "half baked"?
[19:36] <linux__alien> it does not contain the original line nor the modified line is complete
[19:36] <LucidFox> then edit it until it's "fully baked" :)
[19:37] <jdong> preheat oven to 450 degrees...
[19:37] <linux__alien> dch -i
[19:37] <linux__alien> parsechangelog/debian: error: badly formatted trailer line, at file debian/changelog line 5
[19:37] <linux__alien> dch: fatal error at line 462:
[19:37] <linux__alien> Problem executing dpkg-parsechangelog:
[19:37] <linux__alien> i get this
[19:37] <LucidFox> !pastebin
[19:37] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[19:38] <linux__alien> ok will do that sorry
[19:38] <LucidFox> linux__alien> paste your output there
[19:39] <LucidFox> jdong> it's all my fault, I should have checked the bug for validity first :((
[19:39] <jdong> LucidFox: huh, what's your fault?
[19:39] <linux__alien> http://paste.ubuntu-nl.org/55408/
[19:39] <LucidFox> now we can only simulate fixing the bug because we already went halfway through
[19:39] <linux__alien> why should we do that LucidFox
[19:40] <LucidFox> linux__alien> please paste debian/changelog as well
[19:40] <jdong> linux__alien: you should also pastebin debian/changelog
[19:40] <jdong> at least up to a few lines after #5
[19:40] <linux__alien> i am not able to open it using dch -i
[19:40] <LucidFox> no, don't open it with that
[19:40] <linux__alien> vi ?
[19:40] <LucidFox> just open it in a text editor and paste the text from there
[19:40] <linux__alien> ok
[19:41] <LucidFox> gedit/kate will probably be better since you need to paste into a web browser
[19:41] <frafu> Hello, should the needs-packaging bug of mousetweaks not have been automatically closed since it is now in universe and debian/changelog contained: (LP: #162874) ? Or is it still open because the hppa architecture has not been built yet because it is waiting for a dependency?
[19:41] <linux__alien> http://paste.ubuntu-nl.org/55409/
[19:41] <LucidFox> frafu> check if the changesfile contains a Launchpad-Bugs-Fixed line
[19:42] <LucidFox> linux__alien> there should be a space before the <
[19:42] <jdong> frafu: mark it Fix Committed when it's in source NEW, Fix Released when it gets approved
[19:42] <LucidFox> Balaji G <balajig81@gmail.com>
[19:42] <linux__alien> ok LucidFox
[19:42] <linux__alien> thanks
[19:43] <LucidFox> as for dch, it's only needed to _create_ the new debian/changelog entry - after it's there, you can edit debian/changelog in any text editor
[19:43] <linux__alien> oh ok
[19:43] <frafu> LucidFox: where can I find the changesfiles?
[19:43] <linux__alien> now how do i get back the original install file
[19:43] <LucidFox> linux__alien> what for?
[19:44] <linux__alien> the install file is not complete :(
[19:44] <LucidFox> what do you mean?
[19:44] <linux__alien> i had modified the install file remember because i had to give the path of the desktop file that i modified
[19:45] <LucidFox> if you modified it correctly, there's nothing to worry about
[19:45] <linux__alien> i didnt modify it coz we had a problem coz i had modified x-tellico and then we came to know it should be tellico
[19:45] <linux__alien> so left it at that point
[19:46] <LucidFox> just change x-tellico to tellico
[19:46] <linux__alien> oh ok
[19:46] <LucidFox> I'm sorry, I'm sleepy and want to see the result before I go to bed
[19:47] <LucidFox> so, I'm sorry, but could you just build it it already? :)
[19:47] <linux__alien> so left it at that point
[19:47] <ScottK> \sh_away: https://launchpad.net/ubuntu/+source/octave-epstk/2.2-8/+build/506791 looks like an oops, missed a spot from your octave transition.
[19:47] <linux__alien> ok now i ve to give debuild -S at the source
[19:47] <LucidFox> yes
[19:48] <LucidFox> it will create a new source package - 1.3-1ubuntu2.dsc
[19:48] <ScottK> BTW, that one ^^^ looks like it might have an easy fix for a MOTU hopeful to look into.
[19:48] <linux__alien> LucidFox, i get an error because of not signing it
[19:48] <linux__alien> i ve to give -us and then some other option
[19:48] <linux__alien> i forgot :(
[19:49] <frafu> jdong:So I set the bug to Fix Released,  as mousetweaks is in the universe repo!? Or should I wait until the hppa is also in the universe repository?
[19:49] <LucidFox> you mean you didn't configure GPG?
[19:49]  * LucidFox headdesks
[19:49] <linux__alien> :(
[19:49] <Toadstool> good evening!
[19:49] <LucidFox> did it at least create the dsc file?
[19:49] <ScottK> Heya Toadstool.  Long time no see.  Welcome back.
[19:49] <linux__alien> yes
[19:49] <LucidFox> you don't need it signed for debdiff anyway, I just really want to look at it ASAP
[19:49] <jdong> frafu: set it to Fix Released
[19:49] <Toadstool> ScottK: hi!  how's it going?
[19:50] <linux__alien> yes its created the dsc
[19:50] <linux__alien> file
[19:50] <linux__alien> tellico_1.3-1ubuntu2.dsc
[19:50] <LucidFox> ah, good
[19:50] <ScottK> Toadstool: Pretty good.  I'm in front of the Tech Board on Tuesday for my core-dev application.
[19:50] <Toadstool> nice!
[19:50] <Toadstool> good luck!
[19:50] <LucidFox> linux__alien> now you run debdiff between the old and new dsc
[19:50] <ScottK> Thanks
[19:50] <LucidFox> debdiff olddscfile newdscfile > somename.debdiff
[19:51] <LucidFox> after that, paste the contents of the output file to the pastebin
[19:51] <Toadstool> I am so running behind with what happened in MOTU land lately :)
[19:51] <LucidFox> (if you were actually fixing a bug, you would download it to Launchpad, but as  I said, it's my fault)
[19:52] <linux__alien> http://paste.ubuntu-nl.org/55410/
[19:53] <ScottK> Toadstool: It's good to have you back.  Stick around and catch up.
[19:53] <LucidFox> linux__alien> That's it!
[19:53] <linux__alien> Great :)
[19:53] <ScottK> Is anyone here set up to do GCC 4.3 (GCC Snapshot) test builds?
[19:54] <LucidFox> Now, if you were fixing the bug, you would attach it to the bug report and then subscribe sponsors
[19:54] <linux__alien> Oh ok
[19:54] <frafu> jdong: ok, I will do it right away; thanks. Out of curiosity: does it normaly happen automatically? Or is something the reviewers normaly do and it is not automatic?
[19:54] <LucidFox> (ubuntu-universe-sponsors or ubuntu-main-sponsors, depending on where the package is)
[19:54] <linux__alien> i guess once i  get an other bug to fix i would get a more better idea
[19:54] <LucidFox> linux__alien> I'll try to find a valid bug for you the next time around :)
[19:54] <Toadstool> ScottK: yup, that's the plan
[19:54] <LucidFox> right now I'm going to sleep
[19:54] <ScottK> Great
[19:54] <linux__alien> sure will you be here tomorrow
[19:55] <jdong> frafu: I believe it only doesn't happen automatically for a brand new package that hits NEW
[19:55] <linux__alien> me too :)
[19:55] <jdong> frafu: for ordinary uploads with (LP: #foo), it is automatic
[19:55] <ScottK> jdong: It's automatic for New packages too, but after they get out of source New.
[19:55] <jdong> ScottK: oh, hmm I didn't see it happen when clutch passed trhough last week :(
[19:55] <jdong> I had to have it manually done
[19:56] <ScottK> Hmm.  I thought I'd seen it done, but maybe I'm wrong.
[19:56] <LucidFox> linux__alien> actually, wait :)
[19:56] <LucidFox> you screwed up a bit
[19:56] <LucidFox> gah, he left
[19:57] <frafu> SkottK: it did not happen for mousetweaks either; but perhaps because one architecture is not built yet
[19:57] <ScottK> jdong: You're right.  It's because the bug isn't against that package (and it can't be since it doesn't exist yet).
[19:58] <ScottK> frafu: ^^^
[19:58] <jdong> ScottK: aha, that's why :)
[20:00] <frafu> SkottK: that makes sense
[20:02] <ScottK> jdong: It actually sounds like an LP bug to me.  If an upload claims to fix a bug that doesn't have a package assigned, then LP should believe it.
[20:04] <jdong> ScottK: concurred
[20:05] <ScottK> jdong: Would you please file it and I'll confirm it (they've heard enough from me lately)?
[20:06] <frafu> This brings me to another question: When doing a package for a sync to a new release: I thought I had to add do debian/changelog only the items relevant to packaging. But obviously it was wrong because this way, the bugs will not be automatically closed. So I will also have to add the fixed bugs to it.
[20:06] <frafu> In other words: what comes into debian/changelog: Everything from the ChangeLog from the package plus the changes necessary in the packaging?
[20:07] <jdong> ScottK: a bit busy at the moment but if I remember lateri n the day, yes I will
[20:07] <ScottK> K
[20:07] <Toadstool> frafu: what do you mean by sync? new upstream release or sync with Debian?
[20:07] <frafu> new upstream release
[20:09] <Toadstool> frafu: you don't have to specifically mention every single change in the upstream application then.  Just put the changes closing known LP bugs plus packaging changes, I'd say
[20:10] <vemon> frafu, i think "New upstream version x.x (LP: #xxxxxxx)" is enough for the debian changelog. unless you've also made some changes to the packaging scripts
[20:10] <vemon> this is for an updated (new upstream) package.
[20:11] <ScottK> It is nice, but not required to mention major new features in debian/changelog as that's the one that gets shown to users on upgrade.
[20:11] <Toadstool> er... I'd rather use "New upstream version:" and enumerate relevant changes rather than just close random bug reports with (LP: #xxx)
[20:12] <vemon> yes, it's nice to mention the relevant new features
[20:13] <vemon> but blind copying upstream ChangeLog changes to debian/changelog is probably not a good idea
[20:13] <ScottK> Agreed.  That's excessive
[20:17] <frafu> ok; I think that I got the idea: the packaging changes have to be present; the LP# have to be present, and for the rest common sense applies by keeping in mind that it is the packaging changelog)
[20:17] <frafu> Thanks for your input
[20:18] <ScottK> You're welcome.
[20:18] <ScottK> Keep up the good work.
[20:19] <frafu> ScottK: thanks;I will try  ;)
[20:36] <bddebian> Heya gang
[20:38] <ScottK> Heya bddebian
[20:40] <bddebian> Hi ScottK
[21:04] <ScottK> slangasek: If you are around, I'd really appreciate bin Newing of gpsd to I can get the library transition done (only affects 3 packages, but I'd like to get it done before feature freeze as our GPS stuff is totally broken right now).
[21:11] <mok0> ScottK: I need a bit of help here
[21:13]  * ScottK will try.
[21:13] <warp10> MOTUs, my package gbemol (a graphical frontend for MPD) is on REVU and waits for your reviews. http://revu.ubuntuwire.com/details.py?package=gbemol
[21:13] <mok0> Look at the earlier pastebin: http://pastebin.ubuntu.com/4378/
[21:14] <mok0> I got rid of most of it, but I can't figure out lines 15,17,19
[21:14] <ScottK> K
[21:14] <mok0> those init scripts are part of other packages that this one depends on
[21:15] <mok0> the localhost package must simply configure those other packages and start the daemons
[21:15] <ScottK> OK.
[21:15] <ScottK> Why is it a separate binary package?
[21:15] <mok0> So when it doesn't own those init scripts, why does it complain?
[21:16] <ScottK> Because it needs an init it doesn't ship.
[21:16] <mok0> ScottK: It's a "meta-package" that sets up a simple batch system just on 1 machine
[21:17] <mok0> ScottK: it does some reconfiguration of config files and restarts the daemons
[21:17] <mok0> ScottK: I could get rid of the package perhaps
[21:17] <ScottK> Packages aren't supposed to touch each other's config files.  I'd recommend consolidation.
[21:18] <ScottK> That's without knowing the details of why you split it out though.
[21:18] <mok0> ScottK: consolidation?
[21:18] <mok0> = zapping? :-)
[21:19] <ScottK> Putting the stuff that's in that package in the same binary pacakage as ships the conf files
[21:19] <ScottK> err inits
[21:20] <mok0> ScottK: I understand. Thinking about it, I think it is not a good idea to have this package. Perhaps I can supply a script that does the same instead.
[21:20] <ScottK> OK.
[21:21] <mok0> ScottK: There's another question. If you have the source tree present, please take a look at torque-base.postinst and .postrm
[21:22] <mok0> prerm, sorry
[21:22] <mok0> ScottK: I'm doing something bad to /etc/services
[21:22] <ScottK> Looking
[21:22] <mok0> (It works great but I don't think it's allowed)
[21:23] <mok0> The postinst script inserts a block in /etc/services, and prerm removes that same blcok
[21:25] <ScottK> And why are you doing this?
[21:25] <ScottK> In general you are not allowed to touch stuff in /etc that your package doesn't own.
[21:26] <mok0> ScottK: Afair those entries need to be there or the software doesn't work
[21:26] <mok0> ScottK: there really ought to be a /etc/services.d/ where packages could drop entries
[21:28] <mok0> ls
[21:31] <torkel> mok0: torque needs entries in /etc/services? Why? We have been running it for a couple of years without patching services
[21:31] <mok0> torkel: ok?
[21:32] <mok0> Then I get rid of that
[21:32] <torkel> mok0: are you packaging it from scratch?
[21:32] <mok0> I will ask to get the entries defined in net-base
[21:32] <mok0> torkel: yes
[21:33] <torkel> mok0: you haven't checked the package the SARA guys did?
[21:33] <mok0> torkel: nope
[21:33] <mok0> didn't know about it
[21:34] <torkel> ftp://ftp.sara.nl/pub/outgoing/
[21:35] <torkel> check for torque_2_deb
[21:35] <mok0> torkel: thx
[21:35] <mok0> torkel: my package is very close to finished though
[21:36] <ScottK> mok0: I think you aren't supposed to modify /etc/services because I can't find any clear exception to allow it in policy.  I may be wrong though.
[21:37] <mok0> ScottK: I just heard from torkel that you don't need to patch /etc/services, so I'll just get rid of it
[21:37] <ScottK> OK.
[21:44] <mok0> torkel: My packages are split off in into several, for clients, head-node, compute-nodes, etc.
[21:44] <mok0> torkel: perhaps you'd like to test it sometimes
[22:15] <OneTwink> hellboy195: ye don't wanna know that ;-)
[22:16] <hellboy195> OneTwink: ok ^^
[22:16] <hellboy195> OneTwink: lost bet?
[22:17] <OneTwink> hellboy195: nah, insanity going round in #amarok
[22:18] <hellboy195> OneTwink: poor Harald :P
[22:18] <OneTwink> hellboy195: well, I am party responsible for it ;-)
[22:19] <hellboy195> OneTwink: deleted branch for amarok2 alpha? ^^
[22:20] <OneTwink> hellboy195: nope, I was cuddling with a fellow amarok teamster
[22:21] <hellboy195> OneTwink: lol. and how long will you be named OneTwink?#
[22:22] <OneTwink> hellboy195: until we go back to normal again :P
[22:23] <hellboy195> OneTwink: xD freaks. As long as you keep hacking on amarok! ^^
[22:24] <OneTwink> hellboy195: we might stop developing and open up a partnership agency ;-)
[22:24] <hellboy195> OneTwink: omg xD
[22:31] <frafu> Hello, I have a package here that has a debian/control and debian/control.in file. Can anybody please confirm that to add a new dependency to the package, I only have to add the dependency name to the dependency list in both packages?
[22:35] <ScottK> frafu: Add it to control.in and control should get rebuilt.
[22:37] <frafu> ScottK: I am creating a debdiff; will I have to rebuild control or will it be done by the person who applies the debdiff later?
[22:39] <geser> frafu: the clean target will probably recreate debian/control from debian/control.in
[22:39] <ScottK> It should get done automatically when you build the source package to be able to make the debdiff.
[22:39]  * ScottK doesn't necessarily have a deep understanding of this, so I'd listen to geser.
[22:40] <man-di> geser: I would file bugs against packages doing this
[22:40] <geser> ScottK: I'm not sure about the clean target, but as clean is called when the source target and the change propagates to debian/control is should happen in the clean target
[22:41] <frafu> geser: In other words debuild -S will create the new debian/control file; correct?
[22:41] <man-di> frafu: no
[22:41] <geser> man-di: some cdbs packages have control.in and @cdbs@ in Build-Depends. Do you know when debian/control gets recreated?
[22:41] <man-di> frafu: I know at least three packages with debian/control.in that just need to run "debian/rules debian/control"
[22:42] <geser> I remember also seeing package where I modified debian/control to only see in the debdiff that I've missed control.in and the change was lost
[22:43] <man-di> geser: problem is that buildd installs build-depends before starting build and debian/control regeneration could change build-depends
[22:43] <frafu> I am talking about gnome-control-center
[22:44] <geser> man-di: does this also apply to fields like uploaders? some gnome packages use control.in to fill in the team
[22:45] <frafu> unfortunately I don't have any experience with cdbs yet
[22:45] <man-di> geser: IMO its generally a bad idea to regenerate debian/control at build-time, not matter what fields change
[22:46] <frafu> man-di so, if I put the dependency also in debian/control, it will be available for buildd?
[22:48] <frafu> man-di:  I don't understand : just need to run "debian/rules debian/control"
[22:49] <man-di> frafu: I dont know about gnome-control-center but its this way in all packages I maintain with debian/control.in
[22:50] <frafu> So what should I do apart taking a crash course in cdbs ? ;-)
[22:50] <ScottK> geser: I know Debian Python Modules Team used to generate uploaders that way for a while and gave it up as a bad idea.
[22:51] <geser> I've looked at the gnome-control-center package and it does it for uploaders
[22:51]  * ScottK holds his nose.
[22:51] <man-di> ScottK: yeah, this stinks ;-)
[22:52] <frafu> man-di what is what in all packages you maintain with debian/control.in?
[22:53] <man-di> frafu: in my packages we generate Depends and Build-Depends differently for Debian and Ubuntu
[22:54] <man-di> frafu: and also some Depends can be configured at build time
[22:54] <frafu> SkottK, man-di: and I have to cope with it in order to only add a dependency :-/
[22:55] <frafu> is there some tutorial/guide about it?
[22:57] <ScottK> frafu: For your purposes if you make the change in both control and control.in and debdiff the resulting package, it should be safe.
[23:02] <frafu> ScottK: I guess that you are right since geser told above that g-c-c does it for the uploaders (I suppose that he meant that it does it not for the dependencies)
[23:02] <frafu> geser,  man-di: do you concur?
[23:03] <geser> frafu: simply compare control and control.in to see what gets replaced/filled in
[23:04] <geser> frafu: changing control.in and checked that both files are changed in the debdiff should be enough but with changing both files you are on the safe side
[23:08] <frafu> Yes, I changed both files, called debuild -S, created the debdiff and both changes were in the debdiff; to be precise there were exactly and only all the changes that I made in the debfile.
[23:09] <frafu> geser, SkottK,  man-di: thanks for all your input;  I have to quit now; bye
[23:31] <mok0> Where in the package should I document override files?
[23:32] <Baby> probably changelog, I guess
[23:33] <mok0> Baby: yeah
[23:33] <minghua> Yeah, and I wouldn't call a changelog entry "documenting"...
[23:34] <minghua> Not that an override needs documenting, of course.
[23:39] <mok0> minghua: ScottK told me to
[23:40] <mok0> minghua: "I think this should either be corrected or explained and have an over-ride"
[23:40] <minghua> mok0: I hope a changelog entry would be enough explanation.
[23:40] <ScottK> mok0: I meant explained on REVU why the over-ride was appropriate.
[23:41] <ScottK> And in debian/changelog.
[23:41] <minghua> Hey ScottK.
[23:42] <mok0> ScottK: I was commenting on minghua's statement that overrides does not need documenting...
[23:44] <minghua> Just to be clear, I meant a debian/changelog entry with explanations would be good enough for an override.
[23:44] <mok0> minghua: ok, sorry for misrepresenting your views
[23:46] <mok0> This override file, should it contain the whole lintian warning line, or just a unique part of it?