[00:00] <ScottK> k0p: I'm a Kubuntu user.  Your .desktop isn't going to work to well for me.
[00:00] <ScottK> Note: the answer involves su-to-rrot.
[00:01] <k0p> so if I use menu files is it works in Kubuntu?
[00:02] <ScottK> Not what I'm saying.
[00:02] <ScottK> su-to-root will used gksudo or kdesudo depending on which DE is in use.
[00:02] <ScottK> You need to add a call to either dh_pysupport or dh_pycentral.
[00:03] <k0p> ok
[00:03] <k0p> but I'm on ubuntu and I don't have su-to-root command
[00:03] <k0p> is it normal?
[00:04] <ScottK> It's normal for people doing Ubuntu stuff to forget Kubuntu exists.
[00:04] <ScottK> I think it's in the menu package.
[00:05] <k0p> I can't forgot the Kubuntu exists..
[00:05] <k0p> Because I have twice machines .. One of them have Kubuntu :p
[00:05] <ScottK> Good for you.
[00:05] <ScottK> Yes, it's in menu
[00:06] <stgraber> ScottK: su-to-root should be moved to another package and be installed by default ... (installing menu by default is IMHO not a good idea)
[00:06] <ScottK> stgraber: I just volunteer here.  Above my paygrade.
[00:06] <ScottK> Good point though.
[00:10] <k0p> ScottK, I added dh_pycentral
[00:10] <k0p> but I don't understand yet what its suppose it to do
[00:11] <ScottK> You'll need XS-Python-Version and XB-Python-Version in debian/rules
[00:12] <k0p> ScottK, or in debian/control?
[00:13] <ScottK> Control, yes.
[00:13] <ScottK> Sorry
[00:15] <NCommander> ScottK, should I put the manpages in for the library in the -dev, or put it in a seperate -doc
[00:15] <NCommander> (I've seen it all sorts of ways on Debian, so I'm curious if Ubuntu has a preference)
[00:16] <ScottK> You only need a -doc package if the docs are big?
[00:16] <NCommander> Pretty small, manpages
[00:16] <NCommander> It goes in dev, right?
[00:17] <ScottK> man page should go in the same binary that supplies the file that the man page is for, IMO.
[00:17]  * ScottK is no library expert.
[00:17]  * NCommander is not either
[00:17] <NCommander> It makes sense for me to put it in -dev, since if you not going to be doing development work for a library, why clutter up the filesystem?
[00:17] <ScottK> If I can type /usr/bin/foo, I ought to be able to type man foo and learn something with installing another package.
[00:18] <ScottK> with/without
[00:18] <ScottK> urgh
[00:18] <NCommander> THere are no executable binaries in this package
[00:18] <NCommander> just a single library
[00:18] <ScottK> Then -dev.
[00:18] <NCommander> That's what I thought :-)
[00:18] <NCommander> I'm just clearing out the lintman warnings, and I'll upload to revu
[00:20] <k0p> ScottK, what is XB-Python-Version?
[00:21] <ScottK> That's for the binary package what python versions it supports.
[00:21] <ScottK> Since you are packaging an application, I recommend 'current'
[00:22] <k0p> it's little weird because in XS-Python-Version you put >= 2.3
[00:23] <ScottK> I'd put current there too.
[00:23] <k0p> ok
[00:23] <ScottK> No need to have an application built for multiple versions.
[00:23] <ScottK> Grab the Intrepid source for pypolicyd-spf if you want an example.
[00:24] <k0p> ok
[00:26] <k0p> ScottK, when I can see the source files?
[00:27] <jdong> to whomever who approved bug 246834, the package in proposed uses wrong Closes format
[00:27] <ScottK> k0p: dget -x https://launchpad.net/ubuntu/intrepid/+source/pypolicyd-spf/0.7-1/+files/pypolicyd-spf_0.7-1.dsc
[00:28] <ScottK> jdong: Heya.  You missed a 'fun' Flash backport over the weekend.
[00:28] <jdong> ScottK: oh but I read the aftermath
[00:28] <jdong> ScottK: FWIW it worked on my 64-bit system :-/
[00:28] <jdong> though I paid no attention to CPU usage
[00:29] <NCommander> Two lintian warnings left. yay
[00:30] <jdong> oh what silliness, 2W less battery consumption with hacked kernel 2.6.26
[00:31] <jdong> now how to properly switch this macbook mobo to AHCI...
[00:31] <jdong> shocking that simply talking to it as if it were an AHCI device actually worked
[00:31] <k0p> ScottK, so with this my rules it's totally useless?
[00:33] <NCommander> jdong, I got a pro with **** battery life, any chance your hacked kernel will work on mine?
[00:34] <ScottK> k0p: Your rules are debhelper based and mine (in that package) are cdbs.  They will look different and that's OK.
[00:34] <k0p> so twice it's fine?
[00:34] <k0p> both are acceptable?
[00:35] <stgraber> cdbs actually generates debhelper rules but it's usually easier and you get a cleaner rules file
[00:36] <stgraber> for standard "./configure && make && make install" packaging it should only be 2-3 lines with cdbs vs a lot more with debhelper
[00:37] <NCommander> ScottK, my package is architecture specific, should I list lpia as a seperate arch in the control file, or will i386 be enough
[00:39] <Adri2000> NCommander: any doesn't work?
[00:39] <stgraber> what do you mean by arch specific ? It can only build on a limited number of arch ?
[00:39] <NCommander> stgraber, yeah
[00:39] <Adri2000> ah
[00:39] <NCommander> sparc, i386, amd64, hppa
[00:40] <NCommander> (sorta on the last one, the full API isn't available on hppa)
[00:40] <stgraber> ah, so then you'll need to specify lpia
[00:40] <NCommander> Ugh, that's going to make getting this package accepting into Debian "fun"
[00:41] <stgraber> hmm, indeed :)
[00:41] <NCommander> This probably is a new issue, since there are very few packages which aren't arch all
[00:41] <NCommander> (I need this package to resolve a FTBFS on amd64 for google-preftools)
[00:44] <ScottK> NCommander: List lpia
[00:44] <NCommander> Thanks
[00:44] <NCommander> That should be noted somewhere on the wiki
[00:58] <k0p> ScottK, what do you suggest to fix sudo question? replace gksu by su-to-root
[00:58] <k0p> ?
[01:26]  * NCommander grumbles about the pain of splitting this package is
[01:26] <CyberCod> I've been trying to understand the whole packaging process...
[01:26] <CyberCod> I must admit, so far it is beyond me
[01:27] <NCommander> CyberCod, ever compile software from source?
[01:27] <CyberCod> yes, once, but several times I've tried and had errors and didn't know how to correct the problems
[01:27] <NCommander> Knowing a bit of C/C++ is a lot of help
[01:27] <CyberCod> dependencies I guess
[01:28] <CyberCod> yeah, thats where I fall down
[01:28] <NCommander> CyberCod, http://www.debian.org/doc/maint-guide/ - this is how I learned how to package for Debian
[01:28] <NCommander> Pretty much
[01:28] <CyberCod> I did manage to make a local repo on my LAN
[01:28] <CyberCod> I'm still learning
[01:28] <CyberCod> its just sluggish
[01:29] <CyberCod> I am thinking of trying a tougher distro so that I have to get the hang of compiling
[01:29] <CyberCod> like slackware or something
[01:29] <CyberCod> and then come back to ubuntu with that under my belt
[01:30] <NCommander> Go use Arch if you want to compile
[01:30] <NCommander> Or gentoo
[01:30] <CyberCod> I went through that guide before, still felt lost
[01:30] <CyberCod> yeah
[01:30] <CyberCod> I heard gentoo is tough
[01:31] <CyberCod> I've got an old box I could tinker with it on though
[01:31] <NCommander> It takes three lines to install gentoo
[01:31] <NCommander> But each one is a few thousand characters long ;-)
[01:31] <CyberCod> oh
[01:32] <CyberCod> I'm relatively new to linux... started with dapper
[01:32] <NCommander> If you want ot see a *really* simple package, apt-get source hello ;-)
[01:32] <CyberCod> but I've been banging away it it pretty heavily
[01:32] <NCommander> I used to run BSDs before I got here
[01:33] <CyberCod> I think I understood the mechanics of packaging okay, I just don't know how to troubleshoot when things go awry
[01:33] <NCommander> Just hang out around here, and your bound to pick up a few things
[01:33] <CyberCod> I hope to
[01:33] <NCommander> I'd suggest trying to find a broken source package and then making it compile
[01:33] <NCommander> But I already fixed a lot of the easier FTBFS bugs >.<;
[01:34] <CyberCod> do you add packages also?
[01:34] <CyberCod> or just bugfix?
[01:34] <NCommander> Not as often
[01:34] <NCommander> I'm currently working on packaging though
[01:35] <NCommander> A rather anonying library which installs different files on different architectures ...
[01:35] <CyberCod> I found a really nice DVD authoring app, I was really surprised it wasn't already in the repos... heard of ManDVD?
[01:35] <CyberCod> that does sound annoying
[01:36] <NCommander> Not offhand
[01:36] <NCommander> link?
[01:36] <CyberCod> similar in use to Nerovision Express.... hang on I'll find it for you
[01:37] <CyberCod> http://linux.softpedia.com/get/Multimedia/Video/ManDVD-12812.shtml
[01:37] <CyberCod> it already has a Debian package.... it just downloads like 37 dependencies when you run it through Gdebi
[01:38] <CyberCod> much friendlier than Qdvdauthor though
[01:38] <CyberCod> my wife can use it
[01:47] <NCommander> CyberCod, a debian package thats on packages.debian.org?
[01:48] <NCommander> ok, I see
[01:49] <NCommander> It's only in debian-multimedia
[01:49] <NCommander> But we should be able to sync it right into Ubuntu
[01:49]  * NCommander pokes ScottK 
[01:50] <CyberCod> nice
[01:50] <CyberCod> its a good app.... others should be able to find it easily and enjoy it
[01:51] <NCommander> If it can't be synced, it should be very straightforward to get it through revu
[01:51] <CyberCod> it installed easily, just downloaded a butt-load of dependencies
[01:51] <NCommander> Not suprising
[01:52] <CyberCod> be good for UbuntuStudio default DVD app
[01:52] <NCommander> Adri2000, ping?
[01:52] <CyberCod> can't really make a default DVD app for regular Ubuntu, due to format restrictions, though, right?
[01:52] <NCommander> yeah, that's why DVD playback (and MP3 too) is disabled out of the box on ubuntu
[01:53] <CyberCod> yeah
[01:53] <NCommander> Most people who enable it don't really have a legal license ...
[01:53] <CyberCod> this is true
[01:53] <CyberCod> most people couldn't care less
[01:54] <CyberCod> but if it keeps canonical out of court, then I think they made the right decision
[01:54] <CyberCod> its easy enough to add in after installation
[02:04] <NCommander> ScottK, ping
[02:08] <Adri2000> NCommander: pong?
[02:08] <CyberCod> is DVD and MP3 disabled on UbuntuStudio also?
[02:09] <NCommander> Adri2000, can we sync packages from debian-multimedia?
[02:09] <Adri2000> yes
[02:10] <cody-somerville> So does anyone know why the CC meeting didn't occur?
[02:15] <NCommander> Adri2000, where do I file a bug for a package to be synced?
[02:15] <Adri2000> launchpad :)
[02:16] <CyberCod> would it really be considered a bug that a package isn't included?
[02:16] <Adri2000> !sync
[02:16] <CyberCod> I'm not objecting, I'm curious
[02:17] <Adri2000> CyberCod: a wishlist bug yes
[02:17] <NCommander> Adri2000, I meant more specifically, I forgot where I put the sync request
[02:17] <CyberCod> ah
[02:18] <Adri2000> NCommander: if you want to sync from debian, you can use the requestsync script (ubuntu-dev-tools the package), otherwise the wikipage is wiki.ubuntu.com/SyncRequestProcess iirc
[02:18] <NCommander> Adri2000, thanks
[02:18]  * NCommander attempts to figure out lintian overrides
[02:18] <NCommander> First time I ever got a package that needed one
[02:19] <NCommander> Adri2000, I need to kill shlib-with-executable-stack in libunwind7, got any idea how to do that?
[02:20] <Adri2000> I've never dealt with lintian overrides, but what about echo shlib-with-executable-stack > debian/<binary>.overrides ?
[02:21] <NCommander> Trying that
[02:21] <NCommander> Meh, this is the one thing I've never done packaging or fixing a FTBFS
[02:21] <Adri2000> NCommander: it's actually .lintian-overrides
[02:22] <Adri2000> and you need to call dh_lintian in your rules
[02:22] <NCommander> I don't have a dh_lintian O_o;
[02:23] <NCommander> nor can packages.d.o find one ...
[02:24] <Adri2000> it's in debhelper >= 6.0.7
[02:25] <NCommander> *grumble*
[02:25] <NCommander> So only on intrepid?
[02:25] <Adri2000> or you can just install them manually to /usr/share/lintian/overrides
[02:25] <Adri2000> hardy has dh 6
[02:25] <NCommander> 6.0.4
[02:25] <Adri2000> but 6.0.4 indeed
[02:26] <NCommander> *grumbles*
[02:26] <Adri2000> try backports
[02:27] <NCommander> Oh pretty
[02:27] <NCommander> It FTBFS on intrepid right out of the box
[02:27] <NCommander> Figures
[02:28] <NCommander> I'll deal with this headache later, I'm going to the movies
[02:28] <CyberCod> whatcha goin to see?
[02:29] <NCommander> wall-e
[02:29] <CyberCod> ah
[02:29] <CyberCod> enjoy
[02:30] <CyberCod> and thanks for listening
[02:30] <NCommander> yeah
[02:30]  * Adri2000 goes to sleep
[02:31] <NCommander> I'll request the sync when I get back
[03:10] <snadge> wheres the changelog for the latest kernel update (hardy)
[03:24] <Hobbsee> snadge: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-meta/linux-meta_2.6.24.19.21/changelog will tell you
[04:00] <kostmo> anybody home?  looking for a couple reviewers to finalize my pyrocket package: http://revu.ubuntuwire.com/details.py?upid=2857
[04:19] <ilowe> Hi guys, I have my own private apt repo. I have signed the Release file and added my key to the apt trusted keychain; but I still get an "untrusted" message when I try to install packages. Any ideas?
[04:30] <nxvl> emgent: did you solved your problem?
[04:37] <ScottK> Any REVU admins around?
[04:38] <Hobbsee> mmm?
[04:38] <ScottK> You might consider updating the Lintian the REVU is using.  It's a bit dated.
[04:38] <Hobbsee> i think i still am
[04:38] <ScottK> The one that was just sync'ed from Debian today has a number of good improvements and works fine on Hardy.
[04:39] <nxvl> ScottK: i think i have already asked this today, but sync are made by archive admins, isn't them?
[04:39] <nxvl> (aren't?)
[04:39]  * nxvl needs to sleep
[04:40] <ScottK> Sync's are done by archive-admins, but if you aren't a motu/core-dev you need to get one to ack the request.
[04:41] <emgent> nxvl: sure.
[04:44] <nxvl> ScottK: yes, i was asking after the ack
[04:44] <nxvl> :D
[04:44] <nxvl> ScottK: thank you!
[04:47] <Gralco> can anyone help me be eligible to be in the MOTU team
[04:48]  * Gralco corrects himself *become
[05:37]  * NCommander grumbles
[05:51] <NCommander> Anyone alive?
[06:06] <NCommander> ScottK, RAOF ping
[07:09] <NCommander> Finally, finally got this done
[07:13] <\sh> good morning
[07:18] <NCommander> morning \sh
[07:18]  * NCommander finishes packaging libunwind, clearing its lintian warnings on source/binary, and adding the get-orig-source target
[07:18] <NCommander> I think its finally ready for REVU ;-)
[07:30] <NCommander> Is anyone here willing to look at my package in REVU?
[08:12]  * NCommander looks into grumpy groundhog
[08:15] <NCommander> morning Ekushey
[08:16] <Ekushey> thank you NCommander :)
[08:17] <NCommander> I uploaded my first new package to REVU, took ages to work out all the lintian issues
[08:17] <NCommander> (damn thing needed a lintian override in the end -_-)
[08:24] <azeem> NCommander: why didn't you update libunwind-0.98.5 in intrepid rather?
[08:25] <NCommander> azeem, http://packages.ubunut.com/search?suite=intrepid&searchon=names&keywords=libunwind - what libunwind?
[08:25] <Laney> https://launchpad.net/ubuntu/+source/libunwind
[08:25] <NCommander> well
[08:25] <NCommander> ...
[08:25] <azeem> hrm, weirs
[08:25] <NCommander> I can't be blamed for not checking
[08:26] <azeem> well, there seems to be some story behind it
[08:26] <azeem> if the source is there but no binary packages
[08:27] <NCommander> It's only for ia64
[08:27] <NCommander> At least the packaged version is
[08:27] <NCommander> Probably because only the ia64 completely passes the test suite (its documented in the manual that its expected not to fully pass on other archs)
[08:28] <azeem> looks like a shortcoming in packages.ubuntu.com then
[08:28] <NCommander> yeah
[08:28] <NCommander> *grumbles*
[08:28] <NCommander> there goes five hours of my life I won't get back
[08:28] <NCommander> ALthough on the plus side, I did learn quite a bit about packaging libraries
[08:29] <azeem> now you can compare to the existing package :)
[08:29] <Rocket2DMn> Hi, I'm not sure if I went outside my jurisdiction confirming this bug, but a package maintainer needs to perform the sync, and thus be aware of it, see bug 246823
[08:29]  * NCommander is not ina  good mood
[08:29] <NCommander> azeem, on the plus side, my DD application actually moved
[08:30] <NCommander> Probably the first DD to ever get accepted as a "hurd porter"
[08:30] <NCommander> ^through the FD
[08:31] <Rocket2DMn> anybody?
[08:40] <NCommander> so now that I'm sorta ticked about this
[08:41] <NCommander> I'm going to go lie down, and then work on merging this cluster**** tommorow
[09:11] <Hobbsee> hey jono
[09:12] <jono> hey
[09:14] <huats> morning everyone
[09:21] <Rocket2DMn> is somebody interested in taking this request?  bug 246822
[09:53] <waistless> been told to ask here, how do I force sun-java6-plugin to use the regular xulrunner1.6 instead of the one in hardy-proposed?
[09:53] <waistless> because it doesn't require it, sun-java6-plugin is only in the normal hardy repo
[10:00] <Flannel> Why is there a hardy kernel in universe?
[10:07] <wgrant> Flannel: Because some kernel flavours are in universe.
[10:07] <Flannel> wgrant: -generic?
[10:07] <Flannel> http://packages.ubuntu.com/hardy/linux-image-2.6.24-19-generic
[10:08] <wgrant> Flannel: That is a bug.
[10:08] <wgrant> But you shouldn't be using packages.ubuntu.com to work that out.
[10:08] <Flannel> wgrant: The rest of the world agrees.
[10:08] <Flannel> Its easier than showing you a line number on a Packages.gz file
[10:08] <wgrant> Flannel: Launchpad knows better.
[10:09] <wgrant> Launchpad is the source of the information in the first place, and is more obvious, and isn't likely to be days out of date.
[10:09] <Flannel> wgrant: The repositories still reflect it in universe
[10:09] <wgrant> Right.
[10:12] <slytherin> Flannel: what does rmadison command say?
[10:12] <wgrant> Flannel: It's in hardy-updates/main, so it should be OK.
[10:12] <wgrant> But it's still broken.
[10:16] <Flannel> slytherin: I don't have hardy, but: http://paste.ubuntu.com/27681/
[10:18] <slytherin> Flannel: http://paste.ubuntu.com/27687/
[10:24] <huats> Syntux__: are you around ?
[10:36] <Syntux__> huats, I am now
[11:16] <geser> wgrant: https://edge.launchpad.net/ubuntu/hardy/i386/linux-image-2.6.24-19-generic/+index lists it for -updates in main and for -security in universe
[11:17] <wgrant> geser: I thought I said that earlier.
[11:18] <geser> then I should read the scroll-back more carefully :)
[11:23] <slytherin> geser: any luck with batik yesterday?
[11:24] <geser> slytherin: it FTBFS for me during applying the patches
[11:25] <wgrant> That seems to be batik's favourite pasttime.
[11:25] <slytherin> geser: really? which patch?
[11:25] <geser> slytherin: one moment, checking again
[11:25] <geser> perhaps I did a mistake in building the .orig.tar.gz
[11:27] <geser> slytherin: Trying patch debian/patches/01_build_xml.patch at level 1 ... 0 ... 2 ... failure.
[11:28] <slytherin> geser: I will check again when I go home and see if the problem is really with the patch.
[11:28] <geser> slytherin: I guess it's my .orig.tar.gz. For some reason it contains only pdf-transcoder
[11:28] <slytherin> he he
[11:29] <slytherin> geser: still I will have to check. May be the orig-source target was not proper.
[11:31] <geser> slytherin: let me first rerun get-orig-source after I installed unzip. I hope that I've now all packages needed for get-orig-source.
[11:31] <slytherin> geser: Ok. Got to go. Have meeting. Will catch you later.
[11:49] <geser> slytherin: after finally getting a correct .orig.tar.gz it builds without problems.
[11:50] <siretart> \o/
[11:50] <siretart> finally working batik?
[11:50] <geser> siretart: it builds at least
[11:52] <siretart> geser: I'm very looking forward in finally having a working fop, actually
[11:53] <siretart> and that is build-depending on batik
[12:13] <geser> siretart: I just give fop a test-build with batik 1.7 and it FTBFS :(
[12:43] <siretart> geser: :(
[12:54] <huats> ScottK: are you around ?
[12:55] <huats> (I know you remember I was looking for you yesterday)
[13:29] <ScottK-palm> jdong: I've been through all *-backports and for dapper/hardy everything that's tested is acked. feisty/gutsy have some you need to look at.
[13:30]  * ScottK-palm will be off the grid most of the day.
[13:48] <emgent> hey hey
[13:54] <null_vector> morning
[14:13] <slytherin> geser: Great, you sponsor batik, I will take care of anything that depends on it. :-D
[14:17] <geser> slytherin: as the source package is repackaged, shouldn't it be visible in the version string?
[14:18] <slytherin> geser: It is not dfsg repackaged right? I don't know much about that aspect. 1.6 didn't have any special version even though it was repackaged. Also README.Debian-source specified that it was repackaged.
[14:20] <geser> but it's not also just the upstream zip converted into a .orig.tar.gz
[14:20] <persia> Typically doing java .jar or .zip to .tar.gz is considered similar to .tar.bz -> .tar.gz.
[14:21] <slytherin> persia: here I am adding additional sources for pdf-transcoder which is available only as jar in original upstream zip archive.
[14:21] <geser> persia: this also contains a additional svn export
[14:22] <persia> That doesn't belong in orig.tar.gz: it should either be a patch, or the version ought be something like +svn...
[14:23] <balachmar_> Hi, I am trying to create a deb using pbuilder but I am running into problems
[14:24] <slytherin> persia: I just did what was done in previous version also except the svn tag is different. Can we discuss this with Debian guys?
[14:24] <balachmar_> I have started a forum thread here, in which I have posted a link to the output pbuilder gives: http://ubuntuforums.org/showthread.php?p=5378699#post5378699
[14:24] <persia> That probably makes the most sense.
[14:24] <slytherin> persia: Also the svn export is done from fop and not batik. So +svn version is also not appropriate.
[14:25] <persia> Yeah: that belongs in debian/patches, not in orig.tar.gz.  It can be discussed with Debian, but stuffing it in orig.tar.gz just makes it hard to determine how we differ from upstream.
[14:27] <slytherin> persia: Keeping it in patch is easy but it will increase of diff.gz very much. Do you want me to write mail to debian-java list or will you do that. I am not sure I will be able to explain properly.
[14:29] <persia> slytherin: If you could send the email, that would be great.  I haven't looked at the specifics, but in general, the rule is that orig.tar.gz ought be identical to upstream.
[14:29] <slytherin> persia: Fine. I will ask for your review before I send it.
[14:30] <persia> slytherin: Sure.  I've spotty network under current circumstances: please feel free to get another's review if I'm unavailable.
[14:30] <slytherin> oks
[14:32] <balachmar_> Could someone help me find out what goes wrong with pbuilder, because this error: E: pbuilder-satisfydepends failed. Isn't very informative
[14:34] <slytherin> balachmar_: scroll your build output above. There must be some package missing/uninstallable.
[14:38] <balachmar_> http://pastebin.com/m2074bae6 this is a new pastbin. It starts with some package that are not installed, then it seems to select those packages (which is normal I think). Then some packages have unmet dependencies. Then it tries to resolve those. Then it says Score is -9850??
[14:39] <balachmar_> then it removes the package: pbuilder-satisfydepends-dummy, which is normal I guess.. and then later it says: Aptitude couldn't satisfy the build dependencies
[14:39] <balachmar_> E: pbuilder-satisfydepends failed.
[14:42] <slytherin> persia: geser: Please review - http://paste.ubuntu.com/27735/
[14:43] <slytherin> balachmar_: Check line 95 - 103 in your pastebin
[14:45] <balachmar_> slytherin: yeah, I have noticed them, but aren't they fixed in line 112 and 113? I will add those dependencies to the build deps
[14:46] <slytherin> balachmar_: No. The build dependencies you have specified are not installable. See if you have specified correct versions.
[14:47] <balachmar_> slytherin: ok will fix that
[14:47] <geser> balachmar_: use the correct package names: the dev package for pcre is called libpcre3-dev (not pcre-dev) and for dbus it's libdbus-1-dev (and not dbus-dev) (similar for the others)
[14:48] <slytherin> balachmar_: looks like the names are wrong. There is no gtk-xdev in Ubuntu, it should be something like libgtk2.0-dev
[14:48] <balachmar_> geser: Thanks
[14:49] <geser> slytherin: looks good (small typo in line 7: teh -> the)
[14:50] <geser> slytherin: iirc there is no requirement that a repackaged package must be named .dsfg, it's just a common one
[14:51] <slytherin> geser: Sent to debian-java mailing list. Let's wait for their inouts.
[14:51] <slytherin> inputs
[14:54] <geser> slytherin: re batik review: if you need to modify the package again could you please remove the -1 from the versioned (build-)dependencies as that would fix a lintian warning
[14:54] <slytherin> geser: sure
[14:57] <slytherin> geser: Can you tell me what error did you get while building fop? May be I can work on them tonight meanwhile.
[14:57] <persia> slytherin: I can only echo geser.  Nice post.
[14:57] <slytherin> :-)
[14:58] <persia> Separately, +dfsg is often used when something needed to  be removed for DFSG reasons.  Often +debian is used when there are other special arrangements for building the upstream source.
[14:58] <geser> slytherin: too many errors and warnings that would fit into a terminal but I've seen at the end a summary telling the were 23 errors and over 300 warnings
[14:59] <slytherin> geser: Oh, my kind of work. :-D
[15:00] <balachmar_> ok, now it got to the compiling stage, but it raised an error there: /usr/bin/ld: /usr/lib/libgnome-2.a(gnome-config.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
[15:00] <balachmar_> /usr/lib/libgnome-2.a: could not read symbols: Bad value
[15:01] <balachmar_> Might this error be because I am on a 64 bit system and I have not added i32 stuff to the build dep?
[15:03] <slytherin> balachmar_: what package are you trying to build?
[15:03] <balachmar_> openFTD
[15:03] <balachmar_> http://www.openftd.org/site/index.php?option=com_content&task=view&id=19&Itemid=35
[15:06] <geser> balachmar_: is the package using static linking? because of libgnome-2.a
[15:08] <balachmar_> geser: How would I find that out?
[15:09] <geser> balachmar_: check the Makefile
[15:10] <balachmar_> what am I looking for, I haven't made makefiles myself
[15:11] <geser> good question, I'm not sure myself
[15:15] <balachmar_> But what if it is using static linking?
[15:17] <geser> try to change it to dynamic linking
[15:19] <warp10> Heya all
[15:35] <balachmar_> I have no idea where to say that it should link dynamically. Also I have found out that it has something to do with: -fPIC. The error states that I should recompile using -fPIC. (But is that about the library or the program?)
[15:50] <nixternal> OK, I need some regex help here....how would you remove everything after the package name with the following example? ->  binutils-2.17.50.0.6-6.el5.i386.rpm to binutils
[15:51] <StevenK> s/-\d.*//
[15:53] <geser> nixternal: echo "binutils-2.17.50.0.6-6.el5.i386.rpm to binutils" | sed -re "s/([[:alpha:]]*).*/\1/"
[15:53] <nixternal> thank you sirs
[15:54] <nixternal> you are my heros!!!!
[16:04] <geser> nice, I just did a rebuild of pyepl: the compilation fails and still the package build continues :(
[16:30] <xerxas> hi all
[16:32] <xerxas> is there a reason for a package to disappear in a new release ?
[16:32] <xerxas> I see a package that is in dapper, edgy, feisty and gutsy but not in hardy
[16:33] <geser> xerxas: several, which package is it?
[16:33] <StevenK> xerxas: Yes, which package?
[16:33] <xerxas> geser, source: bandersnatch, binary: bandersnatch and bandersnatch-frontend
[16:34] <xerxas> seems to build fine with gutsy's dsc on my hardy-amd64 pbuilder
[16:35]  * StevenK is checking
[16:35] <geser> xerxas: http://people.ubuntu.com/~ubuntu-archive/removals.txt : open security holes, unmaintained, removed from Debian
[16:37] <xerxas> also, how can I build the package for i386 on a amd64 machine ?
[16:37] <StevenK> xerxas: Build an i386 chroot
[16:37] <xerxas> I need to create a pbuilder for i386 , right ?
[16:37] <xerxas> ok
[16:37] <StevenK> So, yes.
[16:37]  * kees likes sbuild over pbuilder  </advertisement>
[16:37] <xerxas> ;)
[16:37] <StevenK> kees: Fix sbuild so that it doesn't need many many many many many chroots :-)
[16:37] <xerxas> never heard about sbuild
[16:38] <kees> xerxas: https://help.ubuntu.com/community/SbuildLVMHowto
[16:38] <StevenK> steven@liquified:~% schroot -l | wc -l
[16:38] <StevenK> 18
[16:39] <kees> hehe, this is fun
[16:39] <kees> $ schroot -l | wc -l
[16:39] <kees> 28
[16:39] <kees> though, I think the person closer to 0 is the winner.  :)
[16:40] <xerxas> geser,  is there a way to know wich security issues are on that package
[16:40] <laga> i've got 0.
[16:40] <StevenK> xerxas: I daresay checking the Debian BTS might tell you
[16:40] <kees> laga wins.  :)
[16:41] <xerxas> me too , I have 0 ;)
[16:41] <laga> kees: i was surprised not to have the "command not found" joker, though :)
[16:41] <xerxas> anyway, guys, thanks !
[16:41] <kees> xerxas: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bandersnatch
[16:42] <StevenK> kees: Many? :-)
[16:42] <kees> only 4.
[16:42] <StevenK> Which cover some brutal issues
[16:42] <StevenK> Multiple XSS and SQL injection.
[16:42] <StevenK> xerxas: Don't use it.
[16:42] <kees> xerxas: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442046
[16:43] <xerxas> StevenK,  why so ?
[16:43] <StevenK> xerxas: Because it does not look safe
[16:44] <xerxas> StevenK,  I don't mind, I need it
[16:44] <xerxas> it will not be public
[16:44] <lilgies> hello, I have a problem with pbuilder. I have this error : checking whether QTDIR environment variable is set... no configure: error: QTDIR must be properly set.
[16:45] <lilgies> and I don't knonw how to set the QTDIR environment variable
[16:45] <xerxas> StevenK,  my company is making a chat, we might have legal issues, so we need to log all traffic
[16:45] <xerxas> bandersnatch seems to do that pretty well
[16:46] <StevenK> xerxas: I'd suggest you don't use it.
[16:46] <xerxas> StevenK,  but you're maybe right , ejabberd have a module that logs all traffic and don't necessarly needs bandersnatch
[16:46] <slytherin> lilgies: You probably haven't added correct build dependencies in the package, due to which the header files are not found and hence it is looking for alternate paths.
[16:47] <lilgies> I have install libqt3-mt-dev
[16:47] <lilgies> and the build depend is in the /debian/control file
[16:48] <lilgies> I need to configure the rules file
[16:49] <lilgies> I have try :  LDFLAGS="-Wl,-z,-L/usr/share/qt3,defs" but no success
[16:49] <slytherin> lilgies: Are you sure it works with qt3? If yes, you can add QTDIR variable in rules file.
[16:49] <lilgies> yes I'm sure
[16:49] <lilgies> how to add QTDIR variable in rules file this depend of the version of the ./configure ?
[16:50] <lilgies> whith the ./configure --help I have not the --qtdir option
[16:51] <lilgies> I have post here : http://forum.ubuntu-fr.org/viewtopic.php?id=236861 (in french)
[16:52] <slytherin> persia: geser: Do we have a meeting tomorrow?
[16:54] <persia> slytherin: Which meeting?  (I have many)
[16:55] <slytherin> persia: sorry, ubuntu-java
[16:55] <persia> Oh, yes.  I believe it's 14:00 UTC.
[16:56] <slytherin> persia: 14:00? I thought it was 16:00. ANyway, I will be in office anyway.
[16:57] <NCommander> hey all
[16:59] <lilgies> the requirement is : qt toolkit >= 3.1.0 and i use libqt3-mt-dev
[17:03] <persia> slytherin: Ask ubottu in #ubuntu-meeting to check for sure.
[17:03] <NCommander> emgent, nice work on becoming an MOTU
[17:03] <Pici> @schedule
[17:04] <emgent> NCommander: thanks :)
[17:04] <slytherin> persia: I will be there hopefully.
[17:04] <NCommander> emgent, so I did something rather stupid; I repackaged something already inn Debian/Ubuntu
[17:05] <NCommander> Just because it didn't show up on packages.ubuntu.com
[17:05] <NCommander> On the plus side, I learned about the wonderful world of lintian overrides
[17:05] <emgent> ehehe
[17:05] <slytherin> NCommander: it is not as wonderful as you think
[17:06] <persia> NCommander: rmadison will become your friend
[17:06] <NCommander> Sarcasm doesn't translate well onto IRC
[17:07] <NCommander> persia, who's rmadison?
[17:08] <StevenK> NCommander: madison is a Debian Archive Kit command to see what packages are in what release and what versions.
[17:08] <jpds> NCommander: whatis rmadision
[17:08] <StevenK> NCommander: rmadison is "Remote Madison", and queries a cgi to see the same information
[17:08] <NCommander> thakns
[17:08] <NCommander> *grumbles*
[17:09] <NCommander> I did check by seeing if it was available via apt-get install
[17:09] <NCommander> But it isn't
[17:09] <jpds> NCommander: it's in devscripts
[17:11] <NCommander> It was still an interesting experience
[17:11] <NCommander> and it did teach me a thing or two about resolving the latest rash of FTBFS
[17:24] <NCommander> emgent, out of curosity, how long did it take for you to become a MOTU?
[17:36]  * NCommander is feeling that unique urge to package something
[17:40] <NCommander> emgent, ping
[17:50] <jpds> Anyone know why pbuilder could fail so: http://paste.ubuntu.com/27775/ ?
[17:52] <NCommander> are you running pbuilder as root?
[17:53] <jpds> Yes: sudo DIST=intrepid pbuilder create
[17:53] <NCommander> anything unusual going on with your system (aka, is your regular /proc fine?)
[17:54] <jpds> Guess so: http://paste.ubuntu.com/27776/
[18:04] <lilgies> hello how to set QTDIR environment in the /debian/rules file ?
[18:15] <NCommander> lilgies, You can se it like QTDIR=*, but why do you need to set it?
[18:25] <lilgies> hello NCommander I have found the problem
[18:25] <lilgies> that is because QTDIR=* must be on the same line that ./configure in the /debian/rules file and not on top of the ./configure
[18:26] <lilgies> on up of the ./configure (sorry for my bad english)
[18:26] <lilgies> I need to set it for create de debian package
[18:28] <NCommander> ah
[18:42] <NCommander> launchpad really running poorly today -_-;
[18:48] <NCommander> I'm thinking of taking a stab at packaging truecrypt
[18:48] <laga> there is no truecrypt package?
[18:49] <NCommander> It's a rather painful package since its a kernel module, binaries, and a few other things
[18:50] <NCommander> It seems though they finally cleared up their licensing
[19:24] <AnAnt> Hello, how can I know that requestsync actually did mail by synch request ?
[19:26] <AnAnt> nevermind
[19:36]  * norsetto kicks ubottu in the private parts
[19:40] <NCommander> norsetto, don't castrate ubottu
[19:40]  * NCommander fixed inkscape ^_^
[19:41] <norsetto> NCommander: hmmm, upstream still hasn't done that, I wonder why ...
[19:41] <NCommander> Upstream as in Debian, or inkscape authors?
[19:43] <norsetto> NCommander: inkscape themselves, they use LP as their bug tracker
[19:43] <NCommander> I found the patch on their trac
[19:44] <norsetto> NCommander: you mean bug 238223?
[19:44] <NCommander> Nope, different one
[19:44] <NCommander> This one is related to a FTBFS due to libpoppler
[19:45] <norsetto> NCommander: ah ok
[19:45] <NCommander> yeah
[19:45] <NCommander> Ubuntu got an updated version of poppler
[19:45] <NCommander> Which causes Inkscape to FTBFS
[19:45] <grimko> hi all
[19:46] <grimko> I would like to package the soft Adeona, the open source tracking system
[19:46] <NCommander> Cool
[19:46] <NCommander> norsetto, you a core dev?
[19:46] <grimko> do you know if someone is already planning to do this ?
[19:46] <norsetto> NCommander: nope
[19:46] <NCommander> darn
[19:47] <NCommander> I need one to help me work out a bug in mono
[19:47] <norsetto> grimko: there is a package in getdeb
[19:48] <NCommander> norsetto, what's getdeb?
[19:48] <norsetto> NCommander: ask joao pinto, he hangs around here regularly
[19:48] <NCommander> IRC nick?
[19:49] <norsetto> grimko: no sorry, its just a packaging request
[19:50] <NCommander> yeah, I saw this request
[19:50] <norsetto> grimko: we have bug 248782 but apparently nobody is working on it
[19:50]  * NCommander looks at what it would tkae to package
[19:50] <grimko> OK I'll have a look
[19:50] <NCommander> norsetto, I'll package it
[19:50] <NCommander> But I can't assign myself to the bug
[19:51] <NCommander> IANA Contributing Developer|MOTU
[19:51] <norsetto> NCommander: of course you can assign it to yourself, everybody can (I think you just need to be an ubuntero)
[19:52] <NCommander> norsetto, I am, but those options are greyed out when I try to edit the bug
[19:52] <vorian> NCommander: join the bugsquad
[19:52] <NCommander> Cool, its an automake package, easy fix
[19:52] <NCommander> er, easy packaging ;-)
[19:53] <NCommander> vorian, BTW, can you relink me to that TODO list for KDE4, I forgot to bookmark it and I can't find it
[19:53] <NCommander> It says I'm already a member
[19:53] <vorian> sure
[19:53] <NCommander> It might be an edge bug ...
[19:54]  * NCommander gets to try packaging with cdbs; a personal first
[19:57] <NCommander> grimko, I already have a building package
[19:59] <grimko> NCommander, OK, what should be the next step then ? Submit it to getdeb ?
[19:59] <grimko> NCommander, I was thinking about learning how to package by trying on this one
[19:59] <grimko> and then how does it end up in Debian or Ubuntu ?
[20:00] <NCommander> grimko, I'll submit it to REVU
[20:00] <NCommander> THis isn't a trival package, it needs patches unfortunately
[20:00] <NCommander> The make install target is interactive
[20:33] <tacone> suppose I want to resolve https://bugs.launchpad.net/ubuntu/+source/vim/+bug/125247 . what shuold I download ? hardy package or intrepid's ?
[20:36] <Adri2000> tacone: intrepid
[20:36] <tacone> Adri2000: there's a command to download from intrepid ?
[20:37] <tacone> usually I use apt-get source but seems to download hardy's
[20:44] <Adri2000> tacone: add intrepid's deb-src to your sources.list, and then use apt-get source
[20:45] <tacone> Adri2000: this won't mess up my system ?
[20:46] <Adri2000> if you only add deb-src, no
[20:46] <amireldor> question: how do i become a motu?
[20:46] <tacone> ok
[20:48] <Laney> Kopfgeldjaeger: Do you plan on doing the merge of nepenthes?
[20:49] <tacone> amireldor: you dig the ubuntu wiki to grasp how to help resolving bugs and how to package, ask your questions about that here. after some practice you ask for a mentor in the ML. as you get better you continue helping here and there until you find people willing to sponsor your application to become a MOTU
[20:49] <Adri2000> amireldor: check out wiki pages such as https://wiki.ubuntu.com/MOTU/GettingStarted
[20:51] <amireldor> Adri2000, thx
[20:52] <amireldor> tacone, thx, will you be my mentor? :)
[20:52] <Kopfgeldjaeger> Laney: I would, if I knew the solution to the build problem
[20:53] <Laney> Kopfgeldjaeger: I've come across this one before a few times so can do the fix if you don't mind
[20:53] <Kopfgeldjaeger> yeah, sure. Would be nice.
[20:53] <Laney> It's pretty simple - just declare a variable "size_t result" and then do result = <line giving the error>
[20:54] <Laney> of course, the proper fix is to actually check the return code
[20:54] <tacone> amireldor: I am less than a beginner right now, so I guess not :-)
[20:55] <NCommander> grimko, well, now there is a package that installs adeone; I just need to create the init.d file, and configuration templates,. and its just about good to go ;-)
[20:59] <norsetto> tacone: adri2000 is right, if you still do not want to add the deb-src to your sources.list you can use dget to fetch your intrepid source packages (or alternatively, you can still use dget to fetch your hardy source packages)
[20:59] <tacone> nice hint norsetto
[21:01]  * norsetto wasn't fast enough to point the new mentoring program to amireldor
[21:01] <slytherin> tacone: and dget -x will download and extract source. :-)
[21:01]  * tacone btw tacone is brand-newly mentored now
[21:01] <Adri2000> and if you have both hardy's and intrepid's deb-src, you can also use apt-get source package=version
[21:02] <norsetto> Adri2000: yes, good point
[21:03] <norsetto> Adri2000: but it slows down your updates :-)
[21:04]  * tacone will just create an alias for dget
[21:04] <slytherin> Doesn't dput check for file names before accepting an uploading? Isn't this upload broken - http://revu.ubuntuwire.com/details.py?package=gcstar
[21:04]  * NCommander grumbles about the license violation in Adeone
[21:06] <norsetto> slytherin: dput uploads what you tell it to uploads
[21:07] <slytherin> norsetto: Ok. So please tell me if I am correct in saying that uploader has messed up that upload (or perhaps he has no clue how debian packaging works)
[21:08] <norsetto> slytherin: I suspect your second choice might be correct
[21:23] <NCommander> anyone know a good random number generator that is under a GPL-compatible license?
[21:26] <laga> i guess we can skip the debian jokes
[21:28] <mario_limonciell> or the xkcd random number generator joke?
[21:28] <laga> yes, please.
[21:28] <mario_limonciell> NCommander, no license on it anyhow :)
[21:28] <NCommander> laga rofl
[21:30] <NCommander> I actually need to see if I can rip out OpenSSL in adeone
[21:30] <NCommander> Its the classic GPL-OpenSSL license pain
[21:31] <NCommander> adeone only using it for HMAC and its PRNG, so it *should* be fairly straightforward to replace that code
[21:31] <NCommander> BTW, mario_limonciell, you work on the ubuntu mono package, right?
[21:31] <mario_limonciell> NCommander, can't say i do
[21:31] <NCommander> damn it
[21:31] <mario_limonciell> NCommander, i may have uploaded a fix in the past possibly?
[21:31] <NCommander> I keep forgetting who I was refered to
[21:32] <NCommander> THere is a broken patch in mono
[21:32] <NCommander> It has caused at least two FTBFS
[21:32] <NCommander> (it was a pain tracking it down)
[21:32] <laga> maybe directhex?
[21:32] <NCommander> ANd probably responsible for quite a bit of mono instability
[21:32] <NCommander> Yeah
[21:32] <laga> not sure, but i think he used to work on it
[21:32] <NCommander> I wanted to mark the bug important, and confirmed, but I can't.
[21:32] <mario_limonciell> yeah directhex would probably be a good person to blame
[21:32] <mario_limonciell> it's easy to do that way :)
[21:32] <NCommander> Well, whoever wrote the package stubbed out an entire function
[21:32] <NCommander> Which causes mono to randomly crash
[21:33] <NCommander> s/package/patch
[21:33]  * NCommander pokes directhex 
[21:33] <mario_limonciell> NCommander, well if it's causing FTBFS, the packagers responsible for mono will have that taken care of by the time intrepid is live
[21:33] <mario_limonciell> what's the bug number?
[21:33] <NCommander> Hold on
[21:33] <directhex> what've i done wrong today?
[21:33] <NCommander> o_O;
[21:34] <NCommander> I go to launchpad's page and I get a directory tree listing
[21:34] <NCommander> Wait, there it goes
[21:34] <StevenK> Which page?
[21:34] <NCommander> I went to launchpad.com by accident
[21:34]  * NCommander hides face in shame
[21:34] <StevenK> Haha
[21:34] <StevenK> I'll stop preparing an "ARGH" phone call
[21:35] <mario_limonciell> directhex, you weren't around, so it seemed okay to blame mono problems on you
[21:35] <NCommander> StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782
[21:35] <NCommander> er
[21:35] <NCommander> that was meant for directhex
[21:35] <NCommander> StevenK, you work on launchpad?
[21:35] <StevenK> NCommander: No, I work for Canonical.
[21:35] <NCommander> wow
[21:36]  * NCommander bows down at StevenK's feet
[21:36] <NCommander> You always have to respect your overlords ;-)
[21:36] <NCommander> directhex, https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782
[21:36] <directhex> NCommander, hooray! meebey's gonna love you for that one
[21:36] <NCommander> That was an absolute nightmare to track down
[21:37] <NCommander> It also is part of why fspot is FTBFS
[21:37] <NCommander> ANd I found another package that was erroring out due to it
[21:38] <NCommander> directhex, I was just lucky the Debian package worked right, then I just had to step through the Ubuntu changes and found it via process of elimation
[21:39] <directhex> NCommander, the debian packages should be 100% source compatible, the ubuntu changes are largely silly. but shhhhhhhhh, don't tell anybody
[21:39] <NCommander> I've got a few ideas how to fix the patch so it won't break everyone and their mothers
[21:39] <NCommander> But I don't want to do anything without someone to sponsor any possible fix
[21:39] <directhex> NCommander, i need to speak with a livecd expert to better understand WHY the patch is there in the first place
[21:40] <directhex> or slomo, if he lives
[21:40] <directhex> or both!
[21:40] <NCommander> directhex, Well, the quick (and VERY) dirty way would to be look for a livecd specific file, and switch based on that
[21:41] <nhandler> When a package is included in the Ubuntu iso, are its recommended/suggested packages also included?
[21:41] <NCommander> nhandler, f-spot requires it
[21:41] <directhex> NCommander, i see the logic, but how much potential slowdown would it cause? how often is the function called?
[21:41] <NCommander> I said quick and dirty
[21:41] <NCommander> ;-)
[21:42] <NCommander> There is no justification for why this patch exists
[21:42] <NCommander> and I haven't had time to run mono's test suite on a livecd to see where and why it blows itself up
[21:42] <directhex> if you could find time, that'd be wonderful. i'm away from the office this week, so i lack my office pc with its handy vmware
[21:42] <NCommander> I can track it down
[21:43] <NCommander> That's easy
[21:43] <NCommander> Finding a sponsor
[21:43] <NCommander> THat's hard
[21:44] <NCommander> I also have no clue how to create an ubuntu livecd
[21:44] <NCommander> At best, I've created a d-i CD for Debian, but something tells me that won't fly
[21:44] <directhex> isn't it possible to just install the mono .deb files from debian whilst booted into a normal livecd? it's all ramfs isn't it?
[21:45] <directhex> i've also only tinkered with d-i, not the livecd gubbins
[21:45] <NCommander> I never looked into how the Ubuntu liveCD's really work
[21:45] <NCommander> I could look into figuring that out
[21:45] <NCommander> But I'm not going to do it unless someone there to critique my work, I'm too used to patches sitting on Debian BTS for years
[21:45] <mario_limonciell> you should be able to just install the debs
[21:45] <mario_limonciell> remastering the cd is more work than you should need for solving this
[21:45] <NCommander> I'm currently rereading the braindeadness of this patch
[21:47] <directhex> NCommander, 1) i'm seemingly the de-facto ubuntu mono maintainer, as the "real" guys are rather busy. i'm currently the correct person to moan at. 2) that one ain't my patch! pwomise! <3 3) it'd be nice to kill the patch if it's not needed, as it's an ubuntu difference, and i've been doing my best to work on packages at the debian level
[21:47] <NCommander> actually
[21:47] <NCommander> According to the changelog
[21:47] <NCommander> It is your patch ;-)
[21:48] <directhex> i've just carried it forward once or twice
[21:48] <NCommander> I'm trying to figure out why accessing /proc/self/exe on a liveCD would cause mono to self-destruct
[21:49] <directhex> slomo added that patch to 1.2.4-6ubuntu1
[21:49] <NCommander> We could cheat and simply hardcode the correct return function in
[21:49] <directhex> hm, i wonder if the old bugs say anything useful
[21:49] <NCommander> yeah
[21:49] <NCommander> I'm working backwards to figure this out
[21:50] <NCommander> Mono uses readlink on /proc/self/exe to determine its currently execution path
[21:50] <NCommander> I can't figure out why on Earth that would fail on a read only filesystem
[21:50] <laga> it's not a read-only file system
[21:50] <laga> the live disk uses unionfs
[21:51] <NCommander> SHouldn't make a different
[21:51] <NCommander> proc isn't part of the main filesystem
[21:51] <laga> well, unionfs has all kinds of interesting breakage
[21:51]  * NCommander is trying to make his way through mono's bug reports
[21:51] <directhex> well, it requires investigation, but i'm in no position to properly investigate myself until i come back from my vacation
[21:51] <NCommander> I can do it
[21:52] <laga> NCommander: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/224110
[21:52] <laga> read stevenk's part.
[21:52] <NCommander> lol
[21:52] <NCommander> I just found that ;-)
[21:53] <norsetto> directhex: the patch is not from slomo, is from scott
[21:53] <laga> NCommander: if that's related to your problem, maybe switching the live CD to aufs instead of unionfs will help.. not sure if it's planned for intrepid, tho. easy to test..
[21:54] <NCommander> Well
[21:54] <NCommander> If we want to be quick and dirty
[21:54] <NCommander> We can hard code the proper /usr/bin response into mono
[21:54] <NCommander> or check for /squashfs, and strip it out as needed
[21:55] <NCommander> Adding /squashmnt -> / and /persistmnt -> / symlinks works around the issue.
[21:55] <NCommander> This typically affects UME and live CDs.
[21:55] <NCommander> THen again, I think that's the better solution
[21:55] <directhex>   * When trying to determine the executable name reading /proc/self/exe,
[21:55] <directhex>     discard known prefixes used for unionfs mounts. LP: #224110.
[21:55] <directhex> laga, thanks for the link
[21:56] <laga> np
[21:56]  * laga doesn't like unionfs. :)
[21:56] <NCommander> So we have three choices
[21:56] <NCommander> Add the proper symlinks to the livecd
[21:56] <directhex> norsetto, ah, right, thanks. still, it was a functional if evil patch whilst it lasted
[21:56] <norsetto> directhex: yes, pretty oldish
[21:56] <NCommander> Have mono strip out the persistmnt/squashmnt, or ignore the issue ;-)
[21:57] <NCommander> directhex, which way do you think we should work on fixing this bug?
[21:58] <directhex> i say we take the openjdk solution. whilst the symlinks are the nicest hack, i think it'll be much easier to get a fixed mono package put out versus a ficked base file structure on all ubuntu livecds
[21:58] <directhex> plus, it's backportable
[21:58] <NCommander> I'm reading what the openjdk "fix" was specifically
[21:58] <NCommander> At least I know how to fix the issue, I can probably kick a patch out in a few hours
[21:59] <directhex> not that anyone would backport mono, since it breaks the rules on frameworks causing regressions. *cough*
[21:59] <NCommander> So it won't be SRUed for Hardy?
[22:00] <NCommander> Despite the fact it probably is causing the SIGSERV in F-Spot?
[22:00] <directhex> ehm... no idea. someone with some seniority might say yay for a single patch
[22:00] <NCommander> Ok, looking at openjdk, they took my second action
[22:01] <NCommander> (that is, detecting the prefix of the path, and then stripping it out)
[22:01] <directhex> yep
[22:01]  * NCommander cracks figures and works at updating this patch
[22:01] <directhex> this will all be clearer after i play some guitar hero
[22:01] <NCommander> THrough the Fire and Flames on Expert!
[22:02] <directhex> i'm a sucker for knights of cydonia
[22:03] <NCommander> at least mono uses dpatch
[22:03] <NCommander> I'd been ticked if it used quilt
[22:03] <directhex> meebey's a big dpatch fan, so that's what any package that goes near him tends to use
[22:04] <directhex> as a result, dpatch is the only patchsys i know
[22:04] <NCommander> I love dpatch
[22:04] <NCommander> I personally think quilt is a pain in the ass to use
[22:04] <NCommander> when I took over maintainership of cvsps, I replaced quilt with dpatch
[22:05] <NCommander> directhex, ok, I'm writing the new patch right now
[22:05] <NCommander> But I'm going to have to create a liveCD to properly test it so ...
[22:05] <laga> probably not
[22:05] <NCommander> that may take awhile to figure out
[22:05] <laga> you can just install packages on the live disk
[22:06] <NCommander> You can?
[22:06] <laga> yes
[22:06] <laga> dpkg -i..
[22:06] <NCommander> That's news to me o_o;
[22:06] <NCommander> Cool!
[22:06] <laga> might have to restart f-spot or whatever is triggering the problem..
[22:06] <NCommander> Every mono package probably should be given back though
[22:07] <norsetto> RAOF: re. bug 249100, does specto require python-gconf?
[22:08] <NCommander> directhex, I've marked that bug nominated for release
[22:16]  * NCommander finishs writing the new patch
[22:18] <tacone> Bug 125247 seems already fixed in Intrepid, but I can't test it because of missing build-dependancies when I run debuild. what shuold I do ?
[22:19] <NCommander> directhex, ok, I'm building a new mono now, and I'll test it by building one of the packages that blew up due to the old patch, and then test it on a liveCD
[22:19] <norsetto> tacone: install the missing build-depends?
[22:19] <directhex> NCommander, brilliant
[22:19] <tacone> uhm.
[22:20] <NCommander> directhex, I work fast; one of the perks of being a Debian GNU/Hurd porter ;-)
[22:23] <tacone> norsetto: I am trying with pbuilder. "Aptitude couldn't satisfy the build dependencies"
[22:23] <norsetto> tacone: you mean you were building your binary package with debuild?
[22:24] <tacone> norsetto: sudo pbuilder build *.dsc
[22:25]  * NCommander wishs his laptop was faster
[22:25] <norsetto> tacone: ok, I think I understand what you are trying to do, if you are backporting the package, make sure that you use correct versions for the build-depends (and possibly depends)
[22:26] <tacone> norsetto: I am trying to fix a bug. since looking at source it seems to be already fixed in intrepid, I was just trying to make a deb to test it.
[22:27] <tacone> guess my pbuilder was set to hardy. trying to update it to intrepid.
[22:27] <NCommander> directhex, any good ideas how to test this on the liveCD? (I'm going to make sure the patch works by building evolution-sharp, which FTBFS due to the old patch)
[22:27] <norsetto> tacone: yes, but if are you trying to make an hardy deb from an intrepid package, you might have to check that b-d and d are available from hardy
[22:27] <directhex> NCommander, seems like the best way to do it
[22:28] <directhex> NCommander, you have your reproducible test case - build evo sharp
[22:28] <NCommander> directhex, am I going to have to run down a sponsor for this, or are you willing to sponsor?
[22:29] <norsetto> NCommander: oh dear, are you going to run down a sponsor? Can I suggest a name :-)?
[22:29] <NCommander> norsetto, funny, very funny
[22:30] <NCommander> norsetto, I'd run down the person who thought it was a good idea to stub out a function in mono without checking to see if it does anything important!
[22:30] <norsetto> NCommander: wait until you hear the name
[22:30]  * NCommander waits for the name
[22:31] <directhex> NCommander, i can't sponsor it AFAIK. i can cheerlead a little if that helps
[22:31] <directhex> faster than a salamander, it's the mighty ncommander! goooo team!
[22:31] <NCommander> directhex, Well, I'm not even a contributing developer, so its a pain to get anything in main
[22:32] <norsetto> NCommander: just subscribe u-m-s,and check with dholbach or sistpoty tomorrow, they are usually helpfull
[22:33]  * NCommander expands the bug report to explain more of what's happening
[22:33] <nealmcb> Is there a convenient tool to do what apt-get source package=version does, but for a different release?  I see that "package/release" is documented in the apt-get man page, but it isn't finding what I'm looking for.  I'd prefer not to have to mess around with sources.list   I basically just want to diff two different ubuntu releases of a package (e.g. hardy vs gutsy).
[22:33] <norsetto> nealmcb: use dget
[22:34] <NCommander> BTW, directhex can you at least sponsor a FTBFS fix for a universe package, its been stuck on the tracker for awhile
[22:34] <Laney> nealmcb: I wrote a pull-lp-source script which might do what you want
[22:34] <nealmcb> and apt-get source net-tools=1.60-17ubuntu1 says E: Unable to find a source package for net-tools   - odd
[22:34] <nealmcb>  -
[22:34] <Laney> nealmcb: bzr branch lp:~laney/ubuntu-dev-tools/dev
[22:35] <directhex> NCommander, which package?
[22:35] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/transproxy/+bug/247886
[22:35] <nealmcb> cool - thanks norsetto and Laney
[22:35] <NCommander> Just call it the tax on me fixing mono ;-)
[22:36] <Laney> It just automates the doing to LP and doing dget -x.
[22:36] <Laney> going*
[22:36]  * NCommander downloads the hardy liveCD
[22:38] <norsetto> Laney: does it use apt-cache?
[22:38] <Laney> norsetto: No, I took that bit of the code from prevu
[22:39] <norsetto> Laney: ah ok, no idea what prevu does, some pretty fancy thing knowing jdong
[22:39] <Laney> It screen scrapes LP at the minute - bit ugly, but at least it doesn't require sources.list modification
[22:39] <norsetto> !jdong
 jdong: yes, but you're FULL OF CRACK!
