[12:15] <hendrixski> why can't dpkg-buildpackage find configure-stamp when there's a patch system attached?
[12:19] <hendrixski> *sigh, umm... google has zero results for this so I'm asking here.. .. dpkg-buildpackage -rfakeroot gives me "make: configure-stamp: Command not found"
[12:19] <hendrixski> what am I possibly doing wrong?
[12:20] <Nafallo> installed build-essential?
[12:20] <Nafallo> you might want to look in debian/rules what configure-stamp is supposed to do as well
[12:21] <hendrixski> yes, of course.... build-essential, debhelper, and dpatch... all there... all I did to debian/rules was add patch-stamp into build-stamp and unpatch into clean
[12:22] <Nafallo> weird
[12:22] <hendrixski> Nafallo, configure stamp does the same thing it did when it was created by dh_make:  "dh_testdir" and "touch configure-stamp"
[12:23] <Nafallo> try tabbing those to see if they are installed.
[12:23] <Nafallo> I would be surprised if they wasn't thou
[12:24] <hendrixski> Nafallo, they tab-completed in bash
[12:24] <Nafallo> weirdness then
[12:25] <Nafallo> you might want to pastebin parts of that rules
[12:25] <hendrixski> k
[12:25] <hendrixski> !paste
[12:25] <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)
[12:26] <hendrixski> oops... should've messaged ubotu for that :-( sorry
[12:26] <Nafallo> no problem :-)
[12:27] <hendrixski> http://paste.ubuntu-nl.org/29725/
[12:27] <geser> hendrixski: re "patch-stamp": that makes sense as patch-stamp is an other target (and not a command) which you specify as a dependency for an other target
[12:28] <hendrixski> geser, ??? whoa what??  
[12:28] <geser> hendrixski: merge line 81 (from the paste) into line 80
[12:29] <geser> make also know dependencies, which target (or file) must be run to be able to run this target
[12:30] <hendrixski> like this:   build-stamp: patch-stamp configure-stamp
[12:30] <geser> yes
[12:30] <hendrixski> ooohhh, so the first line is the dependency for that rule?
[12:30] <geser> build-stamp get only run if patch-stamp (the file created by the target of the same name) and configure-stamp exist
[12:31] <geser> yes
[12:32] <hendrixski> that definately explains a lot
[12:32] <hendrixski> it's like the more of these mistakes I make the more small things I learn and eventually I'll be able to look at a debain/rules and understand what it does
[12:33] <geser> dpkg-buildpackage calls IIRC the binary target, for the binary target to run must first binary-indep and binary-arch be run
[12:34] <geser> for binary-arch must the targets build and install be run 
[12:34] <geser> and so on
[12:36] <geser> in the end are configure, make, make install, etc. run in the right order to create a deb
[12:37] <hendrixski> I see... I didn't catch that from reading any of the manuals...
[12:39] <hendrixski> Man.. There is a TON of information I'd like to add to http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html   like that for example... or how to use diff
[12:40] <hendrixski> YES!!!!! it worked!!!!!  and the program runs with my patch and all!!!
[12:41] <hendrixski> geser, Nafallo,  THANK YOU :-)
[12:42] <Nafallo> no problem. I barely did anything :-)
[12:42] <Nafallo> don't accuse me! I'm innocent! :-)
[12:44] <hendrixski> Nafallo, you got the ball rolling, then handed it off the geser, who scored the goal... in most sports that counts as an "assist" (and helps the athletes sallary go up)
[12:45] <Nafallo> sports. sounds... like something I should know about... I think. has it anything to do with murder? :-)
[12:47] <hendrixski> Nafallo, yup... feeding Christians to lions was a sport once
[12:47] <Nafallo> kewl!
[12:47] <Nafallo> one of my names is Christian
[12:47] <Nafallo> :-P
[12:49] <hendrixski> LOL:  one of my names is Ijustmademyfirstdebianpackagelastnight and another one is Ijustmademyfirstdpatchtoday
[12:49] <Nafallo> hehe :-)
[12:50] <Nafallo> a bit to long for my taste.
[12:50] <Nafallo> should be difficult enough to write your signature ;-)
[12:51] <hendrixski> I could just scribble and draw a few lines the way I do for my regular signature
[12:51] <Nafallo> ;-)
[12:52] <hendrixski> I have two I's and an  in my last name.. so I just turn them into really long lines that hover above a squigle...
[12:52] <hendrixski> now followup question...
[12:53] <hendrixski> adding a patch to a package generally means changing the name right? or are there some that just add patches but keep the same name?
[12:54] <pygi> hendrixski, what do you mean?
[12:54] <pygi> changing the name of what?
[12:54] <pygi> package?
[12:56] <hendrixski> like if I add a patch to helloworld-0.2-1... does it have to turn turn into helloworld-0.2-2, or is that optional?
[12:56] <hendrixski> the package... yes
[12:56] <pygi> hendrixski, it has to turn into -2, yes
[12:56] <pygi> in reality you'd have for example:
[12:57] <pygi> brasero_0.6.0-0ubuntu1 --> brasero_0.6.0-0ubuntu2
[12:58] <hendrixski> pygi, I see... so do I just rename the .deb file or is there a tool that makes the name change for me?
[12:58] <pygi> hendrixski, no, no!
[12:58] <pygi> hendrixski, you do the change in debian/changelog
[12:59] <pygi> actually in some cases when you use "dch -i" it'll do that for you
[12:59] <hendrixski> oh... right... forgot about that
[01:00] <hendrixski> nice, it even drops me into my favorite editor :-)
[01:00] <pygi> hehe :)
[01:01] <pygi> vim, emacs, nano? :)
[01:01] <hendrixski> vim
[01:01] <pygi> hehe, nice :)
[01:04] <hendrixski> hhhmmmm... had a debian/menu this time... but it didn't appear in my applications menu
[01:10] <hendrixski> the menu file looks right...  ?package(hellonurse):needs="X11|text|vc|wm" section="Apps/Accessories"  title="hellonurse" command="/usr/bin/hellonurse"
[01:10] <hendrixski> is there something I need to put in debian/rules or something to access it?
[01:38] <Spec> errr
[01:39] <Spec> do i sign the .dsc file detached or attached?
[01:42] <Fujitsu> Spec: You use debsign on the .changes
[01:45] <Spec> Fujitsu: i'm on a windows box
[01:45] <Spec> Fujitsu: scp'd .dsc and .changes over here...and i was told i could just sign those two files...but i don't know if it's an attached sign or a detached sign
[01:49] <Fujitsu> Spec: It's meant to be inline.
[01:50] <Fujitsu> (building packages on a Windows machine is *really* *really* wrong)
[01:51] <Spec> err, i built it on linux
[01:51] <Spec> it's just the machine i built it is a shared machine, so i don't wanna put my gpg key on it
[01:51] <Fujitsu> Ah.
[01:51] <Spec> as other people have root and i don't know them, therefore don't trust them
[01:51] <Spec> and they've remotely "ifconfig eth0 down"'d remotely  before
[01:51] <Spec> err, s/remotely/moo/
[01:53] <Jazzva> Umm, I have a problem testing a package with pbuilder. This is the last part of the output -> http://www.pastebin.ca/617031
[01:54] <Jazzva> I guess the problem is at dh_installdocs. It asks for CHANGES~, but it isn't present. Does anyone know how can I fix that?
[01:55] <Fujitsu> Jazzva: Check debian/docs in the source package.
[01:56] <Jazzva> Aha, I see... It lists README and CHANGES~ files. So, dh_installdocs trys to find CHANGES~, doesn't succed and then reports an error, right? Should I just remove CHANGES~ from debian/docs?
[01:57] <ryanakca> Jazzva: if CHANGES~ isn't in $(CURDIR) (the root of the sources), then remove it from debian/docs
[02:00] <Jazzva> ryanakca: It isn't, but there is CHANGES, should I include that one in debian/docs? It documents upstream authors' changes from previous versions, so I think it would be useful to include it.
[02:01] <ryanakca> I would substitute CHANGES~ with CHANGES in debian/doc
[02:01] <ryanakca> if it's permissible to include an Upstream changelog in docs... dunno, check the Debian Policy Manual
[02:01] <Jazzva> ryanakca: That's what I meant :). Thanks for the help.
[02:03] <ryanakca> Jazzva: http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs
[02:03] <Jazzva> ryanakca: Thanks for the link.
[02:05] <ryanakca> hmm. Any debian maintainers willing to take a quick look at http://revu.tauware.de/details.py?upid=5992 please?
[02:11] <Jazzva> ryanakca: I'm not sure how am I supposed to install CHANGES as changelog.gz. Any hint?
[02:11] <ryanakca> Jazzva: I think it should get done automatically
[02:12] <Jazzva> ryanakca: Oh, ok. :)
[02:37] <martoss> hi guys
[02:37] <martoss> i am trying to build an updated package of pymol.
[02:37] <martoss> i started from the sources via "apt-get source pymol"
[02:38] <martoss> then i applied the patch, to a directory i checked out via svn, which created me the debian/*  and modified some stuff.
[02:38] <martoss> dpkg-buildpackage: source version without epoch 0.98+0.99rc6-2ubuntu2
[02:38] <martoss>  fakeroot debian/rules clean
[02:38] <martoss> /usr/bin/fakeroot: 152: debian/rules: Permission denied
[02:38] <martoss> this is where I got stuck.
[02:38] <martoss> Any ideas?
[02:41] <martoss> argh, forgot to make it executable.
[02:45] <minghua> martoss: "applied the patch, to a directory i checked out via svn, which created me the debian/*" sounds very wrong.
[02:46] <minghua> martoss: You should already have all debian/* stuff after you did "apt-get source pymol".
[02:46] <martoss> hmm ok, maybe i didn't express correctly
[02:46] <martoss> minghua, yep, this produced me the old source with debian directory
[02:46] <italianninja2> hi can someone help me
[02:46] <martoss> i tried to build a package from the svn directory.
[02:46] <italianninja2> ubuntu wont load gui?
[02:47] <martoss> italianninja2, load the gui? You mean the X-Server?
[02:47] <minghua> italianninja2: Please ask for support on #ubuntu, not here.
[02:48] <italianninja2> they are not answering me ther
[02:48] <italianninja2> e
[02:51] <martoss> minghua, ok maybe my question in a more general form: i wanna checkout sources from sourceforge of pymol. then build a debian package from it
[02:52] <martoss> i got the sources with debian directory from feisty and now i need to modify the svn sources correspondingly. Or do I miss sth.
[02:52] <minghua> martoss: That's not exactly an easy task.  And I don't have time to guide you though it, sorry.
[02:53] <martoss> ok, i play around a bit...
[02:53] <martoss> it's not urgent
[02:53] <minghua> martoss: However, I see that gutsy already has pymol 1.0-1, so you should try backporting the gutsy package first.
[02:54] <martoss> aye!
[02:54] <martoss> introducing additional patches should be easy
[03:10] <persia> DarkMageZ: The Debian maintainer would be best.
[03:11] <persia> ScottK: I'm mostly interested in dumping wx2.4 (which is very broken).  2.6 is acceptable, but it's a loose Lenny target, so I don't really expect it until gutsy+2 or thereabouts
[03:11] <persia> pygi: Great.  Keep watching: it should be done soon.
[03:11] <persia> ryanacka: Hurrah!  That's easiest
[03:11] <persia> hendrixski: There are two menus.  Ideally, you want both a menu file and a .desktop file
[03:11] <persia> TheMuso: My current ETU is about now+90 minutes.  If you get to it first, that'd be great.
[03:16] <ajmitch> Fujitsu: where's your monotone sync bug?
[03:18] <Fujitsu> ajmitch: I was test-building it and it failed right after I closed that. I'm looking at uploading it shortly.
[03:19] <ajmitch> it worked for me
[03:19] <ajmitch> I've been using it for a couple of days with no problems
[03:19] <ajmitch> what version did you grab?
[03:19] <Fujitsu> It works unless you're not building arch-all.
[03:20] <Fujitsu> The build-depends-indep stuff is needed for an arch: any build too.
[03:20] <ajmitch> exciting
[03:20] <ajmitch> obviously the debian maintainer did test-build, just not in the same way you did
[03:20] <Fujitsu> Well, I guess.
[03:51] <nixternal> howdy
[03:52] <RAOF> Howda
[03:56] <ajmitch> salut
[03:56] <persia> TheMuso: My estimate was off.  I'll take care of ubuntustudio-sounds now (unless you're in the middle of it).
[04:10] <Fujitsu> How often do DEPWAIT builds get retried?
[04:12] <minghua> I suppose asking in -devel has a better chance to get an answer. ;-)
[04:12] <Fujitsu> I thought someone in here might know.
[04:14] <crimsun> they're retried automatically.
[04:15] <crimsun> I don't know offhand if they're immediate, however.
[04:17] <StevenK> persia, TheMuso: It seems gimp-svg is not built from a source package any more and ubuntustudio-graphics depends on it. Are either of you able to investigate?
[04:18] <persia> StevenK: I'll take a look.  Thanks for pointing this out.
[04:19] <minghua> persia, StevenK: gimp-svg is built from gimp source package since 2.2.16.
[04:19] <minghua> (at least in Debian)
[04:20] <persia> minghua: Not for the source that my gutsy apt-cache sees :)
[04:20] <minghua> !info gimp gutsy
[04:20] <ubotu> gimp: The GNU Image Manipulation Program - DEVELOPMENT VERSION. In component main, is optional. Version 2.3.18-1ubuntu2 (gutsy), package size 4413 kB, installed size 11172 kB
[04:21] <minghua> Hmm, I should have said "... if you use the 2.2.x stable branch".
[04:21] <minghua> !info gimp feisty
[04:21] <ubotu> gimp: The GNU Image Manipulation Program. In component main, is optional. Version 2.2.13-1ubuntu4.2 (feisty), package size 2899 kB, installed size 7920 kB
[04:22] <minghua> I see.
[04:39] <persia> Erm.  Germinate is interesting.
[04:40] <jdong> tha'ts what she said?
[04:52] <persia> Is hppa 32-bit or 64-bit?
[04:53] <StevenK> Depends.
[04:53] <StevenK> My hppa at home is 32-bit, but 64-bit one are around. I'm uncertain if userland changes from 32-bit, however.
[04:54] <persia> StevenK: OK.  If an app has 32-bit assumptions in the code, should it be distributed by the Ubuntu hppa port?
[04:55] <StevenK> The Ubuntu hppa port hasn't been touched since Dapper, by the way.
[04:55] <persia> StevenK: Right.  I'll just leave it alone then.  Thanks.
[04:55] <ajmitch> people are still looking at hppa
[04:55] <Fujitsu> It's supposedly bootstrapping gutsy, though it was also supposedly bootstrapping feisty.
[04:56] <StevenK> Yeah, it was bootstrapping feisty the entire time it was in development.
[04:56] <Fujitsu> Right.
[04:57] <Fujitsu> How common is hppa, anyway? I've never seen such a machine.
[04:59] <StevenK> Becoming more uncommon, I think.
[05:02] <superm1> persia, in your comment to mythbuntu-live-autostart, you said that get-orig-source should be abel to be ran from any directory.  Are you meaning that it should be launchable from within debian/ (launched as ./ rules get-orig-source)?
[05:02] <superm1> because no rules work launching like that
[05:02] <superm1> everything wants to parse debian/control
[05:04] <persia> superm1: That, or able to be launched from within ~ when the source is in /usr/src/.  I'm not sure why that requirement is in place: perhaps you can get around it using ORIGDIR := $(shell pwd), and forcing the directory change before actually doing anything?
[05:05] <superm1> but if you are starting from somewhere else, how are you supposed to find your way to the root of the directory?
[05:06] <persia> superm1: Perhaps you can do something with $$1?  I'm not sure.
[05:07] <persia> (or perhaps $$0, rather.  I'm not entirely sure)
[05:07] <superm1> well more particularly, does this need to be followed so strictly?  I've had several other packages uploaded with a rule that works from the root of the directory
[05:07] <superm1> thats the most logical place to do it anyhow
[05:08] <superm1> since it puts it in .. for you to be able to run debuild and such
[05:08] <superm1> which was my reason to write the rule this way
[05:08] <persia> superm1: It's a "must" in debian policy, which makes it mandatory.  On the other hand, not everything in the archive is compliant.
[05:09] <superm1> well the other problem then that comes up 
[05:09] <superm1> with cdbs
[05:09] <superm1> running things outside the directory, will include the first .mk files
[05:09] <superm1> so there is no way to get around that unless you can somehow reference where that directory
[05:09] <superm1> the way that policy is written, it makes more sense for static urls, rather than bzr or svn or cvs branches
[05:10] <TheMuso> persia: Thanks. THought I would get to it, but got called away.
[05:10] <persia> superm1: Hmm...  Interesting.  So the use of CDBS prevents compliance.  in that case, I wouldn't worry about it too much.
[05:10] <superm1> i'll fix up the other issue regarding the version names, and reupload in that case
[05:10] <persia> TheMuso: No problems.  I'm currently fussing with ubuntustudio-meta so it will install again (and the NBS stuff can be purged).
[05:11] <persia> superm1: Great.  Thanks.
[05:15] <StevenK> persia: Just out of interest, what are you replacing gimp-svg with?
[05:16] <persia> StevenK: Nothing at all: the plugin is now included in the gimp package (since 2.3.18-1)
[05:16] <StevenK> Ahh
[05:16] <StevenK> Neat.
[05:18] <persia> Does anyone have any good suggestions for testing metapackages on foreign architectures?  I'd like to make sure that I'm not breaking things :)
[05:21] <superm1> okay if anyone is able to take a look and do a revu on the package persia and I were discussion, mythbuntu-live-autostart, i'd appreciate it: http://revu.tauware.de/details.py?upid=5996
[05:23] <TheMuso> persia: -sounds only has 1 advocate on REVU. How was there 2?
[05:23] <ScottK> persia: My suggestion is to tom sawyer someone with the arch to test it for you.
[05:23] <TheMuso> If it got uploaded?
[05:24] <persia> TheMuso: For ubuntustudio-sounds?  Previous guidance indicated that 1 advocate was sufficient for reupload after archive-admin rejection.
[05:24] <TheMuso> Oh ok.
[05:24] <crimsun> err, it was rejected?
[05:25] <persia> ScottK: Great :)  You can take care of i386?
[05:25] <persia> crimsun: Yep.  There were some leftover "No commercial use" bits in ./README, etc.
[05:25] <crimsun> hmph.  I wonder where the email went...
[05:25] <TheMuso> persia: If you want a non-supported arch tested, I'm happy to do ppc.
[05:25] <persia> crimsun: The rejection email?  I think only tsmithe got it.
[05:26] <persia> TheMuso: Thanks.  I'm testing locally now, and will stick the candidate somewhere when I'm done.
[05:33] <ScottK> persia: What's the package?
[05:33] <persia> ScottK: On my machine.  I want to make sure it works locally before collecting extra bug reports :)
[05:33] <persia> (should be 15-20 minutes, max)
[05:34] <ScottK> OK.  I'll test, but I have Feisty, not Gutsy.  Is that a useful test for you?
[05:36] <persia> ScottK: Not really.  Do you have a gutsy chroot in which you could try installing it?
[05:36] <ScottK> No.  Sorry.  I haven't needed one.
[05:37] <Fujitsu> ScottK: Don't you test-build packages?
[05:37] <ScottK> Fujitsu: In pbuilder, yes.
[05:37] <RAOF> Then you've got a chroot available :)
[05:37] <Fujitsu> pbuilder login
[05:37] <ScottK> Ah. Yes, of course.
[05:38] <ScottK> persia: Yes, I have a chroot available.
[05:38] <ScottK> I don't know how long I'll be here tonight though.
[05:41] <ScottK> lionel: I see you touched tftpd last.  I thought you might be interested in looking at Bug #105863.  The last comment looks like it might be enough of a hint to do something with.
[05:41] <ubotu> Launchpad bug 105863 in netkit-tftp "tftpd package broken" [High,Confirmed]  https://launchpad.net/bugs/105863
[05:43] <persia> ScottK: TheMuso: http://revu.tauware.de/revu1-incoming/ubuntustudio-meta-0707122335/ubuntustudio-meta_0.2.dsc
[05:44] <ScottK> persia: What's the upid?
[05:44] <persia> ScottK: http://revu.tauware.de/details.py?upid=5997
[05:47] <persia> Anyone with ia64, sparc, or hppa is also welcome to test, but I'm really not sure it will work :)
[05:48] <Fujitsu> persia: You need to become a DD.
[05:48] <persia> Fujitsu: Why?
[05:48] <Fujitsu> Access to every imaginable arch.
[05:48] <ajmitch> something which we don't have for ubuntu
[05:48] <Fujitsu> Yep.
[05:49] <persia> Fujitsu: I'd be mostly abusing that for Ubuntu work, so I'm not sure I'd use it even if I was a DD.
[05:49] <persia> (Also, given the prevailing attitude around NMUs, I'd rather work with Debian teams)
[05:49] <Fujitsu> I'd really think Canonical would be more capable of providing machines than Debian, as the former sort of has a fair bit of funding.
[05:51] <superm1> well as ppas go active, that will at least help to make sure it builds on the other architectures
[05:51] <persia> superm1: Build, yes.  Install, not so much.
[05:51] <ajmitch> superm1: PPAs are limited to specific archs
[05:51] <Fujitsu> superm1: They're only i386/amd64 at the moment.
[05:51] <ajmitch> like i386 & amd64
[05:51] <superm1> oh didn't realize that
[05:51] <Fujitsu> And I don't think that's changing soon.
[05:52] <ajmitch> not until they have decent virtualisation on the others
[05:52] <Fujitsu> persia: I'm sure you can whip up a package to try to install things.
[05:52] <persia> Fujitsu: An install test in debian/rules?  That's an interesting idea.  I don't suppose you'd like to draft a spec?
[05:53] <Fujitsu> persia: No, as in you write a debian/rules specifically to try to install a package.
[05:54] <persia> Fujitsu: That sounds dangerous.  I'd think dh_installtest would be a safer solution, with the call being at the very end of install:
[05:57] <minghua> I'll just try building a package foo-test that build-depends on foo.
[05:57] <persia> minghua: That could work, but wouldn't it clutter the archive namespace?
[05:57] <Fujitsu> persia: Not on PPA.
[05:57] <Fujitsu> It is meant to be growing a UI soon.
[05:57] <persia> Fujitsu: Not even for one's own PPA archive namespace?
[05:58] <Fujitsu> (LP soon, however)
[05:58] <minghua> persia: I don't really know how PPA works, so maybe that's a bad idea.
[05:58] <Fujitsu> You'll be able to fairly easily remove packages, AFAIK.
[05:58] <minghua> LP soon, heh.
[05:58] <persia> minghua: Neither I, but if Fujitsu is correct, it would avoid a mess.  Also, one could just have a $lpname-test package that one refreshed with new build-deps for each upload.
[05:59] <persia> ajmitch: Does autopkgtest run across all the architectures for all of universe?  Is the output somewhere public?
[05:59] <minghua> Yeah, that would be more convenient.
[05:59] <Fujitsu> But we've got limited PPA archs for the foreseeable future anyway.
[05:59] <ajmitch> persia: I don't know, why don't you fetch the package & see?
[06:00] <ScottK> persia: It built.  I dpkg -i *deb on the lot of them.  apt-get -f intall thought it could fix all the deps except *audio.  I'll let you know when I figure out what it didn't like.
[06:00] <persia> ajmitch: It's not the code - it's the infrastructure :)
[06:00] <persia> ScottK: It probably didn't like ardour (FTBFS due to scons)
[06:01] <ScottK> OK.  I'll check that.
[06:01] <ScottK> 0 upgraded, 561 newly installed, 1 to remove and 0 not upgraded.
[06:01] <Fujitsu> Haha.
[06:02] <ajmitch> persia: I'm sure you could whip up something with it
[06:02] <persia> ajmitch: Ah.  It sounds like one just needs to feed something into debian/tests.  Thanks for the pointer :)
[06:03] <ajmitch> it's easier than hacking up debian/control & rules & .install files to clog the archive or to have a test fork of every package
[06:04] <persia> ajmitch: Much easier :)  One just build-depends on autopkgtest and applies some tests to the *installed* package, getting the install for free.
[06:04] <ajmitch> there's a MIR underway for autopkgtest, and it should be used in debian at some point as well
[06:06] <Fujitsu> ScottK: Oh noes! Look out for all the evil hackers that my parents seem to be so scared of.
[06:06] <persia> ScottK: So it was ardour?
[06:07] <ScottK> Dunno.  My little laptop is still cranking away on the 561 packages to install.
[06:07] <persia> heh
[06:12] <ScottK> Question for while I'm waiting...
[06:13] <ScottK> In my pbuilder chroot I had to install devscripts to get dget.  
[06:13] <ScottK> After installing, dget complained that dget needed wget or curl installed or it couldn't work.  
[06:13] <ScottK> Should they be a | depends of devscripts?
[06:14] <ajmitch> wget is in Suggests
[06:16] <minghua> devscripts's package description has a detailed list.
[06:17] <minghua> (of what package you need for each tool)
[06:17] <ajmitch> yay, my box at home is back
[06:17] <ajmitch> Jul 13 16:17:16 augustine kernel: [627294.905882]  Out of memory: kill process 12597 (rhythmbox) score 178538 or a child
[06:17] <ajmitch> Jul 13 16:17:16 augustine kernel: [627294.905929]  Killed process 12597 (rhythmbox)
[06:17] <ajmitch> 4GB of RAM just isn't enough
[06:18] <RAOF> Yay for the OOM killer
[06:18] <persia> ajmitch: Or rhythmbox has a leak?
[06:18] <ajmitch> persia: no, rhythmbox was a victim, not a perpetrator
[06:20] <ajmitch> I was compiling stuff in the background, and my ssh connection started to get very slow, and then stopped
[06:20] <ajmitch> it must have been thrashing around for an hour or so
[06:21] <Fujitsu> compiz seems to break if I eat up too much swap, and it doesn't like me killing X remotely after that.
[06:24] <ScottK> OK.  Well it seems to me that stuff ought to work without suggests, but whatever.
[06:25] <ajmitch> ScottK: if you had everything necessary in Depends, it would pull in a *lot*
[06:25] <ajmitch> like emacs :)
[06:26] <ScottK> Ah.  That makes sense.
[06:26] <ajmitch> hm, mutt
[06:31] <man-di_> moin
[06:31] <man-di_> Can someone point me at current multidistrotools bzr?
[06:31] <man-di_> the wikipage points to a non-existant repo
[06:33] <minghua> Hmm.  I wonder if devscripts really want to suggest ssh.  It may actually mean openssh-client.
[06:33] <ajmitch> file a bug
[06:35] <minghua> I know. :-)  But I'm not sure.
[06:35] <ajmitch> doesn't seem to be filed in debian, at least
[06:36] <Fujitsu> man-di_: Try http://tiber.tauware.de/~laserjock/multidistrotools/
[06:36] <minghua> devscripts' suggests list also drag in ruby.
[06:37] <minghua> Still much smaller compared with emacs, of course.
[06:38] <man-di_> Fujitsu: thanks, I had it already on some computer, I just dont remember on which one. I was not able to find it anymore.
[06:43] <ScottK> persia: I don't think I'm going to finish investigating tonight.  I'll look into it in 8 to 10 hours.
[06:44] <persia> ScottK: That's fine.  Knowing that everything bug ubuntustudio-audio works, and given that things working on i386 tend to be a superset of things working on amd64, I'm pretty confident.  Thanks for the help.
[06:44] <persia> s/bug/but/
[06:45] <ScottK> OK.  Do you need me to keep looking?
[06:46] <persia> ScottK: No need.  I'm not surprised by the ubuntu-audio issue.  I was more concerned with the other packages.  Thanks again.
[06:46] <ScottK> OK.  Then I'll stop.  You're welcome.
[06:48] <man-di_> Who maintains multidistrotools for real? I just fixed a bug in it.
[06:49] <Fujitsu> I think I've been touching it most lately, but that's not much.
[06:49] <Fujitsu> It hasn't had much maintenance at all, lately.
[06:50] <ScottK> Anyone feel up to reading a clamav stack trace?  It'd be nice to at least figure out if it's clamav, klamav, or some other package to blame.
[06:50] <ScottK> man-di_: Looks like you found your man.
[06:50] <ajmitch> I still have my own code which predates mdt
[06:50] <man-di_> ScottK: hehe, thx
[06:51] <ajmitch> part of that is used for the rc bugs list
[06:51] <man-di_> Fujitsu: http://paste.debian.net/32630
[06:51] <persia> man-di_: What about "wontfix"?
[06:52] <ScottK> It's not a bug, it's a feature request in any case.  
[06:53] <man-di_> persia: right, I missed that too because I dont saw bugs marked "wontfix" in my list
[06:53] <StevenK> man-di_: Any news on sear?
[06:53] <man-di_> ScottK: IMO feature request are bugs too, just wishlist bugs
[06:53] <man-di_> StevenK: Unfortunately not
[06:53] <Fujitsu> man-di_: I'll merge that into my branch (http://people.ubuntu.org.au/~fujitsu/multidistrotools) and ensure that's up-to-date with LaserJock's.
[06:54] <man-di_> Fujitsu: Cool, thank you very much
[06:54] <ScottK> True, but IMO arbitrary changes in proprietary tools don't cause bugs in open software.  It's more the other way around.
[06:54] <man-di_> Fujitsu: will you include "wontfix" too or should I write another patch?
[06:54] <StevenK> man-di_: You said it didn't build due to library transitions, they haven't progressed?
[06:54] <Fujitsu> man-di_: I'll add it myself.
[06:54] <man-di_> ScottK: is multidistrotools proprietary?
[06:54] <man-di_> Fujitsu: thanks
[06:54] <ScottK> No, but Launchpad is.
[06:55] <man-di_> StevenK: I still wait for one library transition
[06:55] <ScottK> The fact that $PROPRIETARY_TOOL changed doesn't make multidistro tool have a bug.  
[06:55] <persia> ScottK: I'd call this a special case, like code to read a DVD, or code to import MS Office documents: when the intent of the open software is to interoperate with the proproetary software, changes in the latter should be considered bugs in the former.
[06:55] <ScottK> Sorry.  It's a bit of a sore point.
[06:55] <man-di_> ScottK: ah, now I understand
[06:56] <ScottK> Sure.  I'm just bitter.  Don't worry.
[06:57] <ajmitch> Fujitsu: you've come a long way :)
[06:57] <Fujitsu> ajmitch: Unfortunately.
[06:58] <minghua> Indeed ScottK reminds me of Fujitsu in edgy cycle. :-P
[06:58] <ScottK> Well LP will be free "Real Soon Now" for how long?
[06:58] <Fujitsu> ScottK: About the same length of time that XML-RPC was coming soon.
[06:59] <man-di_> GRRR, just hit another issue
[06:59] <ajmitch> Fujitsu: oh you mean since sydney when I first heard of it?
[06:59] <man-di_> Fujitsu: maybe next patch coming soon
[07:00] <Fujitsu> ajmitch: UDU? Was that pre-Breezy or pre-Hoary?
[07:00] <ScottK> For this particular situation, I think it's unfair for Canonical to drive work onto volunteer devs without consent.
[07:00] <ajmitch> ScottK: I've never seen a "RSN" promise for lp freedom
[07:00] <ajmitch> Fujitsu: pre-breezy
[07:00] <Fujitsu> I've seen an `eventually' promise, `potentially years'.
[07:01] <ajmitch> which is quite different from 'RSN'
[07:01] <ScottK> That's how I read sabdfl's comments on the LP should be Free bug in LP.  I'd have to look again to be sure.
[07:01] <Fujitsu> I like it how they open-sourced a supposed part of Launchpad (ie. storm)... which isn't actually used in LP at the moment.
[07:02] <ScottK> See, now there's a constructive suggestion that isn't just whining.
[07:02] <Fujitsu> ... or just give some notice.
[07:02] <ScottK> Sure.  But they gave us notice on this one (one day).
[07:03] <ScottK> Good night.  Going to bed.
[07:03] <ajmitch> night
[07:03] <Fujitsu> Night ScottK.
[07:03] <ajmitch> I obviously need a much faster box
[07:06] <Fujitsu> man-di_: That patch (modified a little) is now in my branch.
[07:10] <man-di_> Fujitsu: Cool, thx
[07:11] <Fujitsu> Thanks for noticing and fixing that.
[07:12] <man-di_> Fujitsu: now I fight with mtd versions2html -h ... failing when packages only in Debian exist yet
[07:12] <Fujitsu> man-di_: What's the error it gives?
[07:13] <man-di_> Fujitsu: http://paste.debian.net/32632
[07:14] <man-di_> Fujitsu: I think it misses to check for a 404 correctly
[07:15] <Fujitsu> man-di_: Looks like it.
[07:18] <man-di_> Fujitsu: any idea how to solve this?
[07:19] <Fujitsu_> Bah, it seems the 'net connection of the network my irssi session is running on has dropped out.
[07:19] <man-di_> Fujitsu: oh
[07:20] <white> man-di_: time to organise the svn? :)
[07:20] <man-di_> white: I just sent you a mail about this
[07:20] <Fujitsu_> Hi white.
[07:20] <white> bah greylisting over @debian.org takes ages :(
[07:20] <white> hi Fujitsu_ :)
[07:21] <man-di_> white: disable greylisting /me hides
[07:21] <vorlon> embrace the spam
[07:21] <white> man-di_: nah, spam count explodes afterwards
[07:23] <white> man-di_: you do not understand. I intended to make sure you do the work and I just step in and commit, once everything is done ;)
[07:23] <man-di_> white: hehe
[07:24] <man-di_> white: I would like to get my printer working first
[07:24] <white> . o O(and i would like to have an alternative working for foo2zjs ...) :)
[07:24] <man-di_> white: I still dont know if merging everything into one binary package is really a good idea
[07:25] <man-di_> white: lets discuss this later, I need to prepare for work
[07:25] <white> man-di_: ok
[07:26] <Fujitsu_> Ah, the network came back up.
[07:26] <white> Fujitsu_: do you think we get a BSP or just a nice debian/ubuntu meeting to work for the next mid-semester break?
[07:27] <Fujitsu_> white: I'm fine with either. I have no preference.
[07:28] <white> well I need to contact etbe anyway next week to bring his laptop back
[07:28] <Fujitsu_> etbe?
[07:28] <white> Russell, sorry
[07:28] <Fujitsu_> Ah.
[07:29] <Fujitsu> Much better.
[07:29] <white> Fujitsu: you are struggling :P
[07:29] <white> bah it is raining here :(
[07:29] <Fujitsu> white: How?
[07:30] <white> I want to have at least *one* summer this year (it was raining in Germany and now it is raining here as well)
[07:30] <Fujitsu> Haha.
[07:30] <Fujitsu> That's Melbourne.
[07:31] <white> Fujitsu: Melbourne's winter is like German autumn, it is just unfair :(
[07:31] <white> 38 degree sounds nice
[07:32] <Fujitsu> 38 Fahrenheit is better.
[07:33] <white> Fujitsu: btw how is NM going?
[07:33] <Fujitsu> I'm sitting in the AM-assignment queue.
[07:33] <white> bah
[07:33] <Fujitsu> Passed the advocate check 3 months ago tomorrow.
[07:34] <white> just be patient, it will be a question of time ;)
[07:34] <Fujitsu> So I've heard.
[07:37] <man-di_> white: we will have 30 degrees here too, tomorrow and the day after
[07:38] <white> man-di_: just when i left the country ...
[07:38] <man-di_> white: the weather knows where to go
[07:38] <man-di_> ;-)
[07:39] <white> Fujitsu: I am curious if there is the same discussion in ubuntu than in debian ... Right now debian thinks about a new contributor class, the so called Debian Maintainer (DM) class. Are you familiar with the discussion?
[07:39] <Fujitsu> I am.
[07:39] <white> Fujitsu: what is your opinion?
[07:40] <Fujitsu> I think it makes sense.
[07:40] <Fujitsu> People are likely to know their own packages, and the right to NMU is a much larger responsibility.
[07:41] <Fujitsu> I believe it would be good idea to have a DM class.
[07:42] <white> Fujitsu: how is becoming MOTU implemented into ubuntu?
[07:42] <persia> white: I haven't seen any of the reverse discussion (allowing dedicated maintainers to upload without full access to the component), but the REVU process seems to be working for us (for now - it's definitely aging).
[07:42] <Fujitsu> There was a little bit of discussion on a DM-like thing in Ubuntu around The Beryl Incident.
[07:42] <white> i know that i got some mails from the council asking me about a person's contributions to debian, but i do not what it requires to become a motu
[07:43] <Fujitsu> white: You work with existing MOTU for some time, getting sponsorship as with Debian. Once you've worked with enough packages and people, you go to the MOTU Council to get approved. There are no strict criteria that I know of.
[07:43] <white> and are there people thinking about a NM process or stuff like that or is that a no go?
[07:44] <persia> white: We have an (optional) mentoring process to help people get familiar with the tools.
[07:44] <white> ok, just two questions left :)
[07:44] <Fujitsu> I think the consensus was that something like NM takes ages, and might turn people away. We need as many developers as we can get.
[07:45] <persia> white: https://wiki.ubuntu.com/MOTU/Mentoring
[07:45] <white> Fujitsu: 1. Would you personally consider leaving the NM process out of frustration, because it takes too long? 2. What would you like to be required for being a DM?
[07:45] <white> now i feel like conducting a survey :)
[07:47] <Fujitsu> white: 1) I wouldn't, personally. 2) That's one thing I'm very unsure of.
[07:48] <white> hmm, thanks anyway. Interesting to get some other opinions
[07:49] <persia> white: Regarding #2, I'd suggest that anyone who can 1) demonstrate the ability to create a good package, and 2) demonstrate the commitment to fixing bugs for that package should be considered for DM (did it exist).
[07:49] <vorlon> only committment to fixing bugs, not ability? :)
[07:50] <white> persia: there were several gr proposals, but they mainly differed in the way that they require different things in order to become one
[07:50] <white> persia: one was that it should only be for NMs after a certain stage
[07:50] <persia> vorlon: Yes.  If a maintainer has a good relationship with upstream, and is good at pulling sharply delimited fixes from VCS, should they be penalised for not writing code?
[07:50] <white> persia: another one was to fully connect it with the NM process and demand that process up to a certain point
[07:51] <persia> white: That makes sense as well: to demonstrate the knowledge of and commitment to Debian principles.
[07:51] <white> persia: and the (pretty much) first one was that it can be connected to the NM process, but does not need to.
[07:51] <white> the last one works with advocating people to become a DM
[07:51] <white> (though the advocate can also be the AM during the NM process)
[07:52] <vorlon> persia: what ability to fix bugs in the Debian packaging?
[07:52] <white> persia: i also entered the discussion pretty late and had to catch up on a nearly endless thread
[07:52] <persia> vorlon: Ah.  Yes.  That is required.  I've assumed anyone who can create a good package can probably fix those :)
[07:53] <white> that is the third one i explaint: http://lists.debian.org/debian-vote/2007/06/msg00199.html
[07:53] <white> the one only for NMs: http://lists.debian.org/debian-vote/2007/07/msg00008.html
[07:53] <white> and the one only connected with the NM process, but still with DMs: http://lists.debian.org/debian-vote/2007/07/msg00002.html
[07:55] <white> it seems that the third one (first one posted in the list above, oh my god i am confusing) will be open for a vote
[07:56] <persia> white: personally, I think I like the first of those, although I'm unsure about source NEW vs. binary NEW, and the interactions with experimental from the text.  Primary reasoning being that many upstreams provide Debian-format packages, and it would be nice to have those be checked by someone without requiring NM.
[07:56] <persia> (first posted, #3)
[07:57] <white> persia: that seems to be the general opinion of the people reading -vote
[07:58] <man-di_> persia: the problem with "many upstreams provide Debian-format packages" is that most upstreams have no real clue about packaging at all
[07:59] <man-di_> persia: I have seen upstreams putting jars directly into /usr
[07:59] <persia> man-di_: Right.  That's where the initial sponsor/advocate comes into play.  If I made a lousy package, and asked you to sponsor, would you?  I suspect you'd tell me what I needed to fix, etc.
[07:59] <white> persia: i am curious, did it ever happen that MOTUs got their rights revoked or that they were absolutely not ready, although approved by the council?
[07:59] <man-di_> persia: thats right
[07:59] <man-di_> persia: but I still see a problem with people having upload rigths and dont need a sponsor anymore
[07:59] <Fujitsu> white: The former has never happened, but I'd say the latter has on a couple of occasions.
[08:00] <man-di_> persia: I also question the quality of some DDs...
[08:00] <man-di_> perhaps I'm too much of a perfectionist
[08:00] <white> at least i have to say that i very much like the "DM-Allow" field. I think nobody will come to me for sponsoring anymore, because I would not really consider it after one or two uploads
[08:00] <persia> white: For the first case, only for expiration or voluntary removal (as far as I know), although some people don't upload anymore.  For the second case, it's really hard to say: there've not been many new MOTUs since MOTU Council was approving.  For earlier MOTUs, peer pressure has been enough to get everyone up to speed (and they probably were beforehand anyway)
[08:01] <vorlon> white: you wouldn't consider sponsoring after one or two uploads, or they wouldn't need to because you would give them DM rights after just one or two uploads?
[08:02] <persia> man-di_: Perhaps.  Most of the new upstreams I sponsor for Ubuntu are rather straightforward.  I see about as many issues from new upstreams in Debian (e.g. not updating debian/copyright when upstream changes their website, not updating to latest standards, etc.)
[08:02] <white> vorlon: no, i would not give them DM rights, because i do not feel that i can trust them after 1 or 2 uploads. And i personally think that the sponsoree expects the sponsor to set the field to yes
[08:03] <white> at least they will probably be dissapointed, when they do not get that right from a sponsor
[08:03] <vorlon> some might, I guess
[08:03] <vorlon> but I guess they might be even more disappointed if someone complains about their package quality and their DM status is revoked
[08:03] <persia> white: I think that's a cultural thing.  If most sponsors were stricter, or it worked more like some of the teams that are open to non-DDs, it wouldn't be that bad: DM-Allow could be set after someone demonstrated appropriate responsibility.
[08:04] <white> vorlon: true, but i also think that there will be DDs giving this right pretty early and they will be the favoured target for (totally new) sponsorees
[08:06] <persia> white: Perhaps not: if people who get DM-Allow too easily lose DM status regularly, either the easy DDs will get stricter, or the DMs will be happier to wait (losing DM status presumably means it's harder to find any sponsor).
[08:06] <vorlon> well, the only people who can be given that right, under the proposal, are people who already have their keys in the DM keyring
[08:06] <minghua> Personally I've seen some quite careless sponsored packages, but I won't point fingers on exact package.  I do think if DM process is established, there should be better QA and peer-review than current sponsoring.
[08:06] <vorlon> and the proposal has provisions for blocking people from advocating folks if they show they have a history of poor judgement
[08:07] <Burgundavia> persia: doesn't something like that already exist?
[08:07] <vorlon> persia: mentors.debian.net...?
[08:07] <persia> where DM keyring ~ ubuntu-universe-contributors keyring
[08:08] <white> persia: mentors.debian.net is free for everyone to upload
[08:08] <persia> Burgundavia: Yes,  It exists, but 1) it doesn't have automated checks, 2) there isn't a collaborative sponsorship policy with public comments, and 3) it's not keyring restricted.
[08:08] <Burgundavia> right
[08:08] <minghua> vorlon: mentors.d.n doesn't have comment system, and relies on -mentors list, AFAIK?
[08:09] <minghua> persia: I won't consider REVU keyring-restricted either.
[08:09] <vorlon> minghua: true
[08:09] <white> vorlon: maybe i should just wait and after DM is in place for a while, we'll see if it was good or bad
[08:09] <persia> minghua: It is: uploads are rejected for non-members (not that it's really hard to get in the keyring or anything).
[08:09] <vorlon> white: well, presumably you should also vote your conscience in the GR on the question first
[08:10] <white> true :)
[08:10] <minghua> vorlon: I consider the biggest advantage of REVU is the comment system, so that you see the history of the package, other people's comments, and debdiffs easily.
[08:10] <minghua> persia: Has anybody's REVU key been revoked or refused to be added?
[08:11] <Fujitsu> It's an open team.
[08:11] <persia> minghua: Nope.  Never.  Still, the code's there, and it could be used for web-of-trust analysis, if one chose.
[08:12] <Fujitsu> What web-of-trust?
[08:12] <minghua> persia: Speaking of that, is there an easy way to get the REVU keying now?
[08:12] <Fujitsu> I'm pretty sure most of those keys won't have any sigs.
[08:12] <Fujitsu> minghua: You just join ubuntu-universe-contributors, and wait for the key to be synced.
[08:12] <Fujitsu> *keyring to be synced
[08:13] <persia> Fujitsu: Um.  There's a "strong set" of people with GPG keys, for whom there are at least two trust paths to everyone else in the "strong set".  These people are members of the web-of-trust.  Others just have some collections of random bits that look like keys.
[08:13] <minghua> Fujitsu: no, not "get into", but "get", i.e., export all the public keys in the keyring so I can check the package signatures on my computer.
[08:13] <persia> minghua: I don't know of it: check the revu code (branch is in LP).
[08:13] <vorlon> minghua: for my part, grabbing the current version of the package from the archive with apt-get source for debdiff before sponsoring isn't too much of an obstacle, I find that careful review *of* the debdiff takes much longer
[08:13] <Fujitsu> minghua: Oh, right, oops.
[08:14] <minghua> vorlon: REVU are mostly for NEW packages only right now.
[08:14] <Fujitsu> persia: Right, most of the members of the REVU keyring will not have any sigs, so there's very little WOT to analyse.
[08:14] <vorlon> minghua: then I don't see how debdiffs are of significant benefit to a reviewer, personally :)
[08:14] <persia> vorlon: Agreed: the debdiff review is the hard part, but for new upstreams, or new packages, having something like REVU is much easier.
[08:14] <minghua> vorlon: But I agree on your point about careful review.
[08:14] <Fujitsu> vorlon: Differences between different revisions of new packages/
[08:15] <persia> Fujitsu: True, but if the code was ported for use with the DM keyring (which requires at least one DD signature), it would be useful.
[08:15] <minghua> vorlon: Useful when you are not the only reviewer.
[08:15] <persia> vorlon: REVU also allows multiple uploads with the same revision, so the revision included in the archive includes all the fixes, rather than the history of the reviewing.
[08:16] <vorlon> fair enough
[08:17] <minghua> vorlon: MOTU atmosphere basically encourage a hopeful (i.e. NM counterpart) to jump into IRC channel or list and say "I have a new version that addressed the previous comments, can anyone review again?"
[08:18] <StevenK> Ogre has a M4 configure check that checks for SSE.
[08:18] <ajmitch> that's annoying
[08:18] <StevenK> It turns it off for PPC, and sets it to yes for every other arch.
[08:18] <vorlon> hahaha
[08:18] <ajmitch> it'd be much nicer to check at runtime
[08:18] <ajmitch> hello vorlon 
[08:18] <StevenK> So that's going to work on Sparc, m68k ...
[08:19] <vorlon> hi-ho
[08:19] <minghua> And it actually works better for Ubuntu IMO, because the most knowledgeable people usually don't have much time doing reviews.  So multiple reviewers catch more problems.
[08:19] <StevenK> vorlon: Are you jumping ship and working here instead? :-)
[08:19] <white> StevenK: go away ;)
[08:19] <ajmitch> StevenK: do you think the MC would approve him?
[08:19] <vorlon> StevenK: just spying for the enemy
[08:19] <StevenK> Heh
[08:19] <white> ajmitch StevenK: he is not shareable
[08:20] <ajmitch> vorlon: redhat?
[08:20] <vorlon> ajmitch: there are so many rejoinders that I can't bring myself to pick
[08:21] <vorlon> StevenK: so is this the same ogre in unstable?
[08:22] <vorlon> (where it's built on 7 archs -- 5 of those should fail to compile any SSE code thrown at them)
[08:22] <StevenK> vorlon: Yu
[08:22] <StevenK> Yup, even
[08:23] <vorlon> so something must work around it elsewhere?
[08:23] <StevenK> It failed on ia64 and sparc here.
[08:24] <StevenK> Actually, no it isn't.
[08:24] <vorlon> then I guess it's not the same as in unstable, because ia64 and sparc both built :)
[08:24] <StevenK> 1.4.3-1 is in unstable, 1.4.2-2 is in Gutsy
[08:24] <vorlon>    * Added proper check for determining whether to use SSE.
[08:24] <vorlon> ;)
[08:24] <StevenK> Ah ha.
[08:25] <persia> StevenK: Always remember to check debian first :)  Lots of these are already fixed.
[08:25] <vorlon> there ya go, now you have free time to help me unbreak qt4's atomic operations code on alpha
[08:25] <StevenK> But Ubuntu doesn't support Alpha ....
[08:25] <StevenK> :-P
[08:27] <vorlon> minghua: that's not a fair trade, though, I can just guilt lamont for those anyway
[08:27] <Fujitsu> Why does it manage to lag behind so much?
[08:28] <StevenK> I have a few suggestions, the first few being unprintable.
[08:28] <minghua> vorlon: I know.  And ia64 is essentially abandoned in Ubuntu anyway.
[08:35] <lucas> vorlon is everywhere, pff :)
[08:36] <ajmitch> it's like debian people are taking over
[08:36] <ajmitch> hello Hobbsee 
[08:37] <vorlon> lucas: I don't know what you're talking about; I have always been here
[08:38] <Hobbsee> hi ajmitch 
[08:38] <Fujitsu> Morning Hobbsee.
[08:38] <Hobbsee> hi Fujitsu 
[08:38] <lucas> vorlon: yeah, but I never noticed. that's what makes you a good spy ;)
[08:42] <Hobbsee> lucas: maybe people are thinking?  who knows
[08:44] <persia> lucas: At least for my part, I'm sufficiently of two minds not to have a real response.  It might help for general publicity, but it doesn't really help me get my patches applied: either the DD is Ubuntu-freindly, in which case it usually gets applied in the next update, or they aren't, and I need to convince them that the fix would benefit Debian (or get it applied upstream first).
[08:44] <minghua> lucas: I proposed the same thing for MOTU science group about a year ago, didn't work out.
[08:46] <lucas> persia: by advertising the list of patches, it could help a bit, I think
[08:46] <lucas> or help others second the patch
[08:46] <lucas> but I agree that it's not going to make a huge difference
[08:46] <persia> lucas: Perhaps.  I'm not familiar enough with Debian peer practices to understand how that works: hence not sending a response.
[08:46] <lucas> minghua: why didn't it work out?
[08:47] <lucas> a year ago, usertags were harder to use (you couldn't add them when submitting a bug, you add to do it later)
[08:48] <minghua> lucas: No response what-so-ever.  I didn't have time to do it myself.
[08:48] <minghua> lucas: Yes, I agree the timing is probably better now.
[08:49] <lucas> you wanted to usertag old bugs? or just new ones?
[08:50] <minghua> lucas: The ones that have a corresponding bug in LP.  Either we reported it back to Debian, or we found it's already reported in Debian.
[08:51] <lucas> ok
[08:51] <minghua> lucas: Basically I wanted a way to show Debian that MOTU science team is helping Debian.
[08:51] <lucas> yeah, that's my goal as well
[08:53] <persia> Personally, I think it works better for collaboratively maintained packages, as the culture is closer.  Debian-Python and Debian-Games are good examples of groups that welcome and encourage MOTU involvement (which means, most of those packages are just syncs (excepting dh_iconcache)).
[08:54] <StevenK> That will change, now that dh_icons is taking over.
[08:55] <persia> StevenK: Yep.  DebianImportFreeze hadn't already passed, I'd be chasing that right now :)
[08:55] <persia> (if)
[08:55] <minghua> lucas: Also, I think another reason it didn't work out is I didn't propose good tags.  It probably would work better if I had a concrete plan.
[08:58] <lucas> minghua: do you have any URL for your proposal? was it on IRC or by mail?
[09:02] <minghua> lucas: http://lists.tauware.de/pipermail/ubuntu-science/2006-November/001965.html
[09:03] <minghua> lucas: I'll eventually write a reply to your proposal, but I need time to think (and perhaps more research on usertags).
[09:04] <minghua> Usertags doesn't have the best documentation. :-(
[09:04] <StevenK> persia: Anything happening with ubuntustudio-meta?
[09:04] <persia> StevenK: I'm waiting for TheMuso to report on powerpc.  I'm likely to upload in the next hour or so if I don't hear anything...
[09:05] <lucas> minghua: I've documented what looks needed on the wiki pag
[09:05] <lucas> e
[09:05] <StevenK> persia: Fair enough, thanks.
[09:05] <minghua> lucas: Thanks, I'll definitely read the wiki page.
[09:14] <superm1> could someone archive this upload that's on revu, http://revu.tauware.de/details.py?upid=5995
[09:16] <TheMuso> persia: SOrry, this has been a full on day for me, will do now.
[09:16] <persia> TheMuso: No worries.  StevenK wants there to be no cruft, but I'd prefer that ubuntustudio-meta generated packages that could be installed :)
[09:16] <TheMuso> yup
[09:17] <persia> TheMuso: Just a note: you'll need to manually install the ardour package before installing ubuntustudio-audio, or it breaks.
[09:17] <minghua> superm1: Done.
[09:17] <superm1> thx minghua 
[09:17] <StevenK> persia: Not none, just less. :-)
[09:17] <persia> StevenK: Really?  I thought your goal was none, and that this was just today's item.
[09:18] <TheMuso> persia: Do you mean the binary package of ardour in the archive?
[09:18] <TheMuso> i.e not ardour 2?
[09:18] <StevenK> persia: Well, none is the ultimate goal, but may not happen. :-)
[09:18] <Hobbsee> hi TheMuso 
[09:18] <persia> TheMuso: No, the new source package.  I've migrated ardour-gtk to ardour, under the assumption that this will be fixed soon.
[09:18] <TheMuso> Hey Hobbsee 
[09:18] <Hobbsee> superm1: done
[09:18] <superm1> hmm doubly archived :)
[09:19] <TheMuso> persia: So I need to build a copy of ardour before I install audio?
[09:19] <persia> TheMuso: Either a real copy or install "ardour" rather than "ardour-gtk" from the current set (which isn't as nice, etc.).
[09:21] <persia> TheMuso: nevermind.  The "ardour" binary was apparently dropped long, long ago.  You can either build the current sources, use your old ardour2 package, or install a fake package named "ardour" for testing.
[09:21] <TheMuso> ok
[09:22] <TheMuso> persia: Give me 45 mins or so to build ardou2 ppc, and I'll have an answer for you.
[09:22] <persia> TheMuso: Sure.  Thanks.
[09:22] <Hobbsee> yay, no more packages held back
[09:23] <StevenK> Hobbsee: That's the end of curl?
[09:24] <Hobbsee> yep
[09:24] <Hobbsee> well, ooo works on kde
[09:25] <StevenK> persia: Why does ubuntustudio-meta need ardour?
[09:26] <persia> StevenK: Because it's a metapackage, and apt is set to require Recommends from meta-packages on install (although they can later be removed).
[09:26] <Fujitsu> apt installs recommends on everything, doesn't it?
[09:27] <persia> Fujitsu: Nope, only for meta-packages (unless the user configured it differently).  Perhaps you're thinking of synaptic, adept, or aptitude?
[09:27] <Fujitsu> How does it identify metapackages? Section?
[09:27] <Hobbsee> persia: only metapackages in main
[09:27] <Hobbsee> Fujitsu: yes
[09:27] <persia> Hobbsee: Are you sure?  I thought I saw a changelog indicating you fixed that.
[09:28] <Hobbsee> persia: yeah, but it didnt work.
[09:28] <Hobbsee> persia: that part of the code doesnt seem to do wildcards
[09:28] <persia> Hobbsee: Ah.  Right then.  Still, it's probably best practice for metapackages to verify that Recommends can be satisfied before committing.
[09:29] <Hobbsee> persia: sorry?  i dont understand you
[09:30] <persia> Hobbsee: I've made changes to ubuntustudio-meta, and TheMuso is building ardour to verify installation on powerpc, and StevenK wondered why it needed ardour, and I think it's good to verify the recommends are satisfied before I commit the changes to the repository.
[09:30] <Hobbsee> persia: ah right.  is it in universe, or main?
[09:30] <persia> Hobbsee: universe
[09:30] <Hobbsee> the ubuntustudio-meta?
[09:30] <Hobbsee> persia: right, then it will not install recommends by default
[09:30] <TheMuso> Hobbsee: universe
[09:31] <Hobbsee> persia: it's to do with component overrides, if you were wondering.
[09:32] <persia> Hobbsee: I see.  Looking again, that would explain why joejaxx made everything a dependency.  I should really learn more about germinate before making another metapackage change.
[09:32] <Hobbsee> persia: as in, a metapackage in universe will be overridden, to have Section: universe/metapackages, which does nto fit metapackages
[09:32] <Hobbsee> persia: learning about everything would help, yes.  if that's actually possible :)
[09:33] <TheMuso> heh
[09:33] <persia> Hobbsee: Right.  Which means it doesn't quite have the desired affect.
[09:33] <Hobbsee> persia: exactly
[09:33] <persia> Regarding learning about everything: I firmly believe that Aristotle was the last person for whom that was possible.
[09:33] <Hobbsee> persia: and you cant just feed it a wildcard, so that the code will match *metapackages
[09:34] <TheMuso> I'm sure you people saw the ubuntustudio cd building thread, I actually agree with Colin, and I am sure some of you would as well./
[09:34] <TheMuso> re canonical building ubuntustudio cds, and packages having to be in main.
[09:35] <Hobbsee> maybe...
[09:35] <TheMuso> Hobbsee: ??
[09:35] <Hobbsee> it all depends.  otherwise, tehy tend to keep separate archives, and we can never merge changes across all flavours
[09:35] <lifeless> hiya all
[09:35] <Hobbsee> well, not as easily
[09:35] <Hobbsee> hiya lifeless 
[09:36] <minghua> Colin is on the side that build shouldn't know about universe?  I am on that side.
[09:36] <TheMuso> minghua: Same.
[09:36] <minghua> s/build/build script/
[09:36] <persia> TheMuso: With the current archives, I'd have to agree as well.  Getting everything into main isn't going to happen (jack didn't make it during UDS), so external building probably continues to make sense.
[09:37] <Hobbsee> all that makes sense, yet they are duplicating a lot of effort there.  i dont know.
[09:37] <minghua> But I do think it would be nice for Canonical to have a separate instance of script running which know universe, to help building semi-official CDs.
[09:37] <minghua> Having everything needed in main is not practical IMO.
[09:38] <Hobbsee> persia: xubuntu is "supported" as in, on canonical hradware, abut has no canonical employees on that team
[09:39] <Hobbsee> erk.  i can spell, i really can!
[09:39] <persia> Hobbsee: True.  That falls under "otherwise staffing support".  It helps that most of the necessary components are well supported upstream, and that there's a lot of overlap with Ubuntu.
[09:39] <Fujitsu> Xubuntu is all in main, and never had completely unsupportable stuff such that it couldn't be moved to main.
[09:39] <Hobbsee> right
[09:40] <persia> There's probably a subset of audio things that could be in main, but it's not enough to do much (most musicians aren't programmers).  The same is currently true for video editing.  ubuntustudio-graphics might make it, but it's just a collection of tools.
[09:41] <white> Fujitsu: say something cool and fancy about a new release
[09:42] <white> anyone here, give me some fancy sentences ...
[09:42] <minghua> I was also thinking of building localized remix/derivative CDs on canonical servers.
[09:42] <Hobbsee> white: "this is a fancy sentence"
[09:43] <minghua> And it would be hard to push all needed stuff to main there as well.
[09:43] <persia> minghua: For now, unless nearly everything you want is in main, you'll do better with an external build.
[09:43] <minghua> persia: I know.  That's one of the reason I never tried to start a Chinese remix.
[09:45] <TheMuso> If canonical would disclose a little more on how they build CDs...
[09:45] <white> Hobbsee: bah
[09:45] <white> Hobbsee: i am not much of a press person, so i never know what to answer these guys
[09:46] <Fujitsu> TheMuso: Aren't the instructions public?
[09:46] <TheMuso> Fujitsu: To modify yes.
[09:46] <Fujitsu> (I admit I've never had cause to look, but I presumed they were)
[09:46] <TheMuso> joejaxx had to figure out how to do CD builds for UbuntuStudio mostly by trial and error.
[09:47] <Fujitsu> What fun!
[09:47] <TheMuso> Ad even then, there were little things that still weren't quite right, which we had to use dirty hacks to get around.
[09:48] <minghua> TheMuso: So has the decision about building from universe been made?  I didn't follow that thread.
[09:48] <TheMuso> Actually, repos of the cd build scripts are available, but you have to know how to put it all together.
[09:48] <TheMuso> minghua: afaik no.
[09:49] <TheMuso> The last thing was Colin saying "I'll do it if I have to"
[10:48] <Hobbsee> white: we definetly dont seem to have a process for revoking MOTU rights.
[10:49] <Hobbsee> white: i didnt get much traction with creating one at UDS, either.
[10:50] <persia> Hobbsee: Are social pressures not enough?  I would think that repeatedly having ones uploads reverted would lead to improved behaviour.
[10:50] <Hobbsee> persia: ahhh...so we can revert dodgy uploads too, with a nice changelog message....
[10:50] <white> persia: revert in terms of uploading a higher version with revoking the change?
[10:50] <StevenK> It's hard to revert an upload that's hit the archive.
[10:50] <persia> white: Yes.
[10:50] <Hobbsee> persia: the trouble is *finding* the dodgy uploads, too
[10:50] <Hobbsee> as in, as quickly as possible, before things break too much
[10:51] <persia> Hobbsee: Ah.  True.  Perhaps we do need a removal policy then.
[10:51] <white> does a MOTU have access to vital libraries?
[10:51] <Hobbsee> white: define "vital libraries" please?
[10:51] <persia> white: Define vital.  Anything not required for main is MOTU managed, and some of those libraries might be considered vital for some applications (e.g. libjack)
[10:51] <white> Hobbsee: a library were more than 2 other applications depend on, for instance
[10:52] <white> s/were/where/
[10:52] <persia> Certainly that.  There are lots of cases with more than 10 rdepends.
[10:52] <StevenK> There is plently of those in univer.
[10:52] <white> so there is no restriction for universe uploads done by MOTUs?
[10:52] <Hobbsee> white: MOTU can upload to anything in universe and multiverse.
[10:52] <Hobbsee> white: correct
[10:53] <white> ah ok
[10:53] <Hobbsee> white: apart from social ones, which people will tend to growl at you, if you upload a section that you shouldnt
[10:53] <persia> white: Exactly.  It's somewhat like a continuous 0-day BSP, without NMU considerations.
[10:53] <white> oh
[10:53] <Hobbsee> (like, i will tend to whinge at you if you upload something to do with kde, without going thru the debian QT KDE team)
[10:54] <persia> Hobbsee: You don't always though, as long as it doesn't directly impact kubuntu
[10:54] <Hobbsee> persia: true, i dont have the time to do all of them
[10:56] <Hobbsee> persia: i do want to look at shoving more of our changes back into debian though, for all MOTU, not just the debian qt kde team.
[10:57] <persia> Hobbsee: I think that's a great idea.  beuno has been reviving DCT, and I'm seeing a lot more syncs recently.  Perhaps we can make it all the way: there's not very many changes in universe that are ubuntu-specific.
[10:57] <Hobbsee> DCT?
[10:57] <Hobbsee> persia: that'd be teh long term goal, yes.
[10:57] <Hobbsee> persia: bring it up at the meeting tonight, please
[10:57] <StevenK> What time is the meeting?
[10:58] <persia> StevenK: Tomorrow morning (I think 9:00 in Sydney)
[10:58] <persia> Hobbsee: You won't be there?  It's your agenda item :)
[10:58] <StevenK> Hrm. I'm usually sleeping at 9am on a Saturday.
[10:59] <Hobbsee> i'll likely be asleep
[10:59] <Hobbsee> who put it at that time?
[11:01] <persia> The time was discussed at the last meeting: I believe the idea was to encourage attendance from people in other timezones.
[11:02] <Fujitsu> Isn't it 0000Z?
[11:02] <ajmitch> StevenK: how about 10am?
[11:03] <StevenK> Still sleeping. :-)
[11:03] <persia> Fujitsu: Yes.  Did I do my math wrong?
[11:03] <ajmitch> lazy
[11:03] <Fujitsu> That's 1000 AEST.
[11:03] <StevenK> ajmitch: I get up at 0730 every week day, so I like to sleep in on weekends.
[11:03] <Fujitsu> We're +10, except when we're +11.
[11:03] <Fujitsu> I get up at 0700 every day. I just can't sleep in.
[11:04] <Hobbsee> Fujitsu: yes, but you're insaen
[11:04] <StevenK> Fujitsu: It's a remarkably easy skill to pick up.
[11:05] <Fujitsu> Hobbsee: True, true.
[11:05] <Fujitsu> StevenK: Doubtful.
[11:06] <persia> StevenK: It depends.  If you've never slept in, you can develop the skill, but once you've forgotten how, it becomes difficult to return.
[11:08] <persia> Hobbsee: Right.  I'm not sure it would get more than nods anyway - I think most people who would attend the meetings agree.  beuno's work to organise sending patches and opening ITPs is probably a better focus for interested parties anyway.
[11:10] <StevenK> Can anyone expand that?
[11:10] <Hobbsee> i'm assuming it's distro common tools, but no one's told me
[11:10] <persia> StevenK: https://wiki.ubuntu.com/DCT
[11:10] <Fujitsu> Debian Collaboration Team.
[11:10] <Fujitsu> Distro common tools!?
[11:11] <persia> Hobbsee: From where do you get that expansion?
[11:11] <Hobbsee> persia: oh, im' thinking of a rename of MDT.
[11:11] <Fujitsu> Ah.
[11:11] <Hobbsee> persia: guessing, because no one had actually expanded it when i asked before, so i guessed on context
[11:11] <ajmitch> yay, freezes
[11:11] <StevenK> persia: You tell lies, there's no ubuntustudio-meta upload. :-)
[11:12] <Hobbsee> ajmitch: you
[11:12] <Fujitsu> Not me.
[11:12] <ajmitch> Hobbsee: no, I won't
[11:12] <Fujitsu> ajmitch: Definitely.
[11:12] <Fujitsu> s/:/,/
[11:13] <ajmitch> no, because I haven't nominated myself
[11:13] <persia> StevenK: "(17:22:13) TheMuso: persia: Give me 45 mins or so to build ardou2 ppc, and I'll have an answer for you.".  It's an extended definition of the minute :)
[11:13] <Fujitsu> Ah
[11:13] <StevenK> Heh
[11:16] <cromo> so, what about his bug? https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/125131
[11:16] <ubotu> Launchpad bug 125131 in flashplugin-nonfree "Need to be updated for new stable version (9,0,48,0)" [Undecided,New]  
[11:16] <cromo> it affects a lot of people...
[11:16] <white> Fujitsu: DCT -> tell me more
[11:18] <persia> cromo: If you're preparing a package, you'll want to request sponsorship by subscribing the sponsors team.  If you want to discuss the bug, you'll want to do so in #ubuntu-bugs.
[11:19] <gnomefreak> persia: i tested upstream flash new version seems to work fine. i was worried about the regresstions they had but looks good to me
[11:20] <Hobbsee> cromo: asac and someone else were looking into that for gutsy last night
[11:20] <Hobbsee> calc: your connection isnt behaving today, is it?
[11:21] <persia> gnomefreak: Great.  Are you prepping something for review?
[11:21] <gnomefreak> should be as simple as changing the md5sums since its still the same named tarball upstream
[11:21] <gnomefreak> persia: i dont know flash/bash that well or i would
[11:21] <cromo> Hobbsee: thanks for notice
[11:21] <gnomefreak> i have source just need to figure it out
[11:22] <cromo> persia: I am actually not using ubuntu, though my friends do and so I _do_ care about this bug as they do ;-)
[11:22] <Hobbsee> gnomefreak: it's not - the md5sum changes, depending on which mirror it is, iirc
[11:22] <Hobbsee> gnomefreak: at least, that's what we were finding last night
[11:22] <gnomefreak> persia: 9.0.31 and 9.0.48 tarballs are same name like they removed 9.0.31 from the tar and added 9.0.48 instead
[11:22] <cromo> not a good explainaiton, excuse me that ;-)
[11:22] <persia> cromo: Understood.  It's just that this channel is good for work-in-process, whereas setting the relative priority of bugs and discussing them is better done in #ubuntu-bugs
[11:23] <cromo> I see, didn't know that
[11:23] <cromo> thanks
[11:23] <gnomefreak> so the scripts are looking for md5sum of 9.0.31 but 9.0.48 is there instead
[11:23] <cromo> gnomefreak is right though, they updated the package an left it at the same URL
[11:23] <cromo> *and left
[11:23] <persia> gnomefreak: I remember seeing reports of 3 or 4 different md5ums from the upstream servers, depending on the location from which it was downloaded.
[11:23] <gnomefreak> our script should only have to change md5sums since everything else is same
[11:24] <gnomefreak> thats adobes screw up i thin its thier problem from beginning
[11:24] <gnomefreak> but they wont fix it im sure
[11:25] <persia> gnomefreak: Perhaps not, but if we could get a list of the 3 or 4 acceptable md5sums, and verify that they were all the right package, perhaps we could work around their breakage (with slightly less security).  Check the #ubuntu-devel log from about 20 hours ago for some background.
[11:27] <asac> persia: can someone give me the new md5sum of flashplugin?
[11:27] <asac> i still get the old one here
[11:27] <asac> :(
[11:27] <cromo> I was actually thinking about including the plugins inside the deb file instead of scripting the downloading process? Please note, that as for very recent version Adobe also provides rpm packages for RH.
[11:27] <persia> asac: URL?
[11:27] <cromo> so they'd probabaly agree on that
[11:27] <asac> persia: i don't have it
[11:27] <cromo> http://blogs.adobe.com/penguin.swf/2007/06/new_installation_method.html
[11:27] <asac> would have to use google :)
[11:28] <persia> cromo: That's the download site?
[11:28] <cromo> nope
[11:28] <cromo> it's adobe's bloag about linux flash plugin development
[11:28] <cromo> they just introduced a rpm package with flash
[11:29] <persia> There's a link to the tar.gz.  checking...
[11:29] <cromo> so what I suggest is to contact them and cooperate on creating a deb package for flash
[11:29] <persia> asac: I get 821cc72359a937caef85bb4cc74ef5cd
[11:30] <gnomefreak> why not grab tarball and host it on one of our servers (will stop this issue now and in future)
[11:30] <persia> gnomefreak: No license for redistribution?
[11:30] <gnomefreak> hmmmmmm
[11:30] <gnomefreak> i thought that was for changing it
[11:31] <cromo> I am pretty sure adobe will introduce their deb package soon - it's been requested in comments 
[11:31] <gnomefreak> iw ill have to read thier license
[11:31] <persia> gnomefreak: It might be: I didn't check, but rather am remembering old discussions.
[11:38] <persia> TheMuso: Are you still building or testing?  My enter key is looking really tempting :)
[11:38] <pygi> morning folks
[11:38] <pygi> persia, thanks, it built
[11:39] <persia> pygi: Great.  Don't forget to update the bug.
[11:39] <pygi> persia, yup, going after it now
[11:41] <TheMuso> persia: SOrry, dinner called me away.
[11:41] <persia> TheMuso: That's OK.  How's it looking?
[11:41] <StevenK> Uh, dinner is supposed to be dead, which means it *can't* call out...
[11:41] <TheMuso> well the build was going when I left, so just getting things installed now.
[11:41] <TheMuso> in a gutsy ppc chroot.
[11:41] <TheMuso> StevenK: hardy hardy har.
[11:42] <persia> StevenK: Many people eat live food.  It's considered a delicacy :P
[11:42] <StevenK> TheMuso: Oh, you secretly like my bad puns. :-P
[11:42] <StevenK> persia: I'd rather not think about that ...
[11:51] <TheMuso> persia: Looking good so far, but I need to work out how to install recommended packages
[11:51] <Hobbsee> TheMuso: you cant, unless you fix apt
[11:51] <TheMuso> Hobbsee: Right.
[11:52] <persia> TheMuso: There shouldn't be any - all of *recommends* are 0-byte files.
[11:53] <TheMuso> Well packages are listed as recommends.
[11:53] <Hobbsee> TheMuso: ah right, then that's a bug in your package
[11:53] <TheMuso> i haven't touched meta
[11:54] <Hobbsee> persia: it's not germinate that you're looking in, i think
[11:54] <Hobbsee> er, that you awnt to
[11:54] <Hobbsee> TheMuso: oh, the packages *are* listed as recommends
[11:55] <persia> Hobbsee: ubuntustudio-meta uses germinate to populate Depends: and Recommends: for the binaries.
[11:55] <TheMuso> yes there are some packages listed under recommends yes
[11:55] <Hobbsee> persia: oh good.
[11:55] <TheMuso> ouch 370mb
[11:55] <TheMuso> 380 even
[11:56] <TheMuso> Pumpernickel: Well its not complaining about missing deps at least.
[11:56] <persia> TheMuso: I can't find any recommendations with dpkg -e and looking at the control files.  Are you perhaps thinking of packages recommended by the dependencies of the metapackages?
[11:56] <TheMuso> ugh persia ^^
[11:57] <TheMuso> persia: Ah of course.
[11:57] <StevenK> persia: There's a new germinate going to be published in ~ 5 minutes
[11:57] <StevenK> TheMuso: That's what a local mirror is for. :-)
[11:57] <persia> TheMuso: That's my key concern.  At this point, I don't mean to change the installed list really, just to update for all the cruft.
[11:58] <TheMuso> persia: Right, looks like there shouldn't be a problem, minus binary ardour packages.
[11:58] <persia> StevenK: Hmmm..  I think I'd rather build-test against the new one than try to beat it: otherwise the package might not behave properly for the next person to touch it.
[11:58] <persia> TheMuso: Great.  Now I just need to test against 0.31, and it's all good.
[11:58] <TheMuso> ok
[11:58] <TheMuso> persia: I'll leave the download/install running, just to be safe.
[11:59] <persia> TheMuso: Thanks.
[12:22] <gnomefreak> persia: i tried to upgrade flash and built debs once i get ff installed in chroot ill test it and ill beablet o tell asac (who is working on it) if it works
[12:22] <persia> gnomefreak: Great.  Thanks for helping.
[12:22] <gnomefreak> yw we will see if my fix fixed it (it built) :)
[12:27] <gnomefreak> :)
[12:29] <gnomefreak> thats not it
[12:30] <gnomefreak> couple of hours if the archive team pushes it to buildd than hits repo
[12:31] <persia> gnomefreak: I'm not waiting for build, just for it to go from queue:done to sources.gz
[12:31] <gnomefreak> ah shouldnt be that long than i wouldnt think
[12:33] <Fujitsu> persia: The publisher runs hourly, at 3 minutes past the hour. It takes about 40 minutes to run.
[12:33] <persia> Fujitsu: Ah.  Do the packages live somewhere else public prior to the publisher run?
[12:33] <Fujitsu> persia: They do not.
[12:34] <gnomefreak>     File name: libflashplayer.so
[12:34] <gnomefreak>     Shockwave Flash 9.0 r48
[12:34] <gnomefreak> hmmmm
[12:34] <gnomefreak> it plays
[12:34] <Fujitsu> I believe they're attempting to speed it up so we can have half-hour days soon.
[12:34] <gnomefreak> its installed
[12:34] <Fujitsu> gnomefreak: Yay :)
[12:34] <gnomefreak> Fujitsu: not yay :(
[12:35] <gnomefreak> Download done.
[12:35] <gnomefreak> plugin changed, not trusted
[12:35] <gnomefreak> The Flash plugin is NOT installed.
[12:35] <gnomefreak> that needs to be fixed than
[12:35] <Fujitsu> Ah, lovely.
[12:35] <gnomefreak> but it did install and it works
[12:35] <persia> Fujitsu: half-hour days?  I thought a "day" was two runs.
[12:35] <Fujitsu> cron.daily runs hourly at the moment.
[12:35] <Fujitsu> cron.daily is the publisher.
[12:35] <persia> Ah.  Amusing that :)
[12:35] <Fujitsu> Rather.
[12:36] <Fujitsu> I was somewhat confused when I first saw that.
[12:36] <asac> gnomefreak: just update the md5sum which is in flashplugin-nonfree debian/postinst
[12:36] <gnomefreak> asac: i did
[12:36] <asac> gnomefreak: if you want to test the packaging as well
[12:36] <persia> I suspect there's probably also a cron.24hours or something, as I wouldn't imagine all the daily scripts should run that often.
[12:36] <gnomefreak> both of them
[12:36] <asac> gnomefreak: ah cool
[12:37] <gnomefreak> asac: it built and installed but dpkg said it didnt install
[12:37] <gnomefreak> oh and works
[12:37] <asac> gnomefreak: if it works, report a bug with with debdiff and subscribe universe-sponsors i guess
[12:37] <asac> dpkgsaid it didn't install?
[12:37] <gnomefreak> right
[12:38] <asac> sounds wrong
[12:38] <gnomefreak> see MT channel for the 3 lines
[12:38] <asac> what do you mean by that?
[12:39] <TheMuso> persia: At installing phase, still looks good. Don't expect there to be problems.
[12:39] <Fujitsu> Q-FUNK: Filing sync bugs without subscribing anybody is fairly useless.
[12:40] <joejaxx> someone pinged me in here?
[12:40] <persia> TheMuso: Great.  The new germinate just published, so I'm preparing another test build now.  If the debs end up the same, I'll upload.
[12:40] <TheMuso> ok
[12:40] <persia> joejaxx: I'm updating ubuntustudio-meta, and your name came up when we were talking about all the trouble you had building the CDs for ubuntustudio.
[12:41] <joejaxx> you are updating it?
[12:43] <persia> joejaxx: Yep.  Dropping gimp-svg, migrating ardour, cleaning up the vcs and dssi plugins, etc.  No real changes, just cruft cleanup to help drop some of the old NBS packages.
[12:43] <joejaxx> hmm
[12:47] <persia> joejaxx: Changelog entry is http://paste.ubuntu-nl.org/29771/
[12:52] <persia> Excellent.  There's no changes from the new germinate.
[12:53] <Q-FUNK> Fujitsu: the maintainer is already subscribed.
[12:53] <Q-FUNK> i.e. bryce is the main guy that needs to know.
[01:30] <bryce_> Q-FUNK, Fujitsu, which needs sync'd?
[01:34] <Fujitsu> -amd, I believe.
[01:34] <Fujitsu> Bug #125116
[01:34] <ubotu> Launchpad bug 125116 in xserver-xorg-video-amd "please sync from Debian unstable to Gutsy (universe)" [Undecided,New]  https://launchpad.net/bugs/125116
[01:38] <Q-FUNK> bryce_: yes, amd
[01:38] <bryce_> ok
[01:40] <soren> Anyone with shell access to revu? I need something removed from incoming..
[01:40] <persia> soren: Sure.  Which package?
[01:40] <soren> persia: storm_*
[01:40] <soren> persia: There should be a file and a half there :)
[01:41] <persia> soren: two and a half actually.  manually rejected.
[01:41] <soren> persia: Super. Thanks.
[01:41] <mruiz> hi all
[01:44] <mruiz> Is it possible to add a debdiff to REVU? 
[01:45] <Fujitsu> mruiz: What do you mean?
[01:45] <Fujitsu> REVU is for new packages...
[01:46] <mruiz> and upgrades 
[01:46] <man-di> mruiz: file a bug in launchpad and include your debdiff
[01:46] <mruiz> thanks man-di 
[01:47] <DarkSun88> Hi all
[01:52] <DarkSun88> ..
[01:53] <mruiz> hi DarkSun88 
[02:04] <Hobbsee> hi dholbach 
[02:07] <dholbach> hey Hobbsee
[02:07] <Hobbsee> :)
[02:07] <ScottK> Good morning all.  Interesting backscroll today.
[02:24] <zul> hey
[02:25] <ScottK> FWIW (from the overnight - for me) discussion, Debian Python Modules Team seems to work very well with Ubuntu.
[02:28] <persia> ScottK: I'd say that most of the teams do, even.
[02:28] <ScottK> That's the only one I have any experience with.
[02:31] <xxxxx1> hello all
[02:33] <persia> StevenK: Any objections to me chasing libsilc?
[02:33] <persia> StevenK: nevermind.  I can't read.
[02:35] <StevenK> Heh
[02:36] <StevenK> Although the ABI/API and include files have all changed.
[02:40] <persia> StevenK: No worries.  I just had some time and felt like processing something painless.  I'll go back to looking at RC bugs :)
[02:40] <StevenK> SILC isn't looking painless anymore. :-)
[02:42] <persia> Perhaps that needs a definition then..  "painless" as in: I don't need to think about whether it's a good idea, or what the feature should be, but rather just keep compiling it until the patch finally works, and the binaries run.
[02:42] <persia> (with bonus painlessless when it's in a language I've previously used)
[02:42] <StevenK> Ahh, painless, as in grunt work
[02:42] <persia> Exactly.
[02:43] <persia> Syncs are painless, and useful, but don't come with the same sense of satisfaction that comes from a good patch.
[02:44] <StevenK> Agreed
[02:54] <StevenK> Woot, ggz-grubby uses CDBS.
[02:55] <azeem> oh, is this the CDBS-haters party here now as well?
[02:55] <azeem> or are you really delighted? :)
[02:55] <Hobbsee> azeem: no, we like cdbs here :)
[02:56] <StevenK> azeem: It means adding a patch system to debian/rules is one whole line.
[02:56] <elmargol> dpkg-source: error: source package has two conflicting values
[02:56] <elmargol> it can't find the error
[02:56] <persia> elmargol: Could you paste your command and the output to a pastebin?  The guidance you receive will require knowledge of the affected package and the arguments you used.
[02:57] <StevenK> No, the error is in debian/control.
[02:57] <StevenK> elmargol: Can you pastebin your debian/control?
[02:57] <elmargol> sure
[02:58] <elmargol> http://pastebin.com/m3445f91a
[03:00] <StevenK> Hrm.
[03:00] <StevenK> It isn't jumping out at me, sorry
[03:00] <elmargol> dpkg-source: error: source package has two conflicting values - miro and democracyplayer
[03:00] <elmargol> thats the error message
[03:00] <Fujitsu> Ummm.
[03:01] <StevenK> Oh, I know that is.
[03:02] <StevenK> elmargol: Okay, your debian/control says 'miro' is the Source, but the latest entry in debian/changelog says 'democracyplayer
[03:02] <StevenK> ' is.
[03:02] <elmargol> persia: i just to dpkg-buildpackage
[03:02] <elmargol> StevenK: ahh cool
[03:05] <elmargol> it works now thx
[03:09] <elmargol> How can I restore a deleted file using svn?
[03:10] <Fujitsu> elmargol: svn revert filename
[03:10] <elmargol> thx
[03:15] <mruiz> ScottK: I read your last comment about u-u-s. I subscribed them because dholbach said me. But, anyway I won't do it again.
[03:16] <ScottK> OK.  Not a big deal.  It just means people end up looking at stuff twice.
[03:17] <ScottK> persia is the MOTU process guru...  persia, is there any reason in our process to subscribe UUS to a bug about a new upstream that's already uploaded to REVU?
[03:17] <mruiz> ScottK, thanks ;-)
[03:18] <persia> ScottK: Mostly because it only requires one advocate, and it's not new, so U-U-S is presumably interested.  The old process used to be to attach the .dsc, diff.gz, and URL to orig.tar.gz to the bug, but I think REVU is easier.
[03:18] <elmargol> svn diff shows the revision numbers compared. is it possible to have the dates of the files?
[03:19] <elmargol> I see most patches have the dates
[03:19] <StevenK> svn log will tell you the date of the revision numbers
[03:19] <elmargol> having --- platform/gtk-x11/platformcfg.py.orig	2007-02-03 21:43:13.000000000 +0100 in stead of --- platform/gtk-x11/platformcfg.py     (Revision 4869)
[03:22] <StevenK> Ugh. silky's upstream haven't updated it for the new SILC API.
[03:31] <mruiz> bye all!
[04:14] <CrummyGummy> Hi all, Can I build a feisty package on a edgy box? It says there's no script. Can I download it somewhere?
[04:16] <persia> CrummyGummy: The easiest way is to prepare an edgy chroot, and run aptitude dist-upgrade to get feisty.  If you want to be extra clean, build a new feisty chroot in the upgraded chroot.  Alternately, you could try downloading the feisty debootstrap, but I'm not sure that works properly (it did for me, but that's no guarantee).
[04:18] <CrummyGummy> persia, Thanks, I'll start at option 3.
[04:21] <ryanakca> It's possible to request a sync while a package is still in Debian NEW?
[04:22] <persia> ryanakca: Yes, but it's not likely to be processed until after Debian NEW is done, and it makes life easier for the archive-admins to wait until after that before filing the bug.
[04:22] <ryanakca> ok
[04:23] <ryanakca> persia: can you archive aoeui in REVU please?
[04:23] <persia> ryanakca: For future reference, about the only time that's a good idea is when it's two days until the new packages freeze, and the new package is required to meet a feature goal for the current release.
[04:24] <persia> ryanakca: Sure.
[04:24] <persia> ryanakca: 5992 archived.
[04:24] <ryanakca> thanks
[04:24] <calc> so anyone here have moderator access on motu-council that could let my email through i forgot to post it with my subscribed email
[04:31] <xxxxx1> some MOTU on?
[04:32] <xxxxx1> i need a sponsor for: http://revu.tauware.de/details.py?upid=6004
[04:32] <xxxxx1> I just removed the PDF based on pitti's request and you need a reupload
[04:32] <xxxxx1> ops
[04:32] <xxxxx1> I just removed the PDF based on pitti's request and I need a reupload
[04:34] <bryce_> Q-FUNK, Fujitsu, still waiting on the -amd sync, bug 125759
[04:34] <ubotu> Launchpad bug 125759 in xserver-xorg-video-amd "Please sync xserver-xorg-video-amd (universe) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/125759
[04:34] <Q-FUNK> bryce_: waiting for...?
[04:34] <bryce_> ...it to be sync'd
[04:34] <Q-FUNK> ok
[04:35] <Q-FUNK> thanks for that
[04:35] <Hobbsee> calc: argh!!!!
[04:35] <Hobbsee> calc: try having an openoffice that builds every time...
[04:36] <calc> Hobbsee: it seems to at least partially be the buildds fault
[04:36] <Hobbsee> calc: sure sure
[04:36] <calc> it keeps failing on ppc for example due to timeout
[04:36] <StevenK> calc: I am, and will.
[04:36] <calc> StevenK: heh
[04:36] <calc> they are moving it to build on a different ppc
[04:36] <Q-FUNK> bryce_: unauthenticated connection?
[04:37] <calc> Hobbsee: the first build 5ubuntu1 was by doko
[04:37] <calc> Hobbsee: 5ubuntu2 was good but debhelper was fubar
[04:37] <calc> Hobbsee: 5ubuntu3 is fine now
[04:37] <bryce_> Q-FUNK: huh?
[04:37] <Hobbsee> calc: sure sure.  you just keep breaking it
[04:37] <calc> of course the build failure, retry work thing is very annoying and i have no idea what causes it
[04:37] <calc> eh?
[04:37] <Q-FUNK> bryce_: do you see my incoming query?
[04:38] <bryce_> oh
[04:38] <calc> i've only uploaded two versions of ooo to main so far and only one was broken and it was debhelpers fault :P
[04:38] <doko> Hobbsee: don't complain, fix it ;-P
[04:38] <Hobbsee> doko: i dont have the bandwidth, nor the machine for that.  and i'm still somewhat sane
[04:38] <calc> i wish i could replicate the build failures, it always builds fine for me
[04:38] <StevenK> Heh
[04:39] <calc> seems the retry work failures tend to be the 65280 failures
[04:40] <xxxxx1> ScottK, PM
[04:40] <ScottK> Not now.  Busy with other stuff.  Thanks for checking first.
[04:40] <calc> ScottK: it does build
[04:40] <calc> ScottK: it appears to be buildd issues or very tricky timing issues of some sort
[04:40] <calc> ScottK: since it builds on the same buildd fine after a retry
[04:41] <ScottK> very tricky and OOO do seem to go together.
[04:41] <xxxxx1> i need a sponsor for: http://revu.tauware.de/details.py?upid=6004 can some MOTU upload for me?
[04:41] <calc> and the issue existed apparently long before i took over ooo
[04:43] <ScottK> calc: Don't confuse me with facts.
[04:43] <calc> hmm some people having similar issue claim increasing the ram in the system helped
[04:43] <DarkMageZ> how would one go about generating a ddeb?
[04:44] <calc> if ronne runs out of memory something is wrong
[04:44] <calc> it has 4GB ram and 6GB swap
[04:45] <geser> 10 GB is not enough to build OOo?
[04:46] <geser> DarkMageZ: look at pkg-create-dbgsym
[04:47] <DarkMageZ> geser, thanks.
[04:47] <calc> geser: no it doesn't use that much
[04:48] <calc> geser: somewhere < 1GB is plenty
[04:48] <calc> geser: i build it on my laptop just fine
[05:11] <ScottK> xxxxx1: PM?
[05:25] <AndyP> build depending on imagemagick in an architecture: all package gives "build-depends-without-arch-dep" - do i need to fix that? if so, what's the best way?
[05:26] <man-di> AndyP: put imagemage inot Build-Depends-Indep instead of Build-Depends
[05:26] <AndyP> man-di: thanks
[05:27] <Jazzva> Hello... I'm having a problem with testing the package under pbuilder. First I compiled it in feisty and everything was ok. Now I'm trying to compile it in gutsy and the pbuilder says it can't locate package qca-dev. I checked at packages.ubuntu.com and qca-dev is there... Does anyone know how to fix this?
[05:28] <azeem> maybe your chroot doesn't include universe in sources.list?
[05:28] <azeem> eh, base-tarball
[05:28] <Jazzva> azeem: How can I check that?
[05:29] <azeem> maybe with pbuilder login
[05:29] <azeem> I'm not using pbuilder, sorry
[05:29] <Jazzva> azeem: Ok, I'll give it a try.
[05:36] <doctormo> hello everyone
[05:37] <doctormo> I have a project I need to package up as a deb, with dependancies; it's originaly a dist-utils python install but that no longer works since I can't install the full rpm database under ubuntu.
[05:37] <ryanakca> how do you enable universe in pbuilder?
[05:37] <doctormo> So I need advice and help on getting a new install script made specificly for deb
[05:37] <doctormo> it has no configure file, or makefile
[05:41] <Jazzva> ryanakca: I would like to know that to...
[05:41] <ryanakca> Jazzva: nevermind, found it :)      pbuilder-gutsy update --override-config --othermirror "deb http://archives.ubuntu.com/ubuntu/ gutsy universe"
[05:41] <ScottK> doctormo: Does it have a setup.py?
[05:42] <doctormo> ScottK: yes
[05:42] <ScottK> Then it's easy.
[05:42] <Jazzva> ryanakca: Great :D... That's exactly what I needed. :)
[05:42] <doctormo> ScottK: I may be able to predict what you about to say...
[05:43] <ScottK> doctormo: What version of Ubuntu are you running?
[05:43] <doctormo> ScottK: 7.04
[05:43] <Jazzva> ryanakca: Just add sudo :).
[05:43] <ScottK> OK.
[05:43] <ryanakca> ScottK: don't need to...
[05:43] <ryanakca> ScottK: oops, wrong person
[05:43] <ryanakca> Jazzva: ^^
[05:45] <doctormo> hehe
[05:45] <doctormo> I'm all ears
[05:45] <man-di> doctormo: there are a lot of upstreams using setup.py and a lot of the debian packages packaging them
[05:45] <ScottK> No, what I would suggest is start with a simple python package that's already done
[05:45] <Jazzva> ryanakca: Hmm, really :unsure:? I just tried without sudo and it said " cannot create directory `/var/cache/pbuilder/build//934': Permission denied".
[05:45] <man-di> doctormo: there are ways to just use the setup.py from debian package
[05:45] <ScottK> doctormo: You might apt-get source pyyaml and have a look at that.
[05:45] <ryanakca> Jazzva: you have a different setup than I do. Try finding the old pbuilder howto on the wiki
[05:46] <doctormo> man-di: yes an interesting idea since a standard rpm or deb will die on having the wrong version of python than that which created them
[05:46] <ScottK> doctormo: Actually the Debian packaging tools support packaging for multiple versions.
[05:47] <Jazzva> ryanakca: Ok. Is it better then the new one?
[05:47] <ryanakca> Jazzva: I have a pbuilder-dapper, pbuilder-edgy, pbuilder-feisty, -gutsy and -sit
[05:47] <ryanakca> -sid
[05:47] <ryanakca> Jazzva: umm, well, it has the scripts to set up individual pbuilders for each distro/version
[05:47] <ScottK> doctormo: I'd suggest that between the packaging-guide and looking at how I did pyyaml, you'll be able to get most of it figured out.
[05:48] <Jazzva> ryanakca: Yeah, I see that's only mentioned here. Guess I'm gonna take a look at that howto :).
[05:48] <man-di> doctormo: please read also the new python packaging policy
[05:49] <ryanakca> Jazzva: hunt around for a pbuilder-distribution.sh
[05:49] <Jazzva> ryanakca: Found it :)
[05:49] <ScottK> man-di: The package I pointed him at uses the new policy, so if he uses that as a guide, he should be OK.
[05:49] <doctormo> man-di: do you have a link to the new python packaging polocy?
[05:51] <ScottK> http://www.debian.org/doc/packaging-manuals/python-policy/
[05:51] <ScottK> http://wiki.debian.org/DebianPython/NewPolicy is also useful.
[05:51] <doctormo> ScottK: so PKG-INFO, debian/* are all a part of the wrapper?
[05:52] <ScottK> Yes.
[05:52] <man-di> ScottK: the policy might contain additional infos for him
[05:52] <ScottK> You'll also want https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
[05:52] <ScottK> Right.
[05:55] <doctormo> I'm so glad you guys know what your doing with dist-utils, I've been pulling my hair out
[05:56] <doctormo> ok so another question: the program on install creates copies of dmi info, it's a little script which is currently done by setup.py this won't be effected right?
[05:57] <ScottK> You will need to make sure it gets installed in the right place.  Usually it does, but you'll need to check.
[05:58] <doctormo> any rules for /var/local files and /etc files?
[05:59] <ScottK> CDBS will install files where setup.py says they go.  
[06:00] <ScottK> The simplest thing to do if setup.py points the file to the wrong place is patch setup.py.
[06:01] <ScottK> doctormo: You'll want http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html to know where files are supposed to be installed.
[06:02] <doctormo> ScottK: yep they go there, just confirmed it with that link above. thanks
[06:09] <doctormo> Any info on how to fill out the classifier info? it seems like it's not arbitaryu
[06:11] <ryanakca> "pbuilder-gutsy update --override-config --othermirror "deb http://archives.ubuntu.com/ubuntu/ gutsy universe" should enable universe in a pbuilder, right?
[06:12] <Hobbsee> ryanakca: should do..
[06:28] <zachtib> hey guys, I'm one of the lead devs of Deluge, and we're working on our new release, 0.5.3, now.  UVF for gutsy is 8/16.  What's roughly the latest we can get out a new release and still be fairly assured that it will make it into gutsy?
[06:30] <bluekuja> zachtib, deluge-torrent uses libtorrent rasterbar, if Im right
[06:30] <zachtib> blueyes
[06:30] <zachtib> bluekuja, yes
[06:30] <bluekuja> zachtib, is it included into deluge source?
[06:30] <zachtib> yes
[06:31] <bluekuja> that's really bad
[06:31] <bluekuja> for security issues
[06:31] <zachtib> i know, but we only do that b/c the rasterbar lt isn't in ubuntu's repo
[06:31] <bluekuja> I know
[06:31] <bluekuja> I lead motu-torrent team
[06:31] <bluekuja> :)
[06:31] <bluekuja> and I'm working on that
[06:31] <zachtib> trust me, i'd love to get LT out of our source tarball and use the system one, burt first, libtorrent needs to make it into ubuntu
[06:32] <bluekuja> zachtib, yeah
[06:32] <bluekuja> I've talked with rasterbar devels
[06:32] <bluekuja> and they dont want to change lib name
[06:32] <bluekuja> e.g soname and so on
[06:32] <zachtib> plus, at the moment, we're using an unstable version of LT .13 that we've added our own patches and modifications to
[06:32] <zachtib> debian was planning to package it as libtorrent-rasterbar
[06:33] <bluekuja> zachtib, as I said I'm working on that
[06:33] <bluekuja> for debian too
[06:33] <bluekuja> :)
[06:33] <bluekuja> with some other guys
[06:33] <bluekuja> brb
[06:33] <zachtib> anyways, as far as my original question, when should we have the new release ready to be safe getting it into gutsy
[06:33] <man-di> zachtib: now
[06:34] <zachtib> man-di, lol, yeah, we're looking at an RC this upcoming week, and we're working as fast as we can
[06:35] <zachtib> but 0.5 just missed it's chance to make it into feisty, and so I don't want the same thing to happen with this release
[06:35] <zachtib> this new release doesn't add any new features, but we've made some good progress on performance, and cpu usage is much improved, so obviously I'd like this to be in the repos
[06:35] <Hobbsee> zachtib: are you pushing this into debian, and syncing?
[06:36] <Hobbsee> or is this going directly into ubuntu?
[06:36] <man-di> Hobbsee: what does "uvf" means?
[06:36] <Hobbsee> man-di: upstream version freeze
[06:36] <Hobbsee> man-di: ie, the exception team
[06:36] <man-di> Hobbsee: ah, thx
[06:36] <bluekuja> back
[06:37] <Hobbsee> man-di: :)
[06:37] <bluekuja> zachtib, anyway I'll let you know
[06:37] <bluekuja> join #ubuntu-motu-torrent when you want
[06:37] <bluekuja> for more infos
[06:37] <bluekuja> ;)
[06:37] <zachtib> bluekuja, ok... if we have our release out before the end of July, are we pretty much good?
[06:37] <zachtib> cause i think that's very possible
[06:38] <bluekuja> zachtib, getting rasterbar in will take months
[06:38] <bluekuja> ;)
[06:39] <bluekuja> I'll open a security bug for deluge
[06:39] <zachtib> bluekuja, but our current package doesn't need it.  the deluge pkg in universe now builds against our internal LT
[06:39] <bluekuja> I don't know who accepted it in
[06:39] <xxxxx1> ScottK, PM?
[06:39] <bluekuja> with a lib shipped
[06:39] <bluekuja> zachtib, oh k then
[06:39] <bluekuja> :)
[06:39] <zachtib> it's been in for a while
[06:39] <bluekuja> I know
[06:39] <bluekuja> the sponsor did not check
[06:39] <bluekuja> that
[06:40] <bluekuja> also for debian
[06:40] <zachtib> well, as i said, i'd love to do it the real way, but for that to happen we'd need libtorrent 0.13 released and packaged
[06:40] <zachtib> but until then, this is the only way to get deluge included
[06:41] <bluekuja> yup
[06:41] <bluekuja> we'll see then
[06:41] <bluekuja> we are stoned now
[06:41] <bluekuja> ^^
[06:42] <zachtib> lol
[06:42] <bluekuja> :)
[06:51] <doctormo> ScottK, man-di: I must have missed something, I can't find how you compile it into a deb now
[06:53] <man-di> run the 'debuild' command
[06:53] <man-di> (from package devscripts)
[06:55] <doctormo> ah there must be a specific format for changelogs
[06:56] <man-di> doctormo: yes
[06:56] <man-di> doctormo: use the 'dch' tool to create new entries more easily
[07:09] <Q-FUNK> is there an established method for grepping PACKAGE_VERSION and PACKAGE_TARNAME out of ./configure ?
[07:14] <doctormo> make: *** No rule to make target `/usr/share/cdbs/1/class/python-distutils.mk'.  Stop.
[07:14] <doctormo> man-di: I reformed the existing changelog into the right format
[07:35] <doctormo> debuild is asking me for clearsign gpg keys... I'm sure I have them when I signed up for ubuntu launchpad; the question is how to tie them up to debuild?
[07:36] <gnomefreak> doctormo: you can pass -k(keyid)
[07:37] <gnomefreak> you can also add a line to ~/.bashrc give me a minute ill see if i have it set on htis pc
[07:37] <doctormo> thanks
[07:37] <gnomefreak> export GPGKEY=3C1C3C2A
[07:37] <gnomefreak> replace mine with yours ofcourse
[07:40] <doctormo> remind me where I would find my key stored on my machine?
[07:41] <gnomefreak> doctormo: ~/gnupg but if you added it to your LP page it will be there(easier to locate) try running gpg --list-keys <your email with key>
[07:41] <gnomefreak> doctormo: example gpg --list-keys gnomefreak@bleh.com
[07:42] <gnomefreak> that is usful if you have a bunch of keys saved but you can use gpg --list-keys and it will list all keys you have saved
[07:44] <geser> gpg --list-secret-keys will list all keys where you have also the private key
[07:45] <gnomefreak> !gpg
[07:45] <ubotu> gpg is the GNU Privacy Guard.  See https://help.ubuntu.com/community/GnuPrivacyGuardHowto and class #8 on https://wiki.ubuntu.com/ClassroomTranscripts
[07:45] <gnomefreak> ^^ good document
[07:45] <gnomefreak> the first one.
[07:48] <norsetto> persia:  hi Emmet, how is it?
[07:49] <AndyP> http://revu.tauware.de/details.py?upid=6005 is ripe and juicy now, criticise/advocate at your convenience
[07:53] <norsetto> I have the usual newbie question = whats the best way to include a change in a config.in file: generate a patch with changes to the whole chain or include automake etc. in rules?
[07:58] <martoss> hi folks,
[07:58] <martoss> i try to build konsole from sources
[07:58] <martoss> make: *** obj-x86_64-linux-gnu: No such file or directory.
[07:58] <martoss> what's missing there?
[08:00] <imbrandon> sudo apt-get build-dep konsole
[08:00] <imbrandon> looks like
[08:04] <doctormo> cool it built, thank you guyws
[08:05] <martoss> imbrandon, ok everything should be there
[08:05] <martoss> can i just build konsole and not entire kdebase?
[08:05] <martoss> i am doing dpkg-buildpackage -rfakeroot -us -uc 
[08:05] <martoss> atm
[08:10] <Jazzva> Umm, I
[08:11] <Jazzva> Umm, I'm having a problem with pbuilder. I added manually the universe repo to sources.list and it still can't find the qca-dev package.
[08:11] <imbrandon> martoss, no
[08:12] <imbrandon> not easily
[08:12] <Jazzva> The pbuilder is set for gutsy. In pbuilder set for feisty the package built with no sources.list changes.
[08:12] <Jazzva> Any ideas?
[08:12] <AndyP> Jazzva: https://wiki.ubuntu.com/PbuilderHowto#head-5e61fa0f52f7f2442fb20f074813bd691744460b
[08:14] <Jazzva> AndyP: thanks
[08:20] <Kmos> Jazzva: you need to save the session
[08:21] <Kmos> pbuilder login --save-after-login
[08:27] <Jazzva> Kmos: Yeah, did that.
[08:30] <xxxxx1> ScottK, PM?
[08:57] <Q-FUNK> is there any way to make 'git' display commit dates as CCYY-MM-DD ?
[08:58] <ScottK> xxxxx1: Fine
[09:09] <qball> Seveas still mia
[10:05] <ScottK> Can mpeg encoder firmware be packaged separately or does it have to go in the kernel package?
[10:06] <ryanakca> hmm.. does 'developpers' on https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel mean 'Ubuntu Developers' or 'Ubuntu Developers and Members' ?
[10:07] <ScottK> It means MOTU and core-dev.
[10:07] <ScottK> There is devel-discuss where everyone can post.
[10:08] <superm1_> ScottK, out of curiosity, what mpeg firmware are you speaking to?
[10:08] <ryanakca> ScottK: ok
[10:08] <ScottK>  bug 99107
[10:08] <ubotu> Launchpad bug 99107 in linux-source-2.6.20 "Feisty ships with OLD cx2341x mpeg encoder firmware" [Medium,In progress]  https://launchpad.net/bugs/99107
[10:09] <ScottK> superm1_: ^^^
[10:09] <Q-FUNK> can anyone think of a tool to convert a date from time_t to iso8601 ?
[10:09] <ScottK> Oops.  Not that one.
[10:09] <ScottK> This one bug 90723
[10:09] <ubotu> Launchpad bug 90723 in linux-source-2.6.20 "Please include bluebird firmware for dvb-usb devices" [Wishlist,Confirmed]  https://launchpad.net/bugs/90723
[10:09] <ScottK> So it wasn't a mpeg encoder.
[10:10] <superm1_> ScottK, it should go into the newly formed linux-ubuntu-modules I would say
[10:10] <ScottK> dvd-usb.
[10:10] <superm1_> that's used in gutsy
[10:10] <ScottK> superm1_: Could you come over to #ubuntu-bugs.
[10:10] <superm1_> sure
[10:10] <ScottK> The author of it is one there now.
[10:19] <xxxxx1> bye all
[10:20] <superm1_> ScottK, you doing revu's this afternoon?
[10:20] <ScottK> Not particularly.  
[10:20] <ScottK> I may have time if you have something easy.
[10:21] <superm1_> well i think it's something, easy, you can look and see though :P
[10:21] <superm1_> http://revu.tauware.de/details.py?upid=5996
[10:23] <superm1_> oh and ScottK, should mention to you the ubotu magic you can do with pipes, rather than triggering a bot command, and then mentioning someones name afterwards.  you can do something like this instead:
[10:23] <superm1_> bug 99107 | ScottK 
[10:23] <ubotu> Launchpad bug 99107 in linux-source-2.6.22 "Feisty ships with OLD cx2341x mpeg encoder firmware" [Medium,In progress]  https://launchpad.net/bugs/99107
[10:23] <superm1_> well that didn't work as it was supposed to... it works with the ! commands at least
[10:24] <ScottK> superm1_: Personally, I'd Not advocate based on lack of debian/README.Debian-source (looking at persia's comments).  I think you ought to fix that.
[10:24] <ScottK> superm1_: I think you meant to do that on #ubuntu-bugs anyway.
[10:25] <superm1_> i'll have to read up on policy to double check on that
[10:25] <superm1_> as persia mentions that he couldnt find a reference to it
[10:25] <superm1_> no other big standout things though, right?
[10:28] <ScottK> The Developers Reference having it is good enough for me.
[10:28] <superm1_> ah okay
[10:28] <superm1_> thanks ScottK :)
[10:35] <superm1_> actually i don't even see that section persia was pointing out about a README.Debian-source in section 6.7.8.2 of the developer's reference, http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-repackagedorigtargz
[10:37] <ScottK> I remember it being there too.  I also note  the Developers reference is ver. 3.3.9, 16 June, 2007 - The requirement may have been recently deleted.
[10:39] <superm1_> Ah.