[00:00] <snikker> ah, ok... thanks.
[00:04] <james_w> anyone know what's going on with http://launchpadlibrarian.net/19916491/buildlog_ubuntu-jaunty-i386.glui_2.36-2ubuntu1_FAILEDTOBUILD.txt.gz ?
[00:04] <james_w> touch configure-stamp
[00:04] <james_w> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[00:06] <RAOF> Looks like the actual error is above that.
[00:06] <azeem> james_w: hrm, *maybe* those warnings spit out by libtool led to a non-zero exit status, and bootstrap is reporting that
[00:06] <RAOF> WHile running bootstrap.sh
[00:06] <azeem> RAOF: which error?
[00:07] <azeem> oh
[00:07] <azeem> right
[00:07] <james_w> ah, oh yeah
[00:07] <james_w> is that a parallel make or something?
[00:08] <RAOF> Also, it looks like that's trying a parallel build, and build-stamp's running before configure has finished (or, in fact, started)
[00:09] <james_w> so build-stamp should depend on configure-stamp?
[00:10] <RAOF> Probably on configure?
[00:11] <james_w> hmm, maybe
[00:11] <RAOF> Well, actually, it likely doesn't make any difference.  But yeah; build-stamp should depend on configure(-stamp), because it doesn't work until configure's been run :)
[00:11] <james_w> configure is PHONY, so wouldn't have make build-stamp be run every time?
[00:12] <RAOF> Um...
[00:12] <azeem> sometimes, I wonder whether that configure: target in debian/rules was invented before or after the advent of autoconf
[00:13] <RAOF> I think dependenices of a PHONY target aren't refreshed if they're up to date, but that's something I'd want to check to be sure.
[00:13] <azeem> yeah, I'd assume build-stamp would just be a no-op then if the stampfile already exists
[00:16] <Coringao> ola alguem pode dizer em portugues aqui.. por favor
[00:16] <Coringao> É sobre o repositorio Ubuntu Games
[00:17] <Coringao> tipo tenho um repositorio
[00:17] <azeem> Coringao: this is an english channel
[00:17] <Coringao> deb http://archive.ubuntugames.org intrepid main
[00:18] <Coringao> azeem, sorry.. not english  :(
[00:18] <RAOF> There is a Portugese channel, though.  That'd be #ubuntu-pt (?)
[00:19]  * RAOF can never remember his locale codes.
[00:20] <Coringao> RAOF, I created a repository for the Ubuntu Games
[00:21] <Coringao> RAOF, Where it exists games not official in the Ubuntu
[00:22] <Coringao> RAOF, I am creative and administrator of link Ubuntu Games
[00:22] <Coringao> http://www.ubuntugames.org
[00:23] <RAOF> Do you have a question?
[00:23] <Coringao> RAOF, would like to officialize the repository that I created
[00:24] <RAOF> Right.  Why are the games not in the Ubuntu repositories already?
[00:24] <Coringao> sorry... I am using a translator.
[00:24] <azeem> Coringao: does somebody from your team speak good english?
[00:26] <Coringao> azeem, sorry.. I do not have team. I made this alone project.
[00:26] <Coringao> :(
[00:29] <leleobhz> well
[00:29] <Coringao> leleobhz, De um help aqui
[00:30] <leleobhz> trying to explain quickly
[00:30] <leleobhz> Coringao has created a repository only for games not packaged yet for ubuntu
[00:30] <leleobhz> and he want to know if have a way to add these packages to official branch of ubuntu
[00:31] <leleobhz> actually these packages are stored into ubuntugames.org server
[00:31] <leleobhz> this guy is the project mantainer
[00:31] <leleobhz> the idea is insert these games into multiverse or universe repositories
[00:31] <azeem> are you sure?
[00:32] <leleobhz> about what?
[00:32] <azeem> it sounded like he just wanted to have his repo "blessed"
[00:32] <azeem> not getting his packages in
[00:32] <wgrant> The idea seems to me to be to create another separate repo that is useless and destroys more upgrades..
[00:32] <leleobhz> no
[00:32] <RAOF> There's the standard way, same as getting any other package in Ubuntu.  https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages?action=show&redirect=MOTU%2FPackages%2FNew is an English version of the page; I'm not sure if there's a Portugese translation.
[00:32] <azeem> but if he really wants to get his packages into universe, he just become a MOTU
[00:33] <azeem> the language barrier might be a problem, though
[00:33] <leleobhz> the idea is only to add these packages to ubuntu repositories
[00:33] <wgrant> leleobhz: Why does that site exist, then?
[00:33] <leleobhz> wgrant: because a lot of these games dont exist packaged for ubuntu
[00:33] <wgrant> Then somebody should package them for Ubuntu.
[00:34] <leleobhz> and the intention is teach a easy way to novice users get their games working on linux
[00:34] <azeem> it seems to have been quite some work to build up this community etc.
[00:34] <leleobhz> [24/11-22:32:59] < azeem> but if he really wants to get his packages into universe, he just become a MOTU
[00:34]  * leleobhz think this is the case...
[00:34] <wgrant> I don't see why people are so quick to start their own repositories and communities when they can with substantially greater ease leverage the existing repository and community.
[00:35] <azeem> well, becoming a motu doesn't exactly happen overnight these days, AIUI
[00:35] <leleobhz> the idea is dont need a isolated repository, but have these games available throught ubuntu
[00:35] <wgrant> One doesn't seen to be a MOTU to get packages into universe.
[00:35] <wgrant> s/seen/need/
[00:35] <azeem> leleobhz: there's a vibrant Debian/Ubuntu games team
[00:35] <wgrant> leleobhz: Why does the isolated repository exist, then?
[00:35] <azeem> leleobhz: possibly, somebody of them speaks portuguese
[00:36] <azeem> leleobhz: I think there are at least a couple of spanish speakers in there
[00:36] <azeem> he should contact them
[00:36] <azeem> IMO
[00:36] <leleobhz> wgrant: because the packages isnt on ubuntu (yet i hope :p_
[00:36] <leleobhz> azeem: its a great idea too
[00:36] <azeem> wgrant: let's assume it was by ignorance of the available procedures
[00:37] <wgrant> azeem: There is an awful lot of that around these days, it seems.
[00:37] <azeem> yeah, sure
[00:37] <leleobhz> azeem: yes... these guys arent very experienced about packaging
[00:37] <leleobhz> well, ill discuss with Coringao these ideas
[00:37] <azeem> I guess there's a lot of over-motivated people who hear about FLOSS communities, get excited and want to start their own community
[00:37] <james_w> I have some sympathy though, I wouldn't want to try and push 20 packages in to Ubuntu
[00:38] <azeem> yeah
[00:38] <wgrant> Then I would posit that they have no business running their own repository to work around QA procedures.
[00:38] <leleobhz> and i need to get away because im busy
[00:38] <azeem> leleobhz: thanks for doing this!
[00:38] <azeem> now, where is bddebian when you need him
[00:39] <azeem> wgrant: it's Free Software
[00:39] <azeem> what they do isn't smart for the community, but they can do whatever they please
[00:39] <wgrant> I didn't say it wasn't permitted.
[00:40] <azeem> just remember that Debian people though exactly the same of Ubuntu when it started up
[00:40] <azeem> but anyway, let's hope this is getting resolved in the games team or something
[00:40] <azeem> thought*, anyway
[00:40] <wgrant> True.
[00:49] <directhex> there are cases where you don't have many options
[00:49] <directhex> e.g. my mono updates repo, since mono is barred from foo-backports
[00:49] <azeem> heh
[00:51] <directhex> and i'll continue to cite my 12000+ user statistic, even though the number has dropped significantly post-intrepid-release :/
[01:47] <kirkland> mathiaz: i managed to create an ubuntu branch of ecryptfs-utils: http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=shortlog;h=ubuntu
[01:49] <mathiaz> kirkland: great
[01:49] <kirkland> mathiaz: okay, i'm trying iscsitarget.failed-upgrade
[01:50] <mathiaz> kirkland: I've build your package - it seems that it's working if you renamed iscsitarget.prerm to prerm
[01:51] <kirkland> mathiaz: oh, hmm...  interesting.  i named it iscsitarget.prerm per man dh_installdeb
[01:51] <mathiaz> kirkland: right - however you have docs and dir files in debian/
[01:51] <mathiaz> kirkland: so it seems that debhelper assumes that your only building one package.
[01:52] <mathiaz> kirkland: and you can just use prerm, postinst
[01:52] <kirkland> mathiaz: okay, let me give that a shot
[01:52] <mathiaz> kirkland: ok - how did you notice that it wouldn't work?
[01:57] <kirkland> mathiaz: that what wouldn't work?
[01:58] <kirkland> mathiaz: i tried building the package, and expected the file debian/iscsitarget.prerm.debhelper to be generated, with my code plus the auto-generated code
[01:58] <kirkland> mathiaz:  when you do that (rename it to prerm), do you get: E: iscsitarget: maintainer-shell-script-fails-syntax-check prerm
[02:00] <kirkland> mathiaz: nevermind
[02:00] <kirkland> mathiaz: boneheaded syntax error on my part
[02:04] <kirkland> mathiaz: hmm, so when you said it "worked" ...  did your built package end up with a fully populated debian/iscsitarget.prerm.debhelper ???
[02:06] <kirkland> mathiaz: hmm, but it does look right in debian/iscsitarget/DEBIAN
[02:07] <mathiaz> kirkland: ok - so that means the package is probably correct then.
[02:14] <nhandler> To get a package backported to intrepid, do I just file a bug against intrepid-backports and subscribe ubuntu-backporters?
[02:16] <ScottK-laptop> nhandler: Yes.  If you can say you've tested that it builds, installs, and runs, then say so and set it to confirmed.
[02:17] <ScottK-laptop> nhandler: Feel free to ping me after you've done that.
[02:17] <nhandler> ScottK-laptop: Is it a requirement to upload it to a PPA?
[02:18] <ScottK-laptop> nhandler: Not at all.
[02:18] <ScottK-laptop> nhandler: You  tell me you  tested it and that's good enough.  If it FTBFS, then I send NCommander to hunt you down.
[02:18] <nhandler> ScottK-laptop: Great. I'll submit the bug report. It built cleanly in pbuilder
[02:19] <NCommander> wait, what?
[02:19] <ScottK-laptop> NCommander: Easy.  Not yet.
[02:29] <nhandler> ScottK-laptop: Bug #301914
[02:31] <kirkland> mathiaz: okay, i've got it going now ;-)
[02:31] <kirkland> mathiaz: tested, working
[02:35] <ScottK-laptop> nhandler: Looking
[02:36] <nhandler> Thanks ScottK-laptop
[02:36] <mathiaz> kirkland: did you add the code to failed-upgrade?
[02:36] <kirkland> mathiaz: no, prerm
[02:36] <kirkland> mathiaz: that seemed to work better
[02:37] <ScottK-laptop> nhandler: You also need to say it installs and runs.
[02:37] <mathiaz> kirkland: hm - I meant i the prerm script - under which action did you put the code?
[02:37] <mathiaz> kirkland: upgrade or failed-upgrade?
[02:37] <nhandler> ScottK-laptop: Ok, I'll add that in (it does install/run)
[02:37] <ScottK-laptop> Great.
[02:38] <kirkland> mathiaz: oooooohhhhhh
[02:38] <kirkland> mathiaz: great idea
[02:39] <kirkland> mathiaz:  i couldn't it to work under that part of the case statement, so i removed it entirely
[02:39] <kirkland> mathiaz: duh, it belongs under failed-upgrade
[02:39] <mathiaz> kirkland: http://women.debian.org/wiki/English/MaintainerScripts
[02:39] <mathiaz> kirkland: ^^ there is a chart about the sequence of maintainer script calls.
[02:39] <ScottK-laptop> nhandler: Ack'ed.  Now it's just question of when an archive admin processes it.
[02:40] <nhandler> ScottK-laptop: Thanks a lot
[02:42] <kirkland> mathiaz: bingo, that works perfectly
[02:43] <kirkland> mathiaz: http://pastebin.ubuntu.com/76655/
[02:48] <kirkland> mathiaz: cool, i'm happy with it, uploading ....
[02:52] <mathiaz> kirkland: hm - have you already uploadedÉ
[02:52] <mathiaz> kirkland: ?
[02:52] <kirkland> mathiaz: nope
[02:53] <kirkland> mathiaz: was giving you a chance to respond, since you had looked at it
[02:53] <mathiaz> kirkland: what about protecting the code with a version comparisonÉ
[02:53] <mathiaz> kirkland: ?
[02:53] <mathiaz> kirkland: OTOH you're checking the md5sum
[02:53] <kirkland> mathiaz: i thought about that, but i figure the md5sum was even stronger
[02:55] <mathiaz> kirkland: ok - I think it makes sense.
[02:56] <mathiaz> kirkland: what kind of testing did you do?
[02:56] <kirkland> mathiaz: 1) installed the new package on a system with no iscsitarget package installed
[02:57] <kirkland> mathiaz: 2) installed the new package on a system with the Intrepid iscsitarget package installed
[02:57] <kirkland> (ie upgraded)
[02:57] <kirkland> mathiaz: 3) upgraded from the current jaunty package
[02:57] <kirkland> mathiaz: 4) upgraded against itself
[02:57] <kirkland> mathiaz: all of those seemed to succeed
[02:58] <mathiaz> kirkland:hm ok.
[02:59] <mathiaz> kirkland: I don't see the point of 4) though
[03:04] <kirkland> mathiaz: good enough?  any other concerns?
[03:05] <mathiaz> kirkland: no other concerns.
[03:05] <mathiaz> kirkland: I was just wondering what was the use case of 4)
[03:06] <kirkland> mathiaz: none really, now that i think of it
[03:37] <freeflying> james_w: fcitx has a nmu upload in debian, would u like sync it?
[03:37] <ScottK-laptop> freeflying: Is there currently an Ubuntu difference?
[03:38] <ScottK-laptop> We're in auto-sync now, so if there isn't it'll happen automatically.
[03:39] <freeflying> ScottK-laptop: no, I prepare upload a svn snapshot of fcitx, its good for me to sync it before I uplaod :)
[04:15] <Elbrus> has anybody experience in building in with sbuild? when I add universe to the sources.list I get a "W: GPG error: http://us.archive.ubuntu.com hardy Release: Could not execute '/usr/bin/gpgv' to verify signature (is gnupg installed?)" warning and the build failes.
[04:15] <Elbrus> I could install gnupg in the schroot, but than the root is not "clean" anymore...
[04:16] <Elbrus> Any idea how to handle this correctly?
[04:27] <jmarsden> Elbrus: Read https://help.ubuntu.com/community/SbuildLVMHowto and check the --source-template option?
[04:30] <Elbrus> jmarsden: I have no experience with LVM, it is something worth learning at this moment?
[04:35] <jmarsden> I'm not sure.  Try just reading the sbuild man pages or do more googling for sbuild ubuntu sources?  LVM isn't hard, but if you've never played with it, I'm not sure it's necessary at this point for you either.
[04:36] <Elbrus> what is the minimum that the root should have: build-essential and ubuntu-minimal?
[04:40] <jmarsden> Does man 7 sbuild-setup not answer that?  In a rather Debian-focused way, but still... it mentions several things to apt-get.
[04:41] <jmarsden> Is there a reason you can't use pbuilder, which seems to be simpler to set up and use?
[04:42] <Elbrus> jmarsden: I used the sbuild-createchroot script which is *supposed* to take care of it
[04:42] <Elbrus> jmarsden: yes, lazarus does not want to build in it... to much happening before the source is passed to the jail
[04:42] <Elbrus> might be a bug worth reporting to lazarus, but of that I am not sure
[04:43] <Elbrus> jmarsden: oh, I use pdebuild, but IIUC that is nearly the same, right/
[04:44] <Elbrus> s/\//?
[04:44] <jmarsden> Yes.  You can use   sudo pbuilder --login to play around inside a pbuilder if you need to set something up just so for lazarus?
[04:46] <jmarsden> Worst case, once lazarus builds for you outside of a chrooted world, you could just upload it to your PPA, and see whether it builds OK there? ;)
[04:46] <Elbrus> hmm, it really pukes on it before it even gets to pbuild (the clean rule calles patch and unpatch, I think it goes wrong there)
[04:47] <Elbrus> I prefer only building inside chroots, because I am not so experienced in programming that I trust the handling outside the jail... or am I exagurating here?
[04:48] <jmarsden> It's up to you... I'm not an expert at all.  I tend to build things in my real live machine, then check for dependency issues etc in a pbuilder, then upload to PPA, then if all of those work, my build is probably OK.
[04:52] <Elbrus> and how do you build against different ubuntu versions outside a chroot?
[04:53] <Elbrus> or just test the building on the live machine and then the rest in the PPA?
[04:54] <Elbrus> jmarsden: thanks for the help
[04:55]  * Elbrus is going to bed now.
[04:55] <jmarsden> Elbrus: No problem
[06:10] <dholbach> good morning
[06:12] <NCommander> morning dholbach
[06:13] <dholbach> hi NCommander
[06:14] <NCommander> how goes it dholbach?
[06:14] <dholbach> good good - how 'bout you?
[06:14] <NCommander> Packaging KDE 4.1.80
[06:14] <nellery> hi dholbach
[06:14] <dholbach> great
[06:14] <dholbach> hi nellery
[06:53] <nellery> where does the --logfile option of pbuilder place the created log?
[06:54] <Hobbsee> wherever you specify it directly afterwards, normally
[06:54] <nellery> so --logfile ~/build.log would be fine?
[06:55] <Hobbsee> yes,b ut that may well end up in /root/build.log if you're not careful.
[06:55] <nellery> Hobbsee: I see, thanks for your help
[06:57] <Hobbsee> nellery: you're welcome. If you want to make absolutely sure where it goes, specify an absolute path (eg /home/nellery/build.log)
[06:57] <nellery> Hobbsee: yup, I got that
[06:57] <Hobbsee> cool :)
[06:57] <nellery> thanks
[06:57] <Hobbsee> you're welcome
[13:02] <stefanlsd> Laney: around?
[13:34] <Laney> hi stefanlsd
[13:35] <stefanlsd> Laney: heys. let me try remember what i wanted to ask you :)
[13:36] <Laney> :O
[13:37] <stefanlsd> Laney: I think it was re: bug #246720
[13:38] <Laney> What about it?
[13:39] <stefanlsd> thats the part i cant remember. was doing the merge of the new libavg and wanted to ask u something bout that.   (was on the weekend, so yeah)
[13:45] <Laney> heh
[13:45] <Laney> well if you remember then you can ask me
[13:45] <jussio1> Laney: what happened to the btnx package?'
[13:45] <Laney> jussio1: I gave up
[13:45] <jussio1> :(
[13:45] <jussio1> why?
[13:46] <Laney> The code wasn't in good shape iirc
[13:46] <Laney> have a go at packaging it if you want
[13:47] <jussio1> Laney: if you failed... Im guessing myskills ar much less than yours...
[13:49] <Laney> not necessarily!
[13:55] <jussio1> Laney: Ive not really toched packaging for a while, although I should do....
[14:13] <DktrKranz> nhandler: re loadlin merge, I've got a working copy in my PPA. Anyway, I just passed -fno-stack-protector to the right location, but I'm still not comfortable with it.
[14:13] <DktrKranz> I'd like to see it more in detail
[14:16] <azeem> (IME, the person who did the last loadlin Debian upload is extremely competent at what he does)
[14:19] <DktrKranz> azeem: well, I'm not confident -fno-stack-protector is the best way to "fix" FTBFS in Ubuntu buildds, absolutely no blame to Debian maint.
[14:30] <RainCT> hey
[14:34] <DktrKranz> hey RainCT
[15:06] <bddebian> Heya gang
[15:26] <jcfp> motu's, if you have some time please review http://revu.ubuntuwire.com/details.py?package=sabnzbdplus
[15:27] <Laney> YEAH! DO!
[16:58] <geser> Hi bddebian
[16:59] <bddebian> Heya geser
[17:22] <|eMerzh|> Hi all, i need some help for my package,....i don't understand how to split my package into main and -doc...(http://revu.ubuntuwire.com/details.py?package=sqliteman) ...could someone help me?
[17:28] <RainCT> |eMerzh|: install everything into debian/tmp and from there put it into the appropiate binary package listing the directories you want to include into it in debian/sqliteman.install and debian/sqliteman-doc.install
[17:32] <kirkland> kees: https://code.edge.launchpad.net/~kirkland/bogosec/trunk revisions 294 and 295
[17:33] <kirkland> kees: mikeowens is repacking for updated upload to revu
[17:33] <|eMerzh|> RainCT: ok i'll try this
[17:44] <kees> kirkland: cool!
[18:17] <RainCT> jono: Hey. Did gnome-shell build correctly for you on Intrepid?
[18:18] <jono> RainCT, yep
[18:19] <RainCT> jono: with which automake version?
[18:19] <jono> RainCT, no idea
[18:19] <RainCT> jono: dpkg -l | grep automake  :)
[18:19] <jono> ii  automake                                  1:1.10.1-3                              A tool for generating GNU Standards-compliant Makefiles
[18:20] <jono> ii  automake1.9                               1.9.6+nogfdl-3ubuntu1                   A tool for generating GNU Standards-compliant Makefiles
[18:21] <RainCT> jono: Alright, I'll try with this one. Thanks :).   (It's FTBFS here and a guy who is helping me on #gnome-shell said it may be because of automake)
[18:21] <jono> wicked
[18:21] <jono> good luck :)
[18:22] <RainCT> thanks :)
[18:24]  * RainCT hugs jono -- it build now! :)
[18:26] <jono> woo!
[18:26]  * jono hugs RainCT 
[18:26] <jono> :)
[18:30]  * directhex pokes RainCT 
[18:30]  * RainCT looks at directhex 
[18:31] <directhex> RainCT, mono 2 landed in debian. got a gbrainy transition ready?
[18:31] <RainCT> directhex: I have some changes in SVN but I'm not sure if there was something missing
[18:32] <directhex> RainCT, in pkg-cli-apps?
[18:33] <RainCT> directhex: Yep. svn.debian.org/svn/pkg-cli-apps/packages/gbrainy/trunk
[18:33]  * |eMerzh| has just udpate his package....any review/comments is welcome (http://revu.ubuntuwire.com/details.py?package=sqliteman ) thanks to all
[18:35] <iulian> directhex: I'm the maintainer of giver (it's on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO) and I wonder what I should do.
[18:35] <iulian> I've no idea about this transition.
[18:36] <directhex> iulian, i wrote instructions on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669
[18:36] <directhex> iulian, if anything's unclear, please ask
[18:36]  * iulian is looking
[18:37] <directhex> oh, sodding cdbs. RainCT, looking at your control/rules, you still need to transition it, but i don't understand cdbs enough for the rules change
[18:38] <directhex> - mono-gmcs (>= 1.1.8)
[18:38] <directhex> + mono-devel (>= 2.0)
[18:38] <directhex> that's the control change
[18:40] <RainCT> directhex: yep, the control change is done, but I've just noticed that I didn't commit it :)
[18:41] <sebner> RainCT: gbrainy?
[18:41] <RainCT> directhex: I'll look into the rules one once I've more time (unless you discover what change is required before :))..
[18:41] <RainCT> sebner: yep
[18:41] <sebner> RainCT: nice
[18:42] <RainCT> themuse: where have your caps gone? :P
[18:43] <directhex> ding ding, who feels like telling me how to add a custom flag to ./configure in cdbs-land?
[18:43] <directhex> you're all cdbs-using weenies here, right? :p
[18:43] <sebner> directhex: wäääähhhhhh, noooooooo
[18:45] <directhex> RainCT, looking at gbrainy source, you need to pass MCS=/usr/bin/csc to ./configure
[18:45] <directhex> RainCT, but cdbs is scary!
[18:45] <Laney> directhex: DEB_CONFIGURE_USER_FLAGS += blah
[18:45] <directhex> aha, there you go. thanks Laney
[18:46]  * directhex adds to debian wiki
[18:50] <directhex> how does DEB_CONFIGURE_EXTRA_FLAGS differ from DEB_CONFIGURE_USER_FLAGS?
[18:52] <ScottK> IIRC extra adds to the existing list and the other one replaces it.
[18:54]  * directhex thinks extra is better then
[18:55] <iulian> directhex: Aren't the packages located at svn.d.o/svn/pkg-cli-apps/packages/pkg?
[18:56] <Laney> $(DEB_CONFIGURE_INVOKE) $(DEB_CONFIGURE_EXTRA_FLAGS) $(DEB_USER_CONFIGURE_FLAGS)
[18:56] <Laney> I don't really understand the difference
[18:56] <iulian> directhex: Bleah, they aren't. Just checked on alioth machine.
[18:56] <directhex> iulian, the ones which are in our svn, yes. not all of them are though
[18:57] <directhex> iulian, we don't steal packages which people don't want to have available for collaborative maintenance
[18:57] <directhex> except ironpython, we want to steal that one ;)
[18:57] <iulian> And why can't I co?
[18:58] <iulian> Heh
[18:58] <directhex> giver IS in svn?
[18:58] <iulian> Yes, it is.
[18:58] <iulian> directhex: http://svn.debian.org/wsvn/pkg-cli-apps/packages/giver/
[18:59] <directhex> well, yeah then. don't you have commit access to that folder? o_o
[18:59] <iulian> 110026(pkg-cli-apps),150026(scm_pkg-cli-apps)
[19:00] <iulian> I should.
[19:00] <directhex> well... carry on then!
[19:00]  * directhex got confused :|
[19:01] <slytherin> iulian: what is the url you are using?
[19:01] <directhex> Path: /home/directhex/Projects/pkg-cli-apps/packages/giver/trunk/debian/rules
[19:01] <directhex> Last Changed Author: iulian-guest
[19:02] <iulian> Hmm, then how can I pull that from svn?
[19:02] <slytherin> iulian: what is the url you are using?
[19:02] <directhex> URL: svn+ssh://svn.debian.org/svn/pkg-cli-apps/packages/giver/
[19:03] <directhex> use your iulian-guest alioth login
[19:03] <iulian> slytherin: ^
[19:03] <iulian> directhex: I believe I did that.
[19:03] <directhex> probably need to set it in ~/.ssh/config
[19:03] <iulian> Hmm, I will try again.
[19:03] <directhex> Host svn.debian.org
[19:03] <directhex> User directhex-guest
[19:03] <iulian> I usually use iulian-guest@svn.d.o
[19:04] <slytherin> iulian: I believe the url should be svn+ssh://svn.debian.org/pkg-cli-apps/packages/giver/
[19:06] <amikrop> Hi. When I boot with the vga=791 option, the tty resolution is set correctly, but my splash screen is messed up. Any help, please?
[19:08] <iulian> svn+ssh://iulian-guest@svn.debian.org/svn/pkg-cli-apps/packages/giver: No such file or directory
[19:08] <iulian> Am I missing something?
[19:08]  * RainCT grumbles about aptitude not accepting alternative installs (ie, "aptitude install a | b", which wouldn't do anything if either of them is installed) :P
[19:08] <directhex> iulian, odd. try just checking out svn+ssh://iulian-guest@svn.debian.org/svn/pkg-cli-apps ?
[19:13] <slytherin> directhex: I believe that /svn/pkg-cli-apps should be only /pkg-cli-apps
[19:13] <directhex> oh, should it? balls
[19:14] <iulian> directhex: Ah crap. Forgot the co part. This is the reason why it didn't work. svn is just not my preferred vcs TBH.
[19:14] <directhex> iulian, well, until alioth has a Visual SourceSafe service... :(
[19:15] <iulian> slytherin: There is no pkg-cli-apps dir in /. So it should be /svn/pkg-cli-apps.
[19:15] <iulian> Yay, he already left.
[19:16] <directhex> iulian, got there in the end? \o/
[19:16] <iulian> directhex: Why you guys don't switch to git? IIRC I talked to meebey a few months ago and he wasn't too happy about how svn works.
[19:16] <amikrop> When I boot with the vga=791 option, the tty resolution is set correctly, but my splash screen is messed up. Any help, please?
[19:17] <directhex> iulian, does alioth do git? is that recent?
[19:17] <directhex> amikrop, change the settings in /etc/usplash.conf
[19:18] <amikrop> directhex: and make them what?
[19:18] <directhex> amikrop, erm, make them match 791?
[19:18] <directhex> i think 791 is 1024x768 isn't it?
[19:19] <amikrop> directhex: currently, they are my screen's full res
[19:19] <amikrop> directhex: yes
[19:19] <amikrop> directhex: currently, they are 1920x1200
[19:19] <directhex> ah, was about to ask if it was widescreen trouble
[19:19] <amikrop> directhex: I *have* a widescreen, right?
[19:20] <iulian> directhex: No, I believe not. lrwxrwxrwx 1 root root 23 2006-10-25 12:02 /git -> /srv/git.debian.org/git
[19:20] <amikrop> directhex: ?
[19:20] <directhex> i'd love to fix usplash to cope with widescreen properly, but it's funky c, and i'm scared of just offering backseat programming advice to someone like mjg59
[19:20] <directhex> amikrop, 1920x1200 is 19:10 widescreen, yes. 24/27" tft.
[19:21] <directhex> amikrop, but 791 is a non-widescreen mode
[19:21] <amikrop> directhex: so, what mode would be good for my ttys?
[19:21] <directhex> amikrop, well, "best" would be a 1920x1200 framebuffer
[19:21] <amikrop> directhex: there is not a mode for 1920x1200
[19:22] <directhex> amikrop, not if you're reading charts from sites like linuxquestions there isn't
[19:22] <amikrop> directhex: but...?
[19:22] <directhex> amikrop, install "hwinfo", run "sudo hwinfo --framebuffer"
[19:22] <directhex> amikrop, your GPU may offer a non-standard >1024 mode
[19:22] <directhex> e.g. my laptop has 1280x800
[19:23] <amikrop> directhex: ok, it diplsayed many modes
[19:24] <amikrop> which should I choose?
[19:24] <directhex> amikrop, it displays modes in hex, e.g   Mode 0x0307: 1280x1024 (+1280), 8 bits
[19:24] <directhex> amikrop, pick the "best" mode you can find, and convert the hex mode to decimal
[19:24] <amikrop> directhex: I know, I just ran it
[19:24] <amikrop> directhex: what is the "best"?
[19:25] <directhex> amikrop, well, 1920x1200x24, if you have it
[19:25] <amikrop> The onw with the higher bits? the one with the +number in parantheses? the higher res?
[19:25] <amikrop> * one
[19:26] <jmarsden|work> amikrop: 1920x1200 with 24 bits is the one you want
[19:26] <amikrop> directhex: it is not available
[19:26] <amikrop> jmarsden: it is not available
[19:27]  * directhex smells user support rather than packaging work
[19:27] <amikrop> directhex: two "good" ones seem to be 1600x1200x16 and 1024x768x24
[19:27] <amikrop> sorry
[19:27] <directhex> amikrop, well, use one of those then.
[19:28] <amikrop> 1280x1024x24 and 1600x1200x16
[19:28] <amikrop> directhex: what is the best of these two?
[19:28] <directhex> convert the Mode to decimal and use that line in your menu.lst - e.g.   "Mode 0x0317: 1024x768 (+2048), 16 bits" might look familiar
[19:28] <directhex> amikrop, which do you care more about, the resolution or the color depth? in your consoles, this is.
[19:29] <amikrop> directhex: well, which do *you* care about most, in your consoles?
[19:30] <amikrop> directhex: so? :-)
[19:31] <directhex> amikrop, which do you want in your text console. 65,536 colours or 16,777,216 colours?
[19:31] <amikrop> directhex: It doesn't matter so much, I guess...
[19:32] <amikrop> directhex: Because it is just a console.
[19:32] <amikrop> directhex: right?
[19:32] <directhex> right. but i wasn't answering for you
[19:32] <amikrop> directhex: excuse me? you weren't answering for me? I didn't understand that...
[19:35] <directhex> amikrop, you spent 10 minutes asking which number was bigger, in a development channel
[19:35] <amikrop> directhex: Well, I am sorry.
[19:36] <directhex> amikrop, so like i said. pick the mode you want to use, convert the Mode 0x bit to decimal, use that number instead of 791, and ensure /etc/usplash.conf matches it
[19:37] <amikrop> directhex: after, $ sudo update-initramfs -u ?
[19:37] <directhex> yeah.
[19:37] <directhex> and update-grub after changing menu.lst
[19:37] <amikrop> ok, thanks, and excuse me, again
[19:47] <directhex> was i out of order? O-o
[19:50] <iulian> directhex: Is it required to add CSC=/usr/bin/csc when configuring?
[19:51] <amikrop> directhex: I put vga=884 for 1600x1200x16 but it told me that the the mode 386 or somthing was invalid (during boot) and it prompted me to choose on now. And it gave me a list with modes different than that https://wiki.ubuntu.com/FrameBuffer#grub.
[19:52] <directhex> iulian, strictly speaking, we'll let you live as long as you were already using gmcs - but we want to see the compiler overridden to be 'csc', which is our 'default c# compiler for this release' executable
[19:52] <amikrop> directhex: It gave me a list with 3xy, 3xz etc, and not 7xy, 8xz like the one above
[19:52] <amikrop> I guess its the decimal conversion part, which you told me about
[19:52] <iulian> directhex: Ah-ha
[19:52] <directhex> amikrop, then your GPU behaves funny and doesn't offer high res modes until late in the boot process (e.g. after the driver is loaded). my old geforce did that
[19:53] <directhex> iulian, but different apps use a different thing in autoconf - i need to check the giver source to see if it uses CSC or MCS or CAKE or what
[19:54] <directhex> hm, no autofoo in giver. sigh
[19:54] <amikrop> directhex: any suggestions?
[19:54] <iulian> directhex: That would be great. In the meantime I will test the package to see if it works.
[19:54] <iulian> directhex: Ah, OK.
[19:54] <directhex> iulian, looks like it takes GMCS
[19:55] <directhex> so GMCS=/usr/bin/csc
[19:55] <directhex> amikrop, well, when in doubt, back down to 791 shou;d always work
[19:55] <amikrop> directhex: but 791 is not wide screen
[19:56] <directhex> amikrop, neither is any of the modes you mentioned. and usplash doesn't work peoperly with widescreen consoles
[19:56] <amikrop> directhex: ok, then. thanks.
[19:57] <iulian> directhex: Shouldn't it be /gmcs instead of /csc?
[19:58] <directhex> iulian, currently csc is a link to gmcs.
[19:59] <directhex> iulian, upstream have talked about merging gmcs and mcs again - so we might do something make sure we can phase changes to suit us
[19:59] <directhex> iulian, the way 'python' isn't neccessarily 'python3.0'
[20:00] <iulian> OK, I will just use csc then.
[20:01] <Rinchen> Hi MOTUs!  Question... I've just been alerted to a security exposure in a MOTU packaged Universe package.  Whom do I report this too?
[20:02] <Rinchen> Bug on the source package?
[20:02] <directhex> iulian, looks like you might get the honour of being the first *app* to be transitioned :p
[20:02] <RainCT> Rinchen: Yep
[20:02] <iulian> directhex: Oh, really? Cool ;)
[20:02] <RainCT> Rinchen: there's an option to make the bug private
[20:02] <Rinchen> right... ok.
[20:03] <Rinchen> looks like it was filed
[20:03] <handschuh> Is there anybody who wants to be the second advocate on http://revu.ubuntuwire.com/details.py?package=uiflite ?
[20:03] <Rinchen> but not marked as a security vuln
[20:03] <directhex> iulian, unless you & RainCT get into some kind of exciting battle
[20:03] <Rinchen> actually, it is...
[20:03]  * Rinchen curses his LP Admin privs sometimes :-)
[20:03] <Rinchen> thanks
[20:04] <RainCT> np
[20:04] <RainCT> directhex: heh, no, I leave him the honor :)
[20:08] <directhex> the weekend's mono 2 transition work made both ars technica and boycott novell \o/
[20:08] <iulian> directhex: I see that mono-devel is still in experimental. Should I target it to experimental as well?
[20:08] <directhex> iulian, yes.
[20:09] <directhex> iulian, this is pre-work for squeeze! and jaunty, of course
[20:09] <iulian> directhex: Yeah, wondered why pbuilder failed.
[20:10] <directhex> ah. i recommend you test against jaunty in pbuilder for now
[20:10] <directhex> as mono 2.0-1 in experimental is a little broken - 2.0.1 should land later tonight
[20:10] <iulian> OK
[20:10] <directhex> (it's already in jaunty)
[20:14] <ajmitch> directhex: how many nastygrams have you got for supporting the evil mono?
[20:15] <directhex> ajmitch, to my inbox? only one. the anti-mono crowd are mostly cowards, so they just insulte me on irc & blogs
[20:16] <ajmitch> directhex, singlehandedly destroying free software ;)
[20:16] <directhex> ajmitch, not at all. meebey is the jedi master of mono on debian. it'd go nowhere without him
[20:17] <ajmitch> I know
[20:21] <amikrop> I sticked with 791. How can I set my TTYs to be colorful, now? Is it an option in ~/.bash_profile or something?
[20:21] <amikrop> directhex
[20:21] <directhex> yes.
[20:21] <amikrop> directhex: How can I find out which option it it?
[20:22] <directhex> force_color_prompt=yes
[20:22] <directhex> in bashrc
[20:22] <DRebellion> Hi, could anybody point me to a list of the possible values for the Section: field in debian/control?
[20:23] <amikrop> directhex: thanks :)
[20:29] <iulian> directhex: It's done. It built without problems. Please take a peek at http://users.alioth.debian.org/~iulian-guest/giver_diff
[20:30] <directhex> iulian, looks perfect to me, let me run it by meebey
[20:31] <iulian> directhex: OK, I will commit to svn as well.
[20:32] <slytherin> can someone please give back libxpp3-java?
[20:33] <ScottK> slytherin: Done.
[20:33] <directhex> bring it back, sing it back, bring it back, sing it back to meeeeeeeee
[20:34] <slytherin> ScottK: thanks
[20:34] <directhex> iulian, apparently your restructured rules are a bit odd (the mono 2 transition bit is fine), can you join oftc #debian-mono to speak with meebey?
[20:35] <iulian> Sure
[20:36] <|eMerzh|> if someone want to review my updated package (http://revu.ubuntuwire.com/details.py?package=sqliteman) ... please feel free to leave comments or advocacy
[20:37] <amikrop> directhex: PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ' this line displays green. how can I make it display red?
[20:37] <slytherin> |eMerzh|: There is no need to advertise the package so frequently except on revu days.
[20:38] <directhex> amikrop, i'm no expert on ANSI color codes
[20:38] <ajmitch> play with the numbers
[20:39] <fabrice_sp> Hi. I'm writing the debian/copyright file for a software that is 'GPL' (that's what there is in source files). Is it the same as GPL-2+ ?
[20:39] <amikrop> ajmitch: which numbers?
[20:39] <ajmitch> 32m & 34m
[20:39] <amikrop> directhex: at least, do you know what part is about the color?
[20:39]  * ajmitch can't remember, it's been so long
[20:40] <directhex> fabrice_sp, what does the COPYING file it comes with say?
[20:40] <ajmitch> fabrice_sp: they don't have the usual GPL header in the source?
[20:40] <fabrice_sp> COPYING says "GNU GENERAL PUBLIC LICENSE"
[20:40] <directhex> no version? seriously sounds like v1 o_o
[20:40] <fabrice_sp> yes
[20:41] <fabrice_sp> but v1 has been superseded by v2, right?
[20:41] <ajmitch> any date mentioned in COPYING?
[20:41] <fabrice_sp> Copyright (C) 1989, 1991 Free Software Foundation, Inc.
[20:41] <ajmitch> sounds like GPL 2
[20:42] <fabrice_sp> yes: i've just found that: Version 2, June 1991
[20:43] <fabrice_sp> so it's a GPL-2 only? No +?
[20:43] <fabrice_sp> my reviewer in REVU tells me about GPL-3 :-/
[20:44] <|eMerzh|> slytherin: oups...don't want to upset ....just impatient to see if it 'll we accepted....its my first package....
[20:44] <ajmitch> does the source file not have the appropriate GPL headers in comments?
[20:44] <slytherin> fabrice_sp: check if all files are under same license.
[20:44] <fabrice_sp> slytherin: That's what I'm doing
[20:45] <fabrice_sp> but the sources files only have 'Licence:     GPL'
[20:45] <slytherin> |eMerzh|: Don't worry, someone will review it eventually
[20:45] <slytherin> geser: ping
[20:45] <fabrice_sp> so COPYING licence (GPL-2) apply in that case?
[20:48] <fabrice_sp> arghh: one source file  is under wxWindows licence :-/
[20:48] <ajmitch> oh fun
[20:48] <ajmitch> copyright stuff is a hassle at best
[20:51] <fabrice_sp> ajmitch: yes :-/
[20:52] <fabrice_sp> the new format for copyright file is clearer, I think
[20:52] <fabrice_sp> so it's a bit easier
[21:00] <slytherin> ScottK: one more please - libjboss-classloader-java
[21:15] <slytherin> ScottK: ping