[22:41] <emgent> augh!
[22:47] <NCommander> directhex, https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782 care to add any comments (I added an overview of the bug, and if you could, also please set the importance)
[22:48] <huats> norsetto !!!
[22:48] <norsetto> huats !!!
[22:48] <ScottK> huats: I'm here now for about 10 minutes.
[22:49] <NCommander> hey ScottK
[22:49] <ScottK> Heya NCommander.
[22:49] <huats> hey ScottK
[22:49] <NCommander> ScottK, Been following the broken mono issue?
[22:53] <wgrant> Laney: Why do you need to screenscrape? The URL is predictable now.
[22:54] <Laney> wgrant: The URL to the dsc for a particular release?
[22:54] <ScottK> NCommander: No.  As a KDE person, I've no real interest in mono.
[22:54] <Laney> (also, again, I took that piece of code from prevu)
[22:54]  * NCommander steals ScottK's KDE
[22:54] <wgrant> Laney: For a particularly sourcepackagerelease yes, but not the distrorelease.
[22:54]  * ScottK fires up vim and keeps working.
[22:55] <wgrant> s/particularly/particular/
[22:55] <Laney> wgrant: Right, the screenscraping is to get the version in a particular distrorelease.
[22:55] <wgrant> Ah.
[22:56] <wgrant> You could probably use rmadison or something to get that, but there's no nice Python interface AFAIK :(
[22:56] <ScottK> Stealing running code is easier though.
[22:56]  * Laney nods
[22:57] <Laney> If I want to go that way then I'll reverse engineer rmadison (if someone hasn't done it already)
[22:58] <norsetto> Laney: wouldn't be easier to just look at its source code?
[22:58] <ScottK> Laney: requestsync is written in Python and needs to get the current version from LP.  You might look at that too.
[22:59] <Laney> norsetto: That's what I meant ;) Maybe "port" would have been a better word
[22:59] <Laney> ScottK: That parses rmadison's output. Could be a workable interim approach too
[23:00] <NCommander> ok, mono *finally* finished building
[23:00] <directhex> NCommander, it's not a speedy one to build. generally, nothing MOAR MHZ can't fix
[23:00] <NCommander> MOAR MHZ?
[23:01] <ScottK> NCommander: For me a broken mono is more of a feature than a bug.
[23:01] <NCommander> I'm inclined to agree with ScottK  ;-)
[23:01] <NCommander> However, its also the responsibility of the Ubuntu Developers to make sure that every package we ship is as bug free as possible
[23:01] <norsetto> scottk: since when is mono not broken!?
[23:01]  * NCommander cues the cheesy music
[23:03]  * NCommander has mixed feelings on C# in general
[23:05] <ScottK> NCommander: With mono it's more a question of what you think the biggest bug is.
[23:05] <directhex> here we go...
[23:05] <NCommander> Well, now that Java is free,its pretty hard to justify cross-platform development on Mono
[23:05] <laga> took them (= sun) long enough
[23:06] <NCommander> True
[23:06] <NCommander> But it did happen
[23:06] <laga> yup.
[23:06] <directhex> heaven forbid open source have several similar yet different options with cultish followings
[23:06] <NCommander> Now Mono has to play catchup with whatever version of C# is out from MS, and they seem to like to change the schematics of the language every point release
[23:07] <directhex> hard to justify gnome development now kde4 is out & amazing & new, hard to justify python development when perl is so much more mature, etc etc etc
[23:07] <NCommander> I said cross-platform
[23:07] <laga> exactly
[23:07] <bahadunn> in launchpad in the mentoring section any of these packages labeled [needs-packaging] are good to work on?
[23:08] <NCommander> Mono doesn't have a great track record of running .NET apps coded on VIsual Studio
[23:08] <NCommander> and if its a mixed mode app, you have to install mono in WINE to make it run
[23:08] <directhex> NCommander, how much of that is bad code though? things like hard-coding \ instead of using path.combine()
[23:09] <directhex> or pointless p/invokes to windows dlls like system32
[23:09] <NCommander> Pretty much
[23:09] <NCommander> I don't have a problem creating a FOSS C# language
[23:09] <NCommander> But it seems a little crazy trying to catch up with .NET when you need a full Win32 API if you do anything outside of pure mode apps
[23:09] <NCommander> then again
[23:09] <NCommander> WINE is probably the definition of insanity
[23:09] <directhex> i write for linux, and then find myself pleasantly surprised by apps runnin on windows and mac just as well
[23:10] <NCommander> directhex, That works fine
[23:10] <NCommander> Its the other way that usually breaks straight to hell and back
[23:10] <directhex> MoMA is a useful tool, though
[23:10] <directhex> and for many corps using .net for their internal apps, the small level of work required to fix their biggest coding erros may be worth it
[23:10] <tacone> norsetto: ok, the bug is fixed on intrepid
[23:10]  * NCommander shrugs
[23:10] <tacone> what shall I do ? simply comment on launchpad ?
[23:11] <NCommander> I still perfer Java for cross-platform compability
[23:11] <NCommander> Simply because the offical implementation is now FOSS
[23:11] <norsetto> tacone: its that an important bug? Fixes a crash or something?
[23:11] <NCommander> and thus is write once, work everywhere
[23:11] <directhex> it's certainly true that most off-the-shelf .net apps don't work, but like i said, that's largely due to bad coding practice more than problems with mono itself
[23:11] <tacone> norsetto: syntax highliting in vim :-)
[23:11] <NCommander> directhex, yeah, I gert that
[23:11] <NCommander> directhex, I still find mono is write once, test everywhere ;-)
[23:11] <directhex> NCommander, that argument only gained weight a few months ago though, until then all we had was free "crash your apps every few minutes" java
[23:12] <tacone> irrilevant bug. bug 125247
[23:12] <NCommander> heh
[23:12] <NCommander> Anyway, testing evo-sharp
[23:12] <norsetto> tacone: ok, than its not sru material, just mark the bug report as fix released, you may want to paste the changelog of the fix-releasing version too
[23:12] <directhex> NCommander, almost as handy as "only works for banner ads" free flash
[23:12] <NCommander> directhex, if I didn't think mono was worth it, I won't be here digging through its code fixing it ;-)
[23:12] <NCommander> directhex, actually, my flash works for youtube and nothing else
[23:12] <NCommander> I use swfdec vs. gnash though
[23:13] <tacone> norsetto: ok, if I find it.
[23:13] <NCommander> w00t
[23:13] <NCommander> Ok, updated mono built evo-sharp no problem!
[23:13] <NCommander> now if I get a working mono on the liveCD, I can submit this, and start the sponsor hunt
[23:14] <directhex> subscribe u-m-s, then act loud & obnoxious in #ubuntu-*
[23:14] <directhex> works for me!
[23:14] <NCommander> Pretty muich what I do
[23:14] <NCommander> directhex, it sounds like this issue been floating around (the random segfaults)
[23:14] <NCommander> How far back does it go?
[23:15] <directhex> NCommander, it rings a few bells. let me check some irc logs
[23:17] <directhex> hm, nope, can't find it. most f-spot issues i see mentioned involve hanging on quit
[23:17] <NCommander> Its probably a relief that its finally been nailed
[23:17] <NCommander> directhex, this is probably related
[23:17] <NCommander> if mono segfaults, that's pretty much what would happen to f-spot
[23:17] <directhex> well, yes. i might even be able to convince meebey to include a theoretically non-evil patch in debian's mono packages, for future simplicity
[23:18] <NCommander> Frealomg ;ove CD sp s;pw ///
[23:18] <NCommander> wow
[23:18] <NCommander> *Freaking live CD is so slow
[23:20] <bahadunn> if a bug is triaged what does that mean?
[23:21] <norsetto> bahadunn: that somebody from the bug-squad went through it and believes it has all the necessary info to be able to fix it
[23:21] <NCommander> directhex, well, this isn't the grand stupidity patch the last revision was
[23:21] <bahadunn> norsetto: okay thanks
[23:21] <NCommander> It might even be possible to convience mono-upstream to take it
[23:22] <norsetto> bahadunn: for your future reference: https://wiki.ubuntu.com/Bugs/Status
[23:22] <bahadunn> norsetto: thanks
[23:23] <NCommander> Figures
[23:23] <NCommander> THe intrepid mono has dependencies that hardy doesn't
[23:23] <StevenK> NCommander: It probably has a version greater than hardy, too. :-)
[23:24] <nealmcb> Laney:  ﻿pull-lp-source is working like a charm...
[23:24] <NCommander> yeah
[23:24] <directhex> hang on, i know the answer to this one
[23:24]  * NCommander grumbles and creates an intrepid chroot
[23:24] <NCommander> Oh, awesome
[23:24] <NCommander> I managed to crash the CD
[23:24] <NCommander> Is there an intrepid liveCD?
[23:25] <StevenK> NCommander: Yes.
[23:25] <NCommander> link?
[23:25] <StevenK> NCommander: Would you like a link?
[23:25] <StevenK> Heh, sec
[23:25] <directhex> the intrepid source package should build unmodified on hardy
[23:26] <NCommander> You want me to build on a LiveCD?
[23:26] <NCommander> I like pain, farbut that's taking it a little
[23:26] <NCommander> bah
[23:26] <StevenK> http://cdimage.ubuntu.com/daily-live/20080716/
[23:26] <StevenK> NCommander: ^
[23:26] <NCommander> Thanks
[23:26] <NCommander> THat should help
[23:27] <NCommander> This has 17 minutes to download
[23:27] <NCommander> time to run and get a quick dinner
[23:39] <NCommander> ok
[23:39] <NCommander> back with dinner and a intrepid CD
[23:44] <NCommander> It figurs
[23:44] <NCommander> The intrepid liveCD doesn't properly start it
[23:45] <directhex> why doesn't your hardy cd work, precisely?
[23:45] <directhex> there's always a plan b, which will annoy you intensely as it involves rebuilding mono again
[23:46] <NCommander> Well, I already rm'd the hardy livecd
[23:46] <NCommander> directhex, the dependency for mono aren't there
[23:46] <huats> Syntux: hey
[23:46] <huats> Sorry I have to leave
[23:46] <huats> BUT
[23:47] <huats> I sent you an email :)
[23:47] <Syntux> it's ok :-) hmm well I did not get any email from you
[23:47] <directhex> deb-src http://directhex.mfgames.com/ hardy main
[23:47] <directhex> may cause cancer, blah blah blah
[23:47] <NCommander> what's in that repo?
[23:47] <huats> Syntux: you will, I just sent it
[23:48] <Syntux> huats, okie, will work on it tomorrow :-) Thank you
[23:50] <NCommander> Ok, I got the livecd to boot to a command line
[23:50] <NCommander> I'm in business :-)
[23:52] <directhex> NCommander, that's where i put my mono backports for hardy. since officially backports for frameworks aren't allowed
[23:54] <NCommander> ****
[23:54] <NCommander> There isn't enough room to install mono ont eh CD with its dependencies
[23:54] <laga> :(
[23:54] <laga> how much RAM have you got?
[23:54] <NCommander> 2G
[23:54]  * NCommander ups the amount the VM can use
[23:54] <laga> hum
[23:54] <laga> ah. heh :)
[23:55] <NCommander> and now I wait for the CD to boot. again.
[23:56] <laga> heh.
[23:58] <NCommander> Ok, now the CD has 813 MB of ram