[00:00] <Laibsch> I tried the easiest route, just debuild the tree and upload to my ppa, but the package was rejected (obviously) because the information was for the unstable distribution which does not exist in ubuntu
[00:01] <Fujitsu> Laibsch: Change the distribution in the changelog to an Ubuntu release.
[00:03] <geser> Fujitsu: Hi, how are holidays?
[00:03] <Fujitsu> geser: Pretty good, thanks. I'm about to head off again.
[00:04] <Laibsch> Fujitsu: This is for openembedded.org.  The information is maintained in a version control system upstream.  Is there no easier way than duplicating all information and keeping it in sync?
[00:04] <Laibsch> How does ubuntu handle debian packages for import?
[00:04] <Laibsch> There must be some more elegant way, right?
[00:05] <Fujitsu> Laibsch: The script does special evil things that modify the distribution in the .changes file, I believe, but that's bad, and is to be avoided.
[00:05] <Fujitsu> One should not do that for manually uploaded packages.
[00:05] <Fujitsu> Anyway, I have to go now.
[00:10] <the_belgain> Fujitsu: thanks, I've asked for that package removal in the appropriate place now
[00:29] <StevenK> RAOF: Bug 185099
[00:29] <ubotu> Launchpad bug 185099 in apt "apt output in all caps on amd64 when stdin is /dev/null" [Undecided,Triaged] https://launchpad.net/bugs/185099
[00:30] <RAOF> StevenK: Oh, cool.  That's the actual sbuild trigger?
[00:30] <soren> Yeah, sbuild calls schroot blahbalhbalhbab 'apt-get -y install foo < /dev/null' or something to that effect.
[00:30] <RAOF> Cool.
[00:31] <soren> and due to weirdness in apt's termios handling that sets the pty to spew all uppercase stuff.
[00:31] <StevenK> RAOF: Which makes keescook The Man.
[00:31]  * RAOF prostrates himself before The Man
[00:31] <StevenK> Haha
[00:34]  * ryanakca grumbles at having to write a copyright file for a package (a compilation of libraries/bindings) with 50+ authors...
[00:36]  * ryanakca grumbles at people not giving their email address in Copyright (C) 2007 John Smith
[00:39] <DarkSun88> Mmh, nautilus crashes on my Hardy.
[00:40] <crimsun> dist-upgrade
[00:42] <DarkSun88> crimsun: Yes, I knew but there are packages that the dist-upgrade wants to remove.
[00:43] <crimsun> using aptitude safe-upgrade ?
[00:43] <crimsun> sorry, and* using aptitude safe-upgrade ?
[00:43] <DarkSun88> I'll try it.
[00:43] <RAOF> crimsun: Are you still a Debian ALSA teamer?  If so, or even otherwise, is my thinking in debian bug #436201 reasonable?  I'd like to get that done before FF.
[00:43] <ubotu> Debian bug 436201 in libasound2-plugins "libasound2-plugins: Could we get an ia32 package for amd64?" [Wishlist,Open] http://bugs.debian.org/436201
[00:44] <DarkSun88> crimsun: It works. Thanks a lot.
[00:44] <crimsun> RAOF: yes, it's reasonable.  I read the e-mails earlier, but I don't like to post from yahoo since it's spam-nasty.
[00:45] <RAOF> crimsun: Ta.  I'll look at that tonightish then.
[00:45] <DarkSun88> crimsun: But that command doesn't update the packages?
[00:48] <crimsun> DarkSun88: hmm?
[00:48] <crimsun> safe-upgrade Upgrades installed packages to their most recent version. Installed packages will not be removed unless they are unused (see the
[00:49] <crimsun> direct from hardy's aptitude(8)
[00:53] <DarkSun88> crimsun: After that command, return me the prompt.
[00:53] <crimsun> DarkSun88: well, if you've already executed aptitude safe-upgrade, it's likely it won't do anything but exit successfully if it completed successfully prior :-)
[00:56] <DarkSun88> crimsun: Yes, I've already executed aptitude safe-upgrade but I repeat: It doesn't upgrade my packages. It said me that there are 84 packages not updated.
[01:17] <ryanakca> do you put copyright for install-sh in debian/copyright?
[01:21] <ScottK> ryanakca: Is it the same license as the rest of the package?
[01:23] <ryanakca> ScottK: no, its MIT vs GPL
[01:23] <andresmujica> helo motu`s .  i wonder if there's some guidance docs or suggestions at the wiki  in order to create a development enviroment for my laptop,  i want to develop and package some things for ubuntu but don't want to make my desktop a complete mess....
[01:23] <ScottK> ryanakca: Then you need to mention it.  Not mentioning all licenses is an automatic reject.
[01:24] <ScottK> andresmujica: Install build-essential, devsrcripts, and ubuntu-dev-tools and never compile outside of a chroot.
[01:24] <ryanakca> ScottK: or no... wait... *checks* I'm not sure its MIT, I'll pastebin
[01:24] <ScottK> ryanakca: As long as it's not GPL, it needs to be in there.
[01:24] <LaserJock> andresmujica: chroots and pbuilder/sbuild are very helpful
[01:24] <ryanakca> ScottK: http://paste.ubuntu-nl.org/53101/ ... what do I put it as?
[01:25] <LaserJock> ScottK: clamav backport still going?
[01:25] <ryanakca> ScottK: surprising thing is that the package got into universe /without/ a copyright file.
[01:25] <ScottK> LaserJock: Yes.
[01:25] <LaserJock> ryanakca: what package?
[01:26] <ScottK> LaserJock: Riddell had connectivity problems so not all of them got kicked off properly.
[01:26] <ryanakca> ScottK: well, the file was there, but it was still the default dh_make <Insert upstream issues>
[01:26] <LaserJock> ScottK: ah, I see perhaps Hobbsee is coming to the rescue
[01:26] <ryanakca> LaserJock: kdebindings-kde4
[01:26] <Hobbsee> arrr!
[01:27] <ScottK> Unfortunately the rest aren't source backports, so IIRC they can't be done through the web ui.
[01:27] <Hobbsee> what are the rest?  binary backports or something?
[01:28] <ScottK> Hobbsee: There the ones that they use their automagic script to pull them straight out of soyuz.
[01:28] <ScottK> They are source, but no new source is uploaded.
[01:28] <Hobbsee> ahhh
[01:28] <ryanakca> ScottK: would something along these lines work as a copyright files (incomplete, yes...) http://blog.ryanak.ca/copyright ?
[01:28]  * ScottK looks
[01:29] <ryanakca> simply since there are quite a few copyright holders, each "owning" a section/branch/tree in kdebindings-kde4-4.0.0 ?
[01:29] <LaserJock> ryanakca: ummm, that's messed up
[01:30] <ScottK> Yeah.
[01:30] <ryanakca> crap... so where do I put all the authors?
[01:30] <ryanakca> all in a list, without saying who did what?
[01:31] <ScottK> ryanakca: Collect each license together and say foo is copyright bar, alpha is copyright omega, and they are distributed under the terms of the blankety blank license
[01:31] <ScottK> Also you need the bit like you have with LGPL 2.1.
[01:31] <andresmujica> ok, thanks, i'm gonna explore those packages.
[01:32] <LaserJock> andresmujica: for having chroots the schroot package is very helpful
[01:36] <ryanakca> ScottK: ok, so would it be like the top or bottom part of http://blog.ryanak.ca/copyright2 ?
[01:45] <bddebian> Heya gang
[01:46] <LaserJock> hi bddebian
[01:46] <bddebian> Hi LaserJock
[01:46] <ScottK> ryanakca: Sorry.  I'm busy with $WORK and can't really focus on it.
[01:47] <ScottK> ryanakca: As long as it's clear what license/copyright goes with what files and all the licenses are listed in reasonably compact and clear way, it should be fine.
[01:47] <ryanakca> ScottK: ok, thanks :)
[01:56] <LaserJock> shesh, my uni is getting crazy
[01:56] <LaserJock> I keep getting tons of emails about safety
[01:57] <StevenK> LaserJock: Ah, so they noticed your lab practices?
[01:57] <LaserJock> apparently the answer to several rapes and a kidnapping is to have "Personal Safety Awareness Training"
[01:57] <LaserJock> StevenK: no, my lab's not to horrible
[01:58] <LaserJock> I've actually gotta brush up on lab safety for teaching next week
[02:02] <bddebian> Here's one to make you shudder folks: https://nm.debian.org/nmstatus.php?email=bddebian%40comcast.net  ;-)
[02:03] <bddebian> StevenK: haha
[02:03] <LaserJock> bddebian: \o/
[02:04] <bddebian> ajmitch would probably have a heart-attack :-)
[02:05] <ScottK> bddebian: Congratulations.  Prepare to get a lot of practice waiting.
[02:11] <bddebian> ScottK: Yeah I figure I'll be dead and buried before I actually get in but what the hell :-)
[02:17] <LaserJock> does the AM actually have to meet with you?
[02:18] <bddebian> I hope not :-)
[02:18] <LaserJock> I see "ID to be checked by AM"
[02:20] <jdong> what's a small package with an init script...
[02:20] <jdong> ddclient? *checks*
[02:21] <jdong> I just spent 20 minutes getting a watchfile to work on a new package :)
[02:21] <nenolod> LaserJock, becoming a DD ?
[02:21] <nenolod> LaserJock, if so can i whore you for uploads? (:
[02:21] <bddebian> jdong: "Fun" sometimes aren't they? :-)
[02:21] <LaserJock> nenolod: hah, no
[02:22] <nenolod> LaserJock, no to which?
[02:22] <LaserJock> both
[02:22] <jdong> bddebian: and better... upstream doesn't provide an indexed downloads directory (403 forbidden)
[02:22] <nenolod> LaserJock, then what application manager? :o
[02:22] <jdong> bddebian: so I'm scraping the FRONT PAGE, the only place with an AJAXified download link
[02:22] <bddebian> Ugh
[02:22] <jdong> bddebian: so I'm betting $100 that by the time next upstream release comes, THIS WATCHFILE WONT WORK :)
[02:22] <LaserJock> nenolod: bddebian is going for DD
[02:22] <nenolod> oh. right.
[02:22] <nenolod> LaserJock, i already knew that (:
[02:22] <jdong> but there's some personal satisfaction in writing one
[02:23] <nenolod> i'd go for DD but no debian person has signed my key. :(
[02:23] <bddebian> Boy, that will just make ari's year.. :-)
[02:23] <nenolod> i think being a ubuntu member would provide more value.
[02:23] <nenolod> bddebian, oh yes. ari would love it if i became a DD (:
[02:23] <bddebian> or 2 years, or 3 years... :-)
[02:23] <nenolod> he'd probably have a heartattack
[02:23] <bddebian> nenolod: No, I meant me.  We have a long "interesting" relationship :-)
[02:23] <jdong> I can't find a file with an init script!
[02:23] <nenolod> ah.
[02:23] <jdong> forget it, let's look at apache
[02:24] <nenolod> the only relationship with ari i have is a cooperative trolling one.
[02:24] <nenolod> (;
[02:24] <LaserJock> I don't think I'm really interested in DD, I think DM is enough for me
[02:24] <nenolod> which reminds me
[02:24] <bddebian> LaserJock: Are you on NM for DM ?
[02:24] <nenolod> can i whore someone for an upload in a while? (:
[02:24] <LaserJock> bddebian: not quite yet, gotta sen in my app
[02:25] <LaserJock> *send
[02:25] <bddebian> Ah
[02:25] <nenolod> i'm packaging up a default skin for audacious for ubuntu
[02:25] <nenolod> \:D/
[02:25] <LaserJock> but I got everything I need
[02:25] <nenolod> or do i need to upload it to revu
[02:26] <ScottK> jdong: Just grab a randome tarball and run dh_make on it.  It'll give you a shell for an init.
[02:28] <jdong> ScottK: yeah, actually I'm working from the dh_make examples
[02:28] <jdong> ScottK: unsure whether to use init.d.ex or init.d.lsb.ex, I think the LSB variant
[02:28] <ScottK> Use the LSB one.
[02:28] <jdong> ScottK: then also I wanted to ask what to name it, but I figured that out by myself :)
[02:29] <jdong> wow, debianizing a new daemon is so much fun :)
[02:29] <jdong> (not)
[02:29] <ScottK> Yeah.
[02:29]  * ScottK is working on one too.
[02:31] <nenolod> also, which is better, audacious-skin-human or audacious-theme-human ?
[02:31]  * RAOF would go with theme.
[02:31] <nenolod> nifty, thanks
[02:31] <nenolod> (:
[02:31] <jdong> skin-human sounds mean
[02:31] <jdong> ;-)
[02:32] <DarkMageZ> skin-cat =D
[02:35] <nenolod> DarkMageZ, actually i may need your expertise with something in a bit (:
[02:37] <rzr> hi
[02:37] <rzr> are there some resources on backporting to dapper ?
[02:38] <ScottK> rzr: What are you after?
[02:38] <ScottK> !backports | rzr
[02:38] <DarkMageZ> rzr, as in getting a package into backports or as in you backporting a package for yourself?
[02:38] <ubotu> rzr: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[02:38] <rzr> unicorn is broken in dapper
[02:39] <ScottK> !SRU then.
[02:39] <ubotu> Sorry, I don't know anything about sru then. - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[02:39] <ScottK> Argh.
[02:39] <ScottK> Stable Release Update.
[02:39] <rzr> DarkMageZ: no i want to replace the one in repo .. I'll read this
[02:40] <ScottK> rzr: If the one in the repositories is broken, we can do a stable release update to fix it.  Backports is for new features, not for serious bug fixing.
[02:41] <ScottK> rzr: https://wiki.ubuntu.com/StableReleaseUpdates
[02:41] <rzr> ScottK: the version in hardy is ok
[02:42] <ScottK> rzr: Right, but backports is not enabled by default.  If a package is totally broken, we should try to fix it in updates so more people can benifit.  It's more effort, but worth it.
[02:43] <rzr> ok i note this down for next weekend
[02:48] <DarkMageZ> i heard rumors that debian was obsoleting gtk1.2 and removing it. is this true and if so is ubuntu following the same path?
[02:49] <RAOF> Was that gtk1.2 or all the gnome-1 stuff?  Because I remember someone saying that they're finally reaching the bottom of the gnome 1 stack :)
[02:50] <RAOF> It's possible that gtk1.2 will be included in that master plan.
[02:50] <bddebian> It is suppose to go the way of the dodo
[02:51] <bddebian> One of the reason xmms is scheduled for removal
[02:51] <zul> crap i still use xmms
[02:51] <Elly> use mocp instead =)
[02:51] <bddebian> So do 12,000 other people according to popcon :)
[02:52] <DarkMageZ> so i could reject a "needs-packaging" because it depends on gtk1.2?
[02:52] <DarkMageZ> zul, use audacious.
[02:52] <bddebian> DarkMageZ: I would unless they are willing to port it
[02:52] <DarkMageZ> zul, it's similar to xmms and is still maintained.
[02:53] <RAOF> What needs packaging and is dependent on gtk1.2?
[02:54] <ScottK> Hopefully nothing.
[02:54] <ScottK> New gtk1.2 sutff now isn't where we want to be going.
[02:54] <ScottK> For Gutsy I had to stop something building a gtk1.2 variant to get it into Main.
[02:55] <DarkSun88> Hi all.
[02:55] <ScottK> Hi DarkSun88
[02:55] <DarkSun88> Hi Scott.
[02:56] <bddebian> Heya DarkSun88
[02:56] <DarkSun88> Mmh, nautilus continues to crash.
[02:56] <DarkSun88> bddebian: Hi. :)
[03:00] <DarkMageZ> RAOF, AutoZen
[03:03] <ScottK> DarkSun88: Think KDE.
[03:18] <bddebian> Think xfce! ;-P
[03:26] <DarkSun88> ScottK, bddebian: I think that now, I'll go to sleep. :D Gute Nacht.
[03:26] <ScottK> Gute Nacht
[03:35] <bddebian> Gnight DarkSun88
[03:39] <jdong> does apache (1) have its config files in /etc/apache?
[03:39] <Hobbsee> jdong: /etc/apache2/
[03:39] <jdong> Hobbsee: apache 1.3.x uses /etc/apache2 too?
[03:40] <Hobbsee> oh, i thought you were talking about apache(1), ie the manpage.
[03:40] <Hobbsee> no idea then, sorry
[03:40] <jdong> Hobbsee: well I'll guess it uses /etc/apache till someone screams at me otherwise :D
[03:40]  * jdong is packaging the shiny clutch bittorrent webui
[03:40] <ScottK> jdong: What apache1?
[03:40] <ScottK> We don't have that anymore.
[03:40] <jdong> ScottK: we don't have it anymore?
[03:41] <ScottK> Nope.  Just apache2
[03:41] <jdong> ScottK: pfft well that's even better!
[03:41] <jdong> *happily removes apache1 references*
[04:04] <nenolod> i don't know. am i going in the wrong direction for this: http://nenolod.net/audacious-theme-human.png -- it's intended to be the default theme for audacious in ubuntu.
[04:06] <RAOF> Dear git: go faster.
[04:07] <StevenK> Hah
[04:07] <nenolod> git sucks honestly :/
[04:08] <nenolod> take mercurial, make it use gitweb theme. problem solved :P
[04:08] <bddebian> And bzr ROCKs..
[04:08]  * bddebian hides
[04:08]  * nenolod can't stand bzr
[04:08]  * bddebian either
[04:08] <StevenK> But bzr is great
[04:08]  * StevenK can understand it
[04:08] <nenolod> great for humans
[04:09] <nenolod> i need revision control for nenolods instead (;
[04:09] <nenolod> nenolods are only one human see :P
[04:09] <StevenK> Understanding of git still eludes me, but I use it like once every three weeks
[04:09] <StevenK> nenolod: What doesn't make sense about bzr?
[04:10] <bddebian> Other than being slower than my grandparents? :-)
[04:10] <StevenK> bddebian: Try 1.0
[04:11] <nenolod> StevenK, it's not that bzr doesn't make sense, it's that bzrweb and loggerhead are awful
[04:11] <StevenK> Ah.
[04:11] <nenolod> hgweb just works, and with some tweaking works on mod_python.
[04:12] <StevenK> I tend to not use web frontends to VCSs
[04:12] <nenolod> bzr works great if you push your branch to for instance launchpad
[04:12] <nenolod> but i don't think canonical would appreciate me using their resources for internal development
[04:12] <nenolod> (;
[04:13] <StevenK> Well, I admit I use bzr for Launchpad stuff only, like code hosted there, and the seeds
[04:13] <nenolod> outside launchpad, bzr kinda sucks :/
[04:13] <nenolod> at least for publishing branches
[04:14] <StevenK> I thought you could just push to ~/public_html?
[04:15] <nenolod> yes, but then you don't get searchable branches and all that other nifty stuff launchpad has via loggerhead
[04:15] <AdamSun> Hello everyone, got a quick question
[04:15] <StevenK> Ah, you also miss the nice lists of branches, and so on
[04:16] <AdamSun> I'm working on packaging Handbrake and during the build process it uses wget to download libraries and compile them
[04:16] <bddebian> ugh
[04:16] <AdamSun> yet all of these libraries are available in ubuntu repositories
[04:16] <RAOF> AdamSun: Please kill the devs for us, then.
[04:16] <AdamSun> haha... i wish
[04:16]  * nenolod hands AdamSun a shotgun, "you know what to do."
[04:17] <jdong> AdamSun: the handbrake build system is retarded
[04:17] <RAOF> And how hard would it be to patch this out of their build system.
[04:17] <AdamSun> so i'm guessing my thoughts were true?
[04:17] <jdong> AdamSun: you're gonna have to strip out their build system and make your own
[04:17] <jdong> AdamSun: I recalled looking at this earlier :)
[04:17] <AdamSun> I don't think it will be too hard
[04:17] <nenolod> sounds fantastically crap
[04:17] <jdong> RAOF: their entire build system specializes in fetching deps from random URL's
[04:17] <jdong> it's a living nightmare
[04:17] <AdamSun> Looks like I'll have some fun cleaning it up :)
[04:17] <jdong> it's not make, it's some other system
[04:17] <bddebian> crikey
[04:17] <RAOF> Aaah, the unadulterated joy that is apt.
[04:18] <AdamSun> yeah
[04:18] <AdamSun> it uses jam
[04:18] <nenolod> at any rate, no comments on audacious-theme-human? :P
[04:18] <jdong> AdamSun: well, your task is to write a new buidl system for handbrake
[04:18] <AdamSun> actually though, it switches back and forth between the two... extremely sad
[04:18] <AdamSun> ha.. great fun
[04:18] <jdong> AdamSun: I know, but we'll all be thankful
[04:18] <jdong> AdamSun: (I'm the other transcoding nut around here) :D
[04:18] <RAOF> Shouldn't be too hard to autotoolify it :P
[04:19] <AdamSun> jdong: well.. i'll think of you as i go through hell :)
[04:19] <RAOF> jdong: Excited about Dirac hitting 1.0, then?
[04:19] <AdamSun> this is actually my first attempt at packaging a new app
[04:20] <jdong> RAOF: meh no time for getting excited :)
[04:21] <AdamSun> in terms of packaging this... would it be best to try to just alter their build system, or just scrap it all and start fresh?
[04:23] <jdong> AdamSun: how familiar are you with jam?
[04:24] <AdamSun> I quickly acclimated myself to it when i started, so i'm comfortable with it
[04:25] <jdong> AdamSun: cool, does it look easy to strip off the other build-dep fetchers from their jamfile?
[04:25] <jdong> AdamSun: I mean, I'd hate to see their code for building the actual transmission program go to waste
[04:25] <AdamSun> yeah.. actually that is the main complexity of the build process
[04:27] <AdamSun> my only concern was how to work around the need to download
[04:27] <AdamSun> it'd be nice to just leave them their horrible build process and then use the nice one only with this package
[04:28] <jdong> AdamSun: maybe ship your own jamfile in debian//
[04:29] <AdamSun> jdong: possibly, it actually starts the whole process off with make though
[04:29] <AdamSun> jdong: make then calls jam
[04:31] <AdamSun> jdong: ( cd .. ; ./configure ; cd contrib ; cp -f ../config.jam . ; jam )
[04:31] <AdamSun> jdong: that wonderful line there is called from make
[04:31] <jdong> AdamSun: that might work, what's your clean line gonna look like though? ;-)
[04:32] <jdong> AdamSun: can you not specify an explicit jamfile to jam?
[04:32] <AdamSun> jdong: yeah.. i do believe
[04:32]  * jdong laughs at dpkg
[04:32] <jdong> _i386 is picked over _all
[04:33] <jdong> well there's my problem
[04:33] <jdong> I was WONDERING why that fix wouldn't propagate after 10 rebuilds!
[04:35] <AdamSun> jdong: the jamfile that gets used from that line is basically useless, except that it runs patches to the source... otherwise it's only function is to build the libraries
[04:37] <jdong> AdamSun: ah, ok
[04:40] <AdamSun> jdong: would it be better to create a new rule that builds without wget, or just to alter their rule
[04:44] <jdong> AdamSun: if you alter their rule, do so from a patch
[04:48] <LaserJock> nixternal: ping
[04:56] <ScottK> LaserJock: That's two of us looking for him.  I pinged him about 5 minutes before you did in #kubuntu-devel.
[04:58] <Hobbsee> he's popular, clearly
[04:58] <AdamSun> jdong: looks like i'm going to need to package libdca first :)  luckily it should be easier
[05:03] <LaserJock> heh
[05:04] <LaserJock> well I  don't need him anymore
[05:04] <LaserJock> I lost my plasma panel and wondered how to get it back
[05:04] <nixternal> LaserJock: pong
[05:04] <LaserJock> hah
[05:05] <LaserJock> nixternal: just actually logged into KDE 4
[05:05] <LaserJock> lost my panel
[05:05] <nixternal> that's a scary thought
[05:05] <LaserJock> but figured it out
[05:05] <nixternal> logged out and then logged back in?
[05:05] <LaserJock> yep
[05:06] <LaserJock> I had to kill plasma and then remove the config and it came back
[05:06] <nixternal> ya, that will be fixed with the next release due out in about 2 weeks
[05:06] <nixternal> actually, there have been a lot of fixes for KDE 4.0 already
[05:06] <LaserJock> I wonder though if the icon stuff had been figured   out
[05:07] <nixternal> most of it has
[05:07] <nixternal> apachelogger_ actually patched quite a bit of it already
[05:07] <LaserJock> has it made it to gutsy?
[05:07] <crimsun> DarkSun88: so, are those related to dist-upgrade?  :-)
[05:08] <nixternal> dunno if stdin has updated the gutsy ppa or not yet
[05:31] <superm1> has anyone else been running into some weird FTBFS today related to stat64?
[05:32] <superm1> for example, see this log: http://launchpadlibrarian.net/11491264/buildlog_ubuntu-hardy-i386.mythplugins_0.20.2%2Bfixes15096-0ubuntu3_FAILEDTOBUILD.txt.gz
[05:44] <LaserJock> hmm, KDE desktop effects are pretty sweet
[05:49] <RAOF> LaserJock: Do you not play with compiz much? :).  I found them pretty... jerky isn't really the right word, but it'll have to do.
[05:51] <RAOF> I think it's something to do with the animations.  Effects in compiz tend to go: accelerate, move, decelerate.  Whereas kwin's seem to be all the same speed.
[06:06] <LaserJock> RAOF: well, I guess I'm  just impressed you can even use it
[06:12] <RAOF> LaserJock: What?  Compiz?  Or kwin?
[06:12] <LaserJock> well, both actually
[06:12] <LaserJock> but kwin specifically
[06:12] <RAOF> Heh.
[06:12] <LaserJock> I got a new laptop with an intel graphics card
[06:13] <LaserJock> and my previous laptop had ATI and didn't really do 3D desktop well at all
[06:13] <RAOF> Ah.  Sweet open source drivers.  Without TTM, sadly.
[06:14] <LaserJock> I didn't really know that KDE had made any advancement in 3D desktop
[06:14] <RAOF> I'm currently playing with the metacity compositor.  Which isn't too bad.  But isn't anything like kwin, and has most of the bugs that xcompmgr had.
[06:15] <LaserJock> but the expose and virtual desktop switching is nice
[06:15] <RAOF> I'd played around with it at some point.
[06:16] <RAOF> Exposé is the best new window-manager feature is a long, long time.
[06:19] <RAOF> Oh, dear.  Multiarch is quite a lot harder than I'd hoped.
[06:24] <RAOF> Why can't we have a ia32-libs-dev package :(
[06:29] <StevenK> I thought we did?
[06:29] <RAOF> Not according to aptitude search ia32
[06:32] <StevenK> Hrm. I see that.
[06:33] <RAOF> So I get to play around with fun like -l:libpulse.so.0
[06:39] <warp10> Heya all!
[06:50] <LucidFox> Why couldn't they just use compiz, anyway?
[06:58] <RAOF> LucidFox: Because it's not written in C++ :P
[06:59] <LucidFox> heh
[06:59] <RAOF> LucidFox: I'm not really sure.  I remember one of the reasons being that the plugins were not sufficiently isolated; one bad plugin can bring compiz down.
[06:59] <RAOF> Although that should change reasonably soon.
[07:00] <RAOF> (With the landing of the object-framework branch)
[07:00] <RAOF> Or, rather, it'll make it easier to not bring down compiz.
[07:01] <RAOF> I think that their reasons, while valid at the time, aren't any more.  At least those reasons that I was aware of.
[07:01] <LucidFox> "...And at about the same time, the GNU developers found a fatal flaw in Poppler: they didn't write it! They decided to create GNU PDF, which is like Poppler but different..."
[07:01] <RAOF> Yup, pretty much.
[07:02] <RAOF> It's true that they'd have to introduce a bunch of window manager bugs, but by starting from compiz they would have had fewer compositing manager bugs :)
[07:03] <vemon> i just found this phrase from the packaging guide under KDE section: "remember debian policy implies that every single application has a man page!". so is it mandatory for new ubuntu packages to include a man page?
[07:03] <vemon> and if there isn't one should it be somehow generated from the README file?
[07:03] <RAOF> Yes.
[07:03] <RAOF> That's one way, yes.
[07:04] <vemon> any links or "googlewords" to help with that? :)
[07:04] <LucidFox> I usually use help2man to create the initial draft
[07:04] <RAOF> Well, there's the help2man program.
[07:04] <RAOF> Heh.
[07:04] <LucidFox> and then tweak it in a text editor
[07:05] <vemon> ok. thank you!
[07:05] <RAOF> crimsun: Still here, and willing to be a foil for multi-arch alsa-plugins?
[07:06] <vemon> i should probably generate some kind of faq from all the answers you guys have given me :D
[07:07] <LucidFox> vemon> Actually, that would be a good idea. I'm thinking of writing one on the wiki.
[07:08] <vemon> LucidFox, when it's up&running i'm more than happy to contribute
[07:09] <vemon> i usually write small instructions for everything new i learn to be able to re-do it later
[07:12] <LucidFox> Would an empty debian/docs (rather than just a lack of it) be a blocker for a REVU package?
[07:12] <RAOF> You know what'd be _awesome_?  Frikkin proper dpkg/apt supported multiarch.
[07:15] <vemon> oh. forgot to ask how can i package the man page properly? the packaging guide seems to be lacking that information
[07:18] <vemon> found it. if it's as simple as adding this to rules: DEB_INSTALL_MANPAGES_myapp = myapp.1
[07:29] <LucidFox> vemon> um
[07:30] <LucidFox> I think it's better to add it to debian/manpages than edit debian/rules
[07:34] <vemon> if i add it there will it be magically included in the package and install correctly without adding any (for example) cdbs includes/params to rules?
[07:35] <RAOF> That's right.  dh_installman is automatically run by CDBS, and will look at that file.
[07:35] <vemon> thanks again :)
[07:37] <jackdaw> hello, i want to get involved!
[07:37] <LucidFox> jackdaw> Excellent! :)
[07:37] <jackdaw> great! well that was easy
[07:38] <LucidFox> Do you have any specific interests?
[07:38] <jackdaw> numeric / scientific code is what i'm good at
[07:39] <jackdaw> so it'd be good if there was something i could use that for that would be helpful
[07:40] <LucidFox> Is the software you're interested in already in Ubuntu, or do you want to get it there?
[07:41] <jackdaw> yeah i was just reading the wiki article, so you lovely folks are loosely the package maintainers?
[07:41] <rzr> LucidFox: yea go for waste.sf.net
[07:41] <rzr> it compiled well
[07:41] <jackdaw> i think i was more looking to join something more like a specific dev team
[07:42] <LucidFox> There is a list of MOTU teams here: https://wiki.ubuntu.com/MOTU/Teams
[07:42] <rzr> LucidFox: oops forget what i said , i didnt got the context :)
[07:43] <LucidFox> But generally, the people here will help you with any area
[07:43] <LucidFox> jackdaw> Here is the page for the MOTU Science team: https://wiki.ubuntu.com/MOTU/Teams/Science
[07:43] <jackdaw> thanks! i just got to that myself
[07:44] <jackdaw> ok, i'll lurk for a bit
[08:03] <wallyweek> hello world! :)
[08:19] <man-di> can someone explain https://bugs.launchpad.net/ubuntu/+source/axis/+bug/150081 to me? Whats wrong with the package?
[08:19] <ubotu> Launchpad bug 150081 in axis "autopkgtest gutsy axis: erroneous package!" [High,New]
[08:48] <huats> morning everyone
[09:20] <foolano> HI
[09:21] <slytherin> foolano: hi
[09:21] <foolano> one of the two packages i uploaded to REVU yesterday is already in hardy. how should i proceed to cancel it?
[09:21] <man-di> slytherin: hello, can you please reproduce or close https://bugs.launchpad.net/ubuntu/+source/axis/+bug/150081?
[09:21] <ubotu> Launchpad bug 150081 in axis "autopkgtest gutsy axis: erroneous package!" [High,New]
[09:22] <man-di> slytherin: I guess it can be closed as I cannot reproduce it here in Debian.
[09:22] <slytherin> foolano: let me check
[09:26]  * DaveMorris plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines or single machines.  Has support for sort 1st and sort last.  I'm currently using it to power a cluster with a 46 million pixel display.  It's cool so please revu it. (Since it's been missed the last 2 revu days)
[09:29] <TheMuso> foolano: What do you mean cancel it?
[09:30] <foolano> TheMuso: I mean, as it is already in hardy i dont want it to be reviewed or anything
[09:32] <TheMuso> foolano: Oh you mean on revu, I can archive it if thats what you want. Whats the package?
[09:32] <foolano> TheMuso:  libnet-cups-perl
[09:33] <TheMuso> Ok, I'll fix it up on revu.
[09:33] <foolano> TheMuso: thanks
[09:34] <joejaxx> Good Morning All :D
[09:34] <TheMuso> Hey joejaxx.
[09:35] <TheMuso> foolano: Ok, it has been archived. If you wish to make it appear on the revu main page again, simply upload a new revision of the package.,
[09:35] <foolano> TheMuso: great :)
[09:42] <geser> good morning
[09:47] <joejaxx> hello geser
[09:52] <geser> Hi joejaxx
[09:56] <slytherin> can anyone please ack this sync request? bug 185016
[09:56] <ubotu> Launchpad bug 185016 in groovy "Please sync latest version from Debian" [Undecided,New] https://launchpad.net/bugs/185016
[10:28] <slytherin> man-di: there? I need to discuss something.
[10:32] <geser> slytherin: did you test-build groovy? I ask because: Dependency is not satisfiable: libxstream-java
[10:33] <man-di> slytherin: yes, got around to test axis?
[10:33] <slytherin> geser: Looks like I didn't pay attention to that. I was assuming that the build dependencies are present in Ubuntu. :-)
[10:34] <geser> slytherin: you should test-build it with pbuilder. Just because the build-depends are there, doesn't mean that it also builds in Ubuntu.
[10:34] <slytherin> geser: Sorry for that. I should have confirmed before I logged the bug.
[10:37] <slytherin> man-di: Any idea what can I do about debian bug 423087 Please read the latest comment and let me know how should I frame the response.
[10:37] <ubotu> Debian bug 423087 in w3c-dtd-xhtml "w3c-dtd-xhtml: path to entity sets is wrong" [Normal,Open] http://bugs.debian.org/423087
[10:38] <man-di> slytherin: sorry, I dont know much about this XML stuff
[10:40]  * wallyweek points out he's not away, but that stupid online irc clients keeps disconnetting him
[10:40] <slytherin> man-di: No the problem I have is why can't we simply add symlinks for entity sets? Do we really expect everyone to add an additional library in classpath / dependencies just because the path in dtd is wrong?
[10:40] <man-di> slytherin: as I said: I have no clue about XML
[10:41] <slytherin> man-di: Ok. I will reply to the bug.
[10:45] <vemon> how can i test a manpage without installing it first?
[10:46] <ion_> man foo/bar.1
[10:47] <persia> nroff -man < file | $PAGER
[10:50] <jcastro> bigon`: thank you for taking care of d-feet!
[10:51] <slytherin> man-di: I have replied to that bug. And if it is not fixed by this weekend I will add a patch in Ubuntu.
[10:57]  * persia wonders if it is acceptable to list a corporation under "Author:" in debian/copyright if the corporation no longer has records about who worked on the software before it was publically released.
[10:58] <slangasek> "author" is not a field we're legally required to include in debian/copyright
[10:58] <slangasek> just "copyright holder" and "license"
[10:59] <persia> So we just use "Author" to be nice?  Dropping it makes it easy.  Thanks :)
[11:01] <thp> can someone please sync the new gPodder 0.10.4 release from Debian Unstable to Ubuntu Hardy? https://bugs.launchpad.net/ubuntu/+bug/185317
[11:01] <ubotu> Launchpad bug 185317 in ubuntu "Please sync gPodder 0.10.4-1 from Debian unstable" [Undecided,New]
[11:01] <persia> slangasek: Also, thanks for one more step to make hardy WX2.4 free :)
[11:01] <thp> oh ;)
[11:02] <slangasek> persia: ah? you're working on wx2.4 removal stuff theN?
[11:02] <persia> thp: Please subscribe ubuntu-universe-sponsors to request someone to look at it?
[11:02] <thp> ok i'll do that
[11:02] <persia> slangasek: Actually, I haven't done anything beyond passing Barry hints in about eight months, but it was one of my release goals for Gutsy.
[11:03] <slangasek> ah :)
[11:03] <persia> thp: Thanks.
[11:06] <slytherin> geser: you were right. libxstream-java is not present in Ubuntu. And that in turn has dependency on libcglib2.1-java. :-)
[11:34] <vemon> last manpages
[11:34] <vemon> whops :D
[11:34] <dholbach> Hobbsee: ROCK ON
[11:34] <Hobbsee> dholbach: :)
[11:34] <dholbach> hey sistpoty|work, hey persia
[11:35] <sistpoty|work> hey dholbach
[11:35] <persia> hey dholbach.
[11:35] <dholbach> how are y'all doing?
[11:35] <persia> dholbach: Fairly well.  You?
[11:35] <sistpoty|work> debugging my ugly code... otherwise fine
[11:36] <dholbach> persia: very good thanks :)
[11:37] <theseinfeld> dholbach hi
[11:37] <dholbach> hey theseinfeld
[11:38] <theseinfeld> dholbach i am a bit in a hurry to get that thing done
[11:38] <dholbach> theseinfeld: aren't we all? :)
[11:38] <theseinfeld> dholbach yeah
[11:38] <theseinfeld> dholbach too much coffee :)
[11:39] <theseinfeld> dholbach am I supposed to fill a bug report in the main-sponsors/
[11:39] <theseinfeld> ?
[11:40] <dholbach> theseinfeld: no, it's a NEW package - the sponsoring teams don't do them
[11:40] <theseinfeld> dholbach so it is only in REVU?
[11:40] <slangasek> is there an existing wiki page to link useful universe QA resources from?
[11:40] <dholbach> slangasek: ROCK - it's http://wiki.ubuntu.com/MOTU/TODO or http://wiki.ubuntu.com/MOTU/Bugs
[11:41] <theseinfeld> dholbach i think the package should go in main, and that is what makes me worry about february deadlin
[11:41] <theseinfeld> e
[11:41] <theseinfeld> s/dedlin/dedline/
[11:41] <dholbach> theseinfeld: what would link against it?
[11:41] <persia> slangasek: For test-oriented QA, it'd be nice to list at qa.ubuntu.com.  For developer-oriented QA, it'd be nice to list at qa.ubuntuwire.com
[11:42] <theseinfeld> dholbach: what packages?
[11:42] <dholbach> theseinfeld: yeah
[11:42] <theseinfeld> dholbach in hardy?
[11:42] <slangasek> persia: <whimper> why do we have a wiki if everything gets moved elsewhere?
[11:42] <theseinfeld> dholbach well, i have an issue with the Doxygen building when using PPA
[11:42] <dholbach> theseinfeld: you said it should be in main: if there's nothing linking against the library there's no need for it in main, right?
[11:43] <persia> slangasek: Err..  We like using DNS rather than URL parsing?  What do you have?  I'll get it somewhere.
[11:43] <theseinfeld> dholbach: the libdc1394 was in main...
[11:43] <dholbach> theseinfeld: so it's an update of the libdc1394 package?
[11:43] <theseinfeld> dholbach don't remember which packages are linking, but there are some libraries...
[11:43] <theseinfeld> dholbach that's the trick
[11:44] <dholbach> theseinfeld: why do you intend to rename the source package at all?
[11:44] <theseinfeld> dholbach it is a new API and we did it to work such that it can work with libdc1394 version 1.1
[11:44] <dholbach> theseinfeld: why isn't it an update of the libdc1394 source package?
[11:44] <dholbach> theseinfeld: wouldn't it be enough to just rename the binary package?
[11:44] <dholbach> libdc1394-13 to libdc1394-22 and libdc1394-13-dev to libdc1394-22-dev
[11:44] <slangasek> persia: which "we"?  Having half the info in the wiki and half the info on other sites drives me crazy, because, er, the wiki's search doesn't index other sites
[11:45] <theseinfeld> dholbach no. because then if you use -22 you get conflict with -13
[11:45] <theseinfeld> etc...
[11:45] <persia> slangasek: Which wiki?  We've three of them last I looked :)
[11:45] <slangasek> persia: wiki.ubuntu.com :(
[11:45] <dholbach> theseinfeld: where's the problem with that? is there any need for two source packages containing the library?
[11:46] <dholbach> theseinfeld: it's something that happens all the time: libraries change the soname, binary package names are updated
[11:46] <theseinfeld> dholbach it is a new branch
[11:46] <slangasek> persia: well, I see that the NBS list is linked from qa.ubuntuwire.com, but I wouldn't have thought to look there
[11:46] <theseinfeld> dholbach it is in a way a new library
[11:46] <dholbach> theseinfeld: ah, are all the apps ported to use it already?
[11:47] <persia> slangasek: I don't remember the details, but someone got annoyed by that back in Dapper, and created some other wikis (help and later community).  After that, w.u.c got steadily worse until late feisty, when some cleanup started.  qa.* exist because wikis can't run code.
[11:47] <theseinfeld> dholbach some apps like coriander will be ported to use it
[11:47] <theseinfeld> dholbach but not all
[11:47] <theseinfeld> dholbach and that is why we still need the -13 while we get -22
[11:47] <slangasek> persia: ok, so for things that don't involve running code, are we in agreement that they should be linked from the wiki and not just from ubuntuwire.com? :-)
[11:47] <dholbach> theseinfeld: OK
[11:48] <theseinfeld> dholbach coriander will come later...
[11:48] <theseinfeld> dholbach so far the efrfort is to get the library in
[11:48] <theseinfeld> dholbach than the coriander will freeze maybe in february
[11:48] <theseinfeld> early february
[11:48] <dholbach> I'd somehow prefer the name to be something like "libdc1394-2" or something
[11:48] <theseinfeld> dholbach if i get time i could do the coriander before 14
[11:49] <theseinfeld> dholbach the -22 for the source is coming from the discussions with debian guys
[11:49] <dholbach> oh ok
[11:49] <persia> slangasek: I'm honestly not sure.  Last time we decided that, MOTU/TODO page got a lot of activity adding resources, and then people started putting them in UbuntuDevelopment/Resources, and then...
[11:49] <theseinfeld> dholbach I try to be in sync with them
[11:49] <dholbach> it fails to build for me
[11:49] <theseinfeld> more like to sync them with the dev. process
[11:50] <theseinfeld> dholbach the libdc?
[11:50] <persia> slangasek: There's also some confusion as some of the tools only run on main (lack of resources available within Canonical), and there have been arguments about how they should be listed.
[11:50] <theseinfeld> dholbach from revu?
[11:51] <theseinfeld> dholbach: we have the team PPA where we did the gutsy binaries earlier here: https://launchpad.net/~libdc1394-dev/+archive
[11:51] <dholbach> theseinfeld: yeah
[11:51] <dholbach> building the docs fail
[11:52] <theseinfeld> dholbach: i already filled a bug why it fails: let me check the problem again
[11:52] <theseinfeld> dholbach: http://launchpadlibrarian.net/11473870/buildlog_ubuntu-hardy-i386.libdc1394-22_2.0.1-1ubuntu5_FAILEDTOBUILD.txt.gz
[11:52] <sistpoty|work> in case revu is a little bit unresponsive atm: I'm just doing a backup of sparky
[11:52] <dholbach> yeah, same problem here
[11:53] <theseinfeld> dholbach: it fails because ! LaTeX Error: File `a4.sty' not found.
[11:53] <theseinfeld> in hardy
[11:53] <theseinfeld> dholbach: in gutsy it works
[11:54] <theseinfeld> dholbach: prbably the cjk-latex package forgot the a4.sty to include or something...
[11:55] <dholbach> theseinfeld: try adding texlive-latex-recommended to Build-Depends
[11:55] <theseinfeld> dholbach: question is: how do other doxygen packages that export the HTML/PDF/PS file manage?
[11:56] <theseinfeld> dholbach: should it replace the cjk-latex?
[11:56] <DaveMorris> theseinfeld: what do you mean?  I've a package which uses doxygen for html
[11:56] <dholbach> theseinfeld: I don't know - I don't know the code or what it was put in in the first place
[11:56] <theseinfeld> DaveMorris: what is the build-depends list for latex?
[11:57] <theseinfeld> DaveMorris: in debian/control Source...?
[11:58] <DaveMorris> mine doesn't make use of latex
[12:00] <dholbach> theseinfeld: why is it necessary to call the binary package libdc1394-22-dev instead of libdc1394-dev?
[12:00] <emgent> heya *
[12:00] <theseinfeld> different API
[12:00] <dholbach> oh yeah right
[12:01] <theseinfeld> dholbach: it has binary
[12:01] <dholbach> the thing is it will earn you having to rename it every time and having to add conflicts/replaces all the time
[12:01] <dholbach> it has a symlink
[12:02] <dholbach> upstream calls it libdc1394-2 (in ./usr/lib/pkgconfig/libdc1394-2.pc) - I think that's much more sensible over all
[12:02] <DaveMorris> theseinfeld: the a4.sty style file is shipped with texlive-latex-recommended AFAIK
[12:02] <theseinfeld> DaveMorris: thanks
[12:02] <dholbach> also libdc1394-22-utils - you will rename that with every ABI break
[12:03] <dholbach> and you'll always have to add conflicts/replaces
[12:03] <dholbach> I'd talk to the debian maintainers about that again
[12:03]  * persia is confused by the possible differences between icepick and icedtea
[12:03] <theseinfeld> dholbach: yes. libdc1394-2.pc is for libraries pkgconfig thinggy
[12:03] <dholbach> in libdc1394v2-doc you have the different pattern already
[12:03] <theseinfeld> dholbach: i use the virtual package libdc1394-dev so that user can choose which to pick for development
[12:04] <dholbach> that will probably break the builds of packages that are not ported to the new API yet
[12:04] <dholbach> they are not interchangeable
[12:04] <theseinfeld> dholbach: that v2 is to conform with debian-policy for naming
[12:04] <dholbach> but the v2 naming is not consistent in the binary packages
[12:04] <theseinfeld> if it was just libblablah with no number my life would be much easier now
[12:04] <theseinfeld> :D
[12:05] <theseinfeld> that 1394 is killing me :))
[12:07] <emgent> keescook, jdstrand malone 173153
[12:07] <ubotu> Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153
[12:07] <emgent> gutsy debdiff it's ready
[12:07] <theseinfeld> dholbach: i am just making the new dsc for revu and ppa
[12:07] <dholbach> I added a few comments to the page
[12:07] <theseinfeld> revu page?
[12:07] <emgent> http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/
[12:07] <emgent> deb too avaiable.
[12:08] <theseinfeld> dholbach: uploaded 1ubuntu6
[12:09] <dholbach> added another comment
[12:09] <dholbach> I need to leave now... sorry
[12:11] <theseinfeld> dholbach: thanks. I let you know by email...
[12:11] <dholbach> just follow up on the REVU page so everybody else is notified too
[12:11] <ScottK> dholbach: I just volunteered for motu-uvf.
[12:12] <dholbach> ScottK: I just noticed - that's great - thanks
[12:12] <ScottK> dholbach: I do think we need to follow pitti's suggestion to rename it.
[12:12] <dholbach> ScottK: that makes sense - I think we should name it motu-ff though (to not raise expectations about a 'motu release team')
[12:12] <TheMuso> dholbach: Gee your email sounds so much like a sales pitch. :p
[12:12] <dholbach> TheMuso: it worked though ;-)
[12:13] <dholbach> ScottK: and have the discussion about 'motu release team' separately (gather ideas about it first)
[12:13] <dholbach> sorry guys, need to leave for lunch now and a meeting afterwards - ttyl
[12:22] <RainCT> Hey
[12:22] <jdstrand> emgent: thanks!
[12:23] <emgent> jdstrand, np :)
[12:23] <emgent> wordpress too fixed hehe
[12:35] <jdstrand> emgent: cool thanks
[12:36] <emgent> np :)
[12:36] <emgent> jdstrand, today i will work to malone 181853
[12:36] <ubotu> Bug 181853 on http://launchpad.net/bugs/181853 is private
[12:36] <emgent> upstream reply to me.
[12:38] <jdstrand> emgent: sounds great
[12:45] <slangasek> persia: heh, in regards to some tools only being run on main, I was just discussing yesterday with dholbach that it would be good to have a britney run for universe to show out-of-date packages
[12:45] <Hobbsee> slangasek: for the ones who aren't from debian, which is britney?
[12:46] <slangasek> Hobbsee: britney is the tool that generates http://people.ubuntu.com/~ubuntu-archive/testing/
[12:46] <slangasek> (it does other things in Debian, it's just a reporting tool in Ubuntu)
[12:46] <Hobbsee> slangasek: ah right
[12:46] <persia> slangasek: We asked liw at UDS, and were told there were insufficient resources.  debcheck on ubutuwire is the current means we use to chase that.  If you can convince someone to run against universe regularly, that'd be great.
[12:48] <slangasek> persia: hmm, this was about insufficient resources for britney specifically?  I'll look into it; I haven't tried to have that end of the conversation yet
[12:49] <\sh> moins
[12:49] <emgent> persia, ping
[12:49] <emgent> \sh, hi!
[12:49] <persia> slangasek: I'm not sure: I wasn't physically present during the conversation.  There were a few things under discussion, and it may be that britney got lost as being considered linked to other things.
[12:51] <slangasek> k
[12:52] <slangasek> well, for what Ubuntu uses britney for, I can't imagine it being a resource issue; the resource-intensive parts of britney aren't used at all
[12:53] <persia> slangasek: That was my thought.  I've been hoping we could be running that also for universe since feisty, but it needs higher-level pokes than me.
[12:53] <slangasek> :)
[12:54] <persia> Separately, do those testing runs provide any extra information above that provided by debcheck?
[12:58] <ScottK> dholbach: At least in the last cycle we pretty well acted as the MOTU release team.  I don't thik we need a separate team for that.
[12:59] <persia> I only remember about half the motu-uvf team being involved in the final release efforts, and I do remember some non-uvf people being involved.  I think it's worth discussion about what motu release would mean before deciding we don't need a team (and similarly before deciding to create a team).
[13:01] <slangasek> persia: ok, I checked with liw and he doesn't think britney was ever discussed; the resource-intensive stuff that's a problem are the automated install/upgrade testing, which is quite a bit differently than britney which just acts on a Packages file
[13:01] <persia> slangasek: In that case it's a case of the telephone operator game.  Clearly I need better audio in my spy satellites :)  Thanks for following up.
[13:02] <ScottK> slangasek: Would you be up for doing some backports.  RIddell started the clamav backport to Dapper yesterday, but had connectivity problems and so dapper-backports is about half on the new clamav and half on the old one right now.
[13:02] <slangasek> persia: I'm not familiar with debcheck; output looks familiarly like some stuff I've seen in Debian, which I don't think handles conflicts->depends loops.  I also don't see that debcheck lists out-of-date binaries
[13:03] <slangasek> ScottK: heh, connectivity problems, a likely story :-)
[13:04] <ScottK> https://bugs.launchpad.net/dapper-backports/+bug/183914/comments/12 is the list if you're up for it.
[13:04] <ubotu> Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,In progress]
[13:04] <slangasek> ScottK: yeah, today's seb's archive day, but since I failed to be useful on mine I can have a look
[13:04] <persia> slangasek: Ah.  Some commonality, but perhaps sufficient differences to make both worthwhile.  I know there was some talk about running britney on UbuntuWire, but it didn't happen in favor of debcheck.  Likely best to run both.
[13:04] <ScottK> slangasek: If he was faking, he managed to be a good IRC simulation.
[13:05] <ScottK> slangasek: Thanks.  All the source backports are done, all those should be just the regular backports script.  The only tricky bit being the two that have to come from Feisty.
[13:05] <emgent> persia, http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/    :-)
[13:05] <\sh> hmm...is it possible to tell sbuild to delete old build logfiles and just leave the last build log?
[13:05] <ScottK> slangasek: After the pain he did get through yesterday, I wouldn't blame him much for hiding out anyway.
[13:05] <slangasek> ScottK: well, yes :)
[13:06] <persia> emgent: Great.  As I said 14 hours ago, you need someone from SWAT or security to look at those (and they will likely look at the bug instead).  Thanks for looking into it, and good luck with the other releases.
[13:06] <emgent> persia, sure.
[13:06] <emgent> security people know.
[13:08] <slangasek> ScottK: looks like clamcour,clamtk,dansguardian,klamav just needed flushed out, so that's done now
[13:08] <ScottK> slangasek: Great.  Thanks.
[13:08] <slangasek> libetpan,etpan-ng are going to take me a minute longer as I haven't done a backport myself yet and need to be sure I know what I'm doing on a feisty->dapper backport
[13:09] <ScottK> OK.  Sounds reasonable.
[13:09] <theseinfeld> dholbach: you back?
[13:09] <dholbach> theseinfeld: going to be in a meeting in a bit - so best to just ask the question in here
[13:09] <dholbach> theseinfeld: probably somebody else will answer your questions
[13:09] <theseinfeld> dholbach: thanks
[13:09]  * persia believes that people who upload packages to PPAs with broken addresses in the changelogs should be summarily shot.
[13:10] <theseinfeld> dholbach: i need you :) so I can wait for later :)
[13:10] <theseinfeld> dhobach: it should compile now
[13:10] <ScottK> slangasek: I got the 4 accept mails, so that's all good.
[13:10] <dholbach> theseinfeld: there are much cleverer people than me around here :)
[13:11] <\sh> emgent, why is different in
[13:11] <\sh> +-   defaultTempDir.Printf(wxT("/tmp/audacity1.2-%s"), wxGetUserId().c_str());
[13:11] <\sh> ++   defaultTempDir.Printf(wxT("/tmp/audacity%d.%d-%s"),
[13:11] <\sh> ++			AUDACITY_VERSION, AUDACITY_RELEASE, wxGetUserId().c_str());
[13:11] <\sh> as just adding version and release to the /tmp/ dir?
[13:11] <man-di> dholbach: only the clever people say that *g*
[13:11] <\sh> emgent, it doesn't match your explanation in changelog
[13:11] <\sh> Fix insecure directory creation in /tmp by moving the directory
[13:11] <\sh> +      to the users home directory (CVE-2007-6061; LP: #173153).
[13:11] <ubotu> Audacity 1.3.2 creates a temporary directory with a predictable name without checking for previous existence of that directory, which allows local users to cause a denial of service (recording deadlock) by creating the directory before Audacity is run.  NOTE: this issue can be leveraged to delete arbitrary files or directories via a symlink attack. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6061)
[13:11] <persia> theseinfeld: Please ask questions generally.  There's usually someone with time or inclination to help, and seeking specific people tends to reduce the time they have for other things, and thereby reduce help for everyone.
[13:12] <theseinfeld> ok
[13:12] <emgent> \sh, nope i saw debian && ubuntu hardy patch
[13:12] <theseinfeld> the issue is with the libdc1394
[13:12] <theseinfeld> and the namings proposed by dholbach in his comments
[13:12] <theseinfeld> http://revu.tauware.de/details.py?upid=1427
[13:12] <\sh> emgent, well, the explanation is wrong ;) so the patch does not do what you explained ;)
[13:13] <persia> emgent: Also, anything defaulting to /tmp in a predictable way remains vulnerable to the attack.  It needs to be moved to ~ or made unpredictable.  If hardy is still broken, please fix that as well.
[13:13] <emgent> uhm wait
[13:13] <\sh> emgent, the original gentoo patch is also different :)
[13:13] <\sh> http://bugs.gentoo.org/attachment.cgi?id=141581
[13:14] <emgent> well
[13:14] <\sh> -   defaultTempDir.Printf("/tmp/audacity1.2-%s", wxGetUserId().c_str());
[13:14] <\sh> +   defaultTempDir.Printf("/%s/.audacity1.2-%s", home.c_str(), wxGetUserId().c_str());
[13:14] <emgent> debian use this
[13:14] <emgent> http://people.debian.org/~nion/nmu-diff/audacity-1.3.4-1_1.3.4-1.1.patch
[13:14] <\sh> emgent, but the gentoo patch is doing that what you explained :)
[13:14] <\sh> emgent, which is correct :)
[13:14] <emgent> but, in hardy (it's patched) and use other method
[13:14] <\sh> ember, but http://thc.emanuele-gentili.com/packages/security_fix/gutsy/audacity/gutsy_audacity_1.3.3-1ubuntu0.1.debdiff shows something different
[13:14] <emgent> defaultTempDir.Printf(wxT("%s/.audacity%d.%d-%s"), home.c_str(),
[13:14] <persia> emgent: That would be my fault (and part of why I'm not in SWAT).  Please fix it.
[13:15] <slangasek> ScottK: ok, libetpan/etpan-ng on their way as well; anything else or is this bug ready to be closed?
[13:15] <\sh> s/ember/emgent/
[13:15] <emgent> uhm ok i will review it
[13:15] <emgent> just a moment
[13:15] <ScottK> slangasek: That should be it.  Thanks.
[13:15] <\sh> emgent, even the debian patch is wrong
[13:15] <\sh> emgent, missing a / < in the beginning of the string ;)
[13:16] <emgent> yes i saw gentoo patch
[13:16] <\sh> emgent, use the gentoo patch please, they are correct
[13:16] <ScottK> slangasek: Now I cross my fingers and wait for bugs.  ;-)
[13:16] <emgent> sure \sh thanks.
[13:16] <slangasek> right. :)
[13:16] <\sh> emgent, I'll tell nico that he is wrong ;)
[13:17] <ScottK> slangasek: This is, by a fair margin, the most complex backport that's been done so far, but I think it'll all work out.
[13:17] <slangasek> eh, what could go wrong
[13:17] <emgent> \sh, cool :)
[13:18] <theseinfeld> how long does it take to get a reviewer for my package?
[13:18] <ScottK> theseinfeld: The reviewers are all volunteers.  It varies depending on availability and interest.
[13:18] <DaveMorris> depends if they like you :)  REVU day is monday, it'll prob be looked at then
[13:18] <\sh> emgent, you see, it's quite important to not trust everyone, even when persia is a person to be trusted ;)
[13:19] <persia> theseinfeld: Are you repackaging as an update, rather than a new source?
[13:19] <theseinfeld> it is a new API for an old library
[13:19]  * persia is not always a person to be trusted for Debian syncs for RC bugs.
[13:19] <theseinfeld> hard to qualify it as an update
[13:20] <slangasek> persia: because sometimes you fail to introduce RC bugs?
[13:20] <persia> theseinfeld: Ah.  Too much porting.
[13:20] <theseinfeld> persia: porting?
[13:21] <persia> slangasek: Rather because I tend to pull syncs for anything without Ubuntu variation for which I know an RC bug was closed, without much review beyond builds & installs.
[13:21] <theseinfeld> persia if i do that, i quit my job and family
[13:21] <slangasek> persia: ah :)
[13:21] <theseinfeld> persia: more like life
[13:21] <theseinfeld> :D
[13:21] <persia> If the Debian maintainer didn't actually fix it, it breaks my workflow.
[13:22] <persia> theseinfeld: Right.  Hence the decision for a second source.  Makes sense to me.  Is this the new juju stuff?
[13:23] <theseinfeld> the juju will come a bit later
[13:23] <theseinfeld> when it should detect if the kernel has the juju or old legacy
[13:23] <theseinfeld> persia debian maintainer to fix what?
[13:24] <persia> theseinfeld: cross conversations: debian maintainer for whichever random package claimed to have fixed an RC bug.
[13:25] <theseinfeld> persia: sorry...
[13:25] <theseinfeld> persia: maybe in the 2.0.2 we manage to make the juju stack awareness in the library
[13:26] <theseinfeld> persia: also coriander needs packaging...but i am blocked now in the libdc1394...
[13:26] <theseinfeld> persia: besides, coriander is not yet final for the new api version 2.0
[13:27] <persia> emgent: Don't forget to fix in hardy first (and reopen the task as I was mistaken).
[13:27] <emgent> ok
[13:27] <persia> theseinfeld: Likely not on track for hardy then :(  Only three weeks to Feature Freeze.
[13:28] <theseinfeld> persia: the libdc1394 is ready
[13:28] <DaveMorris> only 3 weeks left :(
[13:28]  * DaveMorris wonders if his package will make it
[13:28] <theseinfeld> persia: if i get this thing out of my table (the motu bureacracy :)) I can get on the coriander
[13:29]  * emgent joint time..
[13:29] <persia> theseinfeld: I've a fairly long review queue right now.  You'd do better to advertise your URL for general review.  I'm interested, and will take a look outside of REVU day if I have time, but don't count on me to get your package in.
[13:29] <emgent> persia, i will fix all this night
[13:30] <theseinfeld> persia: how do you advertise?
[13:30] <theseinfeld> just post the url on revu?
[13:30] <vorian> When I debuild a python package, it generates a debian/pycompat.  how do I avoid this?
[13:31] <vorian> and good morning :)
[13:31] <DaveMorris> theseinfeld: post the url here with a line or 2 describing the package
[13:31] <persia> theseinfeld: Ask for a review in this channel, including the URL on REVU, a short (5-10 word) description of the package, and the current REVU status.  Please limit yourself to one advertisement each 24 hours when it's not REVU day.
[13:32] <persia> vorian: Why do you want to avoid it?  It's part of python package building.
[13:32] <persia> emgent: Thanks.  Don't forget to sleep :)
[13:32] <vorian> persia: dktrkranz is asking me to remove it from a revu package
[13:32] <theseinfeld> ok: libdc1394 API version 2.0 is ready. The library version 1 was in main, and this new package should work in parallel with it. The REVU page is http://revu.tauware.de/details.py?package=libdc1394-22 and you can also check the binary packages in the PPA: https://launchpad.net/%7Elibdc1394-dev/+archive
[13:33]  * persia defers to Dktrkranz, not knowing python packaging deeply, but has seen that in every python package touched
[13:33] <vorian> hmm
[13:33] <theseinfeld> I've been working with couple of guys on the debian so the review should be quite straigh forward and fast :)
[13:33] <vorian> okie dokie, thanks persia :)
[13:36] <persia> \sh: Why change the sbuild bug from triaged to confirmed?  Is the cause not understood?  I thought the explanation was clear, and there's a fix available in a branch.  Does the fix not work for you?
[13:36] <ScottK> vorian: It's a bug in pysupport if you're using that.  If you're using pycentral, it is needed.
[13:37] <ScottK> vorian: What package (REVU link please)?
[13:38] <vorian> ScottK: http://revu.tauware.de/details.py?upid=1423
[13:38] <vorian> ok, changing to pycentral
[13:38] <ScottK> vorian: No need to change
[13:38] <vorian> alrighty
[13:38] <ScottK> You're choice.
[13:38]  * ScottK is going to comment that it's a: Not your fault.  b: Harmless.
[13:39] <vorian> lol
[13:41] <ScottK> vorian: Commented.
[13:41] <vorian> in debian/pyversions, is it ok to use 2.4 and 2.5?
[13:41] <vorian> thanks ScottK
[13:41] <theseinfeld> god dammit
[13:41] <theseinfeld> they have the package already in fedora
[13:41] <ScottK> vorian: What does the package require?
[13:41] <vorian> just says python, no specific version
[13:41] <vorian> it builds either way
[13:42] <vorian> and with each
[13:42] <ScottK> Does it work with Python 2.2 or 2.3?
[13:42] <ScottK> The upstream documentation SHOULD say.
[13:43] <persia> So, about the requirement that upstream include the licensing in the tarball.  If upstream includes a tarball containing only a zip file, and includes the licensing in the zip file, is that acceptable as well?
[13:44] <ScottK> persia: Why wouldn't it be?  Compressed or not, it's present.
[13:45] <persia> ScottK: Thanks.  I just like to seek second opinions when I'm unsure.
[13:45]  * persia also has a general distaste for compressed-archives-in-compressed-archives, but that is separate
[13:46] <ScottK> persia: Agreed.  That's a question of the pain involved, not the legality.
[13:46] <persia> Right :)
[13:46] <sladen> persia: uncompress the inner archive!
[13:48] <persia> sladen: That would break cryptographic match to upstream, which would be worse than compressed-archives-in-compressed-archives.  Complaining to upstream won't do any good, as they distribute .zip to be more cross-platform compliant, but also distribute tar.gz containing the .zip to make a watch file easy (which I appreciate).
[13:50] <lifeless> persia: tarballs in tarballs are really very bad
[13:51] <persia> lifeless: Worse than mismatched md5sums?  In general I agree, but in this special case, I think I'll just complain to upstream that not zipping before they make the tar.gz would be nice.
[13:51] <lifeless> persia: yes, definately worse
[13:51] <lifeless> persia: we routinely have different orig tarballs
[13:52]  * persia is hyper-picky about being able to demonstrate reliability of orig tarballs
[13:52] <lifeless> its a false optimisation
[13:52] <lifeless> a recursive sha of the contents will be identical; thats what matters
[13:52] <lifeless> the only folk that /look/ at orig tarballs are other distro developers
[13:53] <persia> lifeless: Hrm?  I'm optimising for only needing to look through diff.gz when I don't trust the packager, rather than optimising for processing time.  Human effort vs. machine effort.
[13:53] <lifeless> users that check the source matches and then use a binary build are - well, fill in the adjectives
[13:53] <lifeless> persia: uhm, write a trivial script to unpack and sha recursively; call it 'tarball fingerprinter'
[13:53] <lifeless> then you can just fire that off with both tarball urls and go read the diff
[13:54] <persia> lifeless: Hrm.  Maybe I ought do that.  Of course my use case is likely fairly skewed from most, as I routinely inspect sources from packagers I don't know or trust, and who are not known or trusted by any distribution.
[13:55] <lifeless> blobs in the source are bad because it makes using a vcs on the package nasty
[13:55] <lifeless> and vcs benefits >>>> checking the orig tarball hasn't been hacked
[13:56] <cbx33> hey guys
[13:56] <cbx33> what's the LP address for the NEW build queue
[13:56] <persia> lifeless: Maybe.  I'm not sold on the whole VCS maintenance thing yet, and in the few cases where I do VCS maintenance, only debian/ is in the VCS.
[13:56] <geser> cbx33: https://edge.launchpad.net/ubuntu/hardy/+queue
[13:57] <lifeless> persia: I can see why youa re not sold then ;)
[13:57] <persia> cbx33: There isn't a NEW build queue.  You likely want one of https://launchpad.net/ubuntu/hardy/+queue or https://launchpad.net/ubuntu/hardy/+builds.  Also edge is edgy.
[13:57] <cbx33> ok
[13:57] <cbx33> i just uploaded memaker there
[13:57] <cbx33> well yesterday
[13:57] <cbx33> did I upload the right thing?
[13:58] <persia> lifeless: Well, also because I almost never pull from upstream, and have optimised my workflow for debdiffs.
[13:58] <lifeless> persia: this is called accomodation
[13:58] <lifeless> persia: you are accomodating a different toolchain
[13:58] <slangasek> psst, a VCS shared between Ubuntu and Debian makes merging easier ;)
[13:59] <lifeless> golly gosh you thinkn?
[13:59]  * lifeless slaps himself
[13:59] <slangasek> lifeless: that was addressed to persia
[13:59] <persia> slangasek: Yes.  That's where I do VCS stuff.  Still, it doesn't change the debdiff handling I do as a sponsor, and it's not worth pushing all the packages in a VCS just for that.
[14:00] <slangasek> persia: right; it's worth pushing all the packages into a VCS because it also makes merges between Debian/Ubuntu and *upstream* easier
[14:00] <geser> cbx33: did you got a mail?
[14:00] <lifeless> persia: it would change it if you reviewed using bzr not debdiffs :)
[14:00] <cbx33> yes i did
[14:00] <cbx33> but my package seems different to everybody elses
[14:00] <cbx33> mine is a source pacakge
[14:00] <persia> lifeless: For every package?  Show me the 15000 bzr repos :)
[14:00] <lifeless> persia: pateince kemosabe
[14:00] <cbx33> none of the others are
[14:00] <geser> cbx33: both source NEW and binary NEW are in that queue
[14:00] <lifeless> s/patein/patien/
[14:01] <cbx33> ok
[14:01] <geser> cbx33: memaker is listed
[14:01] <cbx33> yes
[14:01] <cbx33> did i upload all I should have?
[14:01] <persia> slangasek: Sure.  I don't disagree.  On the other hand, I try for 3 uploads a day from debdiffs, and I'm completely unfamiliar with most of those packages, and most aren't in VCS anywhere.
[14:01] <geser> cbx33: yes, just wait till an archive admin processes the NEW queue
[14:02] <cbx33> ok
[14:02] <cbx33> someone said I need to send a mail to the motu list?
[14:02] <persia> lifeless: Even when you get there, it'll likely be 6-12 months before all the workflows are caught up, but I do hope there'll be less cause for this discussion :)
[14:03] <persia> cbx33: You should have gotten a NEW report from Soyuz.  You should forward that to the MOTU list.
[14:03] <cbx33> ok
[14:03] <cbx33> heheh would you believe I've never actually uploaded to the queue before
[14:04] <persia> cbx33: There's a first time for everything :)
[14:04] <cbx33> and i think i became a motu before some of you guys here
[14:04] <cbx33> hehehe
[14:04] <ScottK> Fundamentally though, the canonical source for the distro is the source package.  Unless you can move everyone off that and into a common VCS, then all you have is two places to keep the data and one will be wrong.
[14:05] <ScottK> I think packaging in a VCS works in small teams, but I've yet to see evidence it's scalable.
[14:05]  * persia agrees with ScottK, but remains unconvinced that is a complete block to no-more-source-packages.  On the other hand, it's not soon.
[14:06] <slangasek> so does the Debian perl team count as a "small team"? or what level of scalability is required here?
[14:06] <persia> ScottK: Just for purposes of discussion, s/upload/commit/ with a easily branched DVCS.  Of course, it helps if everyone uses the same VCS.
[14:07] <ScottK> slangasek: Universe would be a not small team.
[14:07] <slangasek> well, ok
[14:08] <ScottK> slangasek: I use the Debian Python Modules/Applicaton's Teams svns on alioth routinely and I think it works well.
[14:08] <slangasek> I fail to see the reasons that it wouldn't scale; other than the fact that most folks who /use/ vcses for packages currently do so because they are "small" teams that need that coordination
[14:08] <persia> On the other hand, I'm unconvinced that the bzr-svn-git-hg cross VCS tools work anywhere near well enough for it to be reasonable, but some people might consider those bugs.
[14:08] <StevenK> Who uses irssi? I'm trying to change the colour the topic on the top of the window appears in, and I can't find anything.
[14:09] <slangasek> I use irssi, I don't fiddle with colors though
[14:09] <ion_> Having the packaging as a branch from the upstream archive also makes it possible to have the distro patches as commits in the VCS, and the VCS would be able to intelligently merge new upstream releases so that updating the changes would be much less work.
[14:09] <StevenK> My topic is black on blue, which isn't very readable, and I'm finally motivated to change it.
[14:10] <ion_>   # background for topicbar (same default)
[14:10] <ion_>   #sb_topic_bg = "%4";
[14:10] <slytherin> Does anyone know why suddenly the FTBFS count for multiverse dropped to 34 form yesterdays 60+ :-)
[14:10] <StevenK> ion_: Does that mean sb_topic_fg also holds true?
[14:11] <ScottK> slangasek: I think Debian provides very good tools for repository management and packaging.  Personally, I have little interest in using an Ubuntu unique VCS as an alternative (yes, I know bzr is used outside Ubuntu, I've just never run into it anywhere else).
[14:11] <ion_> stevenk: Dunno. The default theme doesn’t seem to contain such string.
[14:12] <ion_> stevenk: In fact, there’s no _fg in it.
[14:12] <StevenK> ion_: Mmmm. Setting sb_topic_bg to "%4%w" made it all good, thanks.
[14:12] <\sh> emgent, nico was correct...you can leave the beginning slash behind..
[14:12] <emgent> ok cool
[14:13] <emgent> i attach new patch.
[14:13] <geser> slytherin: my guess is that lpia and hppa are in needs building which is only displayed if the package failed on an other arch
[14:14] <slytherin> geser: thanks for explanation. I also think that the latest faac upload might have reduced many other instances.
[14:14] <ion_> :screen mutt
[14:14] <ion_> Whoops
[14:24] <mcisbackuk> Hi all, can someone help me with uploading a package please? I'm currently packaging scummvm 0.11. What do I need to upload, there is already a bug report requesting it as bug #183976
[14:24] <ubotu> Launchpad bug 183976 in scummvm "new upstream version 0.11" [Undecided,New] https://launchpad.net/bugs/183976
[14:26]  * persia is far too slow to suggest bugging bddebian and uploading an interdiff
[14:31] <mcisbackuk> Hi all I have a problem with packaging and an getting an error, i think its my debian-loicy but how do I update it? error at http://paste.ubuntu-nl.org/53177/ would appreciate one of you guys having a look :)
[14:31] <mcisbackuk> *debian-policy
[14:33] <pochu> mcisbackuk: standards -> 3.7.3 in debian/control. the version in debian/changelog should be 0.11.0-0ubuntu1.
[14:33] <persia> mcisbackuk: 1) Install the lintian from gutsy-backports, 2) If preparing an upload for Ubuntu, use an Ubuntu version (e.g. 0.11.0-0ubuntu1).
[14:33] <pochu> (or -1ubuntu1 if it's based on a -1 from Debian)
[14:34]  * persia wonders if policy is also in backports, and if not, if anyone wants to test and push it,as having lintian and policy disagree is sub-ideal
[14:35] <slangasek> is anyone here interested in helping to rebuild libldap2 reverse-deps for the openldap2.3 soname transition?
[14:36] <StevenK> slangasek: Sure
[14:36] <persia> slangasek: Is it mostly rebuilds, or lots of porting?  I've spare machine cycles, but less brain cycles.
[14:37] <StevenK> slangasek: Throw me a list of source packages, and I'll test rebuild them
[14:38] <mcisbackuk> Sorry for late reply. thanks a lot guys :)
[14:38] <ScottK> dholbach: Are you planning on announcing the MOTU Council election on more lists?
[14:39]  * persia wonders why libldap2 doesn't show in the NBS list
[14:39] <slangasek> persia, StevenK: should be all rebuilds
[14:40] <StevenK> slangasek: If you want to split up the list 33/33/33, sounds fine to me.
[14:40] <ion_> Who gets the 1?
[14:40] <StevenK> slangasek. :-P
[14:40] <persia> ion_: You can have newpki-server if you like.
[14:40] <slangasek> StevenK: grep-dctrl -FBuild-Depends libldap2-dev -sPackage /var/lib/apt/lists/*hardy_universe_source_Sources ? :)
[14:41] <StevenK> That gives the whole list. :-)
[14:41] <slangasek> well, yes. :)
[14:42] <StevenK> slangasek, persia: There's 58 packages, giving ~ 19 packages each, I'll take the bottom 19, sorted alphabetically.
[14:42] <slangasek> I should get credit for the 20 I'm already doing in main ;P
[14:42] <TheMuso> What is being done with such a large numbe rof packages/
[14:42] <persia> StevenK: OK.  I fear wine and emacs, so that makes me happy.  I'll take chunk #3.
[14:42] <TheMuso> Oh, ldap.
[14:43] <StevenK> Oh, I missed wine. Oh well.
[14:43] <StevenK> persia: I've got openswan - zabbix
[14:44] <_ruben> whats the current targeted version of openswan for hardy?
[14:44]  * persia claims heimdal - nufw, but offers a special exception on newpki-server if ion_ has already started
[14:45] <ion_> I’m not going to get much done today.
[14:45] <StevenK> slangasek: I guess that leaves you adtool - nss-ldapd
[14:45] <persia> ion_: OK.  You get to pick a different one then.
[14:45] <slangasek> StevenK: right, plus the ones in main I'm not done with yet
[14:45] <mcisbackuk> Hello again guys. I've run 'debuild -S -sa' and 'debuild -us -uc' everything seems fine didn't get any errors, what do i do after I've built it?
[14:46] <ScottK> jdong: Can we do removals in backports if there's a oops?
[14:46] <StevenK> slangasek: If you want to give me a few in main, I'm happy to add them to the list
[14:46] <StevenK> Ew, there's 28 in main
[14:47] <StevenK> Including such fun like Openoffice.org, Evolution and PHP
[14:47] <slangasek> StevenK: you can have OOo, enjoy ;)
[14:47] <dholbach> ScottK: yes I just did - my mistake
[14:47] <StevenK> Haha. No.
[14:47] <ScottK> dholbach: No problem.  Such things happen.
[14:47] <StevenK> That can be calc's penance.
[14:48] <slangasek> StevenK: I think I have a handle on the ones in main right now anyway, I'm just noting that I'm doing those first so any universe ones assigned to me are going to be queued behind
[14:48] <StevenK> slangasek: Fairy nuff
[14:48] <persia> Is there a tracking bug that we should be closing?  (I'm hoping to hear "No")
[14:49] <slangasek> for libldap? no
[14:53] <StevenK> Right, version bumped for 19 sources.
[14:53]  * StevenK kicks off test builds
[14:57] <mcisbackuk> Anyone? All the packages seem to be built (scummvm-0.11.0ubuntu1) now, I just need to know what to do after running debuild -S -sa and debuild -us -uc?
[14:59] <persia> mcisbackuk: You want an interdiff.  See https://wiki.ubuntu.com/MOTU/Contributing and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[15:00] <mcisbackuk> persia: I take it this helps creating the diff file(s) for uploading?
[15:01] <persia> mcisbackuk: It is a tool used to generate a file that the sponsors can use to reconstruct your package during review.
[15:01] <persia> See the section in MOTU/Contributing about submitting the candidates for upload.
[15:01] <mcisbackuk> persia: Cool, thanks I'll have a look :)
[15:04] <persia> ScottK: Please add to the meeting agenda as well as indicating something should be discussed in the ML.  We need more meeting topics.
[15:05] <ScottK> persia: I already wrote to the ML.  I'll add it to the agenda.
[15:05] <persia> Thanks :)
[15:05] <ScottK> persia: When is the next meeting?
[15:07] <persia> ScottK: Urgh.  Someone volunteered to update that :(  20:00 UTC 1st Feb.  Fixing now.
[15:07] <cbx33> where is the motu-tools pacakge now?
[15:07] <cbx33> I have a nother tool to add
[15:07] <persia> cbx33: ubuntu-dev-tools
[15:08] <pochu> What should I do so I'm no longer moderated in ubuntu-devel@l.u.c ?
[15:08] <frafu> TheMuso: thanks for the new review of mousetweaks. I have a question about the copyright holders: do I also have to include (in debian/copyright) the authors of the manual and the po files? (You only talk about the C source and header files  in your comment.)
[15:09] <Hobbsee> pochu: bug cjwatson, iirc
[15:09] <persia> pochu: Subscribe with an address listed on launchpad (or at least I believe that to have worked for me)
[15:09] <TheMuso> frafu: I am not sure about po files, but documentation I'd say yes as well.
[15:09] <persia> pochu: Release planning is more than Feature Freeze exception processing.
[15:09] <pochu> persia: I am.
[15:09] <pochu> Hobbsee: ok, thanks.
[15:10] <pochu> persia: but the team is supposed to handle Feature Freeze only, AFAIK.
[15:10] <pochu> persia: so motu-ff makes sense, whereas motu-release doesn't IMHO.
[15:11] <persia> pochu: Well, that's what we need to discuss.
[15:11] <frafu> TheMuso: the documentation author was already listed. ;-)
[15:11] <pochu> persia: whether the team will handle feature freeze exceptions or something else?
[15:12] <TheMuso> frafu: Right.
[15:12] <bddebian> Heya gang
[15:12] <persia> pochu: Whether there is currently a point to having release planning be separate, and what that would mean
[15:13] <frafu> TheMuso: I know it because it is me   8-)
[15:14] <pochu> persia: best to start on what that would mean then :)
[15:14] <ScottK> persia: I guess the question is if you want actual coordination with the release team or not.  I don't think the way we did it last time was wrong.
[15:14] <frafu> Could anybody please tell me whether the authors of the po files have to be listed in debian/copyright?
[15:16] <Hobbsee> persia: it would probably be helpful for universe stuff to get discussed, while slangasek and co plan the main release schedule
[15:17] <persia> ScottK: I don't think it was wrong either, but I'd like to be involved in release planning, and I'm not a good person to evaluate freeze exceptions.  If it is determined there is enough work to warrant two teams, I don't think two teams is bad.  On the other hand, it's not worth it just for the sake of extra teams.
[15:18] <persia> Hobbsee: Yes.  Exactly.  Further, it would be good to have some means of getting universe feature goals included and stressed as part of planning.  Examples might be oldlibs cleanup, QA stuff, getting Xubuntu just right, etc.
[15:18] <ScottK> persia: Personally, I found it a natural evolution.  Basically UVF just got tighter as we got closer.
[15:18] <Hobbsee> persia: that's something you'll probably need to get slangasek to agree to, as he's the RM, but it sounds sensible.
[15:19]  * jdong uploads some crack to revu
[15:19] <jdong> I think this is like the first time I've touched revu
[15:19] <jdong> (fortunate for you guys :D)
[15:19] <persia> ScottK from a freeze-exception point-of-view I agree.  From a QA or feature perspective, I'm less sure, especially given when the team once called motu-uvf is selected each cycle.
[15:19] <lifeless> Hobbsee: sleep!
[15:20] <persia> Hobbsee: Sure.  I don't imagine many issues as long as we identify the goals early and have sufficient commitment that the RM believes we can meet them.
[15:20] <Hobbsee> lifeless: will soon.
[15:21] <Hobbsee> persia: of course, any non-canonical people are stuck with almost always being in the dark - particularly if they don't make it to UDS's, etc.
[15:21] <Hobbsee> persia: which i don't think many MOTU people will accept, and still be able to do useful stuff with the release team.
[15:21] <slangasek> persia: hmm, I think commitment from MOTU is more relevant than commitment from the RM
[15:21] <persia> Hobbsee: I disagree with that.  Perhaps in the shade though.
[15:22] <persia> slangasek: Well, yes and no.  If MOTU commits to trying to remove gtk1, it is worth holding release by 2 days?  Maybe, but maybe not.  Is the situation the same if MOTU commits to having human themed icons for all universe apps?
[15:22] <slangasek> persia: identifying goals is great, but they don't get achieved if they aren't worked on, and I don't plan to allow myself to be committed to doing the lion's share of such QA work personally :)
[15:23] <persia> slangasek: Heh.  Even if I trust the DDs to have actually closed the RC bugs, I do read the changelogs.
[15:24] <Hobbsee> persia: OK, mostly.  often, one doesn't find out about new procedures at all, or if one does, it's only thru reading irc backlog.  it's rarely published, or if it is, it's not published for ages.
[15:24] <slytherin> Can anyone confirm that if libpt-1.10.10-plugins-v4l2 is still in universe in hardy? I think it is one of the recommends of ubuntu-desktop but does not get included on CD.
[15:24] <persia> Hobbsee: Depends on the procedure.  Also, that's a bug that needs fixing.  There are plenty of non-canonical in core and more in MOTU and if we're not all working as a team, we have issues.
[15:25] <persia> slytherin: rmadison is your freind
[15:25] <Hobbsee> slytherin: it's in universe
[15:25] <slangasek> persia: I have a hard time envisioning a scenario where dropping gtk1 would manage to miss a release by two days.  Two days is nothing, when you know the release schedule in advance 6 months at a time; if something is committed to work on something like that, it's not going to come together at the very last minute (or if it is, I would have reservations about the change being made so shortly before the scheduled date)
[15:25] <slangasek> s/something/someone/
[15:25] <slytherin> persia: rmadison confirmed
[15:26] <Hobbsee> persia: indeed it does.  mabye once enough people outside canonical want it to change, it'll happen.  so far, i don't think there's been sufficient interest.
[15:26] <LucidFox> jdong, could you please look at bug #178845?
[15:26] <ubotu> Launchpad bug 178845 in avidemux "Avidemux 2.4" [Wishlist,Confirmed] https://launchpad.net/bugs/178845
[15:26] <Hobbsee> persia: really, if you (or anyone else) want to do release-based stuff, you'd be better to do it on another distro, perhaps debian.
[15:26] <persia> slangasek: Last couple releases we had one or two broken universe things get in the last couple days.  For gtk1 removal, I would imagine the issue being some last FTBFS that needs sorting.  For icons, I can't imagine it worth the delay (nor accepting uploads after RC release)
[15:27] <slytherin> Hobbsee: persia: so what would be the process to promote libpt-1.10.10-plugins-v4l2 to main?
[15:27] <persia> Hobbsee: I think we have different definitions of "release-based" stuff.
[15:27] <persia> !mir
[15:27] <ubotu> mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information.
[15:27] <Hobbsee> persia: i was meaning ubuntu-release
[15:27] <persia> Hobbsee: I'm not.  I mean generally making sure universe is in a releasable state at the release date.
[15:27] <ScottK> Personally, I think release stuff for Universe is pretty much the coordination work we did last time.
[15:28] <Hobbsee> as in, defining the cycle, sending stuff out, making sure it's ready, and deciding if there needs to be a delay, cd building, etc.
[15:28] <ScottK> persia: Universe is releasable by definition.
[15:28] <Hobbsee> ScottK: you've forgotten mobile, etc, already have you?
[15:28] <LucidFox> persia> What gtk1 removal?
[15:28] <persia> ScottK: At the end, yes.  I think there is opportunity for front-loading, but I'm not sure that's worth a separate team.
[15:28] <persia> LucidFox: The one that will be done for hardy+1 or hardy+2, depending on how motivated we feel.
[15:28] <ScottK> Hobbsee: No, I haven't.  I didn't disagree with you about hidden procedures.
[15:29] <persia> ScottK: If universe were releasable by definition, we wouldn't need SRUs.
[15:29]  * persia tries to ignore the main/universe split even harder
[15:29] <LucidFox> Ah, good. About time.
[15:29] <ScottK> persia: I disagree.  What would be a Universe bug that would stop the release?
[15:31] <persia> ScottK: Not really stop, but any uploads after the release candidate are only supposed to be for release critical bugs.  Personally, I feel any FTBFS, cannot-install, doesn't work out of the box, etc. type bug should be closeable in universe during that time.
[15:31] <Hobbsee> ScottK: something that rated as pretty damn important, and that actually had a person with a fix in sight.
[15:31] <Hobbsee> ScottK: the latter being the limiting factor
[15:32] <persia> Also, I think we could do better to not have so many of those open after release candidate release.  On the other hand, I'm not sure a named team would especially help this.
[15:32] <ScottK> Hobbsee: Would that stop the release or get pushed to updates?
[15:32] <slangasek> persia: well, if there are just a few final FTBFS needing sorted, and the goal is important enough that someone would want to delay the release for them, doesn't that make it plausible to get them sorted out in advance of the release date if there's really a commitment to them?
[15:32] <ScottK> Since universe doesn't affect the iso's, there's no real need to wait.
[15:32] <Hobbsee> ScottK: depends.  probably -updates, as it doesn't affect cds
[15:32] <ScottK> My thought.
[15:32] <ScottK> too
[15:33] <slangasek> persia: I'm shying away from saying "yes, it'd be ok to delay the release if it meant dropping gtk1", even though I think that's a worthwhile goal, because setting a precedent that it's ok invites people to be more lax in their scheduling
[15:33] <persia> slangasek: Of course.  I was mostly talking about coordination: if the release team doesn't want to support a MOTU release goal, it's maybe harder to promote it cleanly.
[15:33] <persia> slangasek: Sure.  I neither expect nor want you to say that.
[15:34] <slangasek> well, ok - I don't see that the release team supporting a MOTU goal or not should make much of a difference, I think the community is able to sort out for itself what it thinks are good goals to prioritize without needing me to tell them
[15:35] <slangasek> or if it's not able to, we should address that :)
[15:35] <slangasek> (e.g., better QA tools so that the problem areas are identifiable)
[15:35] <persia> On the other hand, there were universe packages that went in after the very last really final freeze for both feisty and gutsy, which is more the sort of thing I mean.
[15:35]  * slangasek nods
[15:35] <Hobbsee> persia: if the MC supported the release goal..then it has more chance
[15:35] <persia> slangasek: I'd like to see that, but when you send out a notice, it means more than when I send out a notice.
[15:36] <persia> Hobbsee: Of course :)  Where's your wiki update?
[15:36]  * Hobbsee waves the magic wand
[15:36] <ScottK> persia: However for Gutsy we ended up with all Universe packages built for all architectures.  This is progress from Feisty.
[15:37] <persia> ScottK: I thought we had 939 FTBFS for gutsy release.
[15:37] <persia> (which is still progress from feisty)
[15:37] <ScottK> persia: Sure.  I mean for Feisty we had some archs built on ubuntu1 and others on ubuntu2 for the same package.
[15:38] <persia> ScottK: Right.  We had all packages in sync.  This time, I think we can have all packages built for at least i386, amd64 and powerpc.
[15:39]  * persia is prepared to request removal-without-blacklisting for a couple packages to ensure that
[15:39] <DktrKranz> removal-without-blacklisting?
[15:39] <ScottK> persia: Out of the last batch of RC syncs that I uploaded for you I think we had only one or two FTBFS on a single arch.  So even piling stuff in at the last minute, we made good progress.
[15:40] <ScottK> persia: What we needed was more people working it.
[15:40] <ScottK> i.e. we lacked manpower, not management.
[15:41] <persia> ScottK: completely agreed.  I'm just not convinced that there is an identity between the people best suited for freeze exception review and the people best suited for release coordination.  As I've said, I'm not convinced we need a motu-release team, in part because of the issues Hobbsee raised with ubuntu-release and documentation.
[15:42] <ScottK> persia: I think the end game coordination that was done last time had significant value.  I don't think it makes sense to have a whole another team for it.
[15:42] <persia> DktrKranz: Special type of removal for things that are broken now, but may well be fixed later, but not in time for the next release.  These get pulled back from the next automated sync.
[15:43] <jdong> REVU should recognize me if I've been a member of MOTU contributors since like 2005, right?
[15:43] <persia> ScottK: Today, I agree with you.  As we grow, I suspect I won't.  It's about the people not necessarily being the same, and sharing workload.
[15:43] <jdong> oh nvm
[15:44] <persia> jdong: No.  It forgot everyone who wasn't a MOTU last September, and hasn't uploaded since.
[15:44] <persia> (and some other people too)
[15:45]  * sistpoty|work whistles
[15:45] <jdong> http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch-0.2/
[15:45] <jdong> ROFL
[15:45]  * slangasek takes sistpoty|work off the stove and pours him out into a teacup
[15:45] <jdong> err.... revu should not interpret index.html inside packages
[15:45] <jdong> though admittedly it looks REALLY pretty!
[15:45] <sistpoty|work> he
[15:45] <persia> jdong: That's a feature
[15:45] <jdong> persia: really?
[15:46] <jdong> well, at least it doesn't try to run the PHP scripts in remote/ :D
[15:46] <persia> jdong; http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch-0.2/debian/ works, as does http://revu.tauware.de/revu1-incoming/clutch-0801231620/clutch_0.2-0ubuntu1.diff.gz (the two URLs I tend to check)
[15:47] <sistpoty|work> jdong: feel free to send me an .htaccess to turn this off :P
[15:47] <joejaxx> jdong: wth is that? lol is that what revu looks like now?
[15:47] <jdong> joejaxx: that's the index.html in my package's source root
[15:47] <joejaxx> Lol
[15:47] <persia> sistpoty|work: Doesn't need an .htaccess, just turn off directoryindexing in incoming
[15:47] <jdong> joejaxx: it's Clutch, a sexy AJAX web UI to transmission bittorrent
[15:47] <joejaxx> oh fun :D
[15:47] <frafu> @find po
[15:48] <jdong> joejaxx: yeah, I'm hoping I can squeeze it into universe before we freeze up -- it'd be a great companion to our default torrent client
[15:48] <sistpoty|work> persia: that would be option indexes?
[15:48] <sistpoty|work> (too lazy too look at apache docs right now)
[15:48] <persia> sistpoty|work: Erm.  I was last an apache admin last century.  My advice is certainly outdated.
[15:49] <sistpoty|work> heh
[15:50] <sistpoty|work> damn... /me is listed as server admin
[15:50] <jdong> sistpoty|work: hmm good question....
[15:50] <jdong> sistpoty|work: lemme look into that
[15:51] <sistpoty|work> jdong: thanks... just ping me, while I'll get some work done
[15:52] <jdong> sistpoty|work: wow... this is amazing... there is no way to do it :(
[15:52] <DktrKranz> persia: regarding QA tools, I should really improve my NBS reverse-tracker soon to be used by a wider audience, time is the matter, though :(
[15:52] <jdong> I certainly hope I'm wrong!
[15:52] <sistpoty|work> jdong: there must be a way, I'm quite sure
[15:53] <jdong> sistpoty|work: the way(s) to do it seem to turn off directory listing too
[15:53] <jdong> sistpoty|work: except specifying DirectoryIndex a-highly-impossible-filename-or-path
[15:54] <jdong> actually... that might work
[15:54] <persia> DktrKranz: Yep.  Once we hit FF, NBS tends to clean up fairly quickly (as there are not supposed to be any more transitions).  On the other hand, the larger audience will appreciate it, and I'd really like it as part of the default set for hardy+1.
[15:55] <tuxmaniac> after a  long time of not speaking about Alliance package I am back to trouble the MOTus to review http://revu.tauware.de/details.py?package=alliance
[15:55]  * persia remembers something about apache1 having the ability to set DirectoryIndex for a specific directory on the server, and .../incoming/... is defined in a different stanza then the main application...
[15:56] <tuxmaniac> loads of changes have gone into this one. the binary is giving a few lintian man page warnings which I am looking into already
[15:56] <ScottK> StevenK: Do you have a moment for a requestsync bug or should I just put it on LP?
[15:56] <LucidFox> Whoops, REVU broke
[15:57] <DktrKranz> It has a couple of bugs to be fixed (it's unable to discriminate {pro,de}motion and counts number of NBS instead of number of packages), but it's quite accurate. And, most of all, it has an horrible look-and-feel...
[15:57] <LucidFox> I get an internal server error when trying to access the source directory
[15:57] <jdong> persia: you can set DirectoryIndex for a <Directory> to /some/location/that/really/cant/exist/by/POSIX/permissions
[15:57] <tuxmaniac> in the meantime if someone could point me other review points, I shall do the needful
[15:57] <LucidFox> hmm, seems fixed
[15:57] <jdong> persia: but that sounds like one of those seven deadly apache sins
[15:57] <rulus> If someone has time, please review http://revu.ubuntuwire.com/details.py?package=gtkvd. Thanks :)
[15:57]  * persia refrains from remembering any other deprecated practices
[15:59] <jdong> figured it out!
[15:59] <jdong> sistpoty|work: in the Directory stanza for incoming, DirectoryIndex __NOFILE__ and then don't allow override
[15:59] <jdong> sistpoty|work: AllowOverride None, that is.
[16:00] <jdong> which I hope to god was already in there so users couldn't write their own htaccesses in uploaded packages?
[16:00] <persia> jdong: Don't ask too many questions about how REVU works :)
[16:00] <sistpoty|work> jdong: where do you have that __NOFILE__ from?
[16:00] <LucidFox> tuxmaniac> debian/changelog for alliance is messy
[16:00] <DktrKranz> slangasek: does debian provide a list of packages which depends on NBS packages somewhere?
[16:01] <jdong> sistpoty|work: some dude's blog. I tested it to work if I touched __NOFILE__ apache still shows a directory listing
[16:01] <jdong> sistpoty|work: you should probably verify the same just to make sure I'm not crazy
[16:01] <LucidFox> tuxmaniac> since there have been no previous Debian or Ubuntu releases, debian/changelog should contain only one entry
[16:01] <LucidFox> which is -0ubuntu1
[16:01] <tuxmaniac> LucidFox, hmm ok
[16:01] <persia> DktrKranz: There's the testing report, and the excuses report, which do some of that.  Not quite the same as pitti's script though.
[16:01] <slangasek> DktrKranz: I don't believe so.  In Debian, they're usually removed from the archive as soon as they're NBS.
[16:02] <DktrKranz> thanks.
[16:02] <LucidFox> tuxmaniac> there are other comments, I will write them
[16:02] <tuxmaniac> LucidFox, thanks a million
[16:02] <slangasek> therefore in Debian, you'd really just want a report of uninstallables in unstable
[16:03] <tuxmaniac> LucidFox, we are working hard to get this into hardy. :-) it will be of great support to us.
[16:04] <persia> slangasek: That catches more than just packages needing rebuild or porting though: it also catches packages with various annoying bugs.
[16:05] <persia> The idea of http://people.ubuntuwire.com/~dktrkranz/NBS/ is more to speed library transitions, etc.
[16:05] <slangasek> persia: in Debian there's no way to distinguish
[16:05] <sistpoty|work> jdong: http://revu.tauware.de/revu1-incoming/acer-acpi-0711051850/
[16:05] <sistpoty|work> jdong: doesn't seem to work
[16:05] <sistpoty|work> (c.f. with __NOFILE__ in that dir)
[16:06] <persia> slangasek: Well, currently.  One could presumably regularly grab several packages.gz and sources.gz and compare on a daily basis to build a list.
[16:06] <jdong> sistpoty|work: damn
[16:06] <slangasek> persia: for that matter, knowing that it depends on an NBS package doesn't tell you it doesn't also have annoying bugs that prevent a rebuild; c.f. http://people.ubuntu.com/~ubuntu-archive/NBS/libglib1.2
[16:06] <sistpoty|work> jdong: I'll try "." instead
[16:06] <persia> slangasek: True.
[16:06] <jdong> sistpoty|work: ooh there's a good idea
[16:07] <sistpoty|work> heh, infinite recursion... bla
[16:07] <DktrKranz> mh, I guess there is no common way to catch bugs from NBS list, though
[16:07] <slangasek> persia: in fact, as a general rule packages that we /know/ have annoying bugs that prevent them from building from source are a subset of the NBS list :)
[16:07] <persia> DktrKranz: Not really.  The archive management practices differ signficantly.
[16:07] <jdong> sistpoty|work: related note, is there a purpose to http://revu.tauware.de/revu1-incoming/? it just took me 10 seconds to list that dir which could be DoS
[16:08] <DktrKranz> persia: what do you mean?
[16:08] <persia> slangasek: Yes.  I'm hoping to have some means of detecting the rest usefully in place for hardy+1, but I'm not sure we can have something to address the outstanding issues in hardy.
[16:09] <sistpoty|work> jdong: not too sure right now... but it certainly doesn't cause a DoS (tried that, and apache doesn't really have that much load)
[16:09] <sistpoty|work> jdong: the reason it's so slow, is because I'm causing heavy io-load atm... (doing a backup)
[16:09] <persia> DktrKranz: The means and timing of binary package drops.  Ubuntu frequently has leftover binaries for all sorts of reasons that don't appear in Debian.  I don't understand the details well enough to explain properly, and am too tired to dig up all the examples.
[16:10] <DktrKranz> ah, all clear npw.
[16:10] <DktrKranz> *now
[16:11] <persia> DktrKranz: There's also differences in NEW, accepted, etc, but those are less important for NBS.
[16:11] <jdong> sistpoty|work: ah, ok, that explains it
[16:12] <DktrKranz> anyway, if there are a need to prepare some new tools for QA, I'll likely give a hand.
[16:12] <LucidFox> tuxmaniac> Commented alliance
[16:14] <tuxmaniac> LucidFox, great. thanks.
[16:16] <persia> DktrKranz: I think http://conflictchecker.ubuntu.com/possible-conflicts/ would benefit from a front end, if you're bored.  On the other hand, I think getting a nice interface on NBS for those who like colored clicky thingies would also be of benefit.
[16:19] <jdong> sistpoty|work: I'm gonna try a combination of mod_rewrite with DirectorySlash off
[16:20] <sistpoty|work> jdong: I hope it's much easier... actually I'd just like to disable mod_dir for this directory
[16:20] <\sh> hmm...any python expert on?
[16:21] <ScottK> \sh: Sort of.
[16:21] <\sh> ScottK, trying to import dynamically some modules...
[16:22] <ScottK> OK.
[16:22] <\sh> with a construct like this:
[16:22] <\sh> modconf=__import__('buildservice.'+m.group(1)+'.modulesconf',globals(),locals(),'ModulesConf')
[16:22] <\sh> (took it from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52241)
[16:22] <jdong> sistpoty|work: is there a way to disable modules per directory?
[16:23] <\sh> it should give me mod=modconf() \ mod.method()
[16:23] <sistpoty|work> jdong: I hope there is, but I"m not sure
[16:25] <DktrKranz> persia: colored clicky thingies are sort of things I'm definitely not good at, my sense of fashion is quite bad despite being italian... :)
[16:25] <\sh> ScottK, I wonder if this works even when I'm calling this construct under buildservice.<module>
[16:27] <ScottK> \sh: That's making my head hurt to look at, but I think there's at least one to many names in there.
[16:27] <ScottK> \sh: But once you've done that, isn't it all part of the modconf namespace?
[16:28] <\sh> ScottK, it should be...
[16:28] <ScottK> \sh: I revise my answer to no.  No Python experts here.
[16:28] <\sh> lol
[16:29] <joejaxx> what is the policy on alpha software in universe?
[16:30] <Lutin> you might not want it, especially since hardy is going to be LTS
[16:30] <ScottK> joejaxx: Is it useful to users?  Are you going to support it after release?
[16:31] <joejaxx> hmm now that you mention the first question i do not think anyone else is going to care for it except me
[16:31] <joejaxx> lol
[16:32] <joejaxx> otherwise it would have been in the archive already
[16:32] <DaveMorris> joejaxx: out of interest what was it?  Someone else cares enough to create it
[16:32] <geser> \sh: what do you want exactly to achieve? importing the modulesconf module for the  buildservice.<module>?
[16:32] <jdong> is anyone interested in some REVUing love at http://revu.tauware.de/details.py?package=clutch? :D
[16:33] <joejaxx> DaveMorris: steganographic filesystem
[16:33] <\sh> geser, yepp...got it :)
[16:33] <DktrKranz> vorian: you're welcome, thanks for your patience :)
[16:33] <DaveMorris> joejaxx: I could have fun with that :)
[16:33] <vorian> DktrKranz: no worries
[16:33] <vorian> :)
[16:33] <vorian> you da best!
[16:33] <geser> \sh: should relative imports help you?
[16:34] <joejaxx> DaveMorris: lol
[16:34] <\sh> geser, nopd
[16:34] <\sh> geser, nope
[16:34] <DaveMorris> esp if you could hide files into movies.  Would work well with mythtv :)
[16:34] <\sh> geser, well, it's working now ;) I just should follow the example :)
[16:36] <geser> ok
[16:39] <joejaxx> DaveMorris: it does not exactly work like that :P
[16:40] <jdong> how do revison uploads into REVU work
[16:40] <jdong> do I need to bump the version? -sa?
[16:41] <pochu> jdong: -S -sa
[16:41] <jdong> pochu: thanks :)
[16:41] <geser> jdong: you can upload the same revision as often as needed to REVU
[16:42] <jdong> very good
[16:42] <ScottK> That and diffs between the uploads are, IMO, REVU's killer features.
[16:42] <\sh> geser, ok..works now
[16:45] <frafu> From googling, it seems that the debian/copyright file does not need to list the authors of the po files. The practice seems to be to indentify them in the ChangeLog. Could anybody please confirm?
[16:48] <yamal> MOTUs, the latest & greatest sabnzbd package is ready for review @ http://revu.tauware.de/details.py?package=sabnzbdplus
[16:52] <LucidFox> yamal> Hmm, I just noticed your email address ends with .ru, do you happen to be a Russian?
[16:52] <yamal> nope
[16:52] <LucidFox> :(
[16:53] <\sh> who is doing syncs this week?
[16:54] <geser> \sh: seb128 did some some minutes ago
[16:54] <emgent> \sh, see my query
[16:56] <LucidFox> yamal> Looks good to me now. (IANAMOTU, so can't advocate)
[17:01] <yamal> LucidFox: still, thanks for checking it out :)
[17:02] <LucidFox> jdong, if you have time, I would like you to look at a Gutsy backport: bug #177353
[17:02] <ubotu> Launchpad bug 177353 in gutsy-backports "Please Backport SMPlayer 0.5.62" [Undecided,Confirmed] https://launchpad.net/bugs/177353
[17:02] <LucidFox> * backport request
[17:12] <joejaxx> if upstream has a version setup that is similiar to debian how do you proceed with the version number in debina /ubuntu?
[17:12] <joejaxx> as in package-1.0-2beta
[17:13] <joejaxx> being the upstream version?
[17:13] <joejaxx> debian*
[17:14] <joejaxx> :D
[17:17] <pochu> 2beta means beta2? :)
[17:17] <pochu> joejaxx: if so, I'd go for 1.0~beta2-0ubuntu1
[17:17] <joejaxx> ok
[17:17] <sistpoty|work> joejaxx: I'd substitue the - with another allowed character
[17:17] <pochu> Or maybe it is 1.0.2~beta-0ubuntu1
[17:18] <pochu> sistpoty|work: right, but if there's a package-1.0-2 later, he needs to lower this one with ~beta
[17:18] <joejaxx> hmm
[17:19] <sistpoty|work> pochu: sure, depends just if upstreams version number is after an 1.0 or before an 1.0 release ;)
[17:19] <pochu> sistpoty|work: right
[17:20] <pochu> sistpoty|work: btw were you able to look at my REVU patch? :)
[17:20] <joejaxx> "Package names must only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.)"
[17:20] <joejaxx> it does not like the ~
[17:21] <sistpoty|work> pochu: not yet, sorry
[17:21] <sistpoty|work> (at least not yet in detail)
[17:21] <slangasek> joejaxx: there's nothing wrong with having - in an upstream version number, only the last dash is used to delineate the upstream and debian revisions
[17:22] <pochu> sistpoty|work: ok, no worries :)
[17:22] <sistpoty|work> slangasek: it's against policy?
[17:22] <slangasek> sistpoty|work: uh?
[17:22] <pochu> joejaxx: I've seen lots of packages using ~
[17:22] <slangasek> it most certainly isn't against Debian policy
[17:22] <sistpoty|work> slangasek: ups... inverted the condition *g*
[17:22] <joejaxx> well debhelper is complaining :P
[17:23] <joejaxx> pochu: ^
[17:23] <pochu> complaining as in warning?
[17:23] <sistpoty|work> always these double negations: "If there is no debian_revision then hyphens are not allowed" *g*
[17:23] <slangasek> joejaxx: if you have a ~ in the package name, you've replaced the wrong -
[17:24] <slangasek> for that matter, "bwuh?"
[17:24] <joejaxx> slangasek: 1.0~beta-0ubuntu1 is incorrect?
[17:24] <slangasek> joejaxx: as a package *name*? you betcha
[17:25] <joejaxx> no
[17:25] <joejaxx> :P
[17:25] <joejaxx> as a versoin
[17:25] <joejaxx> version*
[17:25] <slangasek> joejaxx: what error are you getting?
[17:25] <slangasek> you quoted "Package names must only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.)"
[17:25] <joejaxx> debhelper things the 1.0~beta is part of the package name
[17:25] <joejaxx> when it is now
[17:25] <joejaxx> not*
[17:26] <slangasek> please give an exact error message
[17:26] <slangasek> or point to a package that's giving this behavior
[17:27] <slangasek> er, by "debhelper", do you mean "dh_make"?
[17:29] <frafu> TheMuso: I just uploaded the fixed version of the mousetweaks debian package to revu. So, if you have time and are still interested,... Let's hope that this time it will be completely correct.  ;-)
[17:29] <sistpoty|work> pochu: patch looks fine, applied to production. I'll commit it to trunk this evening
[17:29] <sistpoty|work> pochu: thanks!
[17:29] <AnAnt> persia: hello
[17:29] <proppy> hi
[17:30] <joejaxx> lol nevermind
[17:30]  * joejaxx has not had any sleep yet and just named the source directory with that version instead of modifying debian/changelog
[17:30] <AnAnt> dholbach: ping
[17:30] <joejaxx> haha
[17:30] <joejaxx> that will error out for sure lol
[17:31] <joejaxx> slangasek: ^ :P
[17:32] <pochu> sistpoty|work: yohoo, thanks a lot :-)
[17:33] <slangasek> joejaxx: well, I guess that means you found your error? dh_make != debhelper, in any case; so I was a little confused about how debhelper would have ever objected
[17:34] <joejaxx> sorry for the confusion :P
[17:34] <joejaxx> i forgot they are separate packages :P
[17:34] <TheMuso> frafu: Will look at it shortly, thans.
[17:35] <joejaxx> well thanks for being here through my ignorance :P
[17:35] <frafu> TheMuso: thanks to you.    :-)
[17:36] <dholbach> AnAnt: pong
[17:36] <AnAnt> dholbach: could you review the ubuntume-gdm-themes & usplash-theme-ubuntume ?
[17:37] <dholbach> AnAnt: this shouldn't be blocked on me - just ask in here for somebody to do the review
[17:37] <AnAnt> dholbach: ok
[17:38] <LucidFox> If any MOTUs are up for REVU reviews, I would recommend http://revu.ubuntuwire.com/details.py?package=libgee - I reviewed it in the past, among other people, and now all the problems seem to have been solved, I couldn't find any new ones
[17:38] <LucidFox> and I'm interested in this package :)
[17:39] <AnAnt> could someone review those:  ubuntume-gdm-themes & usplash-theme-ubuntume ?
[17:40] <tuxmaniac> LucidFox, if I add Homepage: field to debian/control it gives a warning "Unknown Homepage field" during pdebuild. Is there something I am missing here? This is wrt alliance package that you commented
[17:40] <LucidFox> tuxmaniac> That's normal
[18:37] <jdong> gpg -d <<EOF
[18:37] <jdong> oops
[18:40] <joejaxx> jdong: lol :P
[18:40] <ScottK> Does anyone have an example of a daemon that is written in Python/Perl or some other similar language.  I'm having trouble --exec'ing it in the init.
[18:43] <RainCT> \sh: Hi. «pbuilder-dist build x» doesn't work here now (it says «Command line parameter [] is not a valid .dsc file name»)...
[18:43] <\sh> RainCT, hmmm...
[18:44] <joejaxx> RainCT: did you specify the release? :D
[18:44] <joejaxx> or does pbuilder-dist fall back on which ever release it is published on when not specified?
[18:44] <\sh> joejaxx, he 's right
[18:45] <RainCT> joejaxx: I use pbuilder-hardy, pbuilder-gutsy, etc. (but also tried with «pbuilder-dist hardy»)
[18:45] <joejaxx> RainCT: i thought you were talking specifically about the `pbuilder-dist` command :)
[18:46] <joejaxx> Warning: Unknown distribution «build». << for example :D
[18:46]  * joejaxx stops rambling
[18:46] <RainCT> lol
[18:47] <RainCT> \sh: I think I had the same problem when I tried to add gksudo support myself some weeks ago..
[18:47] <\sh> RainCT, give me a sec...it could be that $@ is wrong
[18:48] <saivann> Hi, I tried to upload a new package for reviewing to REVU and I got a email saying : Signer has no upload rights at all to this distribution. Can someone help me around that? I try to upload simdock package which I would like to be reviewed for bug #183942
[18:48] <ubotu> Launchpad bug 183942 in ubuntu "[needs-packaging] simdock" [Wishlist,In progress] https://launchpad.net/bugs/183942
[18:49] <sistpoty|work> saivann: you seem to have uploaded to ubuntu, not to revu (as revu doesn't write any mails if an upload is dropped)
[18:50] <sistpoty|work> saivann: check /etc/dput.cf... and iirc a revu section should already be there. If so, you can dput revu <changesfile>
[18:50] <saivann> sistpoty|work : Thanks for this info, I used default dput configuration, I'll take a look..
[18:52] <CyberMatt> hello looking for advocates for my package http://revu.tauware.de/details.py?package=jailkit
[18:52] <saivann> I found the problem, thanks!
[18:53] <sistpoty|work> np
[18:56] <LucidFox> saivann> What is the package you're uploading to REVU?
[18:56] <nenolod> crimsun, ping
[18:57] <\sh> RainCT, looks like he is already root without and jumping into /root
[18:57] <saivann> LucidFox : A new package, simdock, for hardy ( it's a dock which doesn't require Compiz )
[18:57] <\sh> and can't find the .dsc
[19:01] <tuxmaniac> has there been any issues with the latest gutsy upgrades. After a recent xserver-xorg upgrade all my videos are in monochrome
[19:04]  * sistpoty|work heads home... cya
[19:06] <\sh> RainCT, please check with something else then pbuilder-dist :)
[19:06] <Adri2000> clear
[19:06] <Adri2000> err
[19:06] <Adri2000> sorry :)
[19:06]  * Pici applies the paddles to Adri2000 
[19:06] <Pici> *clear*
[19:07] <Pici> Oh, this is -motu, not -offtopic.  /me scurries off
[19:07] <\sh> RainCT, because when I use pbuilder manually it gives me the very same error message
[19:11] <DaveMorris> saivann, you need to close the LP bug in your changelog, see my opensg package for an example at http://revu.tauware.de/details.py?package=opensg
[19:12] <DaveMorris> Your debain copyright just needs the preamble of the licence and a link to where it is on the file system, see this for an example http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/copyright
[19:13] <saivann> DaveMorris : I'll fix this in 2 minutes, thanks, you're right I forgot this
[19:13] <DaveMorris> your control file needs to have a hompage and xsbc-orginal-maintainer fields, again see http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/control for an example
[19:14] <DaveMorris> maintainer should be Ubuntu MOTU Team <ubuntu-motu@lists.ubuntu.com>
[19:16] <jdong> anyone in a REVU mood? :D
[19:16] <\sh> RainCT, got it
[19:16] <DaveMorris> saivann: also fix the problems lintian and linda are moaning about
[19:16] <saivann> DaveMorris : I though that it was due to the fact that this package use cdbs, isn't it?
[19:17] <DaveMorris> no, your standards version is old
[19:17] <saivann> Ok, noted!
[19:19] <DaveMorris> saivann: something like this in your rule file will fix the other warning http://www.pastebin.ca/870022
[19:19] <DaveMorris> remember that if needs to be tabbed in though
[19:19] <\sh> RainCT, try to put a "--" between $SUDOREPLACE and pbuilder call, and remove the leading " before pbuilder call and after $@
[19:20] <saivann> DaveMorris: I just added these lines to the rules file, thanks, I'll look if it will fix the warning
[19:27] <DaveMorris> ls
[19:27] <nixternal> jcastro: I like that playbook idea
[19:28] <nixternal> DaveMorris: ls doesn't work in IRC :p
[19:28] <nixternal> I have tried, at least a few thousand times
[19:28] <jdong> Password:
[19:29] <nixternal> heh
[19:30] <\sh> could someone test pbuilder-dist from here? https://code.edge.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk
[19:30] <RainCT> \sh: still doesn't work here.. :/
[19:30] <\sh> RainCT, you need to invalid your sudo session
[19:32] <\sh> hmpg
[19:32] <\sh> if gksudo fails, sudo failes too...
[19:32] <\sh> but sudo is doing correct now
[19:35] <\sh> damn
[19:35] <\sh> it worked and now not
[19:36] <leonel> Just a question   :   asking in #postgresql   about  PostgreSQL 8.3 release  someone said that  before march will be released  ..  according to Hardy Release Schedule  Feb 14 is  Feature freeze   so  if PostgreSQL 8.3  gets released in  March   Is there any chance to include PostgreSQL 8.3 in Hardy ??
[19:39] <rexbron> Got time for a review? Take a look at http://revu.ubuntuwire.com/details.py?package=openlibraries
[19:40] <rzr> hi
[19:40] <rzr> i worked on jaaa, it semms to be uploaded but RFS isnt closed how comes ? https://bugs.launchpad.net/ubuntu/+bug/160732
[19:40] <ubotu> Launchpad bug 160732 in ubuntu "[needs-packaging] Jaaa (JACK & ALSA Audio Analyser)" [Wishlist,In progress]
[19:44] <jdong> wait a sec, orig.tar.bz2s aren't valid, are they?
[19:44] <zul> nope i dont think so
[19:44] <zul> at least I dont recall seeing one
[19:45] <jdong> *grumble* stupid uscan
[19:45] <jdong> aha, uscan --repack
[19:47] <ion_> uscan --repack seems to bunzip2 -c foo | gzip > bar. I wonder why not gzip -9.
[19:48] <jdong> ion_: because it takes 10x as long for a very small gain, IMO
[19:49] <jdong> if we want fast and small, we should work on orig.tar.lzma's ;-)
[19:51] <DaveMorris> saivann: you didn't upload the orginal tarball so your update won't unpack on revu
[19:51] <cbx33> hey hey
[19:51] <cbx33> howz it going everyone
[19:51] <saivann> DaveMorris : I just learned this, my package has been re-uploaded 40 seconds ago
[19:51] <jdong> cbx33: good thanks for volunteering to revu my package :)
[19:51] <cbx33> so, I got a tool to add to ubuntu-dev-tools
[19:51] <cbx33> jdong, I did?
[19:51] <jdong> cbx33: of course :) You spoke first
[19:52] <cbx33> poop
[19:52] <cbx33> Depends how soon you need it?
[19:52] <cbx33> and if imbrandon gave me advocate powers on revu yet
[19:52] <jdong> cbx33: I was just messing with you, if you really want to revu for me, that's cool but I don't expect you to ;-)
[19:53] <cbx33> i'll take a look but can't say it'll be tonight
[19:53] <cbx33> what's the pacakge?
[19:53] <jdong> cbx33: clutch
[19:54] <cbx33> so, what's the procedure for adding to that pacakge, dholbach said I should get the source from lp and commit my change
[19:54] <cbx33> having not done that on someone elses branch before
[19:54] <cbx33> would I checkout
[19:54] <cbx33> as opposed to branching
[19:54] <cbx33> and then would i commit or push or what?
[19:54] <jdong> cbx33: nah, you'd branch like normal
[19:54] <cbx33> oh
[19:54] <cbx33> then push?
[19:54] <jdong> cbx33: and then you'd push to your own ~user_name/ubuntu-dev-tools/your-branch-name
[19:55] <cbx33> oh i see
[19:55] <cbx33> right
[19:55] <\sh> RainCT, ok...something is totally wrong with the script
[19:56] <cbx33> ouch.....why does http://revu.tauware.de/revu1-incoming/clutch-0801231940/clutch-0.2/
[19:56] <cbx33> take me to some weird place with torrent stuff?
[19:57] <cbx33> oh RainCT was it you that improved my 404main script?
[19:57] <cbx33> if so thanks....only saw the changes today ;)
[19:57] <RainCT> cbx33: yes. no problem :)
[19:58] <cbx33> adding a new one
[19:58] <cbx33> it scans a python file and tells you the deps
[19:58] <cbx33> recursive of course
[19:58] <RainCT> cool
[19:58] <cbx33> not 100% fool proof
[19:58] <cbx33> but good for a start
[19:59] <jdong> should manpages go into /usr/man?
[19:59] <jdong> I thought they belong in /usr/share/man?
[19:59] <cbx33> why can't I browse the files and more
[19:59] <cbx33> any
[19:59] <cbx33> just what is http://revu.tauware.de/revu1-incoming/clutch-0801231940/clutch-0.2
[19:59] <cbx33> ??
[20:00] <jdong> cbx33: that's revu interpreting the index.html in the package
[20:00] <ion_> Just an index.html in the root :-)
[20:00] <cbx33> oh
[20:00] <cbx33> stupid
[20:00] <jdong> cbx33: if you've got an idea how to turn that off in apache, we spent an hour on that this morning :D
[20:00] <cbx33> hmm
[20:00] <cbx33> well
[20:00] <cbx33> not locally I don't think
[20:01] <cbx33> that's an interesting one
[20:01] <DaveMorris> jdong: move the index.hmtl our of the root dir upstream ;)
[20:01] <cbx33> does an .htaccess apply to just the current dir or do child dirs inherit?
[20:02] <jdong> cbx33: inherit , I think
[20:02] <cbx33> so
[20:02] <jdong> cbx33: we cannot found any option to turn off DirectoryIndex directives
[20:02] <jdong> cbx33: without turning off auto-indexes
[20:02] <cbx33> hmm
[20:03] <cbx33> DirectoryIndex usually being index.html index.php etc
[20:03] <jdong> right
[20:03] <cbx33> what about setting it to be something exceedingly obscure?
[20:03] <jdong> cbx33: well... that's quite a hack, isn't it? :)
[20:03] <DaveMorris> saivann: Sorry, I was wrong before, you actually nned to remove config.cache and config.status rather than config.log
[20:04] <cbx33> jdong, sure
[20:04] <cbx33> but it would make it so idiots like me didn't get confused
[20:05] <jdong> cbx33: well we wanted to find the "right" solution so as to also reduce the liklihood of security-related consequences of index interpretation
[20:06] <saivann> DaveMorris : np, thanks for that solution, I'll fix it again, but before all, you talked about awn dock for Hardy, do you think that there's any interest to also add simdock?
[20:06] <cbx33> jdong, true
[20:06] <DaveMorris> saivann: you'll also wanna have debhelper (>= 5) instead of debhelper (>= 4.2.16) in your debian/control file
[20:06] <DaveMorris> saivann: I would on my older hardware which can't run compiz/berly
[20:07] <saivann> DaveMorris : Ok, I'm fixing this
[20:08] <saivann> DaveMorris : For the clean rules, is that ok : 	if [ -e config.log ] ; then rm config.cache ; rm config.status ; fi ;
[20:08] <DaveMorris> saivann: your copyright file is slightly wrong
[20:08] <saivann> DaveMorris : In which way?
[20:09] <saivann> DaveMorris : It is not GPL2 ?
[20:09] <DaveMorris> no you want if [ -e config.cache  ] ; then rm config.cache ; fi ; and f [ -e config.status  ] ; then rm config.status ; fi ;
[20:10] <saivann> DaveMorris : Oh you're right
[20:10] <DaveMorris> You copy and pasted the bit from my package bby the look of things, my package was LGPL whereas your is GPL
[20:11] <cbx33> jdong, hmm that's a tricky one
[20:11] <DaveMorris> so lines 12, 18, 24 need changing
[20:13] <saivann> DaveMorris : What is the right name to replace "GNU Library General Public License", "GNU General Public License" ?
[20:14] <DaveMorris> saivann: yes, also looking at the source files they have "either version 2 of the License, or  (at your option) any later version." so you'll need to add that in
[20:17] <saivann> DaveMorris : Is that OK? : http://upload.leservicetechnique.com/bugs/copyright
[20:18] <rzr> le sevice technique hehe
[20:18] <DaveMorris> line 24 has Library on it still
[20:19] <saivann> DaveMorris : Ok updated
[20:19] <DaveMorris> apart from that looks good to me
[20:20] <saivann> DaveMorris : Ok I test building with the rules file and I upload to REVU again, thanks for your assistance
[20:20] <saivann> rzr : leservicetechnique.com, it's because I give technical services to people with their computer :)
[20:21] <rzr> saivann: see #ubuntu-fr you've got a customer waiting :)
[20:28] <ScottK2> Any shell scripting experts handy (or even journeymen I suspect)?
[20:28] <ScottK2> I'm trying to package a daemon written in Python.
[20:29] <ScottK2> I've got a short shell script that is called by the init that fires it off.
[20:29] <ScottK2> I need to have it also make the pid file.
[20:29] <ScottK2> Any suggestions on an easy way to do that?
[20:29] <jdong> ScottK2: start-stop-daemon should have a flag for making a pid file on behalf of the daemon
[20:29] <saivann> DaveMorris : There's probably a syntax error in the rules file, maybe in the "and if" part because that doesn't build, do you see something? :if [ -e config.cache  ] ; then rm config.cache ; fi ; and if [ -e config.status  ] ; then rm config.status ; fi ;
[20:30] <ScottK2> jdong: It does, but it also describes that as a last resort.  I'm going to give that a try now.
[20:30] <DaveMorris> yeah the 2 if's should be on different lines without the and part
[20:30] <DaveMorris> I should of used a pastebin, would of been clearer
[20:30] <saivann> DaveMorris: Ok I'll test this
[20:31] <saivann> DaveMorris : If you prefer :) I'm still very a beginner with this :)
[20:32] <saivann> DaveMorris : It seems to work
[20:35] <saivann> DaveMorris : re-uploaded, waiting to see it in REVU
[20:35] <DaveMorris> yeah, it runs every 10 mins
[20:50] <saivann> DaveMorris : It's here now
[20:52] <asabil> hi all
[20:52] <asabil> anyone to advocate this please : http://revu.tauware.de/details.py?package=libgee ?
[20:55] <\sh> RainCT, I'm rewriting it from scratch...there is really something wrong with it
[20:57] <pochu> what is the command to know the ip of a webpage?
[20:58] <ion_> It’s most likely v4. ;-)
[20:58] <ion_> dig, host, getent hosts etc.
[20:58] <jelmer> 'evening
[20:58] <jelmer> is there documentation somewhere about how to merge changes from debian?
[20:59] <jelmer> in particular, how the changelog file
[21:01] <mok0> hey
[21:02] <cbx33> \sh, you looking after ubuntu-dev-tools?
[21:02] <mok0> cbx33: heh just having a problem with that
[21:02] <cbx33> if so I just added a new tool called pydep to my branch https://code.edge.launchpad.net/~petesavage/ubuntu-dev-tools/trunk
[21:02] <cbx33> mok0, with what?
[21:02] <pochu> ion_: thanks
[21:03] <\sh> cbx33, yepp
[21:03] <cbx33> \sh feel free to see if you like it and add it
[21:03] <cbx33> I'm sure RainCT will hack at it :p
[21:03] <mok0> If I say: pbuilder-dist hardy create is echoes the command line and says: command not found
[21:03] <\sh> mok0, yepp...working on it
[21:04] <mok0> \sh: great.
[21:04] <\sh> mok0, there are some strange problems...and I can't figure out why the sudo call doesn't work..
[21:04] <\sh> without all the crap around and the shell vars set it works
[21:04] <mok0> \sh: do you need sudo when it's building under your root?
[21:04] <\sh> mok0, as user you need sudo ... as root not ;)
[21:05] <cbx33> \sh it's not 100% reliable, but it's a good start if you need to package a python app and don't know its deps
[21:05] <mok0> \sh: root can't write in my home dir, it's on an NFS share
[21:05] <\sh> mok0, well, the problem of pbuilder
[21:05] <\sh> mok0, using sbuild for myself now :)
[21:05] <mok0> \sh: is that better?
[21:06] <\sh> mok0, well it's more like the buildds of ubuntu...
[21:07] <\sh> mok0, but it makes more sense when you have a local mirror...
[21:07] <mok0> \me is ignorant of buildds
[21:07]  * mok0 is ignorant of buildds
[21:08] <mok0> \sh: but I'd like to have one :-)
[21:10] <\sh> hmm...how do I check in a case loop against a value of a shell var ?
[21:10] <\sh> $FOO ) doesn't help
[21:10] <mok0> \sh: "$FOO")   ??
[21:11] <\sh> nope
[21:12] <RainCT> \sh: here $FOO) works
[21:12] <\sh> RainCT, even in a fcuntion with the case?
[21:12] <RainCT> \sh: moment, I'm testing..
[21:14] <RainCT> \sh: yes
[21:14] <RainCT> (tried with both bash and sh)
[21:14] <\sh> RainCT, try this: http://pastebin.ubuntu.com/3817/
[21:14] <RainCT> \sh: http://paste.ubuntu.com/3818/
[21:15] <RainCT> ok, moment
[21:15] <\sh> that's easy...this works ;)
[21:15] <RainCT> looks nice with functions :)
[21:15] <\sh> well, command line options will be dynamic ;)
[21:16] <\sh> tricky a bit
[21:16] <\sh> you see what I want to achieve?
[21:17] <\sh> I'm getting the releases from /usr/share/debootstrap/scripts/ and create a $RELEASES with "dapper|bla|foo|etc" and now I need the value of $RELEASES as check for check_commandline ;)
[21:18] <RainCT> I see :)
[21:18] <\sh> $RELEASES is available in check_commandline...but it's not parsed as value
[21:18] <RainCT> good idea
[21:19] <RainCT> \sh: ./test: 17: Syntax error: "(" unexpected :P
[21:19] <RainCT> \sh: in sh functions are just "blah()", not "function blah()"
[21:19] <\sh> RainCT, yeah
[21:20] <RainCT> ok.. now I don't get any output :P
[21:20] <RainCT> ah ok
[21:21] <\sh> let not defined
[21:21] <\sh> what's the correct syntax in dash for let?
[21:21] <RainCT> \sh: what does let do?
[21:21] <jdong> /bin/bash -c "let .... just kidding
[21:21] <\sh> RainCT, let is for arithmetic vars only
[21:21] <\sh> so all numbers ;)
[21:22] <RainCT> h
[21:22] <RainCT> *ah
[21:22] <RainCT> I'm checking https://wiki.ubuntu.com/DashAsBinSh/, I think there was something about let
[21:22] <\sh> well, the dash bash problem is not important ;) the case is more important ;)(
[21:23] <RainCT> right
[21:25] <torkel> leonel: https://launchpad.net/ubuntu/+source/postgresql-8.3/
[21:26] <leonel> torkel: Great !
[21:27] <\sh> RainCT, 		x=$(($x+1)) is the dash replacement for let x=$x+1
[21:29] <RainCT> \sh: I'm asking in #bash about it
[21:29] <\sh> RainCT, thx :)
[21:30] <RainCT> :(
[21:30] <RainCT> >> greycat: You can't.  Don't put code in variables.  Put code in code.
[21:31] <\sh> RainCT, the $RELEASES is dapper|asdasdkj
[21:31] <RainCT> >> SiegeX6: i think you can ugly hack it with eval
[21:31] <RainCT> breezy|dapper|edgy|etch|feisty|gutsy|hardy|hoary|hoary.buildd|lenny|potato|sarge|sarge.buildd|sarge.fakechroot|sid|warty|warty.buildd|woody|woody.buildd
[21:32] <\sh> well..tomorrow more...need to go...wife is at home
[21:32] <\sh> RainCT, or if you find a solution just mail me :) sh@sourcecode.de
[21:32] <RainCT> \sh_away: okay... cya :)
[21:38] <RainCT> cbx33: where have you put that pydep thing?
[21:38] <RainCT> I don't see it in http://codebrowse.launchpad.net/~petesavage/ubuntu-dev-tools/trunk/files
[21:49] <cbx33> it should be RainCT
[21:49] <cbx33> hang on
[21:50] <cbx33> RainCT, I was stoopid
[21:50] <cbx33> it is there now
[21:50] <cbx33> or will be in a few secs
[21:55] <DaveMorris> saivann: I've built your package and looked at it.  http://www.pastebin.ca/870195
[21:55] <mok0> DaveMorris: ... but you can comment, now
[21:56] <DaveMorris> can I?
[21:56] <mok0> Yes
[21:56] <cbx33> RainCT, it is there now
[21:56] <mok0> New feature on REVU
[21:56] <mok0> DaveMorris: try it!
[21:56]  * DaveMorris finds his password
[21:58] <DaveMorris> so I can
[21:58] <DaveMorris> when did the feature go live?
[21:59] <RAOF> While we're on the shell scripting, how do you actually set IFS to split on lines and nothing else?
[21:59] <blueyed> RAOF: IFS='<ENTER>'?
[21:59] <blueyed> while pressing enter for ENTER of course.
[22:00] <mok0> DaveMorris: a few days ago
[22:00] <RAOF> blueyed: Thanks.  I hadn't tried that particular permutation :)
[22:00] <mok0> DaveMorris: it was announced on ubuntu-motu ML
[22:01] <jdong> can I revu-whore? http://revu.tauware.de/details.py?package=clutch
[22:01] <DaveMorris> I'm not subscribe to that one, I best sign up on it
[22:04] <saivann> DaveMorris : Thanks for these relevant comments, I'll fix this too
[22:09] <DaveMorris> saivann: feel free to ask if your unsure as to how to fix those issues
[22:11] <saivann> DaveMorris : Great! In fact yes I would have a question, in which section of the rules file I should cp the man templates to the build directory?
[22:12] <saivann> s/man templates/man template/
[22:12] <DaveMorris> do you mean how do you install manpage ?
[22:14] <saivann> DaveMorris : I know that during the build process, compiled files go to a /tmp/buildd folder in the debian folder AND after this, these files are packaged as binary package. I need to know when, in the rules file, the manfile template should be copied..
[22:15] <DaveMorris> if you look at http://revu.tauware.de/revu1-incoming/opensg-0801101810/opensg-1.8.0/debian/ you'll see opensg-tools.manpages
[22:16] <DaveMorris> you'll need a file like that called simdock.manpages with the path to find the man page
[22:19] <saivann> DaveMorris : CDBS will automatically install that manpage?
[22:21] <DaveMorris> yes, you also need to create the manpage
[22:21] <saivann> opensg-tools.manpages specify this file : "fcdedit.1" but where is this file?
[22:23] <DaveMorris> it's created with a patch
[22:24] <jdong> c!
[22:25]  * DaveMorris wonders if anyone has 3/4 hrs to review his package. http://revu.tauware.de/details.py?package=opensg
[22:25] <saivann> DaveMorris : Ok I found the patch, this patch creates the man file template at the root of the package?
[22:27] <emgent> lol
[22:27] <DaveMorris> yeah, I use cdbs patches,  to create it for me
[22:27] <DaveMorris> but you can do it different ways
[22:30] <saivann> DaveMorris : All I need to do to use that patch system is to respect names in the patches folder and add this to the rules file? : include /usr/share/cdbs/1/rules/simple-patchsys.mk
[22:32] <DaveMorris> saivann: best way is to 1.) create your man file and make sure it works. 2.) incldue the line you mention in rules. 3.) in the root of your package do "cdbs-edit-patch 01-add-simdock-manpage.patch" This will give you a clean source package to create your patch in. 4.) copy your manpage in and exit the patch shell ( ^D I think)
[22:33] <DaveMorris> this will give you your patch in debian/patches then
[22:33] <saivann> DaveMorris : Wow.. I don't get how the man template finally get in the /usr/share/man folder
[22:33] <DaveMorris> cdbs does it for you with the help of the .manpages file
[22:34] <saivann> DaveMorris : Ok thanks, I copied your instructions and I'll explore this. If you're here in more than 1 hour, perhaps that I'll finished my work on this
[22:34] <DaveMorris> I've got to go now, but I check it tomorrow at work.
[22:47] <RAOF> saivann: More explicitly, cdbs always calls dh_installman, which looks at debian/manpages
[22:48] <RAOF> saivann: CDBS is only magic in that it calls a whole bunch of debhelper (dh_foo) scripts for you automatically.
[22:51] <saivann> RAOF : Thanks for that informations :) I need to learn more about these.
[22:51] <saivann> DaveMorris : Thanks for all the help you gave to me today, I'll continue my work on this
[23:29] <LaserJock> what would -dh_strip do?
[23:29] <LaserJock> I've not seen putting a - before a dh_*
[23:29] <LaserJock> is it just disabling it?
[23:30] <persia> LaserJock: Makes rules not exit when stripping fails.  Shouldn't be there, or we don't see bugs in dh_strip.
[23:30] <LaserJock> hmmpf
[23:31] <LaserJock> well, wine had .debs about 3x larger than it used to
[23:31] <LaserJock> it looks to me like the debugging symbols aren't being stripped
[23:32] <LaserJock> I found that dh_strip was changed to -dh_strip
[23:32] <LaserJock> with the following changelog entry:
[23:32] <LaserJock> * debian/rules: ignore dh_strip errors to fix FTBFS in buildds
[23:33] <LaserJock> so does that mean dh_strip was erroring out hence not stripping all the binaries?
[23:33] <RAOF> Sounds like a plausible hypothesis.
[23:39] <RainCT> good night
[23:39] <mcisbackuk> Evening all! Quick question on packaging if there's anyone to answer?
[23:41] <RainCT> Hi mcisbackuk
[23:41] <RainCT> !ask > mcisbackuk
[23:41] <mcisbackuk> RainCT: Hi
[23:42] <RainCT> !ask | mcisbackuk
[23:42] <ubotu> mcisbackuk: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
[23:42]  * RainCT goes to bed.. good night :)
[23:43] <mcisbackuk> OK...I was packaging scummvm from the latest upstream release, the sources are packaged and there didn't seem to be any problems, just wanted to know if I've done it right....I created the diff and interdiff, and I've uploaded them both to Launchpad, bug #183976. Is there anything else that needs to go on there?
[23:43] <ubotu> Launchpad bug 183976 in scummvm "new upstream version 0.11" [Undecided,Confirmed] https://launchpad.net/bugs/183976
[23:44] <persia> mcisbackuk: That's a well formed upgrade bug.
[23:44] <mcisbackuk> persia: What's that mean?
[23:45] <persia> mcisbackuk: You have done what you need.  You are now waiting for a sponsor to review.
[23:46] <mcisbackuk> persia: Wow, I actually contributed! So there's no further steps for me until it's been reviewed? That's me happy :)
[23:49] <mcisbackuk> Well its thanks to you guys that I've learnt a few things to do with packaging, so for that thank you to the guys who helped its much appreciated :) Hope to be working with you all more often :)
[23:58] <rexbron> persia, I have been reading http://wiki.debian.org/RpathIssue and I believe that the current use of
[23:58] <rexbron> rpath in openlibs is acceptable
[23:59] <rexbron> as it is only between libraries in the same source package and they are installed to a non-standard directory