[00:05] <quentusrex> What about that feature where you can export a global variable with your name and e-mail
[00:05] <quentusrex> ?
[00:05] <ScottK2> export DEBMAIL=...
[00:05] <ScottK2> export DEBFULLNAME=...
[00:05] <nhandler> ScottK2: It is DEBEMAIL, not DEBMAIL
[00:06] <ScottK2> nhandler: Right. Typo.  Thanks.
[00:06] <nhandler> np ScottK2
[00:13] <quentusrex> What is the process for a ?backport?
[00:13] <nhandler> quentusrex: https://help.ubuntu.com/community/UbuntuBackports
[00:13] <quentusrex> Will hardy ever get: dput 0.9.2.35ubuntu1 ???
[00:18] <quentusrex> If I need to change php5's upload_max_filesize from 2M to 20M, can this be done from conf.d?
[00:19] <ScottK2> quentusrex: Not unless someone asks for a backport.
[00:20] <quentusrex> and my second question?
[00:23]  * ScottK2 doesn't know a thing a php and intends to keep it that way.
[00:24] <x1250> I'm mantaining inkscape svn on my ppa. I wonder if I have to replace the Maintainer field (Ubuntu Core Developers) with my own name/email, and remove XSBC-Original-Maintainer field?
[00:25] <nhandler> x1250: I believe that is prefered for PPA packages
[00:25] <x1250> nhandler, ok, thanks
[00:32] <quentusrex> ScottK2: can I ask for a backport? if so how?
[00:32] <nhandler> quentusrex: Read that help.ubuntu.com link I sent you earlier. It outlines the process of requesting a backport
[00:36] <quentusrex> Where do I put post install commands that should only be run on install and not on update?
[00:39] <coppro> is there an ETA on OO.o3?
[00:55] <awmcclain> Hrm. I forget... what's the command that I can use in conjunction with pbuilder to login to the chroot and check my binary dependencies?
[00:57] <awmcclain> sudo pbuilder login. Silly me.
[01:15] <awmcclain> If you run pbuilder create --debootstrapopts --variant=builldd, is it normal not to get adduser within the chroot?
[01:25] <awmcclain> Is there a better way to test Depends: than by trying to install the package inside the pbuilder chroot?
[01:26] <jmarsden> awmcclain: Not that I know of.
[01:27] <jmarsden> Well, you could make a vm using a minimal CD and install in that, if you think the chroot-ness is an issue??
[01:27] <awmcclain> jmarsden: Hrm. I'm trying to set up my pbiulder environment, but my chroot doesn't have adduser (which is required by the pre_install on one of my packages).
[01:28] <awmcclain> jmarsden: My other pbuilder environment has it installed... so I'm wondering if it's something I did when building.
[01:28] <jmarsden> Or does the package need Depends: adduser ?  Not sure.
[01:29] <awmcclain> s/building/running pbuilder create
[01:30] <jmarsden> awmcclain: My Inrtepid i386 pbuilder seems to have adduser in it...
[01:30] <awmcclain> jmarsden: Right. But isn't preinst run before it checks for dependencies? And isn't adduser standard on ubuntu distros?
[01:31] <jmarsden> I wonder if the buildd variant thing does not include adduser for some reason??
[01:31] <awmcclain> hrm
[01:31] <jmarsden> awmcclain: As an additional test you could try uploading to your PPA and see if it builds there??
[01:31] <awmcclain> time to create a new pbuild
[01:32] <awmcclain> jmarsden: Heh. This was all in an attempt to get it TO build on the ppa. ;)
[01:32] <jmarsden> OK, but if you suspect the issue is with pbuilder ... try building some other way.  Does the PPA builder complain about the lack of adduser in the same way?
[01:34] <jmarsden> Wait... testing install-time Depends to get PPA to build?  That sounds odd?  Does the PPA builder really install the resulting binary to check its Depends?
[01:35] <awmcclain> jmarsden: No no. The control file I've been handed is quite poor, so I'm moving packages into the Build-Depends-Indep, and I'm noticing that there are a lot of packages in the Depends: that I think are extraneous. So I'm trying to test that.
[01:38] <jmarsden> OK.  ubuntu-minimal pulls in adduser, so I'd say it really should be in your pbuilder.
[01:39] <awmcclain> Can you explain to me how --debootstrap and --buildd mimic the PPA "more accurately"?
[01:48] <anakron> Hi all
[01:48] <anakron> i have a question
[01:49] <anakron> if a bug is related to a bad translated word into a po file, can i change that file and then make a patch for this program?
[01:54] <anakron> ¿?
[02:05] <ScottK> anakron: If it's a Universe package, yes.  If it's in Main, there's a whole separate process.
[02:06] <anakron> cheese
[02:07] <anakron> but i can change a translation error? or must be a translation team?
[02:09] <awmcclain> jmarsden: Well, pbuilder create (without flags) gave me adduser. go figure.
[02:10] <jmarsden> awmcclain: Bug in the variant=buildd template, then, probably.
[02:22] <anakron> i wanna know
[02:22] <anakron> if it is a translation bug
[02:22] <anakron>  can i fix it editing the po file?
[02:23] <anakron> if its right to do in this way
[02:23] <anakron> and then make a patch for it and upload it to the bug page
[02:24] <jmarsden> awmcclain: In case you care... the code dealing with the buildd variant is in the work_out_deps function in the /usr/share/debootstrap/scripts/intrepid script.  Seems to pick only packages with Build_essential: yes
[02:24] <awmcclain> jmarsden: Ah, which makes sense.
[02:25] <anakron> and if it can be done, someone know a translation into german of "cheese webcam booth"
[02:25] <awmcclain> käse something something
[02:25] <awmcclain> ;)
[02:26] <anakron> XD
[02:26] <jmarsden> anakron: If you do not speak German, do not do German translation for Ubuntu?
[02:26] <anakron> it was published by a german user
[02:26] <anakron> he says that is a bug in the translation of cheese
[02:27] <awmcclain> jmarsden: Do you have any experience with autoppa?
[02:27] <anakron> the translation that appers is "Cheese-Website"
[02:27] <jmarsden> Google language tools suggests   Käse Webcam Stand
[02:28] <jmarsden> awmcclain: No, I'm not prolific enough to need it!
[02:28] <anakron> thanks ill take it like a reference
[02:28] <anakron> but ill look for other opinions
[02:29] <anakron> Käse Webcam Stand?¿
[02:29] <anakron> but it not the right translation
[02:29] <anakron> cause the name of the program musnt be changed
[02:29] <anakron> so it could be "cheese Webcam Stand"
[02:30] <awmcclain> jmarsden: Heh. https://launchpad.net/~awmcclain/+archive Before, I had to upload each one by hand.
[02:31] <jmarsden> Yes, looks like you are good candidate for autoppa.  Does it work for you?
[02:31] <awmcclain> jmarsden: I'm on cloud nine with it. Of course, I had to install a client version of ubuntu since all of the gnupg caching methods require an x server...
[02:31] <anakron> thakns jmarsden :D
[02:32] <jmarsden> awmcclain: Hmm.  gpg-agent and pinentry-curses ?
[02:32] <awmcclain> jmarsden: Do you use bzr to handle packaging branches? If so, do you use LP?
[02:32] <jmarsden> I'm a beginner with bzr.
[02:33] <awmcclain> jmarsden: pinentry-curses wouldn't work for me. I hanged... or, it wouldn't cache the passphrase.
[02:33] <vorian> grrr
[02:33] <jmarsden> awmcclain: File a bug against it?
[02:33] <vorian> what's up with revu! i can't login :P
[02:34] <awmcclain> jmarsden: I'm sure it was the way I had it configured. After wasting too much time at 3AM, i just installed intrepid using vmware. I'm actually very happy with it.
[02:35] <jmarsden> OK.
[02:35] <jmarsden> vorian: It let me log in just fine (using LP OpenID), looks like it is working...?
[02:36] <vorian> ya, just got it
[02:36] <jmarsden> Good.
[02:36] <vorian> there was an error, but I kept refreshing over and over and over again
[02:36] <vorian> <3
[02:36] <vorian> much love
[05:11] <x1250> hi guys, could someone shed some light with this compile error (osmo svn): http://paste.ubuntu.com/78210/
[05:12] <x1250> gui.c: In function 'gui_create_about': gui.c:1806: error: expected expression before ')' token
[05:12] <StevenK> x1250: Need the see the code around that line
[05:12] <x1250>     sprintf(tmpbuf, "%s %d", _("SVN revision"), REV);
[05:12] <StevenK> s/Need the/Need to/
[05:12] <x1250> wait, I'll pastebin it
[05:14] <x1250> StevenK, offending line is 38: http://paste.ubuntu.com/78211/
[05:14] <StevenK> What is REV defined as?
[05:17] <x1250> uhm, I can't find other REV in that file, only #ifndef REV, and the one in the offending line
[05:18] <StevenK> It's more than likely either in conf.h or another header
[05:19] <StevenK> I suspect REV is ""
[05:19] <StevenK> Due to the Making all in src
[05:19] <StevenK> Sigh. Firefox, I hate you
[05:19] <StevenK> Due to "/bin/bash: svn: command not found" in the build log
[05:21] <x1250> StevenK, $ grep -rin "^#define" * | grep REV returns nothing related
[05:22]  * Hobbsee suggests installing svn, as a start.
[05:23] <StevenK> Build-Depending
[05:23] <StevenK> It looks like a PPA build log
[05:24] <StevenK> x1250: -r and * aren't really right.
[05:24] <StevenK> x1250: I'd suggest grep -r REV .
[05:27] <x1250> StevenK, I can't find it, it isn't there, I guess he forgot? :)
[05:28] <StevenK> I guess it gets added at build itme.
[05:28] <StevenK> s/itme/item/
[05:28] <StevenK> x1250: My thought is, REV is "", which makes that snprintf(); blow up, hence your compile error
[05:29] <x1250> what should I do? just change it to some string like "622" (which is the revision) ?
[05:32] <StevenK> x1250: Or add a Build-Depends on svn, so it can run svn info or some such
[05:32] <StevenK> It may try to run a svn update or svn checkout, but don't do that.
[05:35] <awmcclain> If a build fails in the PPA, should I increment the ~ppa version number?
[05:36] <StevenK> It will probably fail to upload if you don't.
[05:40] <x1250> StevenK, adding subversion did the trick...
[05:42] <x1250> thanks
[05:43] <StevenK> No problem
[10:34] <freakabcd> hi all
[10:34] <freakabcd> an offtopic question: Is there a way for me to install/build+install the xorg-video-intel driver from Hardy in my intrepid install?
[10:35] <freakabcd> there is a serious regression in the intrepid package, which is unfortunately due to upstream
[10:40] <RainCT> freakabcd: out of curiosity, which regression is it?
[10:40] <freakabcd> 'screen totally blank', 'screen flickering', 'external display not on proper resolution', 'sometimes showing junk screen on X startup'
[10:41] <freakabcd> many of these happening on many people's various intel chipsets for laptops, 855gm, 915, 945, etc.
[10:42] <freakabcd> i really want to rebuild the source package from hardy onto my intrepid. would you be able to help me out with this?
[10:42] <freakabcd> and judging from the traffic on bugs.fdo, it hasn't been fixed yet :(
[10:42] <freakabcd> the hardy driver worked perfectly for me (and all the others having the problems)
[10:44] <RainCT> freakabcd: and I assume this is with compiz disabled?
[10:44] <RainCT> (and no, I don't know how the X packages work :()
[10:44] <freakabcd> ofcourse, i never used compiz. my graphics chip is incapable of style ;)
[10:45] <freakabcd> RainCT, doesn;t matter. as long as you can perhaps guide me in building the source package of hardy in intrepid
[10:45] <freakabcd> i don;t need to get a final package, just need the intel driver, so i can replace the current one
[10:46] <RainCT> Ah OK. I'm asking because here Compiz doesn't work anymore on Jaunty (but because the new compiz version uses some GPU stuff which the intel driver doesn't support for some older cards). The symptoms didn't match anyway, though.
[10:46] <freakabcd> so i just downloaded the .dsc, orig.tar.gz and the diff.gz file
[10:46] <freakabcd> what do i do now?
[10:48] <RainCT> freakabcd: dpkg-source -x *dsc; cd xserver-xorg-v*; get-build-deps .; dpkg-buildpackage
[10:48] <RainCT> not sure if it will work, though
[10:48] <freakabcd> lemme give it a roll
[10:49] <RainCT> (you'll need ubuntu-dev-tools and pbuilder installed for get-build-deps to work; else you can just look them up in debian/control and install them yourself)
[10:55] <eMerzh> if someone want to review my package (http://revu.ubuntuwire.com/details.py?package=sqliteman ) previously advocated by dktrkranz but just corrected :)
[10:57] <RainCT> OT, does youtube support ogg (or is there some similar page which supports it)?
[11:17] <freakabcd> RainCT, bah.. there were some issues.. but i worked around them and finally built and installed in /tmp/intel as prefix.
[11:17] <freakabcd> so now i will try to replace the currently existing files (making sure to backup ofcourse)
[11:17] <freakabcd> and i hope it works
[11:18] <freakabcd> if it does, i will ask the ubuntu people to provide a package of the old driver for the peole having the issues
[11:18]  * Hobbsee expects they probably won't
[11:19] <Hobbsee> that jump in versions was pretty big, and required upgrades of various other packages, iirc, and a couple of new packages.
[11:19] <freakabcd> nope.. nothing major required..
[11:19] <Hobbsee> so, downward compatibility might be wishful thinking.
[11:19] <freakabcd> i just built the files myself
[11:19] <Hobbsee> does it actually work, or just build?
[11:20] <Hobbsee> right.  I was talking about it actually working.
[11:20] <freakabcd> yeah, have to test it now. only thing i had to modify was to edit the configure.ac file a little bit to enable build
[11:21] <freakabcd> in theory it should work now as a video driver. because it was built with all the right prequisite libs on my machine. hopefully it works too. i've gotta eat now. will teat it after dinner and let you guys know.
[11:21] <freakabcd> anyway, if i get it working and ubuntu guys aren;t willing to provide a deb, i'll probably post in the bug reports that i have it working with the old driver.
[11:26] <goshawk> hi
[11:28] <goshawk> if someone has free time, please can review http://revu.ubuntuwire.com/details.py?package=dsss ?
[12:44] <goshawk> please if someone has free time, can review http://revu.ubuntuwire.com/details.py?package=dsss ?
[14:37] <anakron> Hi all
[14:38] <anakron> Hi RainCT
[15:03] <anakron> Hi al
[15:03] <anakron> hi all
[15:03] <anakron> one question
[15:03] <anakron> if I upload a patch for a bug
[15:03] <anakron> and its works fine
[15:04] <anakron> what i can do now?
[15:08] <RainCT> hi anakron :)
[15:08] <anakron> Hi Rain
[15:09] <RainCT> anakron: I'm looking at it now. Usually you would subscribe the ubuntu-universe-sponsors (or ubuntu-main-sponsors, if the package is in main or restricted) team to the bug report and set the status to "Confirmed"
[15:12] <anakron> i add ubuntu-universe-sponsors
[15:12] <anakron> cause cheese is a universe package
[15:12] <RainCT> yep
[15:13] <anakron> so, now, i must wait
[15:13] <anakron> im looking for some bugs like these ones
[15:13] <anakron> to fix them fast
[15:13] <RainCT> anakron: set the status to "confirmed" and change the "assigned to" field to "nobody"
[15:13] <anakron> ok
[15:13] <anakron> done
[15:26] <eMerzh> if someone want to review my package (http://revu.ubuntuwire.com/details.py?package=sqliteman ) previously advocated by DktrKranz  but just corrected :)
[16:58] <nhandler> If the homepage/author email change for a package not in Debian, should I update the copyright and control files to contain this new information?
[16:58] <Laney> james_w: Still up for some sponsorship? Or shall I just u-u-s it up?
[16:59] <Laney> nhandler: Probably not worth an upload on its own
[16:59] <Laney> but if you're uploading for some other reason then sure
[17:01] <james_w> Laney: hit me up
[17:02] <Laney> james_w: bug #303724
[17:02] <james_w> ! :-)
[17:03]  * directhex hands Laney cake
[17:03] <Laney> It hasn't built for months
[17:03]  * Laney rocks with directhex 
[17:04] <Laney> 'tis actually quite a cool app, I might start using it
[17:04] <directhex> heh!
[17:09] <james_w> Laney: do you have a clean diff I can review?
[17:09] <Laney> I can filterdiff one up
[17:10] <james_w> thanks
[17:10] <james_w> nothing wrong with what you did, just don't feel like wading through right now to find the important bits
[17:12] <quentusrex> I need some help with my apt package.
[17:12] <quentusrex> I need information on what scripts are run and when...
[17:12]  * Laney slaps filterdiff
[17:12] <directhex> quentusrex, you mean the dh_ entries in debian/rules?
[17:12] <quentusrex> Example: I need to know where to put my script so that it is only installed on install, and not run on upgrades.
[17:15] <Laney> james_w: filterdiff -i gtwitter-1.0~beta/gtwitter/Makefile.am -i "gtwitter-1.0~beta/debian/*" -i gtwitter-1.0~beta/configure.ac gtwitter-mono.debdiff
[17:15] <james_w> Laney: thanks
[17:17] <Laney> np
[17:22] <quentusrex> directhex: yes, I mean those entries. I'm trying to find one that will only run on install...
[17:28] <james_w> Laney: uploaded thank you. Now apply for MOTU.
[17:28] <Laney> :$
[17:28] <Laney> I have no confidence!
[17:29] <directhex> but you get a special MOTU hat
[17:29] <james_w> Laney: I think you are definitely ready, and I'm tired of sponsoring thing for you :-)
[17:30] <james_w> directhex: "using Gnome;" doesn't do what I expect, am I missing something?
[17:30] <directhex> james_w, what do you expect? :)
[17:31] <james_w> I have build failure of " error CS0103: The name `Gnome' does not exist in the current context"
[17:31] <james_w> adding "using Gnome" gives "error CS0246: The type or namespace name `Gnome' could not be found. Are you missing a using directive or an assembly reference?"
[17:31] <directhex> james_w, "using" allows you to use methods in a namespace without fully qualified names (e.g. 'using System;' allows you to use 'Console.WriteLine' rather than 'System.Console.WriteLine')
[17:32] <james_w> ah
[17:32] <directhex> james_w, to get your hands on the namespace itself, you tend to need the assembly itself to be referenced when compiling
[17:32] <directhex> james_w, which means -r:/path/to/foo.dll
[17:32] <james_w> I want "import" or something then I guess
[17:32] <directhex> james_w, or, for mono, you can use -pkg:some_pkgconfig_thing
[17:32] <directhex> e.g. -pkg:gnome-sharp2.0
[17:33] <james_w> nice
[17:34] <directhex> another advance found in mono but not in that lame windows CLI framework from that bloated company nobody likes ;)
[17:35] <eMerzh> if a motu or otherone has time to review my package ...http://revu.ubuntuwire.com/details.py?package=sqliteman
[17:37]  * directhex updates debian wiki
[17:37]  * Laney updates debian
[17:37] <james_w> directhex: I uploaded, autopano-sift, working on muinescrobbler
[17:37] <directhex> congrats Laney, i think you've officially got the first transitioned app package in any archive :)
[17:37] <Laney> yay!
[17:38] <directhex> james_w, oh, really? you beat Laney? :o
[17:38] <Laney> unyay!
[17:38] <directhex> hm. is LP being glacially slow for anyone else?
[17:38] <Laney> no more than usual
[17:38] <james_w> I uploaded banshee as well the other day
[17:39] <Laney> james_w: You should be updating http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO !
[17:39] <james_w> yeah
[17:39] <james_w> I can't remember my debian wiki password :-)
[17:41] <Laney> directhex: What does [M] and [U] mean?
[17:42] <james_w> directhex: http://paste.ubuntu.com/78352/ review please :-)
[17:42] <directhex> Laney, universe & main!
[17:42] <Laney> aha
[17:43] <directhex> james_w, let me try a test build
[17:44] <james_w> directhex: it builds :-)
[17:44]  * james_w things directhex is silly for thinking I would dare to show him a patch that wasn't at least build tested :-)
[17:47] <Laney> Shouldn't it be MCS = csc?
[17:47] <directhex> well, i was wondering if the configurability was doing as expected. /me checks build log
[17:47] <directhex> nope, james_w wins
[17:47] <directhex> make[1]: Entering directory `/tmp/buildd/muinescrobbler-0.1.8'
[17:47] <directhex> csc -target:library -out:AudioscrobblerPlugin.dll -r:Mono.Security.dll -r:System.Web.dll -pkg:gconf-sharp-2.0 -pkg:glade-sharp-2.0 -pkg:gnome-sharp-2.0 -pkg:muine-plugin -resource:Audioscrobbler.glade EventQueue.cs Functor.cs Global.cs Song.cs GAudioscrobbler.cs AudioscrobblerPlugin.cs
[17:48] <james_w> ok to upload?
[17:48] <directhex> james_w, well played, seems spot on to me
[17:48] <james_w> thanks directhex
[17:51] <james_w> directhex: shall I do sysinfo in case NEW holds up the package from Debian?
[17:55] <directhex> james_w, IMHO yes
[17:55] <directhex> james_w, hanska hasn't pulled it into pkg-cli-apps svn yet, so evidently any updates at the ubuntu end are still valuable
[17:56] <james_w> directhex: what are pkg-mono's plans for the packages that they do not maintain?
[17:57] <directhex> james_w, beyond passing patches to the maintainers, the options are limited. NMU? it's hardly ideal, and seen as aggressive by some maintainers
[17:57] <james_w> yeah
[17:57] <james_w> though won't everything FTBFS?
[17:57] <directhex> james_w, in experimental? yep!
[17:57] <directhex> james_w, which means OOo and kde4bindings right now :)
[17:57] <directhex> james_w, and all the listed apps/libs in jaunty
[17:58] <james_w> good way to orchestrate a transition :-)
[17:58] <directhex> james_w, violently, you mean? :p
[17:58] <james_w> make everything RC buggy so that you can NMU to your hearts consent :-)
[17:58] <directhex> heh ;)
[17:58] <james_w> directhex: should we ubuntu1 everything you aren't maintainer for then?
[17:59] <james_w> we can always sync over the top later
[17:59] <directhex> james_w, as long as the debian maintainer gets a copy, i think it's probably for the best
[17:59] <directhex> yeah, exactly
[17:59] <directhex> james_w, that's why so much of the core stack is (needlessly now) ubuntu1
[18:00] <directhex> james_w, the only bit of the core stack requiring ubuntuing is monodoc, but we did it anyway to help bypass NEW delays
[18:00] <james_w> my concern is that we could end up with a half-done transition and you trying to find sponsors for these updates when everyone is focused on release
[18:00] <james_w> I assume you are happy with the maintained stuff getting updated in time?
[18:00] <directhex> james_w, yes, i think those are safe enough
[18:01] <directhex> worst case, it slips past DIF
[18:01] <james_w> cool
[18:01] <james_w> sounds like a plan
[18:03] <james_w> ** (/usr/lib/mono/2.0/gmcs.exe:14774): WARNING **: The following assembly referenced from /usr/lib/mono/gac/gdk-sharp/2.12.0.0__35e10195dab3c99f/gdk-sharp.dll could not be loaded:
[18:03] <james_w>      Assembly:   Mono.Cairo    (assemblyref_index=2)
[18:03] <james_w> sounds odd
[18:04] <directhex> james_w, what's throwing it?
[18:04] <james_w> youtranslate
[18:04] <james_w> why does gtk-sharp not depend on cairo?
[18:05] <directhex> james_w, it does
[18:05] <directhex> directhex@mortos:~$ apt-cache depends libgtk2.0-cil
[18:05] <directhex>   Depends: libmono-cairo1.0-cil
[18:05] <directhex> hm.....
[18:05] <james_w> ah, nice didn't know about "apt-cache depends", thanks :-)
[18:06] <directhex> try adding a direct build-dep on libmono-cairo2.0-cil ?
[18:06] <directhex> shouldn't be needed though :x
[18:07] <james_w> yep that works
[18:07] <james_w> want me to upload with that, or does this need a fix in gtk?
[18:08] <directhex> i don't *think* it's a gtk problem, we'd have seen it before
[18:08] <james_w> should it not depend on the 2.0 version
[18:08] <james_w> sorry, I don't mean gtk itself, but libgtk2.0-cil
[18:08] <directhex> hm
[18:08] <directhex> what was the FULL build error?
[18:09] <directhex> actually, let me try it locally
[18:09] <directhex> erk, what a funny build system
[18:09] <james_w> http://paste.ubuntu.com/78366/
[18:09] <james_w> yeah, it's stupid
[18:12]  * Laney munches cookies
[18:14] <Laney> Dare I brave f-spot?
[18:14] <directhex> Laney, i'd coordinate that with whoever's most used to man-handling it
[18:16] <Laney> mm, there's a few people who have worked on it
[18:16]  * Laney takes a peek
[18:16]  * Laney screams
[18:17] <directhex> james_w, very strange build problem, but if adding that build-dep fixes it, then just do it & walk away slowly :)
[18:17] <directhex> Laney, there are worse packages than f-spot, that's the scary bit
[18:17] <directhex> Laney, if you really want to peek inside the mind of cthulu, then the package to look at is ikvm
[18:17] <directhex> worse than OOo ^_^
[18:17] <Laney> haha
[18:17] <Laney> I'll pour myself a stiff drink first
[18:17] <directhex> ikvm is still a fascinating idea though
[18:18] <laga> directhex: does it work?
[18:18] <directhex> java compiler for CIL, that's sorta cool. java bytecode interpreterish for CIL, that's very cool
[18:18] <directhex> laga, i have used it in the past
[18:18] <directhex> laga, literally a couple of years ago
[18:19] <laga> ah, so it's somewhat mature (hopefully)
[18:19] <laga> i like java. i really do.
[18:19] <directhex> laga, it works by... um... well, a rather chunky GNU.Classpath.dll assembly, iirc
[18:19] <directhex> laga, it's quite mad :)
[18:19] <ma10> question: I'm restructuring a package, "package" is becoming package-common + package, with package-common holding most of the stuff previously in package. How can I ensure the update will go smoothly? Is it ok to declare Breaks: package (< version) and Replaces: package (< version) in package-common? Of is Replaces: enough?
[18:20] <directhex> ma10, surely is package depends on package-common, there's no problem?
[18:21] <ma10> directhex: yes, it depends on it, but then when package-common gets installed it conflicts with the files still installed by the old "package"
[18:21] <directhex> ah. hm.
[18:22] <Laney> ma10: I think the usual solution is to make package-common Conflict/Replace oldpackge (<< version-which-last-shipped-the-file)
[18:22] <james_w> ma10: not breaks, but Conflicts as Laney says
[18:22] <james_w> but "<< version-that-moves-the-files"
[18:23]  * Laney defers
[18:23] <Laney> I've seen a page about this before, but couldn't find it
[18:23] <ma10> oh but the debian policy says _not_ to use Conflicts: for this situation
[18:25] <ma10> I'll try with just Replaces: and see how it works
[18:27] <james_w> where does it say that?
[18:28] <ma10> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts here
[18:28] <ma10> A Conflicts entry should almost never have an "earlier than" version clause. .....
[18:31] <james_w> yeah
[18:31] <ma10> and also in the Replaces sections it says that Conflicts: + Replaces: is only to be used when the old package has to be completely substituted
[18:35] <jdong> so Breaks is the correct field to use in this case?
[18:36]  * jdong has to go through a similar transition for a package
[18:36] <ma10> jdong: that's what i understand, the manual makes no examples at all. Or maybe just Replaces: is enough
[18:37] <jdong> replaces I don't think is enough.
[18:37] <jdong> before we used to use conflicts to do this.
[18:37] <jdong> but apparently by new policy we should use Breaks.
[18:37] <jdong> at this point I'm just guessing too
[18:37] <ma10> i'll have to try every combination i guess
[18:38] <jdong> well what works isn't the issue here
[18:38] <jdong> it's what is the correct convention for consistency
[18:38] <jdong> I am willing to bet a lot of combinations of breaks/conflicts/replaces will "work"
[18:39] <ma10> yeah right
[18:39] <jdong> perhaps fire something off to the -devel list
[18:39] <james_w> Breaks is new
[18:39] <james_w> so it can be done without it at least :-)
[18:40] <ma10> i'll do some research first.. i don't want ppl telling me RTFM :)
[18:40] <directhex> autopano-sift is odd. i wonder why it build-depends on winforms
[18:40] <james_w> I'm pretty sure it's Conflicts/Replaces despite what policy says
[18:40] <james_w> directhex: there is a directory called autopano-win32
[18:40] <jdong> james_w: well the policy seems to strongly imply it prefers breaks to conflicts+replaces
[18:40] <james_w> directhex: I didn't look any deeper :-)
[18:40] <jdong> before reading that, I wwas sure the answer was conf+replace too
[18:41] <james_w> jdong: yeah, but you can't even use Breaks in Debian yet
[18:41] <jdong> well in Ubuntu it's been used pretty extensively already
[18:41] <james_w> yup
[18:41] <directhex> james_w, well, tek-nik-ly doing a per-os gui on top of generic internals is fine - even a good idea for native look & feel.
[18:41] <jdong> yeah I'm not a very opinionated one for policy
[18:42] <jdong> hence the suggestion to hit the mailing list and catch the attention of someone who is :)
[18:42] <james_w> directhex: yeah, but does it need to build it on linux? :-)
[18:42] <ma10> i'll see how packages with the same structure do it
[18:42] <directhex> james_w, the package has no binary deps on it, so... no idea o_o
[18:43] <ma10> jdong: btw, sorry for being a little absent lately. I got this new job and it's keeping me quite busy..
[18:43] <directhex> wait a sec.....
[18:43] <james_w> yay, adding a configure check that sets MCS and then using a completely different variable as your compiler \o/
[18:44] <directhex> 		-target:winexe -out:autopano-win32.exe \
[18:44] <directhex> it COMPILES the windows version!
[18:44] <ma10> i would have liked to release the fixes for azureus much earlier
[18:44] <directhex> james_w, another one? sad really isn't it o_o
[18:47] <directhex> james_w, well, it seems the windows gui runs. it looks like poop, but it runs ;)
[18:47] <james_w> directhex: is it installed in the package?
[18:47] <directhex> james_w, no
[18:48] <james_w> good :-)
[18:48] <mok0> directhex: looks like poop? Well then it matches the default theme ;-P
[18:49] <directhex> james_w, it'd be good if someone at some point (i.e. not a priority) removed the winforms bit from the build
[18:49] <james_w> yeah
[18:49] <james_w> it already has code conditional on the platform, but doesn't conditionalise that
[18:49] <directhex> o_o
[18:50] <james_w> directhex: ugh, got a build failure now apparently due to two cairo-cils being installed
[18:50] <directhex> james_w, muinescrobbler again?
[18:50] <james_w> http://paste.ubuntu.com/78378/
[18:51] <james_w> nope that worked fine strangely
[18:51] <james_w> sysinfo
[18:51] <fabrice_sp> Hi. Can someone sponsor or review the debdiff I attached to bug #285674. It would allow to close 2 bugs (and it uses autopano :-) )
[18:52]  * james_w goes to eat dinner
[18:52] <mok0> fabrice_sp: I'll bite
[18:52] <rawler> http://revu.ubuntuwire.com/details.py?package=tetzle <.- awaiting comments / approval
[18:53] <directhex> james_w, perhaps find a way to make the "-r:/usr/lib/mono/1.0/Mono.Cairo.dll" turn into "-r:/usr/lib/mono/2.0/Mono.Cairo.dll"? i suspect it doesn't help that there's no pkg-config file for mono-cairo 2.0
[18:54] <mok0> fabrice_sp: it's from experimental
[18:54] <fabrice_sp> mok0: by the way, I fixed the dvdstyler package you reviewed before
[18:54] <directhex> fabrice_sp, what is hugin?
[18:55] <mok0> fabrice_sp: great, I'll take a look later
[18:55] <fabrice_sp> mok0: yes, but I have it since a quite long time in my PPA, and at least 6 users reports
[18:55] <fabrice_sp> it's a software that allows you to 'paste' several pictures and make a panoramic picture
[18:56] <directhex> fabrice_sp, so is autopano-sift, and james_w just uploaded a new version of that ;)
[18:56] <fabrice_sp> and it's using autopano to detect the common points
[18:56] <fabrice_sp> directhex: yes: that's why I emember that this bug was stil lwaiting :-)
[18:57] <fabrice_sp> s/emember/remember/
[18:59] <mok0> fabrice_sp: quite a few changes from the svn3191 version...
[19:00] <fabrice_sp> mok0: it's basically a bug fixing release, so no big updates
[19:02] <mok0> fabrice_sp: bugfix release? 266 files changed
[19:02] <directhex> mok0, 266 bugs :)
[19:02] <mok0> heh
[19:03] <fabrice_sp> mok0: really? Wow
[19:03] <mok0> fabrice_sp: your debdiff looks sane though :-)
[19:04] <mok0> fabrice_sp: what is autopane btw?
[19:05] <fabrice_sp> mok0: thanks :-) You mean autopano, right?
[19:05] <mok0> fabrice_sp: yes...
[19:06] <mok0> never mind
[19:06] <fabrice_sp> It's an app that find common parts in 2 pictures, to merge them after
[19:06] <fabrice_sp> this is what make hugin more automatic
[19:06] <mgdm> hugin \o/
[19:06] <fabrice_sp> yes :-)
[19:06] <mok0> fabrice_sp: ... and autopano-complete vs. autopano-sift-c ??
[19:07] <fabrice_sp> mok0: autopano-complete is the script name that launch this mono app
[19:07] <mok0> fabrice_sp: I am trying to figure out what justifies our establishes a new Ubuntu delta, that's all...
[19:08] <mok0> s/estabilshes/establishing/
[19:08] <fabrice_sp> mok0: np :-) autopano-sift-c doesn't exist in Ubuntu.
[19:08] <mok0> fabrice_sp: oh, that's a very good reason :-)
[19:08] <fabrice_sp> as it's a mono app, it's not within Debian, and they left the windows name of the app
[19:09] <mok0> fabrice_sp: how ironic, me who hate mono apps and think they should be banished from Ubuntu :-D
[19:10] <fabrice_sp> mok0: arghhh :-D
[19:11] <mok0> fabrice_sp: well, to my dismay the package looks good. Uploading...
[19:11] <fabrice_sp> this change would close the second bug (bug #162575)
[19:11] <fabrice_sp> thanks mok0 :-)
[19:21] <james_w> directhex: yeah, the problem is that mono-cairo 1.0 has a pkg-config file, while 2.0 doesn't
[19:21] <directhex> i wonder why.
[19:26] <james_w> um, did we completely miss the MOTU meeting?
[19:27] <Laney> Looks so
[19:27] <tonyyarusso> Say, debuild isn't finding my secret key for gpg, yet gpg --list-secret-keys shows it.  What's likely my problem?
[19:27] <Laney> Do the details in the changelog match those in the key?
[19:28] <tonyyarusso> yup
[19:30] <tonyyarusso> Laney: the key has "Anthony Yarusso (tonyyarusso) <tonyyarusso@ubuntu.com>" and the changelog has "Anthony Yarusso <tonyyarusso@ubuntu.com>" - I don't see any typos, but sometimes I'm just blind.
[19:31] <james_w> "(tonyyarusso)"
[19:31] <james_w> they are not byte-for-byte identical, so it doesn't work automatically
[19:31] <james_w> you can add a uid, change the changelog, or use -k
[19:32] <tonyyarusso> oh really?  I didn't know it checked the nickname things.
[19:32] <tonyyarusso> -k, that's what I did before.  Thanks.
[19:32] <mok0> tonyyarusso: it just does a string compare
[19:32] <tonyyarusso> nice.  Thought it was a bit smarter I guess.
[19:36] <Laney> :(
[19:36] <Laney> gmcs all over f-spot
[19:38] <Laney> Oh, wait. I think I found it
[19:38] <directhex> Laney, iirc f-spot uses both gmcs and mcs o_o
[19:39] <Laney> hardcoded in Makefile.include for some reason
[19:49] <Laney> Right. This is going to be it.
[19:52] <Laney> woohoo!
[20:05] <directhex> Laney, f-spot is one where you really need to update the debian wiki, to avoid duplication ;)
[20:05] <directhex> or at least mail the ML
[20:05] <Laney> I did put my name next to it
[20:10] <james_w> directhex: why is cowbell not done? :-)
[20:14] <directhex> james_w, i got a fever, and the only prescription is more cowbell :|
[20:15] <directhex> james_w, i''l do it. i should have by now
[20:15] <directhex> assuming it's pkg-cli-apps
[20:16] <directhex> yeah, i'll svn ci
[20:23] <tonyyarusso> Is it possible to search all LP PPAs to see if someone's packaged a particular application?
[20:30] <ma10> tonyyarusso: https://launchpad.net/ubuntu/+ppas
[20:33] <tonyyarusso> ma10: thanks
[20:34] <directhex> o_o @ https://launchpad.net/~mono-edge/+archive
[20:36] <RAOF> 2.2 isn't actually released yet, is it?
[20:37] <directhex> no
[20:39] <directhex> i hope it's not based on 1.9.1 packaging or it's game over for anyone using that repo post-intrepid
[20:40] <directhex> o_o
[20:40] <directhex> native archives? srsly?
[20:40] <RAOF> The fact that it's accidentally a native package doesn't raise confidence.
[20:41] <directhex> it DOES seem to have been based on 2.0.1 packaging though
[20:42] <directhex> so it could be worse
[20:42] <RAOF> What are the new binaries generated by 2.2 going to be?
[20:43] <directhex> RAOF, the csharp shell... monodoc has been merged into mono... mono.simd... a few other bits
[20:43] <RAOF> Ah, yeah.
[20:44] <directhex> okay, looking at the changelog, he's snapshotted 2.0-1 from incoming, then done some rather odd things
[20:44] <directhex> mono (2.0.1-1~ppa2) intrepid; urgency=low
[20:44] <directhex>   * Replace System.Data.Linq with the SoC project
[20:44] <directhex> mono (2.0.1-1~ppa4) intrepid; urgency=low
[20:44] <directhex>   * Use SDL from the atushi-200810 branch
[20:44] <RAOF> Where does mono use SDL?
[20:44] <nellery> If I want to request a sync, and a package's newest version is in experimental, though there are newer ones in unstable, which would I request?
[20:45] <directhex> system.data.linq
[20:45] <directhex> nellery, which do you want?
[20:45] <RAOF> Ah.  Not Simple Directmedia Layer :)
[20:45] <nellery> directhex: I know the unstable version builds fine, but I haven't tested the experimental one
[20:47] <RAOF> It's important to know /why/ the package is in experimental.  It could be there because they don't want to block updates to Lenny with new upstream versions.  It could be there because they expect it to be broken. :)
[20:47] <nellery> It's not mentioned in the changelog, but the main change is a new upstream release.
[20:47] <directhex> it could be there for fun! 8D
[20:48] <tonyyarusso> If an application is crashing on startup to to a buffer overflow, how can I capture that output to a file in bash?  (the basic > doesn't do it; can't remember the other options)
[20:48] <tonyyarusso> *due to a
[20:49] <RAOF> 2>&1 should dupe stderr to stdout, which would make a later > redirect properly.
[20:54] <tonyyarusso> RAOF: so, programname 2>&1 > logfile ?
[20:54] <RAOF> Yah.
[20:55] <RAOF> You might want to check the syntax; it could be 2&>1.  I always get that mixed up :)
[20:55] <mgdm> No, it's 2>&1
[20:56] <tonyyarusso> Still nothing - empty file.
[20:57] <mgdm> try "programname > file 2>&1"
[20:57] <mgdm> it's a little funny about the positioning of the 2>&1 bit sometimes
[20:58] <tonyyarusso> Okay, that put *something* in the file, but all it is is the text "Aborted", not the backtrace info that was printed on the terminal.
[20:59] <mgdm> OK, try "programname > file 2> errorfile"
[20:59] <mgdm> that should make 2 files
[21:00] <tonyyarusso> mgdm: file is empty, errorfile is "Aborted".
[21:00] <mgdm> "Hmm".
[21:00] <tonyyarusso> is there a 3?  :P
[21:01] <tonyyarusso> Someone elsewhere suggested that it could be the shell itself that is printing that information, not the program.
[21:01] <stdin> there can be hundreds
[21:01] <nellery> what package is 'apt-get moo' from?
[21:01] <stdin> nellery: apt
[21:02] <nellery> ahh that's what '-h' refers to
[21:03] <mgdm> tonyyarusso: that's possible, I suppose
[21:38] <eMerzh> if a motu or otherone has time to review my package ...http://revu.ubuntuwire.com/details.py?package=sqliteman
[21:51] <awmcclain> If you're trying to test a package that runs a daemon, what do you do? Login to pbuilder or some other chroot? Create a virtualized machine which you scrap after you test?
[22:26] <james_w> directhex: am I correct that mono-gac should be dropped from Build-Depends as mono-devel provides gacutil now?
[22:58] <james_w> directhex: no I am not :-)
[23:01] <Laney> james_w: Is mono-devel => mono-2.0-devl => mono-2.0-gac not enough?
[23:01] <Laney> Or is gacutil specifically in mono-gac?
[23:01] <james_w> gacutil is in mono-gac
[23:01] <james_w> gacutil2 is in mono-2.0-gac
[23:02] <james_w> and if it requires gacutil it should directly depend on whatever requires it
[23:17] <directhex> james_w, mono-devel should pull in the default gacutil
[23:21] <directhex> james_w, gacutil2 is one of the few things we managed to pressure upstream into providing for us - gacutil generally is used to register a library as being available for apps to arbitrarily use - but as a CLI binary, we had the silly situation where you'd need all of the 1.0 corlib and 1.0 System.dll just to run gacutil
[23:30] <Laney> bah
[23:30] <Laney> No applications ever respect the configure args
[23:30]  * Laney stomps around
[23:31] <james_w> Laney: funny, all the ones I've done do :-)
[23:32] <Laney> :O
[23:32] <Laney> I always get "checking for gmcs... /usr/bin/csc", and then further down they still use gmcs
[23:33] <TheMuso> Its mono. What do you expect?
[23:34] <james_w> I doubt it is a phenomenon specific to mono
[23:35] <directhex> yeah. what about portable.net's c# compiler? :o
[23:36] <Laney> we should have a mono transition BSP ;)
[23:42] <Laney> http://pastebin.ubuntu.com/78491/
[23:42] <Laney> why :(
[23:43] <james_w> heh
[23:44] <RAOF> Laney: You're looking at mirage, I guess?
[23:44] <Laney> RAOF: yessir
[23:44] <RAOF> You're confident you've got it?
[23:44] <Laney> I haven't got it yet
[23:44] <Laney> busy moaning
[23:45] <RAOF> I've got a patch that should work, soon.
[23:45] <Laney> oh, over to you then
[23:45] <Laney> Claim it on the wiki please
[23:45] <RAOF> Oh, there's claiming on wikis?
[23:46] <Laney> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
[23:46] <Laney> your name is next to something already :O
[23:47] <RAOF> Hm.  I wonder whether I've got a login for that wiki :){
[23:56] <Laney> RAOF: I just did it for fun anyway. Change build/build.mk and Test/Makefile.am to use $(GMCS), right?
[23:57] <RAOF> Well, you could do it that way, yes.
[23:57] <RAOF> I was getting it to set MCS correctly, but using $(GMCS) is perfectly acceptible.
[23:58] <RAOF> Laney: You upload, I'll send a patch upstream.
[23:59] <Laney> Hm, it's not even in Jaunty yet.
[23:59] <RAOF> Correct.