[12:15] <norsetto> ScottK: adding a note about the repackaged upstream source 
[12:15] <norsetto> ScottK: was also checking the upstream authoir email .....
[12:15] <norsetto> ScottK: daM, I should have left a note on that upload
[12:16] <ScottK> OK.  Not a big deal.  Do up a -2 with the corrections and bump compat and the debhelper version dependency to 5 while you're there.
[12:16] <norsetto> ScottK okki dokki, sorry about that
[12:24] <TheMuso> ScottK: If a MOTU uploads to REVU, I believe they only need one ACK, so I already uploaded it.
[12:24] <TheMuso> for a new package
[12:24] <ScottK> Ah.  Would have been nice to have archived it on REVU then...
[12:24] <ScottK> I wondered why it was still there.
[12:24] <ScottK> I guess two uploads don't hurt.
[12:24] <TheMuso> ah sorry, my fault.
[12:35] <ajmitch> given that I built a few & then realised that I needed x86
[12:35] <lifeless> use the -arch option
[12:35] <ajmitch> oh I know that now
[12:36] <ajmitch> I just didn't realise that I was building amd64 packages at the time
[12:36] <ajmitch> typical monday morning
[12:37] <lifeless> http://rafb.net/p/QGFBdY36.html
[12:37] <lifeless> thats what I use
[12:37] <lifeless> with a match pbuilder-etch-i386 script
[12:38] <opop>  hey, do the kernel sources in the repositories come pre-configured the same as they are distributed in binary?
[12:38] <lifeless> all the scripts are the same
[12:38] <ajmitch> that'll partly work
[12:38] <ajmitch> except that I need a set of build-dependencies from sid 
[12:39] <lifeless> surely thats just a pinned apt source?
[12:39] <norsetto> ScottK: I believe the cleanest would be to open a new bug report with the patch?
[12:39] <ajmitch> but for now I'm just using a chroot with debootstrap since it's simpler
[12:40] <ScottK> No need for a bug report.  Just upload it.
[12:40] <ScottK> norsetto: Actually, yet
[12:40] <ScottK> yes
[12:40] <ScottK> That's correct.
[12:40] <norsetto> ScottK: ok, thanks man, you ROCK :-)
[12:44] <RainCT> good night
[12:45] <ScottK> Good Night.
[12:54] <norsetto> ScottK: If you need me to do something else just bug me; I'll be glad to (try to) help
[12:54] <ScottK> Did you do the patch?
[12:54] <ScottK> If you uploaded it to revu, that's fine too.
[12:55] <ScottK> norsetto: ^^^
[12:55] <ScottK> Just saw the bug.
[12:55] <opop> is vesafb framebuffer under block devices in menuconfig?
[12:56] <opop> * character devices, rather?
[12:58] <opop> found it under character->graphics
[01:11] <desertc> Heya Fellahs - Got a questions for your about some directory structures, more specifically about games.  Why does it have to be that some of them Ubuntu packages go into /usr/games and some go into /usr/share/games and some go into /usr/local/games ?  Is sure does make a head weary looking in all those directories for a guy's game.
[01:12] <RAOF> desertc: If any of the ubuntu packages install something in /usr/local, that's a bug and should be filed.
[01:12] <desertc> What do you say we lasso all these packages up and wrangle 'em into one place?
[01:13] <TheMuso> desertc: Games that store stuff in /usr/share/games are doing the right thing.
[01:13] <RAOF>  /usr/games should be used differently to /usr/share/games
[01:14] <TheMuso> Generally games will have a data package, that contains all non-architecture specific data, which goes in /usr/share/games/gamename
[01:14] <desertc> That's the type of tough-talk I was hoping to hear... seems to me /usr/share was for putting files on other computers around your so-called LAN... don't reckon there's a reason to put a game for your rig in /usr/share
[01:15] <TheMuso> desertc: Not exactly. A lot of, including desktop environments use /usr/share.
[01:15] <RAOF> desertc: No, that's not what /share is about - /share is for arch-indep data and stuff.  Icons, documentation, etc.
[01:16] <desertc> Now, TheMuso, I gotta take issue with a fellah who thinks he can put a little piece of his program here, and another little piece in that directory.... I figure a fellah should stake out a little plot of land to call his own and defend it with everything he got... but not get too ambitious to take another fellah's place, too!
[01:16] <ScottK> norsetto: Uploaded.  Thanks.
[01:16] <RAOF> desertc: See the FHS - that's not how linux works :)
[01:16] <TheMuso> desertc: I think you need to have a look at the FHS standard.
[01:17] <norsetto> ScottK: thx 2 u Scott
[01:17] <RAOF> desertc: This page is the home of the Filesystem Hierarchy Standard (FHS).
[01:17] <RAOF> The current version is 2.3. It was announced on January 29, 2004.
[01:18] <RAOF> desertc: http://www.pathname.com/fhs/pub/fhs-2.3.html
[01:18] <RAOF> Gah, I really need to get that pasting habit under control.
[01:18] <desertc> Well now -- I now a little bit about the so-called scalability of enterprise computing, but we're talkin about some games here, fellahs... just some eye-candy for fun.  Do we really need to be calling in the law into this matter?  Not like we're going to take this across state-lines, or nuthin'
[01:19] <ajmitch> keeping the whole system consistent is quite useful
[01:19] <ajmitch> rather than doing things 10 different ways just because you feel like being relaxed
[01:21] <desertc> Seems to me, most of these files you are talking about are hardly a meg in size.  Not like you're going to rustle-up a whole new drive for even a hundred of those varmints!  Meanwhile, you got users - moms and pops - racing all around the farm trying to find where you hid the file, like some sort of hunt on easter day.  Now, that doesn't seem right, does it?
[01:21] <TheMuso> desertc: But the fact is, its very easy to find what package owns what file.
[01:22] <ajmitch> and that they're in standard locations
[01:22] <ajmitch> you shouldn't need to care where a package puts its sound files or levels
[01:23] <desertc> Well, shucks, A.J., you don't have to getting all steamed-up over there... I was just saying 'cause I'm throwing fits over here trying to keep my darned self organized.  With a share here, a local there, I hear there's some var and opt making a fuss on occasion, too.
[01:24] <RAOF> desertc: You don't need to keep yourself organised.  Trust apt! :)
[01:26] <desertc> Golly, RA OF, I 'spect I might be takin' your advice on this one.  I'll put my six-shot back for now and be trying my best to build the fence around what I got wit' the apt tool down at the warehouse.  I reckon it won't be too long 'till I got a handle on it all.
[01:27] <desertc> Happy Trails, partners.
[01:31] <norsetto> yawn, oh well, lets call it a day...
[01:32] <norsetto> g'night all, sleep tight and well
[01:32] <ajmitch> that was an 'interesting' visitor
[01:33] <RAOF> Indeed.
[01:35] <opop> vesafb is no longer modularized at all?  I can't even M it in the kernel config, rats.
[01:37] <DarkSun88> Hi all
[01:37] <geser> Hi DarkSun88
[01:38] <DarkSun88> Hi geser 
[01:38] <DarkSun88> Thanks for previous upload
[01:39] <geser> np
[01:39] <geser> are you going to merge wordpress 2.2.2-1 from Debian unstable?
[01:40] <DarkSun88> Yes.
[01:40] <DarkSun88> I'm building it.
[01:41] <DarkSun88> Well, works.
[01:44] <RAOF> Anyone merging deluge-torrent?
[01:51] <jrib> ScottK: hey, thanks for the comments.  I'll work on the LGPL issue.  But the lintian warning seems to have been generated from python-reverend_0.3.svn20070609 which is the older version.  The current version on revu is python-reverend_0.3.svn20070730
[01:54] <opop> i'm gonna recompile the generic kernel without vesafb support, and with nvidiafb support instead.  Is there a good reason not to do this?
[02:02] <RAOF> opop: Because you will no longer be able to file useful kernel bug reports?
[02:04] <opop> RAOF, also, because nvidiafb breaks the prop nvidia driver
[02:04] <opop> RAOF, i've abandoned it.
[02:41] <ScottK> jrib: I may have run the wrong one through lintian.
[02:41] <ScottK> I still have the old one on the hard drive.
[02:43] <Fujitsu> s/stable/1.1.9/
[02:44] <Fujitsu> Hum... To go with 1.1.5 or 1.1.9...
[03:01] <Fujitsu> StevenK: Why does it need NMUing?
[03:01] <StevenK> Because it fails to build, and has 3 RC bugs open on it. :-)
[03:01] <Fujitsu> Ah.
[03:02] <StevenK> The being a bastard bit was NMU'ing a new upstream version, which is frowned on.
[03:02] <Fujitsu> Ah, yes.
[03:04] <StevenK> Oh, THE BASTARD.
[03:04] <Fujitsu> ..?
[03:05] <StevenK> Upstream for xmovie includes libmpeg3, libsndfile1, libquicktime, libogg, libfaad, libflac, and a few others in his tarball.
[03:05] <Fujitsu> Oh, neat!
[03:06] <Fujitsu> I love it when they do that.
[03:06] <Fujitsu> So you have to coerce it into working with external versions?
[03:06] <StevenK> I knew I should have guessed that when he said on his site, "and the distributions change their libraries too fast to justify binaries anymore"
[03:06] <Fujitsu> Haha.
[03:07] <StevenK> Now I have to repack the bloody tarball after waving rm over it, and see if it will actually build.
[03:07] <Fujitsu> Or just let it rot.
[03:08] <StevenK> I'm tempted to get it removed from Ubuntu, yes.
[03:09] <Fujitsu> Or you could ask him to update it.
[03:09] <Fujitsu> He uploaded stuff a couple of weeks ago, so he's around.
[03:10] <StevenK> The Debian maintainer hasn't touched the package in over 16 months.
[03:10] <StevenK> Or any bug reports related to it.
[03:10] <Fujitsu> Hm.
[03:10] <StevenK> I note xmovie doesn't appear in popcon results ... :-)
[03:10] <Fujitsu> Heheh.
[03:13] <StevenK> wc:
[03:13] <StevenK>         cat *.C *.h | wc
[03:13] <RAOF> UUoC!
[03:14] <jmg> Euw.
[03:14] <Fujitsu> Ick.
[03:16] <StevenK> And the Makefile has a very large opinion of the included libraries. Removing it is looking better all the time.
[03:16] <bobrikcz> Hi, I am testing Ubuntu Gutsy in VMware; but to install/reinstall it every time is time consuming - did anyone consider creating "official" VMware images each time new testing release gets released?
[03:16] <Fujitsu> Won't the previous diff handle most of that, though?
[03:16] <Fujitsu> bobrikcz: Why not upgrade it?
[03:18] <StevenK> Fujitsu: Point. I like the Debian maintainer's Makefile much better.
[03:18] <bobrikcz> Fujitsu: I might mess the machine up so I can prefer reinstall, and upgrade between e.g. Feisty and Gutsy can go wrong
[03:18] <bobrikcz> Fujitsu: not to speak about people that did not set up such a machine yet ;)
[03:19] <RAOF> But we care if an upgrade from Feisty -> Gutsy goes wrong :)
[03:19] <Fujitsu> bobrikcz: Well, this isn't the right channel, at any rate.
[03:21] <bobrikcz> Fujitsu: oh, I see; I misread the channel description at #ubuntu-dev :)
[03:43] <StevenK> Right. xmovie $LATEST_UPSTREAM fails too. I am so getting this removed.
[03:44] <Fujitsu> Yay :)
[03:45] <Fujitsu> It must have been almost 2 months since the mass bug-filing.
[03:47] <StevenK> They look to be slowly filtering in.
[03:47] <Fujitsu> I see two open at the moment.
[03:47] <StevenK> There's about five to ten I've gotten NBS'd out.
[03:51] <StevenK> Fujitsu: I'd be curious to see a comparsion of how many libapache-* packages are in Debian, versus Ubuntu.
[03:53] <Fujitsu> StevenK: As far as I can tell there are no differences. 
[03:53] <RAOF> Gah!  There's something I've forgotten to fix in my xgl package:  How do you test for the existance of Makefile, and run $(MAKE) distclean only if it exists?
[03:53] <RAOF> I think the way I currently do it is wrong.
[03:53] <StevenK> RAOF: test -f Makefile && $(MAKE) distclean ?
[03:54] <RAOF> StevenK: Won't that fail (and abort the build) if Makefile doesn't exist?
[03:54] <StevenK> RAOF: test -f Makefile && $(MAKE) distclean || :
[03:54] <RAOF> Won't that always succeed? :)
[03:54] <StevenK> If you want to be that way. :-)
[03:55] <StevenK> RAOF: if [ -f Makefile ] ; then $(MAKE) distclean ; fi
[03:55] <RAOF> Aha!  looks good :)
[03:57] <StevenK> RAOF: Learn shell. :-)
[03:58] <RAOF> I kinda know shell, just not how it interacts with makefiles.
[03:59] <RAOF> (My initial attempt, which was basically the same as your "if ..." thingy didn't work.  Each line is executed in a different shell, perhaps?)
[04:06] <ScottK> Good evening everyone.
[04:07] <Fujitsu> Hi Sco	.
[04:07] <Fujitsu> Oops.
[04:07] <Fujitsu> Laaag.
[04:10] <StevenK> RAOF: Right.
[04:10] <StevenK> RAOF: If you want multiple lines, end it with \, which tells make to join them together.
[04:11] <StevenK> RAOF: if [ -f Makefile] ; then \\n $(MAKE) distclean ; \\n fi
[04:12] <RAOF> StevenK: Thanks.  You've just earned yourself a free "won't get pestered to review xgl" pass :)
[04:12] <RAOF> Everyone else: review xserver-xgl! :P
[04:26] <jmg> hey all. turbogears bugged on feisty? have to roll $ python2.4 $(which tg-admin)
[04:32] <ScottK> jmg: It's build for Python 2.4 and 2.5 both, so you shouldn't have to do that.
[04:32] <ScottK> File a bug if there isn't one already.
[04:33] <jmg> rgr\
[04:38] <jmg> ScottK: no bug reports at all for python-turbogears
[04:39] <jmg> one bug in something called loggerhead
[04:39] <ScottK> Then I'd file one.  Please explain exactly what you did to make it nor work with Python 2.5
[04:39] <jmg> am i searching right?
[04:39] <jmg> all i did was apt-get install it
[04:39] <ScottK> Did you search on just turbogears?
[04:39] <jmg> yeah
[04:39] <ScottK> OK
[04:40] <jmg> but i dont know what i might have done on this box to frell it up
[04:40] <jmg> the shebang is set wrong
[04:40] <ScottK> OK, but " turbogears bugged on feisty" isn't much of a bug report.
[04:40] <ScottK> What's it set to?
[04:40] <jmg> #!/usr/bin/python should be #!/usr/bin/env python2.4
[04:40] <jmg> correct?
[04:40] <ScottK> No,
[04:40] <RAOF> No
[04:40] <jmg> oh
[04:40] <RAOF> Env is wrong.
[04:40] <jmg> :(
[04:41] <ScottK> usr/bin/python gets you the default Python.
[04:41] <jmg> why?
[04:41] <ScottK> Which in Feisty is 2.5
[04:41] <jmg> why is env wrong?
[04:41] <ScottK> Because the results aren't always consistent with what the packaging system tries to do.
[04:41] <RAOF> 1) /usr/bin/env python will show up as "python" in top, etc, not your script name.
[04:41] <jmg> ok
[04:41] <RAOF> 2) what ScottK said
[04:42] <ScottK> It's in the Debian Python policy, but I don't recall exactly where.
[04:42] <jmg> i suspect this only affects tg-admin
[04:42] <ScottK> jmg: Just give us exact test steps including, if needed, a reduced test case to run to make if fail.
[04:43] <ScottK> I know nothing about Turbogears, but I'm likely to be the one trying to fix it.
[04:43] <ajmitch> heh
[04:44] <ajmitch> on gutsy, running 'tg-admin' alone gives me the expected result
[04:45] <jmg> im just checking the rest of the turbogears files
[04:46] <ajmitch> hello Burgundavia 
[04:46] <Burgundavia> hey ajmitch
[04:46] <jmg> hmm
[04:47] <jmg> is there a better way to make find operate on a given set of files then find $(cat list)?
[04:47] <ScottK> jmg: You didn't find a bug because it's already been fixed: Turbogears (1.0.2.2-0ubuntu1) Python 2.5 compatible (LP: #84145)
[04:47] <ScottK> That's in Gutsy.
[04:48] <ScottK> It looks like the fact that turbogears is built for Feisty for Python 2.5 is wrong.
[04:48] <jmg> ScottK: can you mark it as relevant for feisty or must i file a new bug?
[04:49] <ScottK> I can, but can't you work around this?
[04:49] <jmg> I can, but shouldnt the bug get fixed?
[04:49] <jmg> s/ can,/already have,/
[04:49] <jmg> s/Ia/I a/
[04:49] <ScottK> If you can work around it, it's not a crash, and it's doesn't cause data loss, it's not going to be SRU worthy.
[04:50] <jmg> doesnt faliure to start at all count as 'grave' in BTS?
[04:50] <ScottK> The good news is that you can, since it's a new version with new features, ask for a backport.
[04:50] <jmg> Ooo.
[04:50] <ScottK> But you can start it with python2.4, right?
[04:50] <jmg> Yeah.
[04:50] <ScottK> So, not grave.
[04:50] <jmg> I have to use magick to make it start though.
[04:51] <jmg> I cant just invoke the script directly.
[04:51] <jmg> Well, I can, now that i've patched it.
[04:51] <ScottK> File a bug in feisty-backports, build and test the gutsy package, and then ping me: https://wiki.ubuntu.com/BackportRequestProcess
[04:52] <jmg> If I wind up having to deploy this to more than a trivial number of  feisty boxes, I'll raise and patch the bug myself.
[04:52] <jmg> OK.
[04:52] <ScottK> Then you won't have to.  You'll just have the new version.
[04:53] <jmg> my coworker is LOLing at me because I didnt just do "easy_install turbogears" like he said.
[04:53] <ScottK> You're doing the right thing.
[04:53] <jmg> What's the backport-o-matic tool?
[04:53] <ScottK> It's called prevu.
[04:54] <ScottK> If you have a pbuilder set for Feisty you can just use that.
[04:54] <jmg> Cool, i'll give it a go.
[04:55] <jmg> does sudo prevu-init set up the pbuilder for me?
[04:55] <jmg> it's doing stuff.
[04:56] <ScottK> Dunno.
[04:56] <ScottK> I use real packaging tools, not jdong's crack versions ;-)
[04:56] <jmg> i see prevu is pretty ghetto.
[04:57] <ScottK> Turbogears is a DPMT package, so maybe I can invest a little time getting Debian and Ubuntu back in sync.
[04:59] <jmg> 5:00 < ScottK> I use real packaging tools, not jdong's crack versions ;-)
[05:00] <jmg> good thing he's not here to see that
[05:00] <ScottK> Nah, he'd laugh.
[05:00] <jmg> he might kamehameha you
[05:00] <ScottK> If not, he can fire me from ubuntu-backporters and approve all the crack himself.
[05:05] <jmg> heh
[05:08] <jmg> i suppose specifying /usr/bin/python on the shebang is a policy violation rather than a grave bug.
[05:08] <ScottK> He's probably on here on one nick or another anyway.
[05:08] <RAOF> jmg: No, that *is* policy, isn't it?
[05:08] <ScottK> Specifying  /usr/bin/python is correct.
[05:08] <jmg> so its up to the maintainer to make sure the script works with whatever the system interpreter is?
[05:09] <ScottK> It's up to the maintainer to package it correctly.  Python versions are controlled through the packaging system, not by shebang naming in Debian.
[05:09] <Fujitsu> The point of it is to ensure it runs with the packaged Python, rather than something in /usr/local or so.
[05:09] <jmg> Python scripts that only work with a specific Python version must explicitly use the versioned interpreter name (pythonX.Y).
[05:16] <jmg> ok, prevu needs additional smarts to grok gutsy sources
[05:16] <Hobbsee> jm
[05:16] <Hobbsee> jmg: why are you using prevu?
[05:16] <Fujitsu> jmg: It's probably not backportable, then.
[05:17] <jmg> Hobbsee: laziness?
[05:17] <ajmitch> hello Hobbsee 
[05:17] <RAOF> Hobbsee!!!  Review xserver-xgl! :)
[05:18] <jmg> DIST=gutsy prevu turbogears, and it fetches from feisty
[05:18] <Fujitsu> jmg: Why're you trying to build in gutsy? You want to build in feisty.h
[05:18] <RAOF> StevenK: Aww, OK.  If I must :(
[05:18] <Hobbsee> hehe
[05:18] <ScottK> Heya Hobbsee
[05:18] <Hobbsee> RAOF: i'm at uni.   the connection would fall over
[05:18] <Hobbsee> hiya ScottK 
[05:18] <jmg> Fujitsu: in that case, how do i make it download the gutsy version?
[05:18] <Hobbsee> hi ajmitch 
[05:18] <ajmitch> StevenK: we could just avoid reviewing it & just upload it anyway
[05:19] <Fujitsu> jmg: Don't use prevu, I guess.
[05:19] <Fujitsu> Or modify it to accept a local file.
[05:19] <ajmitch> it's crack anyway, I'm sure it can't be made any worse
[05:19] <StevenK> ajmitch: It could be packaged by Kmos ...
[05:19] <Hobbsee> ajmitch: now, if it were to auto-install automatix as well....
[05:19] <StevenK> I'm fairly sure that would make it worse.
[05:20] <Fujitsu> Die die die die die.\
[05:20] <Fujitsu> Yay, finally!
[05:20] <jmg> it should wget -o - http://blah/automatix.py | python
[05:20] <ajmitch> Hobbsee: sure, I think it'd be sane to kill -9 -1 in the preinst
[05:20] <Fujitsu> Damn.
[05:21] <jmg> excellent, prevu is smartened.
[05:21] <Hobbsee> ajmitch: heh
[05:21] <Fujitsu> Has there been a response from the Automatix team yet?
[05:22] <jmg> ScottK: Could not satisf build-dependency
[05:22] <elkbuntu> someone mentioned it on their forums, but no reply to it yet
[05:23] <ScottK> jmg: Which?
[05:23] <Fujitsu> jmg: Which? python-support?
[05:23] <jmg> python-support >= 0.6.4
[05:23] <Fujitsu> Hahha.
[05:23] <ScottK> Your screwed then.
[05:23] <ScottK> Can't backport it officially.
[05:23] <ScottK> Sorry.
[05:23] <jmg> you're
[05:23] <ScottK> Yeah.  That
[05:23] <jmg> *sniff*
[05:24] <elkbuntu> Fujitsu, im still waiting for you know who to say mjg59 has 'no technical merit'. 
[05:24] <ScottK> Backporting major tools like python-support is too crackish even for jdong.
[05:24] <ajmitch> elkbuntu: he's just elitist
[05:24] <jmg> alright
[05:24] <Fujitsu> elkbuntu: Heh, yes.
[05:24] <Fujitsu> ajmitch: Ye, Automatix is great.
[05:24] <ajmitch> Fujitsu: it Works For Me
[05:25] <jmg> you made me do this
[05:25] <ScottK> All the backports breakage we've had recently is stuff done by core-devs.
[05:26] <ajmitch> evil core devs
[05:26] <jmg> Bastards!
[05:27] <ScottK> Well the scary ones are the archive admins because they can and do backport stuff without any documentation the rest of us can see.
[05:27] <elkbuntu> "Turns out that the deb file on my personal hosting had been incorporated into Automatix without anyone asking me and burnt up several gigabytes of bandwidth in a couple of weeks(!)"
[05:27] <Fujitsu> <3 secret documentation
[05:27] <Fujitsu> elkbuntu: Where's this?
[05:27] <elkbuntu> ubuntuforums
[05:27] <jmg> elkbuntu: baaaa
[05:27] <elkbuntu> http://ubuntuforums.org/showpost.php?p=3133201&postcount=28
[05:28] <ajmitch> not as good as the skull wallpaper
[05:29] <jmg> ok
[05:29] <ajmitch> "let's find as many crack repositories as we can & give them to people!"
[05:29] <jmg> so
[05:29] <Fujitsu> Mhm.
[05:29] <elkbuntu> Fujitsu, with jbj?
[05:29] <jmg> what's going to happen
[05:29] <jmg> if i install this python-support_0.6.4ubuntu1~7.04prevu1_all.deb
[05:29] <Fujitsu> elkbuntu: jbj wasn't involved, AFAICR.
[05:29] <ajmitch> probably nothing interesting
[05:29] <Fujitsu> It was in #ubuntu-devel.
[05:30] <elkbuntu> Fujitsu, i misread, sorry
[05:30] <ajmitch> python-support should be compatible with previous versions of itself, given its purpose
[05:30] <Fujitsu> I don't think it should cause any issues, but you never can tell.
[05:30] <elkbuntu> Fujitsu, i thought you were referring to where jbj had this 'great' idea of a repo of every piece of crap any ubuntu dev wannabe can put into a package
[05:30] <Fujitsu> Ah, no.
[05:31] <ajmitch> elkbuntu: oh you mean PPAs?
[05:31] <jmg> well i have a snapshot just in case it does break stuff
[05:31] <Fujitsu> ajmitch: Yeah, pretty much.
[05:31] <ajmitch> Fujitsu: at least it requires source uploads
[05:32] <ajmitch> so no checkinstall 
[05:32] <jmg> haha
[05:32] <jmg> Fujitsu: you cant possibly kick them hard enough
[05:32] <Fujitsu> ajmitch: True...
[05:33] <Fujitsu> We might even be able to convince Canonical to remove evil things.
[05:33] <elkbuntu> ajmitch, it starts here: https://lists.ubuntu.com/archives/sounder/2007-February/010020.html
[05:33] <ajmitch> Fujitsu: unlikely, unless it's not legally redistributable
[05:34] <ajmitch> elkbuntu: oh that thread
[05:34] <Fujitsu> My SSH connection keeps dieing.
[05:34] <ajmitch> he's had some interesting ideas
[05:34] <Fujitsu> And it's not a problem in the network at either end.
[05:34] <elkbuntu> ajmitch, yeah. i misread what fujitsu originally said, and thought he meant that
[05:35] <Fujitsu> elkbuntu: I think I stopped reading sounder around then.
[05:35] <ajmitch> let's use ajax in the desktop!
[05:35] <elkbuntu> i dont blame you
[05:35] <Fujitsu> ajmitch: Yesplease.
[05:35] <jmg> hmm
[05:36] <elkbuntu> Fujitsu, karl had already stopped at that point, usually refusing to even view the archives, until that thread
[05:36] <ajmitch> https://lists.ubuntu.com/archives/ubuntu-devel/2006-November/022294.html for the reference
[05:36] <Fujitsu> I think I have my old account subscribed, but I haven't checked anything bar the INBOX of that in months.
[05:37] <Fujitsu> ajmitch: I made a point of forgetting about that.
[05:38] <Fujitsu> jbj is a great asset.
[05:38] <ajmitch> elkbuntu: sorry
[05:38] <elkbuntu> ajmitch, ;)
[05:39] <elkbuntu> i sometimes get to the point where i think the kid cant flabbergast me any longer, and he goes and achieves it
[05:39] <ajmitch> heh
[05:39] <Fujitsu> https://lists.ubuntu.com/archives/sounder/2007-February/010030.html
[05:39] <Fujitsu> What the &@*#?
[05:40] <ajmitch> you know what they say about something being foolproof
[05:40] <elkbuntu> ajmitch, the problem is when living fools somehow manage to evolve in a negative way
[05:41] <Fujitsu> Heh.
[05:41] <elkbuntu> Fujitsu, tbh, i quite liked my response to him :)
[05:44] <jmg> who is that kid?
[05:44] <jmg> is he a plant?
[05:45] <elkbuntu> jmg, there are plants in the world with more intelligence
[05:45] <jmg> not that kind of plant.
[05:45] <elkbuntu> i know. it just sounded right
[05:46] <elkbuntu> jmg, i dont think he's a plant though, one of the first emails from him i remember was to sounder, along the lines of 'nobody likes me :( :( why?! :( :('
[05:46] <jmg> maybe he's just 12
[05:47] <jmg> or younger
[05:47] <elkbuntu> no, he's older than that
[05:47] <elkbuntu> i think he mentioned uni once
[05:47] <jmg> gmailing from some internet cafe in the shanty towns outside sao paulo
[05:48] <elkbuntu> but anyway as I subscribe to the theory of intellectual osmosis, i will now distance myself from all discussion of this individual
[05:48] <Fujitsu> elkbuntu: Bwahah.
[05:48] <ajmitch> no, he does show some intelligence & far too much misdirected enthusiasm
[05:49] <Fujitsu> Oh, shiny:
[05:49] <Fujitsu> http://www.getautomatix.com/wiki/index.php?title=Automatix2_Server
[05:50] <StevenK> *TWITCH*
[05:50] <Fujitsu> A bit.
[05:50] <Hobbsee> wow...
[05:50] <Hobbsee> even webmin
[05:50] <elkbuntu> ...
[05:50] <jmg> oh man
[05:51] <jmg> now with TUI!
[05:51] <jmg> mmm tui
[05:51] <StevenK> *bloody* webmin
[05:51] <white> don't make webmin coming back :/
[05:51] <Fujitsu> white: Mhm.
[05:51] <Hobbsee> white: it's inside automatix.  anyone using automatix cant file bugs via apport
[05:51] <Fujitsu> Hobbsee: Oh, they can't? Nice.
[05:51] <white> !info webmin gutsy
[05:51] <Hobbsee> Fujitsu: yep
[05:51] <ubotu> Package webmin does not exist in gutsy
[05:52] <Hobbsee> white: long removed. duh
[05:52] <Fujitsu> But this is for Debian.
[05:52] <white> good
[05:52] <Fujitsu> We haven't had in for ages.
[05:52] <StevenK> Neither has Debian.
[05:52] <jmg> openfire?!
[05:52] <Hobbsee> Fujitsu: pitti did it a month or so ago, i think
[05:52] <elkbuntu> white, webmin hasnt existed in repos since dapper afaik
[05:52] <nixternal> anyone remember the name of the app that crimsun was working on that had a qt3, qt4, gtk, and what not front-end for asoundconf?
[05:52] <white> elkbuntu: since sarge, yes
[05:52] <elkbuntu> white, i speak ubuntu, not debian :
[05:52] <StevenK> webmin was removed in Dapper.
[05:52] <Hobbsee>   * Add general-hooks/automatix.py: Refuse to send problem reports if
[05:52] <Hobbsee>     automatix is installed.
[05:53] <Hobbsee> apport (0.92) gutsy; urgency=low
[05:53] <Fujitsu> :D
[05:53] <StevenK> It was last published in Breezy.
[05:53] <elkbuntu> yep
[05:53] <white> !info cacti gutsy
[05:53] <ubotu> cacti: Frontend to rrdtool for monitoring systems and services. In component universe, is extra. Version 0.8.6j-1 (gutsy), package size 936 kB, installed size 3612 kB
[05:53] <Fujitsu> So we no longer support it at all. Good, good.
[05:53] <white> elkbuntu: you want to sync cacti from sid :)
[05:54] <white> !info egroupware gutsy
[05:54] <ubotu> egroupware: web-based groupware suite. In component universe, is optional. Version 1.2.106-2.dfsg-3 (gutsy), package size 6 kB, installed size 40 kB
[05:54] <jmg> i like this
[05:54] <white> elkbuntu: same about egroupware
[05:54] <jmg> Winbind - resolves hostnames
[05:54] <Fujitsu> !info cacti sid
[05:54] <ubotu> cacti: Frontend to rrdtool for monitoring systems and services. In component main, is extra. Version 0.8.6j-1.1 (sid), package size 941 kB, installed size 3612 kB
[05:54] <Fujitsu> !info egroupware sid
[05:54] <ubotu> egroupware: web-based groupware suite. In component main, is optional. Version 1.2.107-2.dfsg-1 (sid), package size 6 kB, installed size 40 kB
[05:55] <white> Fujitsu: don't you trust your communication device?
[05:55] <Fujitsu> ajmitch: Don't you maintain egroupware?
[05:55] <ajmitch> Fujitsu: no
[05:55] <white> Fujitsu: petere does
[05:55] <Fujitsu> ajmitch: Hm... I thought you did for some reasons.
[05:55] <Fujitsu> -s
[05:55] <ajmitch> jmg: tui is crap
[05:56] <ajmitch> hey jsgotangco 
[05:57] <jsgotangco> hi
[05:57] <jmg> ajmitch: you're crap.
[05:57] <Hobbsee> hi spam
[05:57] <Fujitsu> white: Bug #130434, #130350
[05:57] <ubotu> Launchpad bug 130434 in egroupware "[Sync request]  Sync egroupware (1.2.107-2.dfsg-1) from Debian unstable (main)" [Low,Confirmed]  https://launchpad.net/bugs/130434
[05:57] <ubotu> Launchpad bug 130350 in cacti "Please sync cacti (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/130350
[05:58] <white> Fujitsu: nice, I am just forwarding all sec-related stuff here :)
[05:58] <ajmitch> jmg: that's really helpful
[05:58] <jmg> ajmitch: so's insulting beer
[05:59] <ajmitch> it's crap beer that students drink
[05:59] <white> Hobbsee: enjoy
[05:59] <jmg> you're crap beer that students drink
[05:59] <Hobbsee> i'd prefer to go home :P
[06:00] <ajmitch> it's like calling fosters or budweiser 'beer'
[06:00] <jmg> all right
[06:10] <white> !info kdegraphics gutsy
[06:10] <ubotu> kdegraphics: graphics apps from the official KDE release. In component universe, is optional. Version 4:3.5.7-1ubuntu3 (gutsy), package size 22 kB, installed size 64 kB
[06:10] <white> that is another candidate
[06:10] <white> !info koffiice gutsy
[06:10] <ubotu> Package koffiice does not exist in gutsy
[06:10] <white> !info koffice gutsy
[06:10] <ubotu> koffice: KDE Office Suite. In component main, is optional. Version 1:1.6.3-0ubuntu3 (gutsy), package size 25 kB, installed size 76 kB
[06:11] <LaserJock> ajmitch: you around?
[06:11] <white> and koffice
[06:11] <ajmitch> LaserJock: somewhat
[06:11] <LaserJock> ajmitch: it's generally considered bad form to hijack somebody's package in Debian isn't it?
[06:11] <white> LaserJock: yes
[06:11] <ajmitch> LaserJock: generally, yes
[06:11] <ajmitch> why?
[06:12] <white> LaserJock: what are you looking at?
[06:12] <LaserJock> well, a guy I know just sent debian-mentors a RFS for a new upstream release for my package
[06:12] <ScottK> It just occured to me to wonder if Michael Dell has read the Automatix report ...
[06:13] <white> LaserJock: which package?
[06:13] <LaserJock> it seemed, slightly ... bad form?
[06:13] <ajmitch> LaserJock: probably just someone not knowing the procedures - a sponsor should check that & tell him that it's bad
[06:13] <LaserJock> white: gausssum
[06:13] <ajmitch> I prefer to assume ignorance rather than malice :)
[06:13] <white> hmm did not arrive here yet
[06:13] <LaserJock> I'd like to move the package to team maintained
[06:13] <LaserJock> but he keeps doing stuff like that
[06:13] <white> LaserJock: can you write that in an answer to the list?
[06:14] <LaserJock> he NMU'd the package a while back
[06:14] <white> and yes he should have asked you beforehand
[06:14] <RAOF> nixternal: The answer to your question as "asoundconf-gtk", etc.  I didn't see anyone else reply.
[06:15] <pschulz01> Greetings.. how do I create a 'debug or developers' package the same time I build a 'user' package?
[06:16] <pschulz01> The rules file has a 'make' and a 'make install' target, but I would like to do these separeatly (with a make clean in between) for each of the <package> and <package>-dev.
[06:16] <pschulz01> or <package>-debug
[06:17] <StevenK> Damn it doko, stop uploading gc{c,j}-4.2!
[06:17] <LaserJock> white: my guess is maybe the email is in moderation, I'm not subscribed to debian-mentors anymore either
[06:17] <ajmitch> pschulz01: any reason to build multiple times?
[06:17] <LaserJock> maybe I'll reply to him privately first
[06:19] <pschulz01> ajmitch: Libraries - with and without debug symbols, 
[06:19] <ajmitch> pschulz01: man dh_strip
[06:19] <pschulz01> ajmitch: .. or should the policy be.. build everything and then split things out in packages as required?
[06:20] <RAOF> pschulz01: Generally, packages will create all their binaries with a single run, then use dh_install & dh_strip to move the files to the right place and strip the debug symbols (into a dbgsym package)
[06:22] <LaserJock> grrr, that sneaky ...
[06:22] <pschulz01> ajmitch: RAOF I am (partly) asking the question on behalf of someone else.. 
[06:22] <LaserJock> his NMU added himself as Uploader:
[06:22] <LaserJock> so now he's listed as co-maintainer
 Greetings.. how do I create a 'debug or developers' package the same time I build a 'user' package?
 The rules file has a 'make' and a 'make install' target, but I would like to do these separeatly (with a make clean in between) for each of the <package> and <package>-dev.
 or <package>-debug
[06:23] <Fujitsu> LaserJock: Oh, lovely.
[06:23] <pschulz01> mithro: Was that what you were after?
[06:23] <ajmitch> pschulz01: sorry, got called away
 pschulz01: Generally, packages will create all their binaries with a single run, then use dh_install & dh_strip to move the files to the right place and strip the debug symbols (into a dbgsym package)
[06:23] <LaserJock> Fujitsu: it's a little irritating, is what it is
[06:24] <ajmitch> as RAOF said
[06:24] <Fujitsu> Sneaky, irritating, and most impolite.
[06:24] <RAOF> pschulz01: Um, what are you doing?  I saw your question, *and* my response to it :)
[06:24] <pschulz01> RAOF: (sorry) just repeating for mithro.
[06:24] <mithro> pschulz01: yes, kind of
[06:25] <LaserJock> Fujitsu: I suppose I could have a new version uploaded with him removed ;-)
[06:25] <Fujitsu> LaserJock: Has his already been uploaded?
[06:25] <pschulz01> mithro: Is it possible to build everything in one 'make'?
[06:25] <ajmitch> pschulz01: it can even be done simply with cdbs
[06:25] <LaserJock> Fujitsu: yes
[06:25] <Fujitsu> ... why!?
[06:25] <Fujitsu> Shouldn't a sponsor see that it's wrong?
[06:25] <ajmitch> LaserJock: give me a source package, I'll upload a new one for you after work
[06:26] <LaserJock> Fujitsu: well, we are in a team together
[06:26] <LaserJock> and so I think our sponsor kinda overlooked it or something
[06:26] <mithro> pschulz01: it's a "python" application, you don't need to build binaries, you just run "python setup.py install --prefix=<blah>"
[06:26] <LaserJock> but I'm still Maintainer:
[06:26] <LaserJock> so it would have been nice to at least let me know
[06:26] <ajmitch> LaserJock: so it's unofficially team-maintained?
[06:26] <pschulz01> mithro: What's the difference between the 'developer' and the 'install'
[06:26] <LaserJock> ajmitch: yes
[06:26] <pschulz01> mithro: versions
[06:27] <LaserJock> ajmitch: long story is, I took over the ITP from him because he couldn't get it done, once I got it in he's been all over it
[06:27] <white> LaserJock: well, he did a few things in the past (according to changelog) so it might be hard to see for a sponsor
[06:27] <mithro> pschulz01: I think you are confused, there is a "stable" and a "development" version - which come from totally different source tarballs
[06:27] <LaserJock> I was going to move Maintainer: to the team once we figured out what we wanted to do
[06:27] <ajmitch> LaserJock: I love debian politics
[06:28] <LaserJock> but now I'm a little ... irritated
[06:28] <white> if the other versions got uploaded
[06:28] <ajmitch> mithro: right, so the question as asked earlier can be ignored, and you want 2 source packages
[06:28] <white> !info gausssum sid
[06:28] <ubotu> gausssum: parse and display Gaussian, GAMESS, and etc's output. In component main, is optional. Version 2.1.0-1 (sid), package size 186 kB, installed size 652 kB
[06:28] <pschulz01> ajmitch: RAOF Sorry.. my misunderstanding.. we return you to your regular broadcast.
[06:28] <ajmitch> mithro: though having it that way is a bit strange on the part of upstream
[06:28] <LaserJock> white: the sponsor is in our team, it *should* have been sort of ok
[06:28] <white> LaserJock: then he already uploaded version on his own (or merged changelog entries, which is evil)
[06:29] <pschulz01> ajmitch: Although I did learn something.
[06:29] <LaserJock> white: yes, he had a NMU that set himself as Uploader: and now wants a sponsor to upload a new upstream version
[06:29] <white> WTF?
[06:30] <white> 2.0.5-1~dev was not marked as a NMU
[06:30] <LaserJock> he emailed our team list a few days ago saying the new upstream release was ready
[06:30] <LaserJock> but hasn't really given our sponsor time to get too it
[06:30] <LaserJock> so I'm not sure why debian-mentors was involved
[06:30] <white> LaserJock: are you saying that he uploaded a NMU, which he did not indicate as one?
[06:31] <white> LaserJock: when i look into the debian/changelog, i see this version upload 2.0.5-1~dev
[06:31] <white> and it just says new upstream release
[06:31] <white> so i assume that he already did a MU by himself (via sponsor)
[06:31] <mithro> how does one handle the fact that they are both the same "program", just different branches?
[06:32] <LaserJock> white: if you look at http://packages.qa.debian.org/g/gausssum/news/20070701T231702Z.html only the last one was uploaded
[06:33] <LaserJock> so he made the Uploader change in a changelog entry before
[06:34] <white> WTF
[06:34] <LaserJock> but it wasn't uploaded until gausssum (2.1.0-1)
[06:34] <white> well i would expect a sponsor to pick it up though
[06:34] <LaserJock> yes, well, the sponsor is the lead for our team and LI is in the team
[06:35] <LaserJock> and has been working on the package
[06:35] <white> so the lead of your team made him an uploader? or who sponsored it?
[06:35] <white> <- confused
[06:35] <LaserJock> the team lead sponsored it
[06:35] <white> well then i feel it is somehow ok
[06:36] <white> (although the changelog entries should have been merged into one)
[06:36] <LaserJock> well, it was until LI decides to do a RFS on debian-mentors for a package he never asked me to be Uploader on ;-)
[06:36] <white> LaserJock: well, but the lead of your team agreed on him as being uploader and overruled you or?
[06:37] <xtknight> i'm trying to fix Bug 130031.  gutsy has all the dependencies listed on striim's site.  what's the next step?
[06:37] <ubotu> Launchpad bug 130031 in Ubuntu "[needs-packaging]  Striim" [Wishlist,New]  https://launchpad.net/bugs/130031
[06:37] <LaserJock> I think he overlooked it, or it wasn't a big deal
[06:37] <LaserJock> I wouldn't have minded either, except for this latest thing
[06:37] <xtknight> (the striim source tarball has no debian directory)
[06:37] <LaserJock> it's irritating to me to have him RFS on debian-mentors when we already have a sponsor and he didn't even ask before hand
[06:38] <white> i still don't get the whole thing
[06:38] <RAOF> xtknight: dh_make and friends?
[06:38] <white> LaserJock: you are listed as maintainer, so it is *only* your call
[06:38] <RAOF> xtknight: Looks like that's ready to be hit with the packaging guide.
[06:38] <xtknight> RAOF, ahh i see that
[06:38] <xtknight> RAOF, wish me luck ;)
[06:39] <RAOF> xtknight: Good luck :P
[06:41] <xtknight> well what would a driver manager even do?
[06:41] <xtknight> i suppose you could change drivers, but that sounds like it's interfering with the kernel a bit
[06:42] <white> LaserJock: i wrote an answer and asked him on-list
[06:42] <RAOF> xtknight: I don't know.  I really don't know what the people of that thread are thinking.
[06:42] <RAOF> xtknight: I am intrigued, though :)
[06:42] <LaserJock> white: do you see my PM?
[06:42] <xtknight> RAOF,  in windows that's just the way they do things.  they d/l a driver in a zip, right click their device and select the driver thru an install cmd.  but on ubuntu everything is in command line wrt drivers.  besides all instructions on the web are command line.
[06:42] <xtknight> so it doesnt make much sense to me
[06:42] <xtknight> now an NDISwrapper manager, maybe
[06:43] <xtknight> a restricted drivers-like interface for that..
[06:43] <xtknight> besides the fact everyone hates ndiswrapper, it allows a user to actually use his network card, soo... ;)
[06:43] <RAOF> Or even just extending restricted manager to handle that, like it does fwcutter.
[06:43] <xtknight> ah i didn't even know fwcutter had a frontend
[06:44] <RAOF> Restricted manager is a frontend for it now, I think.
[06:44] <xtknight> i was working on something that would detect device compatibility between windows and linux, but i sort of lost interest in it.  there's not much point
[06:44] <RAOF> Not a bad idea.
[06:45] <joejaxx> ajmitch: may i pm you?
[06:45] <xtknight> besides this, stuff like ndiswrapper support couldnt be detected reliably.  including device IDs for proprietary drivers could be a pain
[06:46] <ajmitch> joejaxx: if you're bored, sure
[06:46] <xtknight> if they want to know of driver support, all they have to do is boot up the livecd honesly
[07:01] <LaserJock> ajmitch: is it ok to umm, clean up a changelog after it's already been uploaded?
[07:02] <LaserJock> this package has a few intermediate changelog entries that never actually got uploaded, it's a bit confusing
[07:02] <Fujitsu> Playing with previous entries is generally regarded as a Bad Thing.
[07:02] <LaserJock> alright, that's sort of what I thought :/
[07:08] <LaserJock> weird
[07:08] <LaserJock> he's even got an changelog entry for an identical version to one of mine
[07:09] <Fujitsu> Is the changelog of his new version radically different from the previous one?
[07:09] <LaserJock> no
[07:09] <LaserJock> the problem is that the problem changelog is from the previous upload
[07:10] <LaserJock> Fujitsu: check out http://packages.debian.org/changelogs/pool/main/g/gausssum/current/changelog
[07:10] <xtknight> do contributers count as authors?
[07:10] <xtknight> in a debian/copyright file
[07:11] <LaserJock> Fujitsu: 2.0.4-1 (LI's version) and 2.0.5-1~dev were never upload
[07:11] <LaserJock> Fujitsu: but I *did* upload a 2.0.4-1
[07:12] <LaserJock> what a mess
[07:12] <Fujitsu> Oh, ew.
[07:13] <Fujitsu> That ~dev should be UNRELEASED, and they should really be in order... and sponsors should check that.
[07:13] <RAOF> xtknight: It doesn't hurt to add them, and I think you should.
[07:13] <xtknight> RAOF, probably not translators though, or those also?
[07:13] <LaserJock> and see, his 2.0.4-1 changelog has him added as Uploader, but another person in our team who isn't the maintainer ;-)
[07:13] <LaserJock> s/but/by/
[07:14] <Fujitsu> Yeah, that's wrong.
[07:14] <RAOF> xtknight: AFAIK the general principle is "better safe than sorry".  It's less effort to just list everyone than it is to get rejected by a reviewer, or an archive admin.
[07:14] <Fujitsu> It may be sort of team maintained, but a team isn't set as the maintainer.
[07:15] <LaserJock> Fujitsu: no, we were waiting until we figured out exactly what we wanted to do
[07:16] <LaserJock> but now ... I'm not sure how it's going to work out
[07:16] <ScottK> xtknight: It is absoutely essential that all licenses in the package be listed in debian/copyright.  Minor contributors need not be.  Minor is a squishy concept, so better safe than sorry.
[07:16] <LaserJock> I kinda need to be able to trust my teammates, you know
[07:16] <Fujitsu> LaserJock: Yeah, just a bit.
[07:16] <Fujitsu> They should at least talk to you and not hijack things.
[07:20] <LaserJock> what the heck
[07:20] <LaserJock> I guess I should've paid more attention to what they were doing
[07:21] <LaserJock> they moved install manpages and menu to <package>.*
[07:21] <LaserJock> but there's only one binary package so that just makes debian/ look cluttered
[07:22] <Fujitsu> That's really not NMU material.
[07:22] <LaserJock> it wasn't *meant* as a NMU
[07:22] <Fujitsu> But it was.
[07:22] <Fujitsu> But it w/win 11
[07:22] <Fujitsu> *was
[07:22] <LaserJock> it was meant as a hijack, IMO, although that's maybe a bit harsh
[07:22] <Fujitsu> True.
[07:24] <Q-FUNK> goooooooooooooooooooooooooood mooooooooooooooorning MOTU land!
[07:24] <LaserJock> hello to you too Q-FUNK 
[07:25] <ScottK> On that note, good night all.
[07:25] <Q-FUNK> 'night ScottK
[07:27] <LaserJock> ajmitch: are you available
[07:28] <ajmitch> soon, just finishing stuff at work
[07:28] <LaserJock> I need to head to bed, if I send you a package can you upload it for me?
[07:33] <ajmitch> LaserJock: ok
[07:33] <ajmitch> time to walk home, back later
[07:34] <LaserJock> grr
[07:34] <LaserJock> they change my python-central to python-support
[07:34] <LaserJock> for goodness sakes
[07:34] <Fujitsu> Fun fun fun.
[07:36] <Fujitsu> Yay, I'm up to 6th in the AM-assignment queue.
[08:05] <afflux> g'morning
[08:05] <afflux> could some motu please archive http://revu.tauware.de/details.py?upid=6283 ? thanks
[10:52] <coNP> May I ask some core-dev to sponsor Hungarian spell checker magyarispell (http://revu.tauware.de/details.py?upid=6332)?
[12:57] <Q-FUNK> how do I unsubscribe an Also Affects that was invalidated?  I keep on getting copies of whatever is added to the bug.
[01:04] <Fujitsu> Q-FUNK: You complain to LP people to implement a feature to delete it, or reassign the task to some junk project.
[01:05] <Q-FUNK> ah
[01:08] <Amaranth> so that's why wow-pro gets so many bugs :)
[01:10] <Fujitsu> Amaranth: ?
[01:10] <Amaranth> " reassign the task to some junk project"
[01:17] <geser> ScottK: the turbogears patch in the Ubuntu package is filed as Debian bug #433192
[01:17] <ubotu> Debian bug 433192 in python-turbogears "python-turbogears: Wrong imports for ElementTree if running with python2.5" [Normal,Open]  http://bugs.debian.org/433192
[01:18] <geser> it should be obsolete with the new upstream version
[01:19] <geser> I've filed a wishlist bug for it already (Debian bug #434443)
[01:19] <ubotu> Debian bug 434443 in python-turbogears "python-turbogears: New upstream version: turbogears 1.0.3.2" [Wishlist,Open]  http://bugs.debian.org/434443
[01:20] <geser> as would like to see the new version in gutsy so I'll proabably update the Ubuntu package on the next weekend to get it in before UVF
[02:11] <DarkSun88> Hi
[02:12] <geser> Hi DarkSun88
[02:12] <DarkSun88> Hi geser 
[02:12] <DarkSun88> Thanks for upload.
[02:13] <ScottK> geser: Thanks.
[02:14] <ScottK> I'll see if I can get an upload through Debian Python Modules Team.
[02:14] <ScottK> geser: On packages managed in DPMT, please ping me and I'll try and get stuff done.
[02:26] <xxxxx1> good morning
[02:29] <geser> Hey Hobbsee
[02:29] <Hobbsee> hiya geser 
[02:29] <xxxxx1> morning Hobbsee :)
[02:29] <Hobbsee> evening
[02:29] <Kmos> bug 130618
[02:29] <xxxxx1> ;D
[02:29] <ubotu> Launchpad bug 130618 in cups-pdf "Please sync cups-pdf (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/130618
[02:29] <Kmos> this is a good reason to ask for a sync ?
[02:30] <Kmos> it's confirmed and subcribed to U-A
[02:30] <xxxxx1> Kmos, the sync guy :D
[02:30] <xxxxx1> heh
[02:30] <Kmos> xxxxx1: that's no by me!
[02:30] <Hobbsee> xxxxx1: that is *not* the reputation you want to give out.
[02:31] <Kmos> check it
[02:31] <Hobbsee> xxxxx1: we dont want him to attempt to sync the world, repeatedly
[02:31] <xxxxx1> :)
[02:31] <Hobbsee> Q-FUNK: ping
[02:32] <xxxxx1> Kmos, you're brazilian?
[02:32] <Hobbsee> Kmos: that bug is wrong.  he hasnt had that sponsored, he's not a MOUT
[02:32] <Hobbsee> * MOTU
[02:32] <Q-FUNK> Hobbsee: ?
[02:32] <Hobbsee> Q-FUNK: did you become a MOTU without anyone noticing?
[02:32] <Kmos> xxxxx1: portuguese :)
[02:33] <Kmos> born at germany :p
[02:33] <Q-FUNK> Hobbsee: no, why do you ask?
[02:33] <Hobbsee> Q-FUNK: explain to me https://launchpad.net/bugs/130618 then please
[02:33] <ubotu> Launchpad bug 130618 in cups-pdf "Please sync cups-pdf (universe) from Debian unstable (main)" [Undecided,Confirmed]  
[02:33] <Kmos> Hobbsee: that's why I talk here about that
[02:33] <Q-FUNK> Hobbsee: what is there to explain?
[02:33] <Hobbsee> Q-FUNK: you need to specify with -s to get sponsorship.
[02:34] <Q-FUNK> Hobbsee: having that stated in the man page would help.  oh wait, having a man page for the tool would even be better.
[02:34] <Hobbsee> Q-FUNK: you are not a MOTU, you need sponsorship for everything you upload, and for all sync requests, removal requests, etc.
[02:34] <Hobbsee> Q-FUNK: this is true.  there is documentation on it, on the wiki.
[02:35] <StevenK> Hrm. Do I care enough to run help2man over requestsync? Not so much.
[02:35] <Hobbsee> Q-FUNK: it would be most helpful for you to provide a patch ofr it, then
[02:35] <StevenK> I might care tomorrow.
[02:35] <Hobbsee> StevenK: the -n and -s on requestsync with no arguments are not explained at all, btw
[02:35] <Q-FUNK> Hobbsee: --help doesn't tell much and there is no man page.  fix it instead of demanding explanations.
[02:36] <StevenK> Hobbsee: Hrm? Parse error.
[02:36] <Kmos> https://wiki.ubuntu.com/SyncRequestProcess
[02:36] <Hobbsee> Usage: requestsync [-n|-s]  <source package> <target release> [basever] 
[02:36] <Hobbsee> In some cases, the base version (fork point from Debian) cannot be determined
[02:36] <Hobbsee> automatically, and you'll get a complete Debian changelog. Specify the correct
[02:36] <Hobbsee> base version in that case.
[02:36] <Kmos> it's all here
[02:36] <Hobbsee> StevenK: you never specify what -n and -s actually do
[02:36] <ScottK> Q-FUNK: The sync process is clear on the wiki.
[02:36] <StevenK> Hobbsee: It's help output, it doesn't have to.
[02:36] <Hobbsee> StevenK: then it probably should have a manpage
[02:37] <Q-FUNK> StevenK: either this has a good and usefull --help output, or it has a man page.
[02:37] <StevenK> Q-FUNK, Kmos, Hobbsee: I'm writing a manual page for requestsync.
[02:37] <Q-FUNK> good :)
[02:37] <Q-FUNK> that's at least an improvement
[02:37] <StevenK> What do you want for nothing?
[02:38] <Kmos> StevenK: that's nice
[02:38] <Q-FUNK> rubber biscuits?
[02:39] <elkbuntu> StevenK, a double strength iced coffee would be nice. thanks for offering :D
[02:39] <Hobbsee> most of those will require main sponsors anyway
[02:41] <Kmos> Hobbsee: bug 128634 -> i've the debdiff for stunnel4 attached there
[02:41] <ubotu> Launchpad bug 128634 in crywrap "[Remove]  Please remove crywrap from Gutsy" [Undecided,Invalid]  https://launchpad.net/bugs/128634
[02:42] <geser> Kmos: please check the next time if the package is in main or universe and subscribe the right sponsors time instead of always u-u-s
[02:42] <Hobbsee> Q-FUNK: to be honest, i would have expected that you'd checked one of the bugs real output, just to check that it was working for you, as a non-MOTU.
[02:43] <Hobbsee> rather than filing a whole bunch of them
[02:43] <Q-FUNK> Hobbsee: it does work.  the bug gets filed.
[02:43] <Kmos> geser: sorry.. 
[02:44] <Hobbsee> Q-FUNK: but the sponsors dont get assigned.  those scripts are mostly done for MOTU's and core devs, and sometimes need changing for sponsorships.
[02:44] <Hobbsee> er, but the sponsors dont get added correctly
[02:44] <Hobbsee> which is why it's often a good idea to actually check the script, and the output
[02:44] <Hobbsee> incidently, this is also useful for debian-specific scripts.
[02:46] <Q-FUNK> Hobbsee: you're complaining to the wrong person.  just add usefull --help output and help StevenK complete his man page, then get it released in time for Gutsy.  that's gonna a LOT more towards fixing the issue than routinely doing your offended diva number.
[02:47] <Hobbsee> i love it when people utterly and totally miss the point.
[02:47] <Kmos> Hobbsee :) 
[02:47] <ScottK> Q-FUNK: OTOH, working out of process in bulk and never checking how the script was working for you isn't so great either.
[02:48] <Hobbsee> on that basis though, you can find another core dev and MOTU to sponsor those changes.
[02:50] <Hobbsee> coNP: this is true.  but then it's a pain for all the MOTU's.  hence, providing an option for the non-catered for group is useful.
[02:50] <coNP> (Because the people, who should use a switch are those, know what they want to do. And you can assume core-devs and MOTUs know what they want to do, which you should not assume from everyone)
[02:50] <Fujitsu> coNP: take it as an incentive to become a MOTU :P
[02:51] <Hobbsee> coNP: wow, which bug?
[02:51] <Hobbsee> sync run was only done a copule of days ago, i thought
[02:51] <ScottK> His MOTU application.
[02:51] <Hobbsee> oh right
[02:51] <Hobbsee> thought you meant a sync request
[02:51] <coNP> Hobbsee: you mean where I need core-devs? Or my MOTU application?
[02:52] <Hobbsee> coNP: no - i thought you were talking about that you'd made a sync request, and that it hadnt been dealt with in 12 days
[02:52] <coNP> No, I have made it during the WE. I guess I'll bug someone next Monday if it does not gets done till then.
[02:53] <coNP> ScottK: sorry, I don't see, what you mean. I have certain difficulties in English...
[02:55] <geser> Kmos: are you going to also file a remove request for gnotepad+-help? It's uninstallable now
[02:55] <Hobbsee> geser: there's already one, i ack'd it.
[02:55] <Hobbsee> geser: or else i'm going insane :)
[02:56] <Hobbsee> coNP: i think he means, as a general comment, it's good for MOTU candidates to not be making mistakes, especially trivial ones, and that paying attention to the little details will be useful in that
[02:57] <ScottK> coNP: Not directed at you.
[02:57] <ScottK> What Hobbsee said.
[02:57] <Hobbsee> ScottK: yeah, i didnt think it could be, seeing as coNP seems sane ;)
[02:57] <coNP> Cool, thank you both. I was asking indeed, if it has been directed at me...
[02:57] <Hobbsee> coNP: i think it was more a "and while we're on the subjects of MOTU candidates..."
[02:58] <geser> Hobbsee: ah, I see now what happened: the bug for gnotepad+-help was duped to the one for gnotepad+ but only gnotepad+ got removed
[02:59] <Hobbsee> geser: i wonder why, they're different sources
[03:00] <geser> I've opened a bug task on the acked one for gnotepad+-help, hope this is enough to get it removed
[03:01] <ScottK> geser: Did you un-dupe it?
[03:02] <Hobbsee> geser: would have thought the unduping would be enough, tbh
[03:02] <geser> no, see bug #128637 now
[03:02] <ubotu> Launchpad bug 128637 in gnotepad+ "[Remove]  Please remove gnotepad+ from Gutsy" [Wishlist,Fix released]  https://launchpad.net/bugs/128637
[03:02] <geser> this way all the history is there
[03:03] <ScottK> I think un-duping with a comment about why would be easier and sufficient.
[03:03] <Hobbsee> meh
[03:03] <Hobbsee> either should work
[03:04] <Hobbsee> ScottK: just that i'ts going to cause more bugmail, etc
[03:05] <ScottK> OK.
[03:05] <Hobbsee> ScottK: i guess if they get confused or something, they'd poke on irc
[03:06] <ScottK> That or find something less confusing to work on.
[03:10] <Hobbsee> indeed
[03:10] <Hobbsee> (some more)
[03:12] <Hobbsee> then again, i guess there's only any point when people read it
[03:24] <Kmos> geser & Hobbsee: thanks
[03:24] <Kmos> bug 128634 -> i've the debdiff for stunnel4 attached there, so after new update of stunnel4 this bug can be triaged
[03:25] <ubotu> Launchpad bug 128634 in crywrap "[Remove]  Please remove crywrap from Gutsy" [Undecided,Invalid]  https://launchpad.net/bugs/128634
[03:32] <norsetto> Good time of the day, everybody
[03:33] <Hobbsee> hiya norsetto 
[03:35] <ScottK> DarkSun88: Why did you invalid your python-sqlite sync?
[03:35] <DarkSun88> Because the changes are not in Debian
[03:35] <ScottK> I don't understand what you mean by that?
[03:36] <elmargol> do i have to rename a source directory to lowercase?
[03:37] <DarkSun88> In Ubuntu changes there is bump version of python-central, debhelper and python-all-dev
[03:37] <StevenK> Q-FUNK, Kmos: New devscripts uploaded to Gutsy, now with a shiny manual page for requestsync.
[03:38] <DarkSun88> ScottK: In Ubuntu changes there is bump version of python-central, debhelper and python-all-dev
[03:38] <Q-FUNK> hurray for StevenK!
[03:38] <DarkSun88> ScottK: Add python-all-dbg in field Build-Depends.
[03:39] <ScottK> Ah.  I see.
[03:40] <DarkSun88> ScottK: Debian has python-all-dbg in field Build-Depends but not bump version of debhelper,python-all-dev and python-central
[03:40] <DarkSun88> So, it's not a sync.
[03:40] <ScottK> Then ask yourself are they really necessary?
[03:40] <ScottK> I don't know.
[03:41] <ScottK> Just because there is an Ubuntu diff, doesn't mean it's a useful one.
[03:41] <DarkSun88> I know.
[03:41] <ScottK> If you can answer the question: "It is safe sync over the Ubuntu changes because ..." then it may well be a good sync.
[03:42] <DarkSun88> I want to be sure.
[03:42] <ScottK> Agreed.
[03:42] <DarkSun88> Thanks :)
[03:43] <Kmos> StevenK: nice.. thanks!
[03:53] <geser> snort (universe) FTBFS because html.sty is missing. It's in latex2html (multiverse). Does somebody see an other option except disabling the documentation?
[03:53] <StevenK> Demotion of snort
[03:54] <Kmos> geser: there isn't a new version of it on debian qa ?
[03:55] <geser> Kmos: that's the last version from experimental
[03:55] <Kmos> :-(
[03:55] <geser> StevenK: I would like to avoid that
[03:55] <ubotu> Launchpad bug 130220 in launchpad "LP marks bugs fix released multiple times and sends multiple mails when a bug number appears in more than one .changes file" [High,New]  https://launchpad.net/bugs/130220
[03:55] <ubotu> Launchpad bug 78165 in devscripts "debuild fails to use seahorse-agent or gpg-agent" [Medium,Fix released]  https://launchpad.net/bugs/78165
[03:55] <Kmos> report it to maintainer.. stfl maintainer has done a new revision, removing CFLAGS
[03:55] <elkbuntu> hey guys, if only 7.28% of people who had a problem with ubuntu *failed* to file a bug report, that would be a fair increase on the current, right?
[03:55] <Hobbsee> any idea of latex2html actually needs to be in multiverse?
[03:56] <Hobbsee> elkbuntu: uh, yeah
[03:56] <StevenK> ScottK: Damn it, I uploaded devscripts about 20 minutes ago.
[03:56] <geser> Hobbsee: it's in Debian non-free
[03:56] <ScottK> StevenK: I was subscribed to the old bug and got the bonus bugmail.  
[03:57] <StevenK> ScottK: Ah, I see why. I think I meant to take out that (LP: #) and forgot.
[03:57] <StevenK> ScottK: Sorry for the spam.
[03:57] <ScottK> Yeah, but you shouldn't have to.
[03:57] <ScottK> Not your fault.
[03:57] <ScottK> StevenK: I blame a buggy proprietary application of some name.
[03:57] <ScottK> The good news is it's fixed in the next release.
[03:57] <StevenK> Of course you do, you always do. :-P
[03:58] <elkbuntu> Hobbsee, right, then automatix should count themselves exceptionally lucky then
[03:58] <ScottK> I don't ALWAYS blame LP for stuff, just when it's at fault.
[03:58] <ScottK> Not that that's a rare occurence.
[03:59] <Kmos> Hobbsee: latex2html doesn't say anything on offical homepage about license
[03:59] <Kmos> Some portions of this package are published under the
[03:59] <Kmos> GNU public license. These are clearly marked in the header.
[03:59] <Kmos> http://saftsack.fs.uni-bayreuth.de/~latex2ht/user/LICENSE
[04:00] <StevenK> "Some portions" that doesn't mean all
[04:00] <Kmos> yep
[04:00] <Kmos> :)
[04:01] <StevenK> And latex2html has been in multiverse since warty.
[04:04] <geser> I'll open a bug for the snort FTBFS in Debian as this is AFAIK also a bug there (missing build-depends)
[04:29] <hendrixski> umm, what's the name of that program that brings up the password box when I need to sign things (like while running debuild -S)?
[04:29] <ScottK> pinentry
[04:29] <ScottK> There are different flavors (-gtk2, qt, curses_
[04:29] <ScottK> err. curses)
[04:29] <ScottK> hendrixski: You also need to have gpg-agent installed and enabled (use-agent in gpg.conf for the user).
[04:29] <hendrixski> ScottK, right...  yeah, I accidentally deleted my /home/ directory (forgot to unmount it when deleting a chroot) so I have to reconfigure all those things and I totally forgot the names...
[04:31] <_MMA_> Can anyone tell me if someone is working on getting this into the repos? Mumble: http://mumble.sourceforge.net
[04:33] <elmargol> can someone test a package for me on pbuilder? i don't have enough disk space to setup :(
[04:33] <_MMA_> All I find is bug 129081 So I'm guessing my answer is no.
[04:33] <ubotu> Launchpad bug 129081 in Ubuntu "Mumble needs packaging" [Wishlist,Confirmed]  https://launchpad.net/bugs/129081
[04:35] <Hobbsee> _MMA_: if it's not set as in progress
[04:37] <_MMA_> Hobbsee: Naa... Just "Confirmed". Maybe I can get one of my guys to do it.
[04:38] <_MMA_> Hobbsee: If it can be synced do I have to talk to a motu or can a "motu in training" do it?
[04:38] <ScottK> _MMA_: Synced from where?
[04:39] <_MMA_> Debian.
[04:40] <_MMA_> ScottK: I couldnt find it there. I'm just assuming. Might not be there.
[04:40] <_MMA_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429988
[04:40] <ubotu> Debian bug 429988 in wnpp "ITP: mumble -- Voice chat client" [Wishlist,Open]  
[04:41] <ScottK> That would mean someone is likely working on it.
[04:41] <ScottK> You might e-mail the person who filed the ITP and see how close they are.
[04:41] <_MMA_> Ok.
[04:43] <ScottK> It's maybe too late to get something uploaded to Debian, through Debian NEW, and then sync'ed into Ubuntu before the Universe new package freeze.
[04:43] <ScottK> You might invite them to work with you to get an upload to Ubuntu first if they are close.
[04:43] <_MMA_> Thats my only worry. Ill email them now.
[04:44] <norsetto> _MMA_: https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/001996.html is this the same guy?
[04:46] <_MMA_> norsetto: No. Doesnt look like it.
[04:46] <_MMA_> "Grkan Sengn" Is on the Debian one.
[04:47] <_MMA_> But he just submitted it. I'm not sure that means he's working on it.
[04:47] <norsetto> _MMA_: don't think he is
[04:49] <_MMA_> Too bad we cant get the GetDeb guys more in-line with helping here. They have a package there. :(
[04:52] <elmargol> can someone please sync the revu keyring?
[05:01] <elmargol> can someone help me please? I tried to upload a new package to revu. Where can I see if it was successfully uploaded?
[05:01] <elmargol> dput says that it worked
[05:02] <peebrain> elmargol: http://revu.tauware.de/
[05:02] <ScottK> But it takes seveal minutes for it to show up usually.
[05:02] <elmargol> if the keyring is not synced it will be rejected right?
[05:03] <ScottK> Yes.
[05:17] <Hobbsee> !info gcj-4.2 gutsy
[05:17] <ubotu> gcj-4.2: The GNU compiler for Java(TM). In component main, is optional. Version 4.2.1-1ubuntu1j1 (gutsy), package size 2703 kB, installed size 5968 kB
[05:29] <elmargol> should i use pbuilder or sbuild
[05:33] <ScottK> elmargol: Whatever works for you.  I use pbuilder.  With the scripts at http://revu.tauware.de/~laserjock/ it's very easy to set up.
[05:38] <StevenK> Hah, that's cute.
[05:38] <StevenK> "Never underestimate the power of somebody with source code, a text editor, and the willingness to totally hose their system."
[05:39] <ScottK> I like that.
[05:40] <mohammad> ScottK: hello, thank you for advocating my package :)
[05:41] <ScottK> You're welcome.
[05:41] <ScottK> I've been waiting for Persia to show up and see if he would review it, but I haven't seen him.
[05:41] <ScottK> mohammad: I know it's been a lot of work.  I hope you can see that the package is improved by it.
[05:43] <StevenK> That's a bad loop.
[05:44] <StevenK> bmm starts swimming, and doesn't stop until the weather turns back. He could be swimming for weeks!
[05:44] <StevenK> s/back/bad/
[05:44] <ScottK> That or painful if he's not in an ocean.
[05:45] <StevenK> ScottK: Tumble turns? :-)
[05:51] <mohammad> I have one advocate for http://revu.tauware.de/details.py?upid=6329, and I am looking for another one. that's a Quran study tool. If you are interested, would you please take a look
[06:11] <elmargol> how big is pbuilder?
[06:11] <StevenK> Installed-Size: 460
[06:12] <elmargol> is this the minimal size?
[06:12] <StevenK> It's 460KB once unpacked.
[06:12] <elmargol> no i mean the build env
[06:13] <StevenK> That's a different story, and it usually is roughly 70 to 80 MB per base tarball.
[06:13] <elmargol> ok thx
[06:25] <keescook> Fujitsu: tcpdump> yeah, I made a mistake in the version #
[06:25] <keescook> joejaxx: apparmor> sure, what's up?
[06:27] <ScottK> keescook: Speaking of apparmor...  If cupsys can't find the init for apparmor, is that a cupsys problem or an apparmor problem?
[06:27] <ScottK> It seems I don't have one on my Gutsy box.
[06:28] <keescook> ScottK: I haven't dug around to see how pitti implemented the apparmor profile for cupsys yet.  if you need the apparmor init script, the "apparmor" package should include it.
[06:28] <ScottK> OK.  I'll file a bug then.
[06:29] <ScottK> I'll put both packages on it and let you two sort it out.
[06:31] <keescook> ScottK: sounds right to me.  :)
[06:37] <ScottK> keescook: Looks like there is an existing cupsys bug on it.
[06:37] <keescook> ScottK: cool, which is it so I can check on it later today?
[06:38] <ScottK> Sorry, already closed the browser window.  I'll dig it up again, but it'll take a minute.
[06:40] <ScottK> keescook: Bug #130014
[06:40] <ubotu> Launchpad bug 130014 in cupsys "[Gutsy]  Unable to upgrade or reinstall cupsys after trying to upgrade" [Undecided,New]  https://launchpad.net/bugs/130014
[06:42] <keescook> ScottK: sweet, thanks
[06:43] <elmargol> Can someone review my .postinst please?
[06:43] <elmargol> https://gnunet.org/svn/GNUnet/debian/gnunet-daemon.postinst
[06:45] <elmargol> Adding the user seems to be problematic
[06:45] <ScottK> elmargol: On Ubuntu, /var/run is a tempfs, so you can't assume that a directory exists either for postinst or for init.
[06:45] <elmargol> oh interesting
[06:46] <ScottK> elmargol: For the user addition, I'd suggest grabbing the clamav source package and look it it.  It works.
[06:46] <geser> ScottK: it should be safe to assume it in the postinst as it's created by the package and you seldom reboot between unpack and configure
[06:46] <ScottK> geser: Should be, but isn't.
[06:47] <ScottK> I've gotten clamav bugs on it.
[06:47] <geser> how can a /var/run dir vanish between unpack and configure?
[06:48] <geser> aborted installation and running dpkg --configure -a?
[06:48] <ScottK> geser: I have no idea, but it did and it's a cheap test.
[06:48] <broonie> geser: Attempt to install. Fail to configure due to missing dep or whatever.
[06:48] <broonie> Then reboot while fixing it up.
[06:48] <geser> ok
[06:48] <broonie> Or loose power during an upgrade.
[06:48] <geser> dpkg-reconfigure would be an other possibility
[06:48] <broonie> Kill dpkg at the wrong moment.
[06:49] <ScottK> Hmmm
[06:49] <geser> ok, checking for the dir should be added then
[06:49] <ScottK> Clamav is one of the packages that Automatix installs, so kill dpkg at the wrong moment is a VERY good possibility.
[06:50] <elmargol> Doesn't clamav detect automatic as virus? :D
[06:50] <ScottK> It is a virus scanner, yes.
[06:50] <elkbuntu> ha. if only
[06:50] <broonie> elkbuntu: It'd be easy to make it do so...
[06:51] <elkbuntu> broonie, please. I'll bring the popcorn.
[06:51] <StevenK> Oooh, why don't we get clamav to Conflict against the automatix package?
[06:52] <zorglu_> q. i run autogen.sh in a project, and it create a lot of files, COPYING etc... is there a command to remove all the file which has been created ? or should i all remove them by hand ?
[06:53] <elkbuntu> StevenK, sounds good, but i'd prefer it built into clamav. it'd make more sense to people then ;)
[06:53] <elmargol> zorglu_: dpkg-source -tc should work
[06:53] <ScottK> Well we could patch it.
[06:54] <elmargol> has gutsy a new compresion for debs?
[06:54] <zorglu_> elmargol: anyother possibility ? :) i dont have the package working yet 
[06:54] <elmargol> zorglu_: use a cvs system like git or bazaar
[06:54] <zorglu_> elmargol: ok so i have to remove them by hand, ok :)
[06:55] <ScottK> zorglu_: dh_clean?
[06:55] <elmargol> somehow I'm downloading debs faster than my connection is...
[06:55] <ScottK> zorglu_: I know little about autogen, so don't assume I'm right.
[06:56] <zorglu_> ScottK: im learning it :)
[07:06] <zorglu_> utomake: src/Makefile.am: not supported: source file `mylib1/dir1/mylib1_1.c' is in subdirectory <- inside a MAkefile.am, is it possible to point to a source which is a subdirectory. apparetnly it throw me an error
[07:07] <broonie> zorglu_: Have a Makefile.am per directory.
[07:07] <zorglu_> broonie: nothing execpt that ? i mean i got a LOT of directory and putting a Makefile.am in each of them is not really an option
[07:08] <zorglu_> else i could work it around by doing a first pass with symlink on a single directory
[07:08] <zorglu_> and replacing / by _ or something 
[07:08] <elmargol> is it ok to have # comments on a template file?
[07:09] <broonie> zorglu_: Are you sure you want to use automake?
[07:09] <zorglu_> broonie: honnestly, if you have any alternative, i am a taker :)
[07:10] <broonie> This source has no upstream build environment at all?
[07:10] <zorglu_> broonie: without using the gnu stuff, i have to make all the cross compilation script myself and this start to be hard
[07:11] <zorglu_> broonie: i am the one coding the 'upstream' :) currently this is a old makefile made by hand which is more than 3000line long... not that i am proud of that. so i look for alternative :)
[07:11] <zorglu_> broonie: i am more a coder trying to make a package, that a packager trying to package a code :)
[07:12] <keescook> hunh.  snort 2.7.0 failed on i386 but not amd64 due to latex issue?  weird.
[07:12] <broonie> zorglu_: Hrm. In that case using auto* is probably reasonable but your life will probably be easier if you do what it wants rather than trying to work around it - it's got some definite ideas about how things should look.
[07:13] <geser> keescook: fixed already, snort waits to be build
[07:14] <zorglu_> broonie: well currently im trying on a 'small corner'. i have to avoid any 'polution' of my code just to get autotool running :) so i will do the symlnk workaround. thanks for your help, i may have other silly question along the way  :)
[07:14] <keescook> geser: okay, cool.
[07:14] <broonie> zorglu_: You could probably autogenerate the recursive Makefile.ams.
[07:14] <elmargol> W: gnunet-daemon: maintainer-script-hides-init-failure prerm:9 <- what does this mean?
[07:15] <geser> run linda/lintian with -i and you should get an informative text
[07:18] <zorglu_> broonie: i just counted, i got 1595 directories :) i think you may understand better why i dont want 1595 makefiles :)
[07:31] <elmargol> I search a tool to debug manpages.
[07:32] <elmargol> W: gnunet-client: manpage-has-errors-from-man usr/share/man/man1/gnunet-stats.1.gz 42: warning [p 1, 9.2i] : cannot adjust line
[07:32] <Amaranth> zorglu_: why the heck do you have that many? :/
[07:33] <zorglu_> Amaranth: well it is a large c++ project and i like to have different objects in differents directories. there are like 10apps + 42 library inside the project. depending on like 10 external libraries :)
[07:34] <Amaranth> zorglu_: wow how long does that take to compile?
[07:34] <zorglu_> Amaranth: not that much... the whole stuff is like 310kline. maybe 25min for a native linux target
[07:35] <zorglu_> with no optimisation and dynmic linking
[07:43] <hendrixski> umm... after setting up pinentry, gnupg, all that.. I still can't run debuild -S
[07:43] <hendrixski> it tells me gpg-agent command get_passphrase failed:operation canceled... then it can't sign anything :-(
[07:44] <hendrixski> I have "use-agent" in ~/.gnupg/gpg.conf   what am i missing?
[07:45] <superm1> hendrixski, are you perhaps hitting bug 78165 ?
[07:45] <ubotu> Launchpad bug 78165 in devscripts "debuild fails to use seahorse-agent or gpg-agent" [Medium,Fix released]  https://launchpad.net/bugs/78165
[07:45] <superm1> if so, there is a work around listed in the bug for feisty
[07:47] <hendrixski> superm1, I'll take a look at it and see if that's what I'm hitting
[07:47] <elmargol> where can I specifiy the gpgkey to use? I'm bored of using -k
[07:49] <hendrixski> superm1, yup... disabling caching on seahorse made it prompt me for the passphrase.
[07:49] <superm1> hendrixski, that wasn't the work around i was referring to, but that works too i guess :)
[07:50] <superm1> for me i think it was unsetting the clearing of  DISPLAY in /etc/devscripts.conf or something to that effect
[07:50] <hendrixski> right, I should do that as well I guess
[07:51] <hendrixski> debuild -S is supposed to produce a .deb right?
[07:51] <superm1> Nope
[07:51] <superm1> er ya
[07:51] <superm1> it should a signed deb
[07:51] <superm1> debuild -sa produces a  source package
[07:52] <superm1> the -S is indeed for source package.  I always do -S -sa, so i seem to have forgotten :)
[07:52] <superm1> so if you want to produce a deb, just do it with -b 
[07:53] <hendrixski> ah, Ok
[07:53] <Amaranth> -sa is to include the original source
[07:53] <Amaranth> in the .changes file
[07:54] <hendrixski> superm1, you maintain the mythtv debs, right?
[07:55] <superm1> hendrixski, yes
[07:55] <hendrixski> superm1, so have you run into that problem, where pbuilder just doesn't handle mythtv-frontend?
[07:57] <superm1> "doesn't handle"?  I wouldn't say so
[07:57] <hendrixski> hhmmm... because I gave myself the challenge of packaging torrentocracy to better learn this stuff... and I mimicked the dependencies from mythtvplugins.. but pbuilder would always crash before getting any work done.. myth-database would not connect to sockets or something and I wan't able to get a package out of pbuilder :-(
[07:58] <superm1> hendrixski, come join #ubuntu-mythtv and we can chat a bit about it
[07:58] <hendrixski> oh. there's a channel for this... awesome
[07:58] <ScottK> hendrixski: You can also download the gutsy devscripts source package and just copy the debuild script over.
[07:59] <ScottK> Then your agent should work.
[08:31] <zorglu_> q. in my configure.ac, i got quite a long AC_CONFIG_FILES aka all my submakefile. is there a way to tell him "follows all the SUBDIRS you find in the first Makefile" instead ?
[08:32] <coNP> You generate your Makefile with configure.ac, aren't you?
[08:34] <zorglu_> coNP: yep. but i got like 50 makefiles. so i would like to avoid to get the whole list in the configure.ac
[08:34] <zorglu_> coNP: if i understand the "SUBDIRS" variable in Makefile.am, it is possible for it to do the recursion automatically, no ?
[08:58] <jrib> If I export from svn to create the orig.tar.gz, should the get-orig-source rule in debian/rules specify the same revision that I am using to create my deb or should it just fetch HEAD?
[08:59] <jrib> the exmaple at https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball specifies a date but http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules says "most recent version" so I'm not sure
[09:09] <ScottK> jrib: I'd follow the Debian policy manual.
[09:14] <jrib> thanks
[10:21] <norsetto> /norsetto felt for a moment very alone
[10:37] <blueyed> I've uploaded a package to revu two days ago, before the keyring was synced probably. But the package does not appear anywhere and I cannot get a password by "recover" to login.
[10:38] <zorglu_> Makefile.in seems to ignore the --datarootdir setting <- i got a lot of those when doing ./configure . any idea where it might come from ?
[10:38] <blueyed> However, the file exists already, I cannot dput it again.
[10:43] <zorglu_> datarootdir = @datarootdir@ <- nevermind, i just found a workaround, adding this in all Makefile.am
[10:47] <jrib> blueyed: tried passing -f to dput?
[10:47] <blueyed> jrib: just now, but the same error "Cannot create file". It talks about using dcut, should I try this?
[10:47] <jrib> blueyed: idk, maybe wait for someone that's more familiar with revu to be around
[10:48] <blueyed> ok. Do I need to have a successful upload before password "recovery" is supposed to work?
[11:43] <jmg> good news - lenovo to sell laptops preloaded with lunix
[11:43] <jmg> bad news - it's SuSE
[11:43] <desertc> There's plenty of support contracts to go around.
[11:43] <calc> jmg: overall news, lenovo systems will be tested against linux... good news
[11:43] <calc> even if its SuSE its better than not testing against linux at all :)
[11:43] <jmg> lolol
[11:43] <jmg> M.Dell rolls automatix
[11:43] <pygi> jmg, ergh?
[11:43] <jmg> http://www.dell.com/content/topics/global.aspx/corp/biographies/en/msd_computers?c=us&l=en
[11:43] <jmg> Automatix2
[11:44] <pygi> ah, I know that
[11:44] <jmg> so
[11:44] <jmg> here's a question
[11:44] <jmg> we all hate automatix
[11:44] <jmg> so why cant we make something like automatix that doesnt suck?
[11:45] <pygi> easyubuntu?
[11:45] <jmg> yeah
[11:45] <pygi> that exists =)
[11:45] <jmg> okay, why doesnt it have mind share?
[11:45] <pygi> dont ask me
[11:45] <pygi> http://easyubuntu.freecontrib.org/
[11:55] <yamal> t
[12:04] <Hattory> can i "talk" about personal repositories there? 
[12:08] <calc> evand: normally people set up a w.u.c page as well with info on what they have done and their future plans, but with your amount of merges you may be ok without it