[12:13] <ScottK> apacheLAGger: No big deal.  I'll get over it.
[12:13] <apacheLAGger> ScottK: ok ^_^
[12:14] <geser> Hi persia
[12:14] <geser> I've some build logs for adour from PPA
[12:15] <persia> geser: Great!  Any clues about pkg-config?
[12:15] <geser> http://librarian.dogfood.launchpad.net/7747178/buildlog_ubuntu-gutsy-i386.ardour_1%3A2.0.2-2ubuntu2%7Eppa1_FAILEDTOBUILD.txt.gz
[12:15] <TheMuso> Hey persia, geser.
[12:15] <geser> scons: Configure: Checking for pkg-config version >= 0.8.0... 
[12:16] <geser> pkg-config --atleast-pkgconfig-version=0.8.0
[12:16] <geser> /bin/sh: Syntax error: "(" unexpected
[12:16] <geser> Hi TheMuso
[12:16] <jmg> whats dogfood?
[12:16] <persia> geser: Cool!  We can replicate without the actual buildds :)
[12:16] <jmg> lp beta?
[12:16] <geser> that's the same error as in xmms2 before it moved away from scons
[12:16] <TheMuso> Wow.
[12:16] <geser> jmg: PPA
[12:16] <jmg> ppa?
[12:16] <persia> jmg: http://en.wikipedia.org/wiki/Eat_one%27s_own_dog_food
[12:17] <jmg> persia: i know what that means, its our company motto :)
[12:17] <TheMuso> So am I guessing that its a pkg-config problem?
[12:17] <jmg> i was just wondering what dogfood.lp.net was
[12:17] <geser> there was some change on the buildds some time ago, so the error message isn't that verbose as in the beginning
[12:17] <docta_v> minghua: according to --contents there is no /.deb
[12:17] <jmg> geser: that looks like a bash to nash error?
[12:17] <docta_v> but if i install it creates a /.deb
[12:17] <persia> TheMuso: Except that any recent version of pkg-config really ought to be >> 0.8
[12:17] <TheMuso> persia: Yeah.
[12:18] <geser> see bug #87077
[12:18] <ubotu> Launchpad bug 87077 in launchpad-buildd "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,New]  https://launchpad.net/bugs/87077
[12:18] <geser> that the bug about the xmms2 build problems with scons
[12:18] <persia> Worse yet: "Get:55 http://archive.ubuntu.com gutsy/main pkg-config 0.22-1 [52.5kB] " is definitely >> 0.8
[12:18] <TheMuso> Yeah
[12:18] <TheMuso> So why does it work for us
[12:18] <jmg> how come dogfood runs an older build of lp then?
[12:19] <docta_v> hmm i think i fixed it
[12:19] <persia> jmg: It's for testing random extra features: not the latest code - see snapshot or beta
[12:19] <jmg> ok
[12:20] <geser> TheMuso: it seems to be a bug in sbuild used on the buildds
[12:20] <TheMuso> Ok
[12:20] <jmg> also there is no definition on the wiki for ppa
[12:20] <geser> or the buildd environment
[12:20] <persia> TheMuso: That's an interesting question.  I'm tempted to try to set up a gutsy schroot under Dapper, but I think the buildd configuration is even more complex than that.
[12:20] <geser> jmg: personal package archive
[12:21] <TheMuso> .bbl, breakfast
[12:21] <geser> the problem is to find someone who has time and can fix it :(
[12:22] <geser> but I don't understand why only scons triggers this problem
[12:24] <persia> geser: It's not just scons: there are other strange corner cases to the buildds as well :)
[12:28] <TheMuso> persia: I'm guessing people have forgotten to unsubscribe uus.
[12:29] <TheMuso> I always do it now.
[12:29] <TheMuso> As it does indeed make it easy to know what has been taken.
[12:30] <persia> TheMuso: Indeed.  Thanks to you for taking the bugs and handling them.  I'll still prod when I find the extras :)
[12:30] <TheMuso> np. I feel that not enough MOTUs help with this queue actually.
[12:31] <geser> is xml.etree.ElementTree from python2.5 a full replacement for elementtree.ElementTree from python-elementtree which only supports python2.4?
[12:34] <persia> TheMuso: I see about 10 active sponsors, and feel that the queue time is acceptable (it no longer takes months to get a review), so I'm not that worried.  More hands are good, but I'd rather 10 committed people than 50 who look once in a while (of course, 50 committed people would be better :) )
[12:34] <TheMuso> yup
[12:39] <TheMuso> persia: What do you think of all these packages that are in the queue where the docs are being included in Ubuntu, whereas tey are not in Debian, for license rasons?
[12:39] <TheMuso> I uploaded one y esterday, as that change had already been allowed in a previous merge, but I am not so sure about changing a package not  yet touched in this way...
[12:39] <persia> TheMuso: My understanding is that Ubuntu doesn't block on GFDL, but I don't remember why I'm of that opinion.  On the other hand, most of them are waiting for emacs22, and despite a recent promise, I don't see that yet.
[12:40] <TheMuso> referring to stuff like nxmn-mode  etc
[12:40] <TheMuso> right
[12:40] <persia> Did nxmn-mode build?  The ones I tried didn't build properly without the updated emacs.
[12:41] <TheMuso> haven't tried those.
[12:41] <TheMuso> I uploaded erc, which did build for me at least.
[12:41] <TheMuso> Which was the merge.
[12:43] <persia> Does anyone happen to know how often packages.qa.debian.org updates the current versions in the repositories?
[12:43] <RickH> Hello.  I'm a total newbie to Linux and Ubuntu.  But, I love it.  I am a Windows software developer and would like to learn about Ubuntu/Linux development.
[12:44] <geser> persia: I'd guess once or twice a day
[12:45] <persia> RickH: Great!  We're more focused on packaging for Ubuntu than development here, but you'll probably get good support from channels where the name matches your target development environment.  On the other hand, looking at other source packages can be a great way to see how others do it, which can make it easy to learn.
[12:45] <persia> geser: Thanks.  I'll wait a bit more then :)
[12:45] <RickH> I'm looking at MOTU/Recipes right now.
[12:54] <RickH> "Since these are the important goals of Ubuntu:  1) User-friendliness, 2) out-of-the-box workability, 3) bling factor, 4) and many more surprising things"... I like #3. :)
[12:56] <geser> persia: dinstall is only run twice a day: http://people.debian.org/~joerg/dinstall.html
[12:56] <geser> and ftp.debian.org is only a normal mirror, so it won't see new packages more often than that
[01:06] <persia> geser: Right.  I was looking at a package that is in experimental, but doesn't show yet in packages.qa.debian.org, but as I investigate, I'm beginning to think I'm confusing a meta-package with a provider package.
[01:12] <superm1> hi persia 
[01:12] <persia> superm1: Hello
[01:12] <superm1> persia, I didn't notice an upload this morning after soyuz came back to life.  Could you still do that?
[01:12] <persia> superm1: Sure.  I'll check my queue again, and if I can't find it, I'll push it again.  Thanks for the reminder.
[01:12] <superm1> thanks again persia 
[01:12] <superm1> talk about crazy netsplits going on
[01:12] <geser> persia: I did another try with ardour on ppa. this time with a call to env
[01:12] <geser> http://librarian.dogfood.launchpad.net/7747184/buildlog_ubuntu-gutsy-i386.ardour_1%3A2.0.2-2ubuntu2%7Eppa2_FAILEDTOBUILD.txt.gz
[01:12] <geser> the HASH is there
[01:12] <Kmos> geser: bug 124744
[01:12] <ubotu> Launchpad bug 124744 in balazar "Please sync balazar (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/124744
[01:12] <persia> geser: Interesting.  Any idea what it means?
[01:12] <superm1> do only ~ubuntu-motu and ~core-dev get access to ppa, or do all ubuntu members get access too?
[01:12] <persia> Kmos: Isn't balazar dependent on the new libode?
[01:12] <persia> superm1: At this point, only certain testers have access, which is neither of -motu nor -core-dev.  Later, it will be available to a wider audience.
[01:12] <Kmos> persia: really don't know
[01:12] <superm1> persia, launchpad beta testers?
[01:12] <superm1> or is it another group
[01:12] <persia> superm1: I'm not really the best person to ask.  Sorry.
[01:12] <superm1> i'll poke around #launchpad.  thx
[01:12] <geser> persia: the first time it occured I asked on #ubuntu-devel and the guess was that is looks like a perl hash
[01:12] <geser> Kmos: have you tested if it build in a gutsy pbuilder? what about the needed versions of python-soya and python-cerealizer mentioned in the changelog. are they in gutsy already?
[01:12] <persia> geser: It does, but I'm not sure how that would get exported to the local environment, but only on the buildds.  Perhaps something is generating too many fields, so $foo shows the address of @foo, rather than the expected content.
[01:12] <nixternal> I am writing a package analyzer, I think I will call it persia :)
[01:12] <nixternal> howdy persia 
[01:12] <geser> as I've now a verbose build log I will dig out that old thread on ubuntu-devel
[01:12] <Kmos> https://launchpad.net/ubuntu/+source/python-soya -> page not found
[01:12] <persia> nixternal: That'd be confusing.  How about Medes?
[01:12] <nixternal> hehe, well since persia finds everything and then some, I figured that would be the perfect name :)
[01:12] <persia> nixternal: 90% of what I find comes from lintian and linda :)
[01:12] <nixternal> from your lintian and linda, not mine :)
[01:12] <nixternal> but now I have taken all of the package test commands I have found and added them to scripts
[01:12] <Kmos> geser: i'll test it at my pbuilder
[01:13] <Kmos> geser: it works fine with pbuilder.. the balazar one
[01:15] <Kmos> geser: can you do the sync ?
[01:16] <geser> Kmos: I want to go to bed now, I'll look at it tomorrow (if nobody else does it)
[01:17] <Kmos> geser: ok, thanks
[01:17] <Kmos> good night :)
[01:18] <geser> thanks
[01:19] <persia> superm1: Reviewing my logs, I didn't upload.  Trying again, the changelog patches don't apply to the current releases.  My apologies for not getting back to you earlier.
[01:20] <superm1> that's a bit odd that the changelog pach didn't apply to the current release
[01:20] <superm1> i diffed the current release to that one
[01:20] <superm1> did you try to diff the new patch to the old patch i did perhaps by accident?
[01:25] <superm1> *apply the diff to the directory after appying the old one
[01:28] <persia> superm1: I downloaded and unpacked the available source (`apt-get source foo`), and applied the patches (`cd foo; patch -p1 < ../foo.diff`).  In both cases, I'm seeing rejections between two UNRELEASED versions: do I have the right diffs?
[01:31] <persia> superm1: I think I found it: it appears that in your master, 0.20.1+fixes13837-0.0ubuntu1 is unreleased still, whereas I see that version in gutsy.  Perhaps you want 0.20.1+fixes13837-0.0ubuntu2?  Also, you might want to update the trunk changelog to match the previous gutsy upload.  Alternately, perhaps someone else already did this?
[01:33] <superm1> 13837 is in gutsy?....let me double check here what happened then
[01:33] <superm1> one sec
[01:38] <superm1> okay 13737 is whats in gutsy still -
[01:38] <superm1> the trunk changelog should have reflected that too.
[01:38] <persia> superm1: No, you're right.  I can't read.  Still, http://paste.ubuntu-nl.org/29304/ is an example of the rejects (they are basically the same).
[01:38] <superm1> persia, here is the correct changelog: http://codebrowse.launchpad.net/~ubuntu-mythtv/mythtv/ubuntu/annotate/supermario%40portablemario-20070709151729-41vq6i0x2ezcwmte?file_id=changelog-20061207062049-3pdmp6d4dhibhg0b-3
[01:38] <superm1> i'm not sure how it was messed up in the diff (as I bzr commit'ed it before i made the diff)
[01:40] <persia> superm1: Right.  It looks like s/UNRELEASED/gutsy is required for the patch, but I'm not sure that nothing else is affected.  Could you send me another set, without any UNRELEASED lines?
[01:40] <superm1> persia, not until i get home from work - within about an hour
[01:40] <persia> superm1: Sure.  No rush :)
[02:28] <RAOF> StevenK: If you're interested, nouveau works again :)
[02:28] <superm1> persia, i think i see what happened here
[02:28] <superm1> when keescook last committed, he accidently left a few changelog.* entries
[02:28] <superm1> so thats why i didn't see them in my local 13737 branch, whereas they are there from the source package on the archives
[02:28] <persia> superm1: Ah.  That makes sense.  Everything is clean now then?
[02:28] <StevenK> RAOF: Nice. :-) I did what you suggested, and sent off a renouveau dump
[02:28] <RAOF> StevenK: Yay.
[02:28] <RAOF> Now I'm building mesa to try glxgears :)
[02:28] <superm1> persia, the branch never got any of his changelog.* files, i don't see why diff -urN didn't delete them though when you patched
[02:28] <persia> superm1: The deletions weren't indicated in the diff, so it had a conflict.
[02:28] <StevenK> RAOF: Mesa 7?
[02:28] <persia> superm1: More generally, patch knows it's primitive, so it requires that every addition or deletion in an affected section be indicated, or it assumes that there is version skew, and human interaction is required.
[02:28] <superm1> persia, i'll mail you a new patch that does that then
[02:28] <superm1> i just made one and it does do so
[02:28] <RAOF> StevenK: git head.  That's where the nouveau dri modules hide
[02:28] <Q-FUNK> can anyone think of a way of generating a dependency based on the version number of a build-depends and some {substitution} variable?
[02:28] <persia> superm1: OK.  Please send two, and please make sure they apply cleanly to the repository sources :)
[02:28] <superm1> double checking as we speak :)
[02:28] <StevenK> RAOF: Ah, so 7.0 + crack. :-)
[02:28] <superm1> remind me to throw something at keescook for leaving the .BASE, .OTHER files :)
[02:28] <persia> Q-FUNK: It helps to know the language affected, and more about what you're trying to do: there are several ways to do it.
[02:28] <RAOF> StevenK: Yup ;)
[02:28] <keescook> whaaa?  I left over merge files??
[02:30] <Q-FUNK> persia: the depends is supposed to be foo-bar-core and version number equal to foo-dev. I was wondering if perhaps misc:Depends might be a good candidate.
[02:30] <keescook> superm1: err, what'd I break?
[02:30] <superm1> keescook, in the last mythtv upload, the debian directory had a few changelog.* files
[02:30] <superm1> that weren't resolved in conflict merge i take it
[02:30] <keescook> _doh_
[02:30] <superm1> they weren't there in the bzr branch
[02:34] <superm1> so persia was going to upload a next set of changes and we couldnt figure out why the diffs were applying cleanly here
[02:34] <superm1> and not there
[02:34] <keescook> s
[02:34] <persia> keescook: Might I leave this to you, as you've the repository configured already?
[02:34] <superm1> no problem keescook, but as a punishment you have to take care of bug 124842 :)
[02:34] <ubotu> Launchpad bug 124842 in lirc "Package new lirc version" [Undecided,In progress]  https://launchpad.net/bugs/124842
[02:34] <keescook> persia: I don't have it checked out at the moment -- I had to do some clean ups last week and it got wiped.
[02:38] <keescook> superm1: heh, yeah, I saw that one -- I'll get it done, but my time this week is rather limited.  :)
[02:38] <persia> keescook: OK.  We'll get on with it then.  No problems.
[02:40] <RAOF> StevenK: Woo!  glxgears runs!
[02:44] <StevenK> RAOF: Way cool.
[02:44] <StevenK> RAOF: What about crack-attack? :-)
[02:44] <persia> Q-FUNK: I've just reviewed the listed uses of misc:Depends in dh_*, and none seem to apply in your case.  is foo a library package?  If so, you can probably do it with shlibs:Depends.  If it's python or perl, python:Depends and perl:Depends might also help.
[02:44] <persia> RAOF: Does glxgears still run if it's wider than it is tall?
[02:44] <RAOF> persia: Well, it runs.  But not correctly
[02:44] <Q-FUNK> persia: none of the above.
[02:44] <persia> RAOF: Ah.  Soon then...
[02:44] <RAOF> I havent tried to break it by spawning multiple glx windows yet.  Last time I tried that, it took a reboot to re-initalize the card correctly :)
[02:44] <StevenK> RAOF: Be a man, and try crack-attack? :-)
[02:44] <RAOF> StevenK: What's crack attack?
[02:44] <StevenK> Description: multiplayer OpenGL puzzle game like "Tetris Attack"
[02:44] <RAOF> Uuuuh.  That probably uses textures.  Nouveau doesn't do textures yet :)
[02:44] <StevenK> Heh. That rules out most screensavers, too. :-)
[02:44] <RAOF> Absolutely correct.  Thanks for reminding me, I need to prevent the lappy from trying that :)
[02:44] <StevenK> Heh
[02:44] <StevenK> RAOF: It also rules out compiz, which maps X windows into OpenGL textures. :-)
[02:45] <persia> superm1: There's not a few lintian warnings pending.  You might want to schedule a cleanup at some point :)
[02:50] <superm1> persia, in the 'mythtv' package lintian should be pretty clean
[02:51] <superm1> only thing that comes up is W: mythtv source: changelog-should-mention-nmu
[02:51] <superm1> in mythplugins however, there are two missing debhelper tokens, but they were giving me trouble when they were there, so i'll sort those out next upload
[02:52] <persia> superm1: missing debhelper can be a concern: this means that none of the automated things will be included: you may want to check which routines would otherwise have been included, to make sure you have covereage.
[02:53] <keescook> superm1: lirc uploaded -- nice work!  I adjusted your changelog slightly to add the "#" needed in (LP: #nnnnn) for auto-bug-closing.
[02:53] <superm1> thanks keescook :)
[02:53] <superm1> persia, from the run through many times in a VM, it appeared to be fine thus far, i will make sure for the next upload though that it works with them there
[02:54] <superm1> night keescook 
[03:03] <TheMuso> Yay! Desktop images seem to be building again.
[03:19] <StevenK> ScottK: Is that your usual state of mind? :-P
[03:19] <ScottK> Only when I'm having network troubles.
[03:19] <ScottK> That's the 3rd nick on my list and I've been AFK.
[03:19] <StevenK> Ah
[03:19] <StevenK> It's more your IRC client being confused, as opposed to you being confused?
[03:19] <ScottK> Yes.
[03:31] <StevenK> ScottK: Or when you've just shown someone you are by accident? :-)
[03:31] <ScottK> That would be one set of circumstances that would qualify as cornered.
[03:35] <ScottK> Speaking of confused...
[03:35] <ScottK> I have a package that now has a config file that I am trying to install into /etc/packagename/filename.  I get a permission denied error when I build the binary.  Any suggestions on how to deal with that.  It's a cdbs package.
[03:35] <crimsun> what's the complete error?
[03:35] <StevenK> Install into $DESTDIR/etc/packagename/filename, or /etc/packagename/filename?
[03:35] <ScottK> Ah.  That may explain it.
[03:35] <ScottK> mv: cannot move 'policy-spf.conf' to '/etc/python-policyd-spf': Permission Denied.
[03:35] <StevenK> ScottK: That also shows why we use fakeroot to build packages, and not sudo. :-)
[03:35] <ScottK> I think that's exactly what the problem is.
[03:35] <ScottK> Thanks.
[03:35] <ScottK> Yep.
[03:35] <minghua> Hmm, using sudo to build package is so much more dangerous than I thought.
[03:35] <StevenK> Mainly because it allows you to shoot yourself in the foot and blow your whole leg off.
[03:35] <persia> superm1: Both uploaded.  Due to timing issues, mythtv should take up to 15 minutes to appear.
[03:35] <superm1> okay thanks persia.  I'll get those other lintian odds and ends cleaned up for next time too
[03:35] <superm1> mythplugins will show up in the queue "after" mythtv though still right?
[03:35] <persia> superm1: Great!, and No :(
[03:35] <superm1> well with this release it hopefully won't be too big a deal - it will just build against the older mythtv
[03:35] <superm1> in the archive
[03:35] <superm1> but i dont anticipate any large library changes recently
[03:35] <superm1> so it should end up fine
[03:35] <persia> superm1: I didn't see any library changes (but I didn't look really hard), so it should just work.
[03:35] <superm1> okay i'm gonna go make some dinner right now, cya later persia 
[05:37] <ScottK> StevenK: Thanks for the hint.  My package update is uploaded to Debian.
[05:39] <StevenK> ScottK: No problem
[06:33] <Q-FUNK> hm
[06:34] <Q-FUNK> any way to tell dh_mkshlibs that we depend on an extra package of a specific version?
[06:35] <Q-FUNK> non-library, but same idea as -Vlibfoo (>= version)
[06:41] <StevenK> You can't just mention it explicitly?
[06:53] <ScottK> StevenK: Is Adept fixed yet?
[06:53] <ScottK> Err
[06:53] <ScottK> StevenK: is Apt fixed yet?  Sorry, wrong package.
[06:54] <StevenK> mvo fixed it.
[06:54] <ScottK> Cool.
[06:55] <ScottK> Other than ooo, is there anything that's particularly broken just now?
[06:55] <RAOF> Soft!  You're not already running a pure gutsy/sid install?
[06:55] <ScottK> No.
[06:56] <Q-FUNK> StevenK: no, since it has to be substituted every time the package is built
[06:56] <persia> ScottK: It's early yet.  You might at least want to wait for Tribe 3.  Something breaks here about once a day or so.
[06:56] <ScottK> Then at least if it gets broken someone had to actually do something.
[06:56] <StevenK> Q-FUNK: Ah, you can use substvars.
[06:56] <ScottK> persia: I understand.  That's why I've got a spare hard drive for the laptop.
[06:56] <StevenK> ScottK: OO.o is unbroken on amd64. *hint* :-)
[06:56] <Q-FUNK> StevenK: yes indeed, but how?
[06:56] <ScottK> Except the arch all parts are still broken.
[06:58] <ScottK> or/of
[06:58] <Q-FUNK> StevenK: debian/$pkg.substvars gets deleted at build time
[06:58] <persia> ScottK: You might want to configure a chroot to match your system (with dpkg --get-selections and dpkg --set-selections) and test the upgrade first - that way you can see the broken package list before you really upgrade.
[06:58] <StevenK> Q-FUNK: Actually, it gets deleted during clean
[06:58] <ScottK> persia: Good idea.
[06:59] <Q-FUNK> StevenK: right, so how can I pass variables to debhelper to generate extra substvars?
[06:59] <StevenK> Q-FUNK: I have no idea. substvars are how ${shlibs:Depends} are generated, but I've never needed to do it.
[07:00] <Q-FUNK> right, so I cannot used substvars
[07:00] <StevenK> ScottK: Wimp. My main desktop has been running Feisty for 2 months.
[07:00] <StevenK> Q-FUNK: Why not?
[07:00] <persia> ScottK: For Dapper -> Feisty, you probably want to go by way of Edgy: the LTS upgrade path isn't as well tested.
[07:00] <StevenK> ${shlibs:Depends} are expanded at build time, it sounds like exactly what you want.
[07:01] <StevenK> persia: What LTS upgrade path? There is no second LTS realease.
[07:01] <ScottK> persia: If I do it directly, it'll be when I have time to fight it.  I might get to file some good bugs.
[07:01] <persia> StevenK: Right.  When there is, suddenly someone will start looking at the upgrade path :)
[07:02] <persia> ScottK: True, actually.  Good luck.
[07:02] <StevenK> I daresay a bunch of people will. :-)
[07:02] <ScottK> Good morning Hobbsee.
[07:03] <ScottK> Good night all.  I'm going to bed.
[07:05] <Hobbsee> hey ScottK 
[07:06] <RAOF> Hey Hobbsee
[07:06] <Hobbsee> hi RAOF 
[07:08] <StevenK> steven@blerk:~% cat /sys/block/sr0/size
[07:08] <StevenK> 4
[07:08] <StevenK> I think I know why Gnome refuses to burn disks now.
[07:12] <superm1> morning Hobbsee 
[07:13] <Hobbsee> hi superm1 
[07:13] <superm1> it appears you fixed apt :)
[07:13] <Hobbsee> i didnt fix it, mvo did
[07:13] <Hobbsee> but yeah
[07:15] <imbrandon> apt://new_computer
[07:15] <Hobbsee> hah
[07:16] <superm1> imbrandon, didn't you read the post, that only works in FF right now :)
[07:16] <TheMuso> Heya Hobbsee.
[07:16] <Hobbsee> hi TheMuso!
[07:17] <imbrandon> superm1, its worked in kde a long time as long as you have the apt kio slave :)
[07:17] <TheMuso> What was up with apt?
[07:17] <Hobbsee> TheMuso: it made everything else installing wise not install
[07:18] <TheMuso> Hmm ok. Didn't notice anything amiss with my chroots.
[07:22] <StevenK> TheMuso: I'm guessing no adept or anything special in them.
[07:25] <imbrandon> can the archive admins sync from mentors ?
[07:25] <StevenK> I can't recall a request to do so.
[07:26] <imbrandon> hrm
[07:31] <Q-FUNK> StevenK: because nobody knows how.
[07:34] <StevenK> Q-FUNK: Read dpkg-source(1)
[07:35] <Q-FUNK> StevenK: you mean dpkg-gencontrol(1)
[07:36] <StevenK> % zcat /usr/share/man/man1/dpkg-gencontrol.1.gz
[07:36] <StevenK> .so man1/dpkg-source.1
[07:38] <Hobbsee> more likely that just no one has asked yet
[07:39] <StevenK> Actually, ubuntu-restricted-extras does it.
[07:39] <Hobbsee> does it?
[07:39] <Hobbsee> StevenK: uh, how?
[07:40] <StevenK> Read debian/rules, it uses substvars, if I recall correctly.
[07:42] <Hobbsee> StevenK: true that.  i was thinking you meant about syncing from mentors, with u-r-e somehow doing that..
[07:43] <StevenK> No, no, nothing like that.
[07:43] <Hobbsee> dammit.  u-r-e doesnt work.
[07:44] <white___> hi
[07:44] <Hobbsee> hi white___!
[07:45] <white___> what a nick :(
[07:45] <Hobbsee> heh
[07:48] <yigal> hello i need help deciding where i should put my time.  i am a member of MOTU Science - I am not MOTU, but I don't use Ubuntu at least I haven't for 3 months and have been using Debian unstable.  I don't seem to have any energy to help package for a distribution I am not using and which seems to not be pulling its weight when it comes to producing "new" versions of packages - which I understand is Ubuntu's goal of being an ups
[07:48] <white___> yigal: what is your point?
[07:49] <yigal> excuse me s/understand is/understand is not/
[07:49] <yigal> white___: no point, I am trying to find a solution for myself
[07:49] <ajmitch> hi white_______
[07:49] <white___> yigal: i do not think that anyone is forcing you to work on opensource :)
[07:49] <white___> yigal: you can work on whatever you want
[07:49] <white___> ajmitch: hi :)
[07:49] <white___> damn cold here :(
[07:50] <ajmitch> be glad you're not here then
[07:50] <man-di> white___: got too much '_' on your keyboard? ;-)
[07:50] <white___> ajmitch: i am in melbourne
[07:50] <white___> man-di: bah freenode does not give me my nick back :(
[07:50] <ajmitch> white___: and melbourne != dunedin :)
[07:50] <yigal> white___: that's awesome for you not reading what I am saying
[07:50] <Hobbsee> !ghost | white___ 
[07:50] <ubotu> white___: On IRC, if you own a nick that is currently being used, you can make it quit by typing: /msg nickserv GHOST <username> <password>
[07:51] <ajmitch> yigal: what you said got cut off
[07:51] <yigal> cut off?
[07:51] <yigal> too long?
[07:51] <man-di> yigal: cut off
[07:51] <ajmitch> ...is Ubuntu's goal of being an ups
[07:51] <yigal> sort of distribution, but any way if anyone has anything to write I would really appreciate it.
[07:52] <yigal> i did not have much more to say?
[07:52] <yigal> i like the latest and greatest but i like ubuntu's community
[07:52] <man-di> yigal: I dont get what you wanna say at all
[07:52] <yigal> i am angry at ubuntu but i want to understand
[07:52] <yigal> basically
[07:53] <man-di> you want to understand why you are angry?
[07:53] <yigal> it seems that ubuntu takes all of debians work and packages it as its own product
[07:53] <yigal> excuse me s/seems/"appears to me"
[07:53] <yigal> i know this is not the full picture
[07:53] <yigal> but 
[07:54] <yigal> good
[07:54] <yigal> how so?
[07:54] <man-di> both sides get good things from eayh other
[07:54] <white> well, that's better
[07:54] <yigal> i am sorry if this is not an appropriate place to air my concerns
[07:55] <yigal> what things, for instance does debian get, other than a pool of possible people who will migrate from ubuntu to debian after some time?
[07:55] <yigal> i am sorry if i sound harsh, i really am
[07:55] <white> yigal: you know who is active in core developments, such as gcc/g++?
[07:56] <white> and to the best of my knowledge, this also counts for dpkg
[07:56] <yigal> no. maybe this will help, ubuntu ?
[07:56] <yigal> :)
[07:56] <yigal> ?
[07:56] <yigal> white: you have your name 
[07:56] <man-di> some of the core development for Debian is done in Ubuntu
[07:56] <yigal> that makes me feel good
[07:56] <white> yigal: i am not talking about myself, i am not developing for ubuntu :)
[07:57] <white> (and i am certainly not doing any devel stuff for dpkg or gcc :) )
[07:57] <yigal> no, no it doesn't matter
[07:57] <ajmitch> actually quite a few people in here are debian developers :)
[07:57] <man-di> there are two communities that write bug reports and if looking and fixing both you will improve the other side automatically
[07:57] <yigal> man-di: open source at its best
[07:57] <yigal> ok, i feel a lot better already
[07:57] <white> yigal: there are parts which need to be improved, that is true. But we are not at the point, where we see ubuntu as the devil
[07:57] <yigal> :)
[07:58] <man-di> white: well some do, but we can easily ignore them
[07:58] <white> yigal: if you are interested in improving the communication and stuff, i can certainly help you and give you some work :)
[07:58] <yigal> not devil spoiled child is more how I thought of it before this conversation - white: i would very much appreciate this
[07:59] <white> yigal: right now, the review of the new packages added to universe is stucked in a sense that nobody from the debian site controls, if they should be added to debian main
[07:59] <white> i used to write mails to the ubuntu developers, asking them if they want to maintain the package in debian, but i ran out of time for this
[07:59] <white> feel free to continue with it
[07:59] <white> i had some scripts in place, which send me mails about new packages added to ubuntu universe, which were not in debian
[08:00] <yigal> it just seems problematic after receiving 20-30 emails/day telling me that some science program is being synced from debian unstable 
[08:00] <white> there might be some false positives, but all in all you could do some communication work there
[08:00] <yigal> hmm ok
[08:00] <white> what is the current ubuntu release name?
[08:00] <yigal> i will have to think - at least I am not angry any more
[08:00] <yigal> Gutsy
[08:01] <yigal> or Feisty?
[08:01] <white> yigal: that is good, hate is boring ;)
[08:01] <man-di> gutsy
[08:01] <yigal> white: :)
[08:01] <man-di> gutsy is the development distro, feisty latest stable
[08:01] <white> man-di: thx
[08:02] <white> yigal: let me just adjust my scripts
[08:03] <yigal> ok
[08:03] <white> yigal: i have always seen it as an important part. Asking the maintainer, where it is appropriate, reviewing the package and maybe sponsoring it
[08:04] <yigal> by "it" you mean, Im sorry white Im a little confused?
[08:04] <yigal> the scripts?
[08:04] <yigal> or the communication
[08:04] <yigal> oh, thats funny of me, sorry
[08:04] <white> yigal: taking care of the resyncing of packages from ubuntu universe to debian main
[08:05] <yigal> ah
[08:06] <yigal> well i am more confused now than anything else - which is good - complexity rather than simple false models
[08:07] <yigal> best, have a great day
[08:08] <white> and now he left without telling me his email address?
[08:11] <StevenK> I found that a little pointless, anyway
[08:13] <white> StevenK: you mean the communication part thing or the person who just left?
[08:13] <StevenK> The latter.
[08:14] <StevenK> "Oh, I'm so angry, you guys steal from Debian ..."
[08:14] <white> well it seems that you are right ...
[08:15] <imbrandon> ...
[08:16] <imbrandon> StevenK, got a moment ?
[08:16] <StevenK> imbrandon: Sure.
[08:17] <imbrandon> StevenK, a package i grabbed from mentors i'm looking at sponsoring , mind putting another set of eyes on it ? http://revu.tauware.de/details.py?upid=5945
[08:17] <imbrandon> ran a revu-build on it too
[08:17] <imbrandon> to make it easyier
[08:18] <imbrandon> its basicly a mapper for rdp->xvnc
[08:19] <StevenK> mkdir -p /tmp/buildd/xrdp-0.4.0/debian/xrdp/usr/man/man5
[08:19] <StevenK> mkdir -p /tmp/buildd/xrdp-0.4.0/debian/xrdp/usr/man/man8
[08:19] <StevenK> If I'm reading that right, that's bad.
[08:20] <StevenK> Hrm. It seems it's fixed in debian/rules. Still bad.
[08:22] <imbrandon> hrm
[08:23] <white> somebody here familiar with valknut?
[08:24] <StevenK> mv $(CURDIR)/debian/xrdp/usr/man $(CURDIR)/debian/xrdp/usr/share
[08:24] <StevenK> Twitch.
[08:24] <imbrandon> haha i was just noticing that
[08:26] <StevenK> imbrandon: Personally, I'd rather that was fixed properly.
[08:26] <imbrandon> yea it looks like this needs a bit more work than i thought ...
[08:26] <imbrandon> nother day or two wont hurt
[08:45] <Sp4rKy> please, what's the new Maintainer team for a universe package ?
[08:48] <Hobbsee> sarah@LongPointyStick:~$ cat scripts/update-maintainer | grep MOTU
[08:48] <Hobbsee>         "universe"|"multiverse")    email="Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"  
[08:48] <Hobbsee> Sp4rKy: ^
[08:49] <Sp4rKy> ok thx
[08:49] <StevenK> Useless use of cat!
[08:49] <Sp4rKy> :)
[08:50] <Hobbsee> StevenK: i know.  habit.
[08:54] <TheMuso> Oh lovely.
[08:54] <TheMuso> I am getting gobbldygook from LP.
[08:54] <TheMuso> So much that I can't even get to the link to disable it temporarily.
[08:55] <TheMuso> nvm, went to the monepage, and disabled it.
[08:55] <TheMuso> homepage even
[08:58] <LucidFox> What should I do if an application uses a GUI build configurator?
[08:59] <StevenK> Sob. Very loudly.
[08:59] <TheMuso> LucidFox: What do you mean exactly?
[08:59] <LucidFox> actually, never mind
[09:00] <LucidFox> well, "configure" is a Qt application that displays a GUI window where one can specify build options
[09:00] <RAOF> ...!
[09:00] <LucidFox> but never mind, this one seems to have a command-line mode as well
[09:00] <StevenK> *TWITCH*
[09:01] <ajmitch> that's pretty special
[09:01] <Hobbsee> .....that's.....well, special's one word for it
[09:01] <Flannel> what app is that?
[09:03] <Hobbsee> LucidFox: you should tell the author of it to PUT *DOWN* THE CRACK PIPE, IMMEDIATELY!!!
[09:04] <Flannel> makes me wonder how much time was wasted on creating that configure doohickey
[09:04] <LucidFox> Flannel> qdvdauthor
[09:05] <StevenK> Yeah, but the author of qdvdauthor is a crack-head.
[09:21] <imbrandon> mmmm crack
[09:24] <RickH> Can anyone help me with a glib problem?
[09:25] <RickH> I'm getting this:
[09:25] <RickH> *** 'pkg-config --modversion glib-2.0' returned 2.13.6, but GLIB (2.12.11) was found!
[09:26] <RickH> I've tried everything I can think of to fix it.  I think gnome-devel is installing 2.12.11, but I'm not sure.
[09:45] <LucidFox> http://revu.tauware.de/details.py?upid=5943 <-- isn't xchat-gnome in main, not universe?
[09:46] <TheMuso> LucidFox: Use apt-cache madison to find out where the package is located.
[09:46] <RickH> Can anyone help me with a glib problem?
[09:46] <RickH> I keep getting:  "*** 'pkg-config --modversion glib-2.0' returned 2.13.6, but GLIB (2.12.11) was found!" when I try to install GTK+-2.10.13.
[09:47] <RickH> I don't know how to resolve this.
[09:47] <LucidFox> http://archive.ubuntu.com/ubuntu/pool/main/x/xchat-gnome/ <-- yes, it's in main
[09:47] <LucidFox> but REVU is for universe/multiverse only, isn't it?
[09:47] <imbrandon> no
[09:48] <imbrandon> but it is only for new packages, not ones in the archive already
[09:48] <imbrandon> updates should be attached to LP
[10:45] <LucidFox> ScottK, I have corrected qconf per your comments: http://revu.tauware.de/details.py?upid=5947
[10:46] <persia> LucidFox: In general, you'll get the best package if you get reviews from lots of different people, rather than repeated reviews from the same person.  As a result, it's preferred to ask the channel generally, rather than a specific person when requesting review of a package.
[10:47] <LucidFox> well, he was the one who commented on the REVU page
[10:48] <TheMuso> persia: Just got a reply from mdz on -devel to geser's sconz post. Doesn't explain why it works for us however.
[10:50] <persia> TheMuso: I think we need to grab a buildd admin and go over several failures.  It may be due to bugs in scons, but I'm not sure the lack of replication is clear in the current discussion.  This week is probably not ideal, due to the sprint, but soon...
[10:51] <TheMuso> persia: Yes. We (UbuntuStudio) really would like ardour.
[10:52] <persia> TheMuso: I'm not sure you need such a restricted We :)  I suspect there are many other parties who would prefer not to have gtk+ 1.2 based ardour, even if they don't use it.
[10:53] <TheMuso> persia: heh true.
[10:53] <TheMuso> bbl dinner
[10:53] <persia> (my interest is the support for MIDI transport, but still... )
[10:59] <imbrandon> brb
[11:23] <LucidFox> bad-version-number 1.0~rc1-0ubuntu1
[11:23] <persia> LucidFox: If that is from your lintian output, it's safe to ignore.
[11:24] <LucidFox> ok
[11:33] <persia> (apologies to those in the mid-pacific - please feel free to continue REVU day if you like)
[12:18] <persia> siretart: Is emacs22 still expected in the near future?  Is there a time estimate, or does it require additional work still?
[12:27] <persia> siretart: Sorry.  Ignore that.  I see it now :)
[12:40] <TheMuso> Is it just me, or are others showing as not logged in when viewing bug lists/bug details on edge?
[12:41] <TheMuso> Ok, that time I got crap.
[12:41] <TheMuso> TIme to disable again...
[01:17] <DktrKranz> persia, about your comment in http://revu.tauware.de/details.py?upid=5924, pitti suggested to manage them as separate source packages.
[01:19] <persia> DktrKranz: OK.  Does that mean that http://revu.tauware.de/details.py?upid=5701 should be pulled from the queue?
[01:19] <DktrKranz> persia, it can be dropped
[01:20] <DktrKranz> we will upload it again if there will be need of
[01:20] <persia> DktrKranz: OK.  Thanks.  Archiving...
[01:46] <TheMuso> Evening RAOF.
[01:46] <RAOF> Evening TheMuso 
[01:48] <ScottK> persia: That bad version number is not IAW Debian Policy.  Why is it safe to ignore?
[01:49] <ScottK> "~" is not allowed in upstream version.
[01:49] <siretart> persia: emacs22 is still in source NEW, AFAIK
[01:49] <persia> siretart: Right.  Sorry for bothering you.
[01:49] <siretart> persia: there are quite some important updates to the emacs22 package pending in the packaging branch
[01:49] <siretart> mwolson is doing a really great job
[01:49] <persia> ScottK: It works, and sorts before.  I'll hunt up a reference for you in a minute.
[01:50] <siretart> I queued his other upload after the emacs22 approval
[01:50] <persia> siretart: OK.  mwolson has also prepared a bunch of new updates for other things waiting on emacs22.  They all look clean, but I can't upload them yet.
[01:51] <Fujitsu> Urgh, why is this website saying Medibuntu is an official Ubuntu repository?
[01:51] <ScottK> persia: Just because it may work at the moment, I don't think that means it should ignored.  Here's the policy ref: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[01:51] <Fujitsu> ScottK: It's used all the time...
[01:52] <Sp4rKy> Fujitsu: what website ?
[01:52] <Fujitsu> I don't think Debian policy has been updated to reflect the addition of ~
[01:52] <ScottK> OK.  So this is one of those times that the policy is wrong and we all know it, but it hasn't been updated?
[01:52] <Fujitsu> http://linuxondesktop.blogspot.com/2007/07/35-cool-applications-to-install-on.html
[01:52] <persia> ScottK: ~ is only about a year old - it takes a while to filter into policy :)
[01:52] <ScottK> OK.
[01:53] <ScottK> Consider me properly thwacked.
[01:53] <persia> ScottK: See the changelog for dpkg (1.10.11)
[01:53] <ScottK> OK.
[01:53] <persia> (Sorry - 3.5 years old)
[01:54] <persia> ScottK: I'm fairly sure it was feisty (or dapper) lintian complaining about XubuntuY.  That's where I usually see that report originating.
[01:54] <broonie> Well, the support was added in dpkg ages ago.
[01:55] <broonie> But in order to allow packages to be unpacked on the latest stable it wasn't allowed to be used in Debian until that dpkg was in stable.
[01:55] <persia> broonie: So, officially it wasn't correct until the Etch release?
[01:56] <Yagisan> ever spent 3 days looking for the bug in your program, when it was GCC that was actually broken instead ?
[01:56] <siretart> persia: right. mwolson agreed to subscribe the 'ubuntu-elisp' team, so that the emacs related uploads are kept together for batch processing
[01:56] <persia> siretart: Shall I unsub U-U-S in the meantime?
[01:56] <broonie> persia: It may have been sarge, I can't remember.
[01:59] <siretart> persia: as you wish, but I still see u-u-s appropriate for those debdiffs
[02:00] <persia> siretart: OK.  I'll just leave them there a bit longer, hoping NEW processing happens in due course :)
[02:00] <Yagisan> could someone on i386/amd64 on gutsy confirm if this bug still exists *before* I upgrade -> https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/125031
[02:00] <ubotu> Launchpad bug 125031 in gcc-4.1 "defines BIG_ENDIAN on little endian machines" [Undecided,New]  
[02:02] <ScottK> LucidFox: You might also look into why qconf_1.3-0ubuntu1.diff has several empty directories and a bunch of makefile spew in it.
[02:04] <ajmitch> ok, rc bugs + comments works for me, I'll push it somewhere public tomorrow, perhaps
[02:04] <Yagisan> night ajmitch 
[02:04] <persia> ajmitch: Thanks a lot!
[02:06] <LucidFox> ScottK> ok
[02:08] <LucidFox> hmm
[02:10] <LucidFox> I don't see any empty directories, but the .qconftemp directory is indeed redundant and shouldn't be in the diff
[02:11] <doko> RainCT: what's the reason to set severity for sync requests?
[02:12] <RainCT> doko: they don't need any?
[02:13] <RainCT> doko: (tought they should be wishlist in order to don't count as bugs in the stats)
[02:19] <LucidFox> http://revu.tauware.de/details.py?upid=5952 <-- this should be better, no temp directories
[02:19] <LucidFox> and a smaller diff overall
[02:19] <xxxxx1> good morning all (?) :)
[02:28] <RainCT> doko: so?
[02:29] <doko> RainCT: these bugs are usually short-lived, and just tagging them wishlist without looking at the changelog sounds like the wrong thing
[02:29] <doko> but you may ask the archive admins
[02:32] <Fujitsu> doko: I often consider going through and wishlisting them, because they greatly clutter bug listsings.
[02:32] <Fujitsu> *listings
[02:37] <persia> Fujitsu: Why is it a metabug?  If we wanted to cherrypick, we'd do so.
[02:40] <TheMuso> Could anybody have a look at the build log found here, and tell me why its crapping out? http://www.themuso.id.au/ubuntu/buildlogs/
[02:41] <persia> TheMuso: Looks to me (without digging) like the definitions in stat.h and cmd.o don't match properly.
[02:41] <RainCT> (OT) is pynotify installed by default on Ubuntu / Kubuntu?
[02:41] <TheMuso> persia: Right.
[02:43] <TheMuso> c
[02:43] <TheMuso> ugh
[02:44] <RAOF_> It's not going to be the same when you get that fixed :)
[02:45] <RAOF_> Ah.  My acx woes are bug 118539
[02:45] <ubotu> Launchpad bug 118539 in linux-ubuntu-modules-2.6.22 "[regression]  acx does not load" [Undecided,Confirmed]  https://launchpad.net/bugs/118539
[02:46] <RAOF_> No wireless for you!
[02:46] <TheMuso> Looks like it could be a gcc thing, as 1.1-4 was done in April last year, and the latest 1.1-4ubuntu revision in LP appears to have built.
[02:47] <TheMuso> bloody edge. Spitting crap at me again.
[02:57] <ScottK> RainCT: It's in Main, so something installs it. https://launchpad.net/ubuntu/+source/notify-python (I assume that's the same).
[02:57] <Q-FUNK> can anybody think of a way to make debhelper generate substvars e.g. misc:Depends content via debian/rules?
[02:58] <RainCT> ScottK: ok, thanks (yes, it's the same)
[03:01] <persia> Q-FUNK: Must you use debhelper to generate it?  If you know what you want, you could just cp debian/substitutions debian/subtcars before the debhelper calls.
[03:05] <man-di> persia: nice typo: subtcars
[03:46] <TheMuso> c
[03:46] <TheMuso> ugh
[03:47] <RAOF_> :)
[03:56] <yamal> any revu admin: please remove any and all of sabnzbd from incoming so I can re-upload. Thanks.
[04:03] <persia> yamal: Sure.  I'll let you know when it's gone.
[04:04] <persia> yamal: Try uploading again.
[04:05] <yamal> persia: on it
[04:07] <yamal> done
[04:08] <persia> motu-mentoring-reception team: are there any guidelines on who has what shifts when, or should I just pick one of you randomly for an update?
[04:09] <StevenK> Ugh. Finally. I *think* I have all of the libflac++ transition done.
[04:10] <StevenK> Doesn't help that I had to rewrite parts of the FLAC code for 2 of the packages by hand.
[04:11] <TheMuso> StevenK: Ouch.
[04:13] <StevenK> If I set GPG_TTY, you use pinentry-curses. Use pinentry-gtk2, damn it!
[04:24] <yamal> ladies & gentlemen, "my first package" (sabnzbd) is awaiting your expert comments at http://revu.tauware.de/details.py?upid=5953
[04:26] <imbrandon> !kernel
[04:26] <ubotu> kernel is the core of the Ubuntu Operating System (named 'Linux') - see https://help.ubuntu.com/community/Kernel.  You shouldn't have to compile one, but if you're convinced you do, see https://wiki.ubuntu.com/KernelCustomBuild
[04:30] <jekil> anyone can review please? http://revu.tauware.de/details.py?upid=5896
[04:32] <StevenK> persia: And in answer to your question about emacs22, it's in source NEW.
[04:32] <xxxxx1> join #ubuntu-devel
[04:32] <persia> StevenK: Yep.  I saw it there about 10 minutes after I was confused.  Unfortunately, I have yet to find the "undo" feature for globally distributed communication systems :)
[04:32] <xxxxx1> ops
[04:33] <StevenK> persia: You and me both. :-)
[04:35] <persia> So, this new "NewPackageRequirements" page mentions the suspicious-source script in the ubuntu-dev-tools package.  Anyone know where I can find the package?
[04:37] <ScottK> persia: IIRC it's in bzr.
[04:38] <persia> yamal: Commented.
[04:42] <persia> ScottK: I thought that was the motu reviewing tools package.  Is it the same one?
[04:43] <geser> persia: ubuntu-dev-tools is in bzr and nearly packaged (some licences missing)
[04:44] <persia> geser: OK.  I still think "package" isn't the right term yet, but no worries :)
[04:44] <yamal> persia: what license is commonly used for the packaging? gpl or is there some specialized one?
[04:45] <persia> yamal: I recommend using a license compatible with your source package.  In general, GPL and PubDom are good choices.
[04:46] <ScottK> yamal: Same license as the stuff you are packaging is a safe/useful choice.
[04:46] <yamal> then gpl it is, as most of the package is under that, too
[04:47] <geser> persia: if you want to test it out https://code.launchpad.net/ubuntu-dev-tools is the location for it
[04:48] <geser> yamal: which version of the gpl?
[04:48] <persia> jekil: Advocated.
[04:48] <yamal> geser: rest of package is 2 (or later)...
[04:48] <persia> geser: I'll wait :)  My experience with pre-repository packages has usually been negative.
[04:49] <jekil> persia: thank you a lot :)
[05:39] <jussi01> hmmm, anyone know how to make a command run on a remote machine via ssh, even after you have closed the ssh terminal?
[05:40] <mgalvin> jussi01: automatically or manually? manually just background it... command &
[05:41] <jussi01> mgalvin: ok, so just add an & on the end of the command and close the terminal?
[05:41] <mgalvin> jussi01: yes, that should do the trick for you
[05:42] <jussi01> mgalvin: thanks! that helps a lot!
[05:42] <jussi01>  :)
[05:42] <mgalvin> jussi01: np, glad to help :)
[05:52] <tsmithe> hi all; i would be very grateful of anyone free to sponsor ubuntustudio-sounds and usplash-theme-ubuntustudio ;)
[05:57] <geser> jussi01: man nohup
[06:00] <sladen> tsmithe: are they any good ;-)
[06:01] <tsmithe> sladen, of course :)
[06:56] <ScottK> StevenK: You don't mind if I take clamav back for a new merge do you?
[07:20] <ScottK> shawarma: Have you got a moment to help with a shell scripting problem?
[07:22] <shawarma> ScottK: sure thing. 
[07:22] <shawarma> ScottK: If you hurry, that is. :)
[07:22] <ScottK> If you recall the clamav postinst fix you helped me with...
[07:23] <shawarma> I do.
[07:23] <ScottK> The Debian maintainer adopted it, but I think screwed it up.
[07:23] <ScottK> He changed newal='which newaliases' ||true
[07:23] <ScottK> to newal='which newalisases || true'
[07:23] <ScottK> The later (on a system that has newaliases) returns /bin/true
[07:23] <shawarma> Those are backticks, surely?
[07:24] <ScottK> Yes.
[07:24] <ScottK> Copy/Paste isn't working for me on IRC for some reason.
[07:24] <lucas> ScottK: it doesn't
[07:24] <shawarma> ScottK: No, it's ok.
[07:24] <ScottK> And now that you mention it, I don't think I used back ticks when I tried it.
[07:24] <lucas> it works here
[07:24] <ScottK> OK.
[07:25] <shawarma> The stuff after || does not get executed if the stuff before it succeeds.
[07:25] <shawarma> And even then, /bin/true does not return anything.
[07:25] <ScottK> Ah.  OK.
[07:25] <shawarma> I'm afraid I have to run away now. I'll be around in 4 hours time.
[07:25] <ScottK> Thanks.
[07:27] <ScottK> Sure enough.  Works fine when I use back ticks.
[07:27] <ScottK> Thanks too lucas.
[07:29] <lucas> I reported that bug in debian actually ;)
[07:29] <ScottK> Odd.  I sent them a patch after shawarma helped me figure it out.
[08:04] <ScottK> StevenK: I didn't think so.  Uploaded.
[08:24] <jussi01> is signal 11 == ctrl + c in terminal?
[08:24] <jussi01> nm
[08:25] <geser> signal 11 is segmenation fault
[08:26] <geser> ctrl-c should be SIGTERM (15)
[08:26] <geser> see also man 7 signal
[08:54] <hendrixski> could somebody recomend a guide for setting up an schroot?
[08:54] <Kmos> geser: you forget bug 124744
[08:54] <ubotu> Launchpad bug 124744 in balazar "Please sync balazar (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/124744
[08:58] <minghua> hendrixski: schroot(1) man page is not good enough?
[09:00] <hendrixski> minghua, ya know, that would be the most obvious one which means that I haven't tried it yet 
[09:00] <hendrixski> lol
[09:03] <sommer> ScottK: hey
[09:03] <sommer> I was wondering if anyone
[09:03] <ScottK> Hi
[09:03] <sommer> is working on the sylpheed-claws packages for clamav
[09:03] <ScottK> Not that I know of.
[09:04] <ScottK> We'll definitely need those done.
[09:04] <sommer> cool I'll work on those next.
[09:04] <ScottK> If you're up for it, go for it.
[09:04] <sommer> MIMEDefang is pretty cool.
[09:04] <sommer> thinking about switching from MailScanner...heh
[09:08] <hendrixski> minghua, there's nothing in there about how to debootstrap a file system into an schroot
[09:09] <geser> Kmos: see my comment on that bug
[09:10] <minghua> hendrixski: Sorry, can't help you much, I also only use dchroot (and not often even for that).
[09:10] <sommer> ScottK: will the symoblic link in /var/spool/MIMEDefang be added to the postinst too?
[09:11] <ScottK> I think so.
[09:11] <Kmos> geser: ok
[09:12] <ScottK> minghua: Do you really thing bug #103482 is SRU worthy?  There was some debate about it on #ubuntu-bugs while you were offline.
[09:12] <ubotu> Launchpad bug 103482 in r-cran-psy "[can-not-install]  postrm failure" [Medium,Triaged]  https://launchpad.net/bugs/103482
[09:13] <hendrixski> minghua, :-) thanks anyway
[09:14] <minghua> ScottK: There is no fix yet.  I suspect a missing Pre-Depends, but I'm not sure and haven't looked carefully yet.
[09:15] <ScottK> Right.  I guess the question is, is it worth fixing at all in Edgy.  I suspect that most who will upgrade have already done so.
[09:15] <minghua> ScottK: Debian never shipped 0.70-1 in a stable release, so fixing this is not important there.
[09:17] <minghua> ScottK: My personal preference is not touching non-LTS release's -updates at all.  But this affects dapper, so I'll eventually look at it.
[09:17] <ScottK> Ah.  For Dapper I would agree.
[09:17] <minghua> ScottK: I don't care about edgy-updates at all, to be honest.
[09:17] <ScottK> OK.  How about I mark it fix-released and then add tasks for dapper and edgy and wontfix the Edgy one?
[09:18] <minghua> ScottK: Sounds good to me.  I'll probably assign the dapper one to myself if nobody take it in a few days.
[09:18] <ScottK> OK.
[09:20] <sommer> ScottK: I just retested p3scan and the clamav user doesn't need to be in the p3scan group.
[09:20] <sommer> I think I added from reading a guide somewhere, but it's not strictly needed.
[09:20] <ScottK> OK.  Then update the wiki
[09:20] <ScottK> Feel free to delete my comment.
[09:20] <sommer> I'm all over it.
[09:25] <mohammad> Hello, would someone please review http://revu.tauware.de/details.py?upid=5955 It had some licensing issues. Now all are resolved.
[09:29] <ScottK> mohammad: I saw your comment on REVU.  It's on my list for (hopefully) today.
[09:29] <mohammad> ScottK: ok thank you so I will wait :) see you then
[09:38] <blueyed> I have updated a package with the current upstream release (popfile). We sync this from Debian. How do I get it into Debian? Is it enough to create a bug and attach the debdiff there?
[09:39] <ScottK> No.
[09:39] <ScottK> blueyed: You should contact the Debian maintainer and ask them if they are interested in uploading the package to Debian.
[09:40] <blueyed> ok. Even better.. just one email ;)
[09:50] <Baby> what is the package? :)
[09:52] <ScottK> Baby: He said popfile.
[09:53] <broonie> The usual approach is to file a wishlist bug against the package in Debian asking for a new upstream release.
[09:53] <ScottK> Actually it looks like the Maintainer may well be MIA.
[09:53] <broonie> That way if there is some reason for not doing the upload then it's more obvious.
[09:54] <ScottK> It look like the maintainer has only touched one package in the last couple of years http://qa.debian.org/developer.php?login=lwall@debian.org
[09:55] <ScottK> Good point about the wishlist bug.
[09:59] <RickH> Anyone feel up to helping me with the Brasero MOTU/Recipe example?  I'm getting a problem during the "debuild -S -sa" operation.
[10:00] <icf7> RickH: Could you post the error message?
[10:00] <RickH> Yeah, it's several lines.
[10:00] <RickH> Is that okay?
[10:00] <icf7> RickH: pastebin.ca
[10:00] <geser> !paste
[10:00] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[10:01] <RickH> okay, just a sec
[10:02] <minghua> ScottK: I see plenty of activities on that Debian QA page, the most recent being April this year.  So the maintainer is definitely not MIA.
[10:02] <RickH> How do I indicate where it is?  It says "Posted by RickH on July 10th 22:01"
[10:02] <RickH> Ah!  http://paste.ubuntu-nl.org/29406/plain/
[10:02] <icf7> RickH: Do you have a well-configured gpg key?
[10:02] <ScottK> minghua: Other than the one package it looked like nothing had been updated in a long time.  I guess one update is enought to not be MIA>
[10:03] <RickH> I assume the problem is that my GPG key is not under "rick@rick-desktop", but rather a different email address.
[10:03] <minghua> ScottK: Maybe there just aren't much to update. :-)
[10:03] <RickH> ?  But, I don't know how to set that.
[10:03] <geser> that's only about signing and independent from the actual build (debuild builds the package and tries to sign it)
[10:04] <RickH> So, the source is extracted, just not signed?
[10:04] <minghua> RickH: Most likely you have the uploader email wrong in debian/changelog.
[10:04] <RickH> Very possibly.
[10:04] <RickH> I didn't know to change that. :)
[10:04] <geser> a source package is build but not signed (signing is only important for uploading)
[10:04] <icf7> RickH: just edit debian/changelog
[10:05] <geser> RickH: use dch to edit debian/changelog (it's in devscripts)
[10:06] <RickH> got it
[10:06] <icf7> RickH: And I don't know the policy, but a global email address (rickh@example.org) instead of a local allows others to contact you
[10:06] <RickH> it was set to rick@rick-desktop.
[10:06] <RickH> I hadn't run source at that time, maybe?
[10:06] <RickH> BTW, I'm a total newbie to Linux development.  I began using Ubuntu on Sunday. :)
[10:07] <minghua> !packagingguide
[10:07] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[10:07] <minghua> RickH: It would be good if you read some documentation first then.
[10:08] <RickH> minghua:  I'm going through the MOTU/Recipe doc right now.
[10:09] <RickH> That's when I found this error.
[10:11] <minghua> Okay.  I don't really know much about the docs.  But skimming show that page assumes some basic understanding of the packaging.
[10:12] <RickH> I would agree. :)
[10:13] <RickH> I'm now getting the same message for my proper setup:  "secret key not available"
[10:13] <ScottK> Did you make a key that uses the same e-mail address you are using?
[10:13] <RickH> yes
[10:13] <ScottK> OK.
[10:14] <ScottK> Then it's probably debian/changelog related.
[10:14] <minghua> Check with "gpg --list-secret-keys" to be sure, I would suggest.
[10:14] <ScottK> Which version of Ubuntu are you running?
[10:14] <RickH> Okay.  Thanks!
[10:14] <RickH> Fesity Fawn, 7.04
[10:14] <RickH> desktop version
[10:15] <icf7> minghua: Problem is there are no good docs, and existing ones are scattered, as I pointed out here: https://wiki.ubuntu.com/MOTU/Documentation/Wishlist . Feel free to add a suggestion or comment on this.
[10:15] <RickH> Is it the uid portion?
[10:15] <minghua> icf7: I know doc situation is not very good.  But as I said, I don't know much about documentations.
[10:16] <frafu> I am currently using this: http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[10:16] <frafu> might be helpful
[10:16] <RickH> frafu:  Thanks!
[10:17] <minghua> I already gave that URL above...
[10:17] <minghua> The packaging guide is generally quite good, but a little outdated.
[10:17] <RickH> Just what an uninformed, ignorant newbie likes to hear. ;)
[10:17] <minghua> icf7: "A central and complete list of all rules and recommendations", I think there is no such thing.
[10:18] <frafu> I logged in a few minutes ago; sorry 
[10:18] <icf7> minghua: Yes, and that's the problem. gentoo has a central, although short documentation on everything
[10:18] <jussi01> hmmm, how do I make soemthing compile with gcc 3.x instead of 4.x?
[10:19] <tsmithe> jussi01, build it and see what needs fixing
[10:19] <minghua> icf7: I meant "You can't get a complete list of all rules, they are constantly changing".
[10:20] <icf7> minghua: Then why not document this change?
[10:20] <jussi01> tsmithe: i build it and it gives me a seg fault
[10:20] <icf7> minghua: ebuilds are far simpler than debian packages ;)
[10:20] <tsmithe> jussi01, the resulting binary or the compiler?
[10:20] <minghua> icf7: Not enough manpower.  There are probably hundreds of rules.  Listing them all doesn't make much sense.
[10:20] <tsmithe> jussi01, can you get a stack trace?
[10:21] <icf7> minghua: Where are they listed now?
[10:21] <geser> jussi01: build-depend on the right gcc package and make sure that it gets used
[10:21] <minghua> icf7: In Debian, each team/tool has its own documentation.
[10:22] <minghua> icf7: New tools are invented, old tools are improved, so I don't think it make sense to have a central place for all documentations.
[10:22] <icf7> minghua: I have no problem with tool documentation, this is about packaging guidelines.
[10:22] <man-di> icf7: different tools are used for packaging
[10:22] <minghua> Well, if you package use certain tools/language/platform, you need to abide by those rules.
[10:23] <icf7> man-di: I know, thanks to you ;) , but why not create subpages for individual tools?
[10:24] <geser> icf7: the packaging guidelines depend on the tool used and may get outdated as the tools improve
[10:24] <man-di> icf7: there are too many of them
[10:25] <icf7> geser: Well, there is a high number of tool-independent rules, like indenting debian/copyright. I could swear someone here showed me a link on how to do it, but man-dir told me my version was totally incorrect.
[10:27] <icf7> man-di: afaik (yet), there are debhelper/CDBS and maybe a few else to generate debian/rules. Apart from this, a lot of things do not change. And even if they do: Why should changes be documented somewhere instead of e.g. a central wiki?
[10:29] <tsmithe> man-di, did you get a chance to see wired?
[10:30] <geser> icf7: the debian policy has a chapter how debian/changelog should look like
[10:31] <icf7> geser: debian/*copyright* . The chapter on debian/changelog is one of the best in the whole debian policy, partly because the use BNF
[10:32] <geser> I should read better :)
[10:32] <broonie> Note that the changelog needs to be machine parsable.
[10:33] <icf7> BNF-like, to be precise
[10:34] <geser> icf7: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html has some guidelines (linked from the maintainer guide)
[10:35] <icf7> geser: Thanks for illustrating my point about obscure and distributed sources ;) . man-di told me there should be no indenting at all for the main text, and 4 spaces for the license
[10:37] <broonie> It really makes no difference so long as it is legible.
[10:39] <icf7> broonie: It does, how am I supposed to find that posting, deduce it's how to do it, and that as a new contributor who's glad dpkg-buildpackage runs for the first time without any errors?
[10:41] <xxxxx1> bye all
[10:41] <broonie> icf7: It's just pointing out stuff that's already in the existing docs (well, the link to the reject FAQ probably isn't but...).
[10:42] <broonie> I'd suggest filing a bug on the developers reference in Debian asking for any missing stuff to be added (perhaps the example would be a good idea)
[10:42] <icf7> broonie: Which existing docs? And could you point me to a documentation that says the license in debian/copyright should be indented with 2 spaces?
[10:43] <RickH> It worked.  It required the full uid, including the comment.
[10:44] <icf7> broonie: That's a good idea, but this is a general problem that there are lots of invalid packages which follow all the guidelines in the docs (aka Debian Policy Manual), and even vice versa
[10:45] <broonie> icf7: You can indent the copyright file however you feel like so long as it is legible; that is just an example there (where it improves the legibility for the multipe GPL blocks)
[10:47] <icf7> broonie: man-di told me otherwise. That's my point: There is no central, unique, and *binding* instance although it would rapidly enhance packaging, especially for non-MOTUs
[10:48] <broonie> In terms of Debian things become best practice long before they are binding policy.
[10:49] <man-di> icf7: such a doku would be much bigger when wikipedia, when complete
[10:50] <man-di> icf7: and as broonie said, Debian isnt so formal, you are allowed to do things as you like
[10:50] <broonie> Excluding technical requirements like the transition to the Python policy the list of things you *should* do will always lag the documentation.
[10:50] <icf7> man-di: I doubt that, if it's limited to packaging
[10:50] <broonie> Really.
[10:51] <man-di> icf7: feel free to look at some of the bigger packages
[10:51] <broonie> Consider things like the array of patch systems - there's none, quilt, dpatch, dbs and others.
[10:51] <man-di> icf7: like gcc, eclipse, openoffice.org
[10:52] <broonie> It's only very recently that it was decided to kill debmake, for example.
[10:52] <man-di> icf7: if you package them accroding to some guideline you would fail
[10:52] <man-di> icf7: and e.g. there are still packages using yada as build system
[10:52] <icf7> man-di: I did (Firefox, Eclipse, Konqueror, hello and others), and mimicking their solutions often turns out to be partially or fully wrong
[10:53] <broonie> It's a bit like the adoption of bzr packaging in Ubuntu - it's being pushed, it's quite probably a good idea but it's not 100% there yet.
[10:54] <icf7> broonie: That maybe the case because (new) packagers don't even find the name on the Ubuntu packaging guidelines and wherever else they look.
[10:54] <broonie> The best approach to widespread adoption (where possible) is often to get lintian to warn about not doing it :0
[10:55] <icf7> broonie: Exactly, and lintian is equivalent to matching a set of BNFs
[10:56] <broonie> Well, not quite. But note that it is overridable and that it's not always possible (hence the "where possible").
[10:57] <broonie> In any case, I'd suggest starting with a wiki page linking to best practices and also tracking efforts to push the information there back into more formal documentation.
[10:58] <icf7> broonie: I'll do that after my exams, I am going to begin working on it about 2007-8-1, I'll try to publis it about a week later
[10:58] <avoine> when MOTU upload to ftp://upload.ubuntu.com they only upload a .dsc and a .changes files and the autobuilder build the .deb for each architecture?
[10:59] <icf7> avoine: dput uploads also the *.orig.tar.gz and a few more files
[11:00] <geser> avoine: in principle yes
[11:00] <avoine> ok
[11:00] <avoine> thanks
[11:01] <gnomefreak> crimsun: are you around?
[11:02] <gnomefreak> crimsun: ill brb i have to reboot real fast
[11:07] <ScottK> cromo: When gnomefreak gets back, you might want to point out Bug #125131.
[11:07] <ubotu> Launchpad bug 125131 in flashplugin-nonfree "Need to be updated for new stable version (9,0,48,0)" [Undecided,New]  https://launchpad.net/bugs/125131
[11:07] <cromo> ScottK: ok
[11:08] <gnomefreak> ok lets see what we got
[11:08] <ScottK> gnomefreak - Bug #125131.
[11:08] <ubotu> Launchpad bug 125131 in flashplugin-nonfree "Need to be updated for new stable version (9,0,48,0)" [Undecided,New]  https://launchpad.net/bugs/125131
[11:09] <ScottK> It seemed relevant.
[11:09] <gnomefreak> ScottK: last i heard many big regresstions in latest
[11:09] <ScottK> I wasn't sure how recent that release was since the bug was just reported.
[11:10] <ScottK> Maybe some of them got fixed.
[11:10] <cromo> I updated it a bit
[11:10] <RickH> Do other people use other Linux distros?  Is Debian the best?  It seems to be much easier to use than others I've tried.
[11:11] <gnomefreak> ScottK: well something is wrong with it either way, md5 should match unless adobe played with thier site
[11:11] <ScottK> Sure thing.
[11:11] <cromo> gnomefreak: maybe they updated the package?
[11:12] <gnomefreak> the changelog isnt showing a change for this
[11:13] <cromo> well, maybe a repackaging ;-)
[11:13] <RickH> I should've said:  "Does anyone here use other Linux distros as well?"  Is/are Debian-based distros the best you've used?
[11:13] <cromo> RickH: this is a distro-war request...
[11:14] <gnomefreak> cromo: the script is either looking in wrong place or adobe screwed something upfor s
[11:14] <icf7> RickH: You're asking in the wrong channel, try in #opensuse, #rhel , #slackware , #gentoo , #debian ;)
[11:14] <RickH> Point taken, icf7. :)
[11:15] <icf7> ... and starting a massive flame war
[11:15] <RickH> Feel free to kick me if you'd like. :)  I'm tough.  I can take it. :)
[11:15] <cromo> kick RickH ;-)
[11:15] <gnomefreak> now that is a small rules file if ive ever seen one :(
[11:17] <gnomefreak> i think this is more of an adobe issue as everything seems to look atleast as sane as we can get it
[11:18] <cromo> hold on a sec
[11:18] <cromo> I'll see how it's here under archlinux
[11:19] <cromo> that's the md5sum the packagin script here is expecting: 76b38231a68995935185aa42dfda9db7
[11:19] <gnomefreak> if its looking for install_flash_player_9_linux.tar.gz than its gonna grab latest stable.
[11:19] <cromo> yeah, I just had a look at the URL and it's the same
[11:20] <cromo> I wonder why doesn't the tarball name doesn't obey the common rules and include the version number... 
[11:20] <gnomefreak> cromo: same as what ubuntu is lookng for
[11:21] <cromo> everytime I see some kind of package distributed as such I have a strong feeling the software developer is actually linux-newbie
[11:21] <cromo> yeah, good point, too
[11:23] <cromo> I grepped the package for strings, it's a 9.0.48 indeed
[11:23] <cromo> they updated the package
[11:24] <cromo> er, they updated the plugin
[11:28] <RainCT> good night
[11:29] <gnomefreak> im about to lose power :(
[11:30] <gnomefreak> wonder if we can go with embedded tarballs so this doesnt keep happening
[11:30] <qball> anybody here knows how well epm works?
[11:31] <cromo> gnomefreak: what does the flashplugin license says about that?
[11:31] <gnomefreak> WGETRC=wgetrc wget http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz \
[11:31] <gnomefreak> that would be the reason
[11:32] <cromo> indeed
[11:32] <gnomefreak> our package expects the same version we have had and adobe used same named tar for newest version (common i would think)
[11:32] <cromo> gnomefreak: we have exactly the same case here under archlinux
[11:32] <gnomefreak> looking at lic.
[11:33] <gnomefreak> blame adobe
[11:33] <gnomefreak> :)
[11:33] <cromo> yeah...
[11:33] <gnomefreak> ummmm thats odd
[11:34] <ScottK> gnomefreak: What is the copyright file for?  The stuff that grabs the Flash or the Flash?
[11:35] <gnomefreak> looks like the scripts
[11:35] <gnomefreak> ScottK: but either way shouldnt it hold adobes as well?
[11:35] <ScottK> I'd have to look.
[11:35] <ScottK> Which I'm not going to do right now.
[11:36] <gnomefreak> hell i dont blame you :)
[11:39] <gnomefreak> well im gone beofre power goes out. will look at it tomorrow(upstream version) see how bad its screwed up.
[11:39] <gnomefreak> noght
[11:40] <cromo> gnomefreak: opera won't work with it
[11:40] <cromo> as they changed the method of embeeding
[11:40] <gnomefreak> that doesnt suprise me a bit
[11:40] <cromo> *they means Adobe
[12:06] <Q-FUNK> silly question, but how do I cross the bridge from NM to MOTU?