[00:07] <Laney> soren: I will forward it to debian after your review, ok?
[01:08] <TheMuso> NCommander: Re darkroom, was there no newer version in Debian to merge with?
[01:09] <NCommander> TheMuso, not even packaged in Debian
[01:09] <TheMuso> ncOh ok.
[01:09] <TheMuso> NCommander: oh ok
[01:15] <persia> Three cheers for UEHS!
[01:15] <wgrant> What has it done now?
[01:15] <persia> Well, it no longer has darkroom for one.
[01:17] <NCommander> THat was FAST
[01:18]  * NCommander only uploaded less than 15 minutes ago
[01:18] <wgrant> Hmm, the watch wizard doesn't seem to be working at all.
[01:19] <persia> popcon count seems missing too.
[01:20] <wgrant> Right, Ubuntu popcon is old.
[01:20] <wgrant> Debian popcon gives a more machine-friendly database format.
[01:23] <persia> Is that something easy to work around, or is it better to complain to the popcon people?
[01:23] <wgrant> Oh.
[01:23] <wgrant> They've published the script to create the DB from the raw results now.
[01:30] <persia> Does anyone know if there's a schroot command to delete a schroot entirely, or do I need to manually remove it from the conf, and lvremove the volume?
[01:31] <wgrant> persia: I think you need to do it manually.
[01:32] <persia> pity.  Thanks.
[01:44] <NCommander> I need a chemist, anyone around?
[01:49] <coppro> no chemistry skill here, why?
[01:55] <NCommander> gamgi got uploaded.
[01:55] <NCommander> I ran the tutorial which was a good enough for me to upload it (since my results looked right)
[02:04] <wgrant> persia: We should now have popcon on UEHS, although some packages seem to lack data...
[02:14] <nxvl> NCommander: would you like to give me a hand with this -> http://launchpadlibrarian.net/19444715/buildlog_ubuntu-jaunty-i386.ssmtp_2.62-2ubuntu1_FAILEDTOBUILD.txt.gz
[02:14] <NCommander> Sure, I'd be glad to
[02:15]  * nxvl HUGS NCommander 
[02:15] <NCommander> nxvl, the compiler isn't doing something kosher
[02:16] <cody-somerville> "ssmtp.c:489: error: 'else' without a previous 'if'"
[02:16] <NCommander> nxvl, this is universe, right?
[02:16] <NCommander> cody-somerville, or the source
[02:16] <NCommander> probably a combination of the two
[02:16] <nxvl> right
[02:16] <nxvl> the funny thing is that it seems that the problem is only 386
[02:16] <NCommander> nxvl, did it go boom on all architectures, or just i386
[02:16] <NCommander> oh
[02:17] <nxvl> let me confirm
[02:18] <nxvl> no, it hasn't build yet on any other arch
[02:18] <NCommander> testing on amd64
[02:18] <NCommander> And it went perl shaped
[02:18] <NCommander> ...
[02:18] <NCommander> pear
[02:18] <Yasumoto> NCommander: nice
[02:18] <nxvl> that replies the why i've just get the i386 message
[02:21] <nxvl> NCommander: i think i get the error
[02:21] <NCommander> well
[02:21] <NCommander> Its kinda obvious why it exploded
[02:21]  * NCommander bets there is a bad patch causing this
[02:21] <nxvl> heh
[02:21] <nxvl> almost
[02:22] <NCommander> Yup
[02:22] <NCommander> ahaha
[02:22] <NCommander> Take a look at the series file
[02:22] <nxvl> found it?
[02:22] <NCommander> There's your bug
[02:22] <nxvl> heh
[02:22] <nxvl> yes
[02:22] <nxvl> you've got it
[02:22] <nxvl> :D
[02:22] <NCommander> want me to upload?
[02:22] <nxvl> NCommander: no, i already build it
[02:23] <nxvl> but thank you
[02:23] <NCommander> aw
[02:23] <NCommander> -ENOUPLOAD
[02:23]  * NCommander is shot
[02:23] <NCommander> nxvl, you don't know anyone who runs KDE3, do you?
[02:25] <nxvl> nop
[02:25] <nxvl> i don't
[02:25] <NCommander> ugh
[02:26] <NCommander> When doing UEHS, do we want to update even if Debian is carrying the package? (debian hasn't uploaded anything due to lenny I bet)
[02:26] <NCommander> actually, its a QA upload
[02:26] <NCommander> so
[02:28] <wgrant> We deliberately list QA packages as well.
[02:40]  * NCommander looks for someone to do a qa uploads in debian
[02:44] <coppro> time to install wincrawl on my VM!
[02:44] <NCommander> lol
[02:46]  * coppro has no KVM sadly: (
[02:47] <coppro> what perms does /dev/kqemu need again?
[02:47] <coppro> ah, hmm
[02:48] <coppro> is there any way to give me group access without having to log out?
[03:16] <ethana2> Alright, so say there's an app out there with GPL source code, and I want to turn it into a 32 bit Ubuntu .deb
[03:17] <ethana2> ...is there documentation out there that goes through that process in a fairly simple and straightforward manner?
[03:18] <ethana2> ok, this looks like it   https://wiki.ubuntu.com/PackagingGuide/Complete
[03:22] <ethana2> Ok, I've made a working directory, I've got the guide up here, fetching latest stable stellarium source code..
[03:23] <ajmitch> if it's the stellarium that's already in universe, you may want to look at the section about updating packages
[03:23] <ethana2> Well I'd like to skip the politics
[03:24] <ethana2> ..build it myself and put it on getdeb.net
[03:24] <ethana2> ..and maybe use that knowledge to contribute to ubuntu in the future
[03:24] <ethana2> ...is there any reason I as an end user should bother with pbuilder?
[03:25] <ajmitch> because it builds packages in a clean environment, so you don't miss dependencies, etc
[03:25] <wgrant> GetDeb is not the solution.
[03:25] <wgrant> If you just want it on GetDeb, you probably won't get any help here.
[03:25] <ethana2> Hmmmmmm
[03:25] <ethana2> Very well
[03:25] <ethana2> I want to get it into 8.10 backports
[03:25] <wgrant> Then get it into 9.04, not GetDeb.
[03:26] <ethana2> ah, so it has to get into 9.04 before it can get into 8.10 backports?
[03:26] <wgrant> Yes.
[03:26] <ethana2> interesting
[03:26] <ethana2> ....do I need to worry about debian?
[03:26] <ethana2> or is 9.04 as far up as I need go?
[03:27] <wgrant> You would ideally approach Debian about it first.
[03:27] <wgrant> The Debian maintainer may well have plans to update it already.
[03:27] <wgrant> And duplication of work is bad.
[03:27] <ethana2> ah
[03:27] <ethana2> ...how would I go about doing that?
[03:28] <ajmitch> there's a bug filed about it on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504329
[03:28] <ethana2> ah, well that's encouraging
[03:29] <ajmitch> so he should at least know about the new release now, though that bug is less than a week old
[03:31] <ethana2> ...are they usually pretty good about handling those upgrades quickly?
[03:32] <ajmitch> depends on the developer :)
[03:34] <ethana2> Does debian have an automated system with all their upstream software for .tar.gz and release note transfers?
[03:35] <ajmitch> there's a semi-automated system for updating a package, called uupdate. I suspect the packaging guide will mention that
[03:36] <ajmitch> the developer has to run it themselves, it's just a tool to help them when they come to do the work
[03:36] <ethana2> How would I go about telling whether OpenOffice 3 is in Jaunty?
[03:36] <ajmitch> packages.ubuntu.com may be up to date
[03:37] <ajmitch> I doubt it's been uploaded yet
[03:39] <ethana2> Hmm..  so if I wanted to just take a .tar.gz and turn it into a .deb for my own use and perhaps a few close friends..
[03:40] <ethana2> is that a pretty straightforward process?  I think last time I tried I ran into a problem with checkinstall
[03:40] <ajmitch> because checkinstall is very much the wrong way to go about it
[03:40] <ethana2> ah
[03:40] <ethana2> What's the Right Way?
[03:40] <ajmitch> packaging guide that you linked above
[03:40] <ajmitch> yes, it's more involved
[03:41] <ethana2> It seems to involve creating patch files...
[03:41] <ajmitch> only if you need to patch it
[03:41] <ethana2> oh, ok
[03:44]  * ethana2 is install dh_make
[03:45] <ethana2> If it's one app, does that mean it's 'single binary'?
[03:47] <TheMuso> ethana2: Depends on the package.
[03:47] <TheMuso> ethana2: If there is a library in the app, it should be in its own package.
[03:47] <ethana2> It seems the tarball isn't named right or something
[03:48] <ethana2> Could not find stellarium_0.10.0.orig.tar.gz
[03:48] <TheMuso> ethana2: The tarball is not correctly named.
[03:49] <TheMuso> Thats why it can't find it.
[03:49] <ethana2> ..so I'll just change it to what it said it wanted
[03:49] <TheMuso> ethana2: Unless its .tar.bz2, in which case you will have to bzip2 -d, and gzip the resulting tar file, then rename it.
[03:52] <ethana2> that's odd, I don't use trash, like, ever...  but now I need to restore a file from it
[03:52] <ethana2> ..aaand I'm not seeing an option in the context menu when i right click on the file I need to restore
[03:53]  * NCommander is watching the world dumbest on TV
[03:53] <ethana2> ah there we go, cut and paste
[03:54] <ethana2> so it doesn't create it because it's already there, but it doesn't like me when it's not
[03:54] <ethana2> Skipping creating ../stellarium_0.10.0.orig.tar.gz because it already exists.  Currently there is no top level Makefile. This may require additional tuning.  You already have a debian/ subdirectory in the source tree.
[03:54] <ethana2> dh_make will not try to overwrite anything.
[03:55] <wgrant> Why are you repackaging it from scratch?
[03:55] <ethana2> oh.   Only run dh_make once. If you run it again after you do it the first time, it will not work properly.
[03:55] <ethana2> wgrant: should I be doing it a different way?
[03:55] <wgrant> ethana2: Yes... there is existing packaging, so use that.
[03:55] <ethana2> I really don't know what I'm doing, just trying to follow this guide I found
[03:55] <ethana2> the latest version?
[03:56] <ethana2> ohh
[03:56] <ethana2> I think I /may/ get what you're saying
[03:56] <ethana2> existing /debian information for the .deb
[03:56] <ethana2> Am I understanding you correctly?
[03:57] <wgrant> The debian/ in the old source package, yes.
[03:57] <ethana2> so apt-get source stellarium
[03:57] <ethana2> ..and yank the /debian and slap it into the new version?
[03:57] <wgrant> man uupdate
[03:57] <ethana2> ..modify a text file or two, make sure the directory is named right
[03:57] <ethana2> k
[03:58] <ethana2> No manual entry for uupdate
[03:58] <wgrant> Do you have it installed?
[03:59] <ethana2> The man pages for that?  Evidently not..
[03:59] <ethana2> E: Couldn't find package uupdate
[03:59] <wgrant> command-not-found should tell you where it is. I guess uscan.
[04:00] <TheMuso> its in devscripts
[04:00] <ethana2> $ install devscripts
[04:00] <ethana2> it's working..
[04:00] <ethana2> ok, got 'em, attempting to get man page
[04:03] <ethana2> Ok, so instead of packaging from scratch, I'm taking the source for ubuntu's version and using uupdate to take the current source..
[04:03] <ethana2> and create a .deb using information from the ubuntu source?
[04:06] <ethana2> ..ok, I started over by removing the directory from the .tar.gz, and renamed the .tar.gz as it seemed it wanted me to
[04:06] <ethana2> when I untared it, it made a directory with the old name it didn't like, do I just rename that too?
[04:07] <ethana2> ok, it appears not
[04:09] <ethana2> Packaging from scratch is the only thing I see in this documentation
[04:11] <ethana2> Oh, I think I see what's going on, but I'm not sure...  I'll just see how this goes
[04:11] <ScottK> ethana2: If you're just starting, it can be good to work on bugs and updates before starting from scratch packaging.
[04:12] <ScottK> Making a new package is one of the harder jobs there is.
[04:12] <ethana2> But I'm not making a new one, I'm taking an old one and switching the old source code out, right?
[04:13] <ScottK> I see.  I hadn't read all the scrollback.
[04:15] <ethana2> ohhhhhh, the patch /is/ the .deb information
[04:18] <ethana2> Hmm, can one list recursively only to one directory nesting?
[04:19] <ethana2> Like, I want to see a directory and all the directories in it, but I don't want to see what's in /those/
[04:19] <henrik-kabelkaos> how do i go about getting stuff into intrepid backports? it's for a wifi driver module.
[04:19] <ethana2> it has to get into jaunty first
[04:20] <ethana2> ..and it's advised that it gets into debian before that
[04:20] <ethana2> ..if it's a wifi driver, that's kernel stuff with serious potential for breakage
[04:22] <ethana2> http://pastebin.com/d5c73a2ef   ...I'm not quite sure what I do now..
[04:23] <henrik-kabelkaos> can it be in a standalone package for jaunty or does it need to go into one of the *modules* packages?
[04:23] <wgrant> henrik-kabelkaos: Sounds like you want linux-backports-modules, and to ask #ubuntu-kernel.
[04:24] <NCommander> StevenK, ping
[04:24] <henrik-kabelkaos> wgrant: thanks
[04:26] <ethana2> so dh-make automatically applies the .diff.gz from the ubuntu source?
[04:28] <Yasumoto> How do I unpack a .deb file? (To make sure I've packaged everything correctly)
[04:29] <emgent> moin
[04:29] <ethana2> Yasumoto: 'extract here'?
[04:29] <ethana2> Yasumoto: do you mean from the CLI or just in general?
[04:30] <fabrice_sp> Yasumoto: you can also run lintian, that will check some 'big' errors
[04:30] <fabrice_sp> (but not only that)
[04:31] <ethana2> http://pastebin.com/d3858edb4
[04:31] <ethana2> Am I doing it right?
[04:32] <Yasumoto> ethana2: from CLI
[04:32] <ethana2> actually, that may not be enough info.
[04:32] <Yasumoto> ethana2: yeah, to extract it into my current directory
[04:32] <ethana2> Yasumoto: oh.
[04:32] <Yasumoto> fabrice_sp: ah, cool, I'll do that too
[04:32] <ScottK> Yasumoto: A .deb is an AR compressed archive.  Just use your favorite archiving tool (I like ark) to rip it open and have a look.
[04:32] <Yasumoto> ScottK: oh, cool. thanks, will do
[04:34] <ethana2> http://pastebin.com/d320f6f4e   there, that should be enough to determine..
[04:34] <ethana2> What should I do now?
[04:34] <ethana2> the guide doesn't say where to run dh_make from
[04:35] <ethana2> It seems they're only dealing with one version of 'hello
[04:35] <fabrice_sp> you have to run dh_make from inside the stellarium-0.9.1 directory
[04:35] <fabrice_sp> if you want to package from scratch
[04:36] <fabrice_sp> because if a debian directory already exists, dh_amke will gives you an error
[04:36] <fabrice_sp> s/dh_amke/dh_make
[04:37] <ethana2> So I run dh_make from the old source directory?
[04:37] <ethana2> not the new source directory?
[04:37]  * ethana2 scratches head
[04:37] <fabrice_sp> in the pastebin, I don't see a new directory?!
[04:37] <superm1> Yasumoto, additionally if you have dpkg-dev installed, file-roller (the default archive manager in ubuntu) learns how to open it nicely
[04:38] <ethana2> it's the 0.10 one
[04:38] <ethana2> stellarium-0.10.0
[04:38] <ethana2> Do I have these directories arranged incorrectly?
[04:39] <fabrice_sp> my fault: you're right
[04:39] <ethana2> oh, ok
[04:39] <fabrice_sp> in general, the new and old version are at the same level :-)
[04:39] <ethana2> so I run dh_make from inside the stellarium-0.10.0 directory, right?
[04:39] <ethana2> oh, ok
[04:39]  * ethana2 adjusts
[04:40] <ethana2> ethan@home:~/source/stellarium$ list
[04:40] <ethana2> stellarium-0.10.0  stellarium_0.10.0.orig.tar.gz  stellarium-0.9.1  stellarium_0.9.1-2.diff.gz  stellarium_0.9.1-2.dsc  stellarium_0.9.1.orig.tar.gz
[04:40] <ethana2> Is that better?
[04:40] <fabrice_sp> yes :-)
[04:40] <ethana2> ok sweet
[04:40] <fabrice_sp> so, do you have a debian directory inside 0.10.0 directory?
[04:40] <nellery> should new packages in debian be submitted as syncs?
[04:41] <ethana2> I don't think so
[04:41] <emgent> \sh: danke for nUbuntu :)
[04:41] <ethana2> dh_make is supposed to make the /debian directory, right?
[04:41] <ethana2> "Now we need to create the customary debian directory where all the packaging information is stored, allowing us to separate the packaging files from the application source files. We will let dh_make do the work for us: "
[04:42] <nhandler> nellery: Since we are still pre-Debian Import Freeze, new packages in Debian should automatically be synced into Ubuntu
[04:42] <fabrice_sp> ethana2: yes, but as there is an existing package, you can copy the one from old version
[04:42] <nellery> nhandler: thanks
[04:42] <ethana2> fabrice_sp: do I need to change anything in it at all?
[04:42] <fabrice_sp> ethana2: and review the content (for example, existing patches)
[04:43] <ethana2> existing patches?
[04:43] <fabrice_sp> add the new version in the changelog, at least :-)
[04:43] <ethana2> So first I copy the /debian directory over..  /me copies
[04:43] <fabrice_sp> ethana2: in this case, do you see the patches directory inside debian one?
[04:44] <ethana2> yeah
[04:44] <fabrice_sp> this are the patches
[04:44] <fabrice_sp> :-)
[04:44] <ethana2> Ok, so what do I do with them?
[04:44] <ethana2> remove them?
[04:45] <fabrice_sp> by the way, @all: do you think we should continue ethana2 and myself in a private channel?
[04:45] <ethana2> if you would be so kind, i think that'd be good
[04:45] <fabrice_sp> ethana2: nop: you should have a look at each one, to see if they still apply
[04:45] <ethana2> ...sounds like that involves knowing what I'm doing
[04:46] <ethana2> but I think all fixes have been applied by upstream
[04:46] <ethana2> ..so I'm inclined to think that they don't
[04:47] <fabrice_sp> (following in a private channel)
[05:05] <superm1> congrats NCommander
[05:05] <NCommander> thank you
[05:05] <superm1> what's your first crack going to be?
[05:06] <jdong> superm1: he's already on backporters. brace for impact
[05:06] <TheMuso> superm1: Don't you mean, what was it?
[05:07] <superm1> TheMuso, ah well i've not watched jaunty-changes, perhaps there already is some crack from him :)
[05:07] <superm1> jdong, ah, between the two of you intrepid will stay interesting enough then
[05:07] <emgent> heya superm1 TheMuso NCommander
[05:08] <NCommander> jdong, oh, I forgot about those momentary
[05:08]  * NCommander rolls up his selves
[05:08]  * NCommander gains the EVIL glint in his eye
[05:09] <jdong> NCommander: for source backports let's keep a cross-ACK policy
[05:09] <jdong> i.e. a backporter other than he who creates debdiff should ACK :)
[05:09] <NCommander> Agreed
[05:09] <jdong> ScottK: ^^
[05:09]  * NCommander blows the dust off his chroots
[05:10] <NCommander> jdong, just to clarify, I shouldn't upload to backports without the second ack? (since it will get stuck in unapproved)
[05:10] <ScottK> jdong: Ahhh, I've just been doing it, should I stop?
[05:10] <jdong> ScottK: you're okay :)
[05:11] <jdong> ScottK: I think it's not a bad idea from a QA standpoint to ahve a second eye on it
[05:12] <ScottK> Generally if it's not a package I know well it'll be someone else's debdiff I'm reviewing before upload.
[05:13] <jdong> yeah in the case of a backporter reviewing someone else's debdiff I think one suffices
[05:13] <jdong> but I think for self-made debdiffs there might be cases of "creator's blindness" where a fresh pair of skeptical eyes would be helpful
[05:14] <superm1> now what y'all really need is the ability to ack them out of unapproved rather than having to bug archive-admins to do it
[05:14] <jdong> superm1: eep I'd rather not :D
[05:14] <superm1> too much responsibility for your actions? :P
[05:14] <jdong> superm1: there's a cozy warm feeling of having an archive deity touch it last :)
[05:15] <NCommander> jdong, so I ACK, then mark In Progress, and subscribe the archive team?
[05:15] <ScottK> jdong: If it's at all difficult, I can see that, but (fore example) I've backported clamav to Dapper a bunch of times and I've got a standard packaging patch I use.
[05:15] <jdong> NCommander: yep for normal backports
[05:15] <ScottK> I don't think it's critical that I get that kind of thing reviewed.
[05:15] <jdong> ScottK: yeah, I think on second thoughts I'll write it down as an "In general, it is recommended to..." popint
[05:15] <jdong> not a requirement
[05:16] <superm1> Well that's weird, i've got a package that will build fine in sbuild but pbuilder complains this: "  pbuilder-satisfydepends-dummy: Depends: libconfuse-dev which is a virtual package.
[05:16] <superm1> "
[05:16] <ScottK> I'm fine with that.
[05:17] <ScottK> superm1: Either you didn't enable universe or switch to the classic pbuilder-satisfydepends
[05:17] <jdong> superm1: yeah pbuilder-satisfydepends-dummy is fast but not an accurate simulation of sbuild's satisfydepends
[05:17] <superm1> oh that's it - i didn't enable universe, you're right.  this was a fresh pbuilder and I completely forgot you need to go through the extra args to do so
[05:18] <jdong> universe not being enabled is a more common reason though :)
[05:18] <superm1> thanks ScottK
[05:18] <jdong> I think I've seen a single case in my time where sbuild and pbuilder-satisfydeps behaved significantly differently
[05:18] <ScottK> Cool.  The new lintian 2.0 has a 'certainty' field in it's results so it'll tell you how certain it is of the issue.
[05:19] <superm1> i much prefer to use sbuild, but i dont always have access to my machine that has lvm setup
[05:19] <jdong> sweet
[05:19]  * NCommander gets by w/ pbuilder
[05:22] <NCommander> ScottK & jdong: https://bugs.edge.launchpad.net/hardy-backports/+bug/240136 - please review
[05:23] <NCommander> ScottK, & jdong https://bugs.edge.launchpad.net/hardy-backports/+bug/241560
[05:24] <jdong> NCommander: do you have any hunches why compat was set at 7?
[05:24] <NCommander> jdong, not a clue, nothing in rules used seven
[05:24] <jdong> NCommander: okay
[05:26] <jdong> NCommander: commented on both
[05:26] <NCommander> thank you
[05:27] <jdong> sure thing :)
[05:27]  * NCommander is doing all the easy backports
[05:27] <NCommander> the mail already starting to pile up
[05:27] <lifeless> win 40
[05:28] <lifeless> bah
[05:29] <NCommander> jdong, here too
[05:29] <NCommander> https://bugs.edge.launchpad.net/hardy-backports/+bug/267391
[05:31] <jdong> NCommander: comment added
[05:32] <NCommander> Thank you
[05:32] <NCommander> jdong, also, your two cents here (if its worth backporting samba)
[05:32] <jdong> NCommander: no
[05:32] <jdong> NCommander: too much responsibility
[05:32] <jdong> unmaintainable
[05:33] <NCommander> fair enough
[05:33]  * NCommander kills that backport
[05:35] <ScottK> NCommander: You might consider samba4 backport to Hardy along with openchange.  They're both alpha's so it's not like peole should actually expect them to work.
[05:35] <jdong> oh do they install side-by-side?
[05:35] <ScottK> AFAIK, yes.
[05:35] <NCommander> jdong, the samba backport was for three
[05:35] <NCommander> Four is fessible
[05:36] <ScottK> You'd want to check.
[05:36] <jdong> NCommander: 4 is mmm-okay-ish iff it installs side by side
[05:36] <jdong> NCommander: though knowing the firefox gutsy fun, be ready to revisit in a year :)
[05:36] <ScottK> NCommander: Does fessible mean you'd admit to doing it if questioned?
[05:37] <NCommander> I'll do the actual backport, it probably will require a source backport to fly
[05:38] <NCommander> Ah the sound of backports being done
[05:38]  * NCommander will be happy when the queue is under 50 again
[05:39] <StevenK> Argh
[05:39] <NCommander> :-)
[05:39] <NCommander> Oh yeah
[05:39] <StevenK> What are you guys doing?
[05:39]  * ScottK filed the first 4 intrepid backports.
[05:39] <NCommander> Now the archive team is also going to get spammed bombed
[05:39] <NCommander> Sweet
[05:39] <NCommander> StevenK, they made me a backporter
[05:40] <NCommander> Run.
[05:40] <jdong> NCommander: making friends on day 1 of the job :)
[05:40] <NCommander> Run fast.
[05:40] <jdong> lol
[05:40] <ScottK> NCommander: "They" didn't make you a backporter.  jdong did.  Let's get this clear.
[05:41] <NCommander> StevenK, it could be worse. I could be on SRU
[05:41] <StevenK> Hah
[05:42] <StevenK> You don't randoming just say 'do it' on the SRU team at the consistent volume that the crackports team does
[05:42] <jdong> ScottK: uh oh something about that is going to come back to haunt me :)
[05:43] <ScottK> Just want to make sure we're clear where the credit/blame goes, whichever it turns out to be.
[05:44] <NCommander> jdong, I need to respin the amsn patch
[05:44] <NCommander> jdong, same changes, it just happens intrepid has an upgrade since I made that one
[05:44] <jdong> NCommander: okay
[05:44] <StevenK> Hm
[05:44] <StevenK> Apparently, NCommander is an MOTU
[05:45] <ScottK> StevenK: Yes.  He doesn't waste time.  Just happened today.
[05:46]  * NCommander nods
[05:49] <Hobbsee> !crackports | jdong
[05:49] <NCommander> O_O;
[05:50] <jdong> Hobbsee: lol :)
[05:50] <Hobbsee> !jdong
 jdong: yes, but you're FULL OF CRACK!
[05:50] <Hobbsee> Q.E.D.
[05:50] <jdong> Hobbsee: you didn't even need a tracker bug in launchpad to add that factoid?!?!
[05:50] <jdong> *ducks*
[05:50] <Hobbsee> no :P
[05:50] <NCommander> brb
[05:50] <ScottK> Hobbsee: For a second there I thought you kicked yourself for being abusive.
[05:51] <Hobbsee> ScottK: no, i hit ctrl+q, instead of shift+q.
[05:51] <Hobbsee> which closed the channel.
[05:51] <Hobbsee> which means the list is now out of order :(
[05:51] <ScottK> Sure, but my way was funnier.
[05:51]  * Hobbsee glares at the shift key for trying to hide
[05:51] <Hobbsee> :P
[05:52] <ScottK> Don't glare too hard or it will melt and smell bad.
[05:53] <NCommander> jdong, http://paste.ubuntu.com/68717/ - amsn debdiff
[05:54] <didrocks> morning o/
[05:54] <NCommander> jdong, if there is nothing wrong, I'm ready to upload it (I confirmed installation, and that I can sign on to MSN)
[05:55] <jdong> NCommander: looks good to me
[05:55] <NCommander> and away it goes
[05:55] <wgrant> NCommander: You're not a core-dev, so can't upload it...
[05:56] <jdong> wgrant: and that's no longer true as I found.
[05:56] <wgrant> jdong: Oh, how odd.
[05:56] <wgrant> Wouldn't Launchpad changelogs be nice
[05:56] <jdong> wgrant: https://edge.launchpad.net/ubuntu/gutsy/+source/firefox-3.0/3.0.3+build1+nobinonly-0ubuntu0.8.04.1~gutsy1
[05:56] <wgrant> jdong: That doesn't tell me who signed it.
[05:56] <NCommander> wgrant, I would probably guess backports is now following proposed w.r..t to permissions
[05:56] <soren> Laney: They already have a bug about it with a patch.. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358637
[05:56] <superm1> jdong, isn't that because in gutsy the firefox-3 source package didn't exist?
[05:57] <NCommander> wgrant, well, I'll know in a moment if this rejects
[05:57] <lifeless> Hobbsee: getting soft in your old age?
[05:57] <wgrant> superm1: Previously only core-devs could upload any sourceful backports.
[05:57] <superm1> if say you try to upload it to hardy, I think it should fail
[05:57]  * Hobbsee whacks lifeless' ankles with her cane.
[05:57]  * NCommander hears Hobbsee's creak
[05:57] <ScottK> superm1: It did previously exist though.
[05:58] <StevenK> NCommander: s/'s//
[05:58] <superm1> oh so it did, but it was in universe in gutsy looking at  https://edge.launchpad.net/ubuntu/+source/firefox-3.0
[05:59] <jdong> superm1: yeah, idn if I can upload across the universe barrier
[05:59] <NCommander> ScottK, can I ACK a clamav backport? (that package is your domain)
[05:59] <soren> wgrant: There's clearly a bit of terminology, I'm unfamiliar with... What does "sourceful" mean in this contexxt?
[05:59] <wgrant> Erm, isn't ClamAV backported in -security anyway?
[06:00] <NCommander> wgrant, I lost track at this point
[06:00] <jdong> NCommander: I'd rather have ScottK deal with all things clamav :)
[06:00] <ScottK> NCommander: No.  We need to deal with rdepends crap on that.
[06:01] <wgrant> soren: Backports are normally performed by archive admins, without any real upload. The correct term was probably "upload with source changes", but mrh. I must have seen sourceful used to mean that somewhere.. hm.
[06:01] <ScottK> wgrant: We got 0.92.1 into -security via backports.  About to start over with 0.94.1.
[06:01] <wgrant> ScottK: How many rdepends need a rebuild each time?
[06:01] <NCommander> wgrant, I just my accepted into UNAPPROVED email
[06:02] <wgrant> NCommander: You just a verb.
[06:02] <ScottK> wgrant: It's worse.  They generally need patching.  It's only a handful, but you've got to deal with it.
[06:02] <NCommander> ^got
[06:02] <wgrant> ScottK: Oh, sounds lovely!
[06:02] <soren> wgrant: That's how I've seen it used as well. I just didn't understand how launchpad would tell the difference between an upload with source changes and one without. I thought the ones without at least had a new changelog entry.
[06:02] <NCommander> ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/286337 I assume we're not crazy enough to actually try this
[06:03] <wgrant> soren: The ones without changes aren't uploaded through any normal means. They get injected straight into Soyuz.
[06:03] <jdong> NCommander: didn't I say no to one of those already?
[06:03] <ScottK> NCommander: I'm guessing not.
[06:03] <jdong> NCommander: but the answer is absolutely not.
[06:03] <NCommander> jdong, nope
[06:03] <wgrant> NCommander: Ewww.
[06:03] <wgrant> KILL
[06:03]  * NCommander kills it
[06:03] <didrocks> ScottK: I am maybe not very awake at this early hour, but I do not see any update for pbuilder, devscript nor debootstrap from intrepid-backports. (I am on the archive.ubuntu.com mirror). Am I dreaming?
[06:04] <Hobbsee> didrocks: they're probably not built yet?
[06:04] <soren> wgrant: I see. I've never actually used backports :/ They *do* have a new changelog entry, don't they?
[06:04] <wgrant> soren: They do.
[06:04] <didrocks> Hobbsee: I guess the contrary from ScottK mail
[06:04] <wgrant> But "with source changes" in this case means more than the changelog.
[06:04] <soren> wgrant: I understand.
[06:04] <ScottK> didrocks: They've been backported, but are still waiting to build.  They're behind the queue for the big autosync run going on right now.
[06:05] <soren> wgrant: I just wasn't sure how launchpad would tell the difference. I get it now.
[06:05] <ScottK> Hobbsee is correct.
[06:05] <didrocks> ScottK: ok, that's was what I assumed. Thanks ;)
[06:06] <ScottK> I missed my goal.  I was trying to make a new package in an hour.
[06:06] <ScottK> It took 1 hour, 11 minutes.
[06:06] <ScottK> I hadn't banked on having to write two man pages.
[06:06] <didrocks> ScottK: yes, but we disturbed you, so, you have an excuse :)
[06:06]  * ScottK is always disturbed.
[06:07] <didrocks> I can imagine, same here with the French loco-team tasks…
[06:10] <ScottK> jdong: I think 'backports' is a pocket, not a repository (re; your wiki change)
[06:11]  * wgrant agrees with ScottK.
[06:12] <jdong> ScottK: gah silly technicalities.
[06:12] <jdong> please correct *runs off to bed*
[06:19]  * NCommander cuts the backport queues down the size
[06:19] <NCommander> Litterially
[06:19] <Yasumoto> so when merging, the only things I add in to the changelog
[06:20] <Yasumoto> should be what I'm keeping in from ubuntu, right?
[06:20] <Yasumoto> if I'm replacing ubuntu changes with debian changes, I don't mention it?
[06:21] <StevenK> Yasumoto: Yes. You mention it in a "Ubuntu changes dropped:" section
[06:21] <ScottK> jdong: More changes than I have patience for.  I did drop Feisty and Add Intrepid.
[06:22] <Yasumoto> StevenK: thanks
[06:35] <NCommander> ScottK, how do you want to handle the bazaar backport?
[06:37] <ScottK> NCommander: The way I want to handle it is let jdong do it.
[06:37] <ScottK> He said he would.
[06:37] <ScottK> NCommander: So I'd ask him.
[06:37] <NCommander> ScottK, you mind checking and testing the fluxbox backport for me? I can't run it on this machine ATM
[06:38] <jdong> ScottK: NCommander: I do have that in mind, I was waiting to check on the bzr-svn situation and possibly stick a new version of that into jaunty and handle 1.8 and its stack at the same time
[06:40] <ScottK> NCommander: I'm heading to bed, so not today.
[06:41] <NCommander> ScottK, aw :-/
[06:43] <ethana2> Ok, I've got stellarium 0.10.0 to compile on Ubuntu 8.10 with a HUGE amount of help from fabrice_sp
[06:43] <ethana2> ...but I don't have a gpg key and it can't sign the .deb
[06:43] <ethana2> so it won't make it
[06:43] <ethana2> How do I solve this problem?
[06:43] <ethana2> gpg: skipped "Ethan Anderson <ethan@home>": secret key not available
[06:43] <ethana2> gpg: [stdin]: clearsign failed: secret key not available
[06:45] <ethana2> I don't know how to get a key, I'm thinking that may be a complicated process?
[06:46] <stefanlsd> ethana2: https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[06:46] <stefanlsd> its not really that complex
[06:46] <ethana2> thanks
[06:47] <csilk> Can't you get a gpg key?
[06:48] <csilk> nope
[06:48] <csilk> quite simple
[06:48] <csilk> ahh, just about to find you that link
[06:52] <ethana2> Ok, do I need someone else to 'trust' me or something?
[06:52] <stefanlsd> ethana2: naa. as long as u trust yourself :)
[06:52]  * ethana2 assumes not
[06:52] <ethana2> k
[06:52] <ethana2> well like
[06:52] <ethana2> I'd like to redistribute this .deb to close friends
[06:53] <ethana2> is that going to cause problems on the software level?
[06:53]  * ethana2 assumes not
[06:54]  * ethana2 compiles again
[06:55] <dholbach> good morning
[06:55] <NCommander> morning dholbach
[06:57] <dholbach> hi NCommander
[06:57] <stefanlsd> hihi!
[06:58] <NCommander> dholbach, how goes it?
[06:58] <dholbach> hi stefanlsd
[06:58] <dholbach> NCommander: good good - I'm slowly waking up
[06:58] <NCommander> dholbach, I can't sleep :-/
[06:59] <stefanlsd> thats what upload privs does!
[06:59] <NCommander> Well, its something else
[06:59]  * NCommander is right now putting a second dent in the backports build log
[06:59] <NCommander> WIth the added bonus now that the archive team is getting spam bombed from the ACK emails <g>
[06:59] <StevenK> Argh
[06:59] <StevenK> NCommander: I will get youi
[07:00] <StevenK> s/i$//
[07:00] <NCommander> StevenK, and I can't stop fixing your FTBFSes ;-)
[07:00] <NCommander> s/can't/can/g
[07:04] <dholbach> congratulations NCommander!
[07:04] <NCommander> dholbach, yup :-)
[07:04]  * NCommander is already using his powers for "good"
[07:04] <NCommander> Although StevenK may disagree
[07:05] <jdong> they need to make bigger unicode quotes for that ;-)
[07:05]  * NCommander wonders how load the other archive admins will bitch
[07:08] <ethana2> my poor machine has had to compile this so many times..
[07:08] <ethana2> I wish it would throw those gpg errors /before/ running make
[07:08] <NCommander> ethana2, use debsign or debuild -nc
[07:08] <ethana2> debuild -nc?
[07:09] <ethana2> does that mean it doesn't sign it?
[07:09] <NCommander> no
[07:09] <soren> ethana2: Just use debsign?
[07:09] <NCommander> just don't clean/rebuild
[07:09] <ethana2> I'm running debuild -b
[07:09] <jdong> ethana2: -nc means don't clean
[07:09] <ethana2> debuild uses debsign
[07:09] <ethana2> signing is worthless to me
[07:09] <ethana2> completely
[07:09] <jdong> ethana2: use only if you're confident that you haven't touched the source too much
[07:09] <ethana2> i haven't touched it at all
[07:09] <jdong> ethana2: probably -uc -us is what you want for don't sign :)
[07:10] <ethana2> i'm not competent enough to touch source
[07:10]  * ethana2 reads man page
[07:11] <ethana2> debuild -i -us -uc -b  ?
[07:11] <ethana2> This man page doesn't seem to explain all those....  which is odd
[07:12] <ethana2> What are the -uc and -us parameters?
[07:13] <ethana2> Well, I seem to have two .deb files
[07:13] <soren> -uc means "don't sign the changes file".
[07:13] <ethana2> app_version_i386.deb and app-data_version_all.deb
[07:13] <soren> -us means "don't sign the .dsc file"
[07:13] <ethana2> Are binary files signed?
[07:14] <soren> no.
[07:14] <ethana2> ohhhhh
[07:14] <ethana2> ok
[07:14] <soren> The corresponding .changes file is, though.
[07:14] <ethana2> oh, I see, stellarium-data isn't code
[07:14] <ethana2> ..thus it's for all architectures
[07:14] <soren> ...but if you're not uploading it to build service, it's not something you need to worry about at all.
[07:14] <ethana2> right
[07:28] <ethana2> it runs, but slowly
[07:29] <ethana2> it has dependencies that it doesn't use at all
[07:29] <ethana2> ..and I think gcc gave me a quick compile instead of a quick binary
[07:31] <iulian> Morning.
[07:43] <Yasumoto> So I'll bug RAOF when he gets on, but if anyone wants to initially glance over my merge for miro, I'd be stoked :) https://bugs.launchpad.net/ubuntu/+source/miro/+bug/294459
[07:47] <slytherin> Yasumoto: Isn't that a weird description of bug? The "I am merging" part
[07:50] <Yasumoto> meh, yeah
[07:50] <Yasumoto> That's what RAOF suggested
[07:50] <Yasumoto> it's more typical to be third-person though?
[07:51] <Yasumoto> I think it was mainly because it already had someone 'assigned' to it
[07:55] <NCommander> geser, ok, ready to upload ilohamail. I think all the "easy" merges/syncs you have are done
[07:56] <Yasumoto> slytherin: is this better? "Please merge miro 1.2.8-1 from Debian unstable"
[08:01] <LucidFox> Do I have to use my legal name for Ubuntu contribution?
[08:03] <NCommander> LucidFox, you mean as a donation?
[08:04] <LucidFox> No, package work
[08:04] <LucidFox> and development
[08:04]  * NCommander knows the offical Debian policy is that you must at least be confirmed by your name, but your db entry doesn't require it
[08:04] <NCommander> LucidFox, I take it you don't like your legal name?
[08:06] <LucidFox> I've recently come to identify myself as non-gendered, and I'd like to use a female identity for Launchpad to counterbalance my real-life male identity. However, it's probably a silly request.
[08:06] <slytherin> Yasumoto: The description you specified is good. And then simply assign the bug to yourself if you are still working on it.
[08:07] <stefanlsd> LucidFox: heh. i think if thats the name u want to contribute under, and you stick to it, its ok
[08:14] <Yasumoto> slytherin: nope, attached both debdiffs, so just waiting for some more eyes to check it. thanks a bunch :)
[08:20] <elmargol> Any ideas? http://elmargol.soup.io/post/6713919/Bild
[09:02] <james_w> NCommander: hey, have you seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466373 ?
[09:03] <james_w> NCommander: it's RC, so it would be great to fix
[09:04] <NCommander> Nope, totally missed that
[09:04] <NCommander> That was actually on my "do tommorow" list
[09:04] <NCommander> james_w, your not a DD, are you?
[09:04] <james_w> nope
[09:05] <james_w> there's a patch on there, but it sounds like you founded more needs to be done
[09:18] <Laney> soren: AFAICS that bug is about a different library, libiptc - and it was closed anyway
[09:49] <directhex> LucidFox, i think as long as you have a GPG key that people trust is "you", minor issues of identity are pretty irrelevant
[09:51] <LucidFox> All right - I was going to add the female name to the key anyway, even if I wasn't going to use it for Ubuntu
[09:53] <soren> Laney: Well, feel free to forward the patch if you want. I'm not going to stop you :)
[09:53] <soren> Laney: I'll look at it later today, probably. Thanks for looking into it!
[09:59] <Laney> \o/
[10:02] <sistpoty|work> hi folks
[10:04] <Laney> hi sistpoty|work
[10:04] <sistpoty|work> hi Laney
[10:05]  * sebner hugs sistpoty|work =)
[10:05]  * sistpoty|work hugs sebner
[10:31] <slytherin> Can anyone having access to updated Debian unstable please check rdepends or reverse-build-depends for libjaxp1.2-java?
[10:53] <kgoetz> hi all. I'm wondering if theres a tool to check that a package is buildable on an architecture before trying to compile it? I'm thinking along the lines of 'check if package builds on amd64. no, its i386 only. skip it'
[10:54] <azeem> kgoetz: apt-cache showsrc <package> | grep Arch
[10:54] <kgoetz> azeem: thanks.
[12:16] <persia> Anyone from MOTU SRU about?  I want to fix bug #294914 in intrepid, but I'mo currently blocked on fixing it in jaunty by debootstrap, and would rather not wait.  Would t be acceptable to push intrepid in advance of jaunty in this case?
[13:06] <karooga> hi, anyone got some time to look at http://revu.ubuntuwire.com/details.py?package=pyephem   It's a package providing scientific-grade astronomical computations for the Python.
[13:08] <persia> karooga, You've had someone test the binary now?
[13:08] <persia> karooga, Since you're not doing anything special, if your watch file works, you don't need get-orig-source.  Test with uscan --force-download
[13:09] <karooga> Not yet.  I'm still running hardy and this is packaged for jaunty.
[13:10] <persia> You don't need the licenses in python-pyephem.docs, or PKG-INFO.  INSTALL isn't useful because you've changed that to be `apt-get install python-pyephem`.
[13:13] <persia> I suspect your copyright file is wrong, as there's usually a reason to ship both GPL and LGPL in a tarball.  Check the source files carefully.  Also, I'd recommend reorganising it to match http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html or http://wiki.debian.org/Proposals/CopyrightFormat (your choice)
[13:30] <directhex> hm. do packages in sid but not jaunty need explicit sync requests? aren't they usually auto-synced at some stage?
[13:35] <persia> The new packages sync usually happens after the buildds have calmed down a bit.  No need to be explicit except for stuff in contrib or non-free.
[13:36] <karooga> ﻿persia: sorry, my connection went down.
[13:36] <karooga> ﻿persia: did i miss anything else? you were talking about copyright problems.
[13:36] <persia> Some packages will fail to sync for various reasons, and need to be handled manually, but in these cases, the archive-admins don't have any special ability to make it happen, so it's more just an upload request.
[13:36] <persia> karooga, I haven't said anything about your package since pointing at the recommended debian/copyright formats.
[13:37] <karooga> persia: cool :-)
[13:37] <persia> I'm not much of a python person, so I tend to avoid trying to review python packages, as I'm not confident I'll get it right.
[13:37] <persia> Some stuff isn't python-specific, so for that, I'm happy to provide recommendations.
[13:38] <directhex> persia, anyone comes to you with a mono app, slap 'em and tell them to talk to pkg-mono-apps@alioth
[13:39] <karooga> persia:  thanks, i'm just trying to get it right
[13:39] <persia> directhex, Nobody comes to me with anything.  People put stuff on REVU.  If you want more mono apps, I'd recommend looking over the selection there, and commenting on anything you find interesting.
[13:40] <persia> As much as I believe packages will do better in Debian, I'm not going to block uploads to Ubuntu just because there is a willing team in Debian : I think it's better to get the package published *somewhere*, and use existing coordination methods to handle packages that aren't in both Debian and Ubuntu.
[13:41]  * persia misses an active DCT
[13:42] <directhex> i count one package on revu i know is CLI, and it's got a rather lower version number than i have here in pkg-cli-apps svn
[13:42] <directhex> norsetto was giving feedback on it. i wonder if our debian guy made any similar mistakes
[13:43] <directhex> hm, i think the Vcs lines are wrong
[13:45] <persia> directhex, In that case, you probably want to leave a comment saying that there's a newer version on alioth, and suggest collaboration.
[14:14] <slayton> are there any plans to backport synergy1.31-4ubuntu2 to hardy?
[14:17] <ScottK> slayton: Look for a bug about it in the hardy-backports project on Launchpad.
[14:17] <ScottK> If not, you can request it.
[14:18] <ScottK> !backports | slayton
[14:18] <slayton> ScottK, sorry I should have checked ther first
[14:18] <slayton> still trying to wake up
[14:20] <ScottK> persia: We're all the DCT now.
[14:28] <persia> ScottK, Well, I guess.  Doesn't seem to be reducing the Ubuntu-local package count much.
[14:29] <ScottK> persia: In the areas I work in in Debian I see many more Ubuntu people more active than they were a year ago.  So if it's not reducing, maybe just staying even is progress.
[14:30] <persia> ScottK, I see about the same thing : I think we're currently keeping up, but there's the legacy of the first couple years that needs help.
[14:31] <ScottK> Fundamentally, absent someone who cares it won't get into Debian because no one will sign up to maintain it.
[14:32] <ScottK> So we have to ask ourselves if we want packages no one will care for in Ubuntu?
[14:32] <persia> Right.  That's why I miss DCT.  Could be a collaborative team maintaining these in Debian, and perhaps filing the RoM requests when necessary, rather than waiting for things to bitrot into cruft.
[14:34] <ScottK> Well bitrot in both distros or one, I don't see a huge difference.
[14:35]  * ScottK summons the cruft clearing spirit of NCommander to expunge the bit-rottenness from our archive ...
[14:38] <sistpoty|work> what was that url to the list of ubuntu-only packages again?
[14:38] <persia> Well, more that there'd be a group of people explicitly looking at them.
[14:38] <persia> sistpoty|work, http://qa.ubuntuwire.com/multidistrotools/all.html has a list.
[14:39] <sistpoty|work> thanks persia
[14:39] <RainCT> NCommander: FTBFS master, FYI, koverartist doesn't build :P
[14:39] <persia> sistpoty|work, unless you're explicitly looking for the list, UEHS is probably a better target right now.
[14:40] <sistpoty|work> persia: actually, I'm just looking if there's anything I might want to take over maintenance :)
[14:40] <persia> Then mdt is probably the best list :)
[14:41] <DktrKranz> I'm going to have a look at ubuntu local packages and see which ones are untouched since gutsy, just to have a look at older packages which have a greater chance to be obsolete
[14:42]  * persia doesn't think age correlates with obsolesence well
[14:43] <DktrKranz> there are several packages uploaded and left outside alone
[14:43] <DktrKranz> those need love
[14:44] <james_w> I could perhaps come up with a list of likely targets
[14:44]  * ScottK suggests http://qa.ubuntuwire.com/multidistrotools/all.html#sameversionbutlocalinB for people who would write bug reports for Debian.
[14:56] <ScottK> jdong: Closing bugs in changelogs against backports tasks works now.
[15:29] <jdong> ScottK: cool good to know
[15:30] <ScottK> jdong: Here's a particularly 'extensive' example: Bug #278075
[16:30] <amikrop> Hello. Where can I find the Ubuntu Packaging Guide, but in one page?
[16:31] <chrisccoulson> https://wiki.ubuntu.com/PackagingGuide/Complete
[16:31] <RainCT> !packaging
[16:38] <webtech_m33> Hello, i am looking for help on getting clamav updated on my Hardy 8.04LTS box, right now it's 92.1 but the newest one out is .94.1, i see it's in the intrepid rep, but i don't know how to get it into my hardy box.. any suggestions?
[16:40] <jdong> webtech_m33: ScottK is usually the one who handles backports of clamav
[16:40] <persia> webtech_m33, You can watch backports for it, or wait for more tasting.  ClamAV is fairly closely watched in Ubuntu, and mostly kept up-to-date, so you should have some sort of update (either the newer version or patches to provide current protection) before too long.
[16:40] <ScottK> webtech_m33: What are you using clamav with?
[16:40] <persia> jdong, You're an SRU person.  What do you think about pushing the intrepid fix for bug #295914 before it gets fixed in jaunty?
[16:41] <persia> Err. 294914
[16:41] <webtech_m33> ScottK: spam filter
[16:41] <jdong> bug 294914
[16:41] <ScottK> webtech_m33: Which package?
[16:41] <webtech_m33> ScottK: clamav (0.92.1~dfsg2-1.1ubuntu0.2)
[16:42] <jdong> persia: looking. btw, stupid question, when does auto-sync from Debian start?
[16:42] <persia> jdong, two days ago
[16:42] <webtech_m33> Scott: this is what freshclam says: WARNING: Your ClamAV installation is OUTDATED!
[16:42] <webtech_m33> WARNING: Local version: 0.92.1 Recommended version: 0.94.1
[16:42] <ScottK> webtech_m33: We don't quite have 0.94.1 in Jaunty yet.  We have the RC.  That should get resolved over the weekend and then I'll start working on backporting.
[16:43] <ScottK> webtech_m33: Our 0.92.1 is patched with the major security fixes from later releases, so it's not a significant risk to be patient.
[16:43] <webtech_m33> ScottK: you want some help testing the backport verison?
[16:44] <ScottK> webtech_m33: Yes.  Come around early next week.
[16:44] <webtech_m33> Scottk: sounds like a plan to me
[16:44] <jcastro> RainCT: 15 minutes until your session!
[16:46] <amikrop> chrisccoulson: thanks :-)
[16:46] <RainCT> jcastro: yep, thanks for the reminder :)
[16:46] <jdong> ScottK: do we really need to keep the big urgent warning from freshclam?
[16:46] <ScottK> jdong: It's upstream's warning.
[16:46] <jdong> ScottK: I'm assuming there's cases where new signatures won't work with old(er) engines?
[16:46] <ScottK> Yes.
[16:47] <jdong> ScottK: and/or upstream will be really mad at us if we suppressed the warning too :)
[16:47] <ScottK> I'm pretty sure they wouldn't be happy.
[16:51]  * jdong refreshes prevu for jaunty-awareness
[16:54] <ScottK> jdong: Upstream on clamav just asked the Debian Maintainer to review their proposed API changes for the next release.  That's, AFAIK, never happened before.  I don't want to upset the applecart just now.
[17:00] <csilk> I'm just setting up pbuilder for intrepid on another one of my machines and I get
[17:00] <csilk> W: Failure trying to run: chroot /var/cache/pbuilder/build/9924/. mount -t proc proc /proc
[17:00] <csilk> pbuilder: debootstrap failed
[17:00] <csilk> ?
[17:12] <slytherin> persia: about the bug, wasn't gnome-network-admin removal intentional?
[17:13] <persia> slytherin, For Ubuntu Desktop, yes.  For Ubuntu Studio, no.  In fact, the seed history reports it was added, but the string got dropped along the way.  Ubuntu Studio doesn't have Network Manager.
[17:13] <slytherin> oh, then it is problematic
[17:15] <persia> Yeah, and I can't update the ubuntustudio-meta source for jaunty yet, although I'll probably take a look at debootstrap to be able to do so if someone else doesn't in the next couple days.
[17:18] <slytherin> persia: I have jaunty pbuilder set up. If you want I can try that today. But AFAIK, -meta packages are supposed to be updated via seeds right?
[17:20] <persia> slytherin, Oh, the seeds are updated.  Don't worry about it.
[17:20] <slytherin> Ok.
[17:20] <slytherin> Got to go now. See you all later.
[17:45] <jdong> sigh torrent clients are like delusional ex'es.
[17:45] <jdong> almost a week after I've stopped seeding iptables is still recording a few hits per day to my former torrent port
[18:01] <bddebian> Heya gang
[18:01] <sebner> RainCT: ok, with me there were 3 people :P
[18:01] <sebner> hi bddebian
[18:01] <RainCT> sebner: yeah lol
[18:01] <gregor> is it possible, that you put metacafe-dl,youtube-dl,nicovideo-dl and all others "video downloaders" into one package?
[18:01] <RainCT> sebner: it was an intensive session, though ;P
[18:01] <sebner> heh
[18:02] <bddebian> Heya sebner
[18:12] <gregor> http://dad.dunnewind.net/main.php
[18:12] <gregor> Warning: filesize(): stat failed for /srv/web/dad.dunnewind.net//crash/crash_4.0-6.3-1ubuntu2.patch in /srv/web/dad.dunnewind.net/code/index.template on line 104 Warning: filesize(): stat failed for /srv/web/dad.dunnewind.net//pyenchant/pyenchant_1.4.2-2ubuntu1.patch in /srv/web/dad.dunnewind.net/code/index.template on line 104
[18:16] <persia> gregor, Thanks for the report.  In the meantime, you might try MoM.
[18:16] <persia> If the error persists, it's worth filing a bug on LP.
[18:16] <gregor> what ist MoM?
[18:17] <persia> Merge-o-Matic : merges.ubuntu.com
[18:18] <persia> DaD fulfills the same rough function as MoM.  MoM has a richer dataset to collect the updates, and DaD has a better interface, and both have slightly different sets of bugs in the merging code, although most of the egregious ones have been ironed out in each case.
[18:19] <persia> Which you use is mostly a matter of taste.  There's been some effort to create something with the DaD frontend and the MoM backend, and improved merging logic that includes the best bits from each, but it only exists at bzr branches right now, and remains unfinished.
[18:19] <gregor> http://merges.ubuntu.com/main.html needs some html-cleanup btw. ;)
[18:20] <persia> That's part of why the DaD front-end is considered better than the MoM frontend :)
[18:43] <jdong> whee, new prevu :)
[18:43] <jdong> now with 75% more crack
[18:46] <ScottK-laptop> jdong: Did you integrate checkinstall yet?
[18:47] <jdong> ScottK-laptop: lol no :)
[18:47] <jdong> ScottK-laptop: apart from the usual adding jaunty support, I did add a new prevu-nomangle command that skips bumping down the version number, i.e. it's now usable as a pdebuild-like incantation.
[18:48] <ScottK-laptop> I see.  I have see references to using it outside the backports context, so I'd expect that's going to be used.
[18:49] <jdong> yeah, I've seen enough requests for this that I felt it should be implemented. It's also good for things like local kernel backports, where the buildscripts don't cope well with weirdness like ~ and words in the version
[19:03] <Laney> pochu: Someone took a look at fet before I got the change (without asking me, tsk tsk) - bug #294381
[19:03] <Laney> s/change/chance/
[19:06] <persia> Laney, Do you disagree with their recommendation?
[19:06] <Laney> persia: No, it looks correct
[19:07] <persia> Then they're just saving you work.  Plenty of other stuff to do :)
[19:08] <Laney> but of course - I just thought that the procedure was to ping the last uploader
[19:08] <persia> Not reliably.
[19:08] <Laney> If I was actually bothered I'd make the effort to contact them
[19:08] <Laney> but I tend to disagree with that procedure anyway
[19:08] <persia> If you expect to spend significant time on it, and want to declare you're working on it, open a bug in LP and assign yourself.
[19:09] <persia> Anyone who ignores that deserves complaint, as they clearly didn't bother to check the open bugs against the package when doing the merge.
[19:09] <persia> Most packages don't need so much time, so it's more of a who-gets-to-it-first.
[19:09] <persia> The last uploader generally has more ideas about a package than some random person, so they are a good person to ask questions.
[19:10] <Laney> I read "starting to work on the merge, you should check with the previous maintainer and/or the previous uploader, if they intend to work on the merge themselves." as being stronger than it actually is, then
[19:10] <persia> Also, if nobody else does it, the last uploader is expected to perform the merge, so when the archive first opens, we generally just do our own, unless we need something as a dependency or otherwise *really* want to do it.
[19:11] <Laney> before starting, that is
[19:11] <persia> At this point in the cycle, it's considered polite to do that, and not doing it is mildly rude.  Come December, it's more of a free-for-all.
[19:12] <Laney> Right, that's how I worked for Intrepid
[19:12] <persia> That said, if you're merging something that you've not previously uploaded, unless you're *really* sure, take extra care.
[19:12] <persia> Right, although for Intrepid, it was s/December/June/
[19:12] <Laney> of course
[19:13] <Laney> Well, the good news for fet is that it can be a sync again since Debian took the patch I forwarded to them :)
[19:13] <persia> Anyway, those who want to do uploads and don't have merges pending would do better to look at UEHS or harvest, rather than chasing others merges.
[19:14] <Laney> One of my first contributions comes full circle
[19:14] <Yasumoto> persia: what's UEHS?
[19:14] <Laney> must dash anyway, I'll be back later
[19:14] <persia> Yasumoto, http://qa.ubuntuwire.com/uehs
[19:15] <persia> Check out the list of packages not in sync with upstream : they would all benefit from a look, and probably a pull of the new upstream.
[19:15] <persia> Some have other outstanding bugs, which might have patches worth applying.
[19:16] <Yasumoto> persia: oh, cool
[19:16] <Yasumoto> thanks :)
[19:17] <persia> Yasumoto, Thanks for looking.  Personally, I think those merges are at least as important as the Debian merges, but few people actually check that.
[19:20] <Yasumoto> persia: it seems like we'd want most of these updated in debian first though, right?
[19:26] <gouki> Hi everyone. I FINALLY built something that works, and I uploaded to REVU. However, after finding a typo, I tried uploading again, but can't because the package was already uploaded.
[19:26] <persia> Yasumoto, Well, maybe.  Most of them aren't in Debian.  Those that are in Debian are orphaned.  Updates for the orphaned ones might be appreciated by the QA team (and adoptions would certainly be appreciated), but they aren't likely to be updated with the current freeze.
[19:27] <gouki> How can I force the upload or delete my previous package?
[19:27] <quadrispro> RainCT, hi!
[19:27] <persia> gouki, remove the .upload file.
[19:28] <gouki> OK persia.
[19:29] <DktrKranz> gouki, or use dput -f
[19:30] <gouki> DktrKranz, ok! Thank you.
[19:30] <DktrKranz> you're welcome
[19:31] <RainCT> quadrispro: hi
[19:32] <quadrispro> RainCT, I've just uploaded to REVU a fixed version of installation-report-generator
[19:32] <quadrispro> http://revu.ubuntuwire.com/details.py?package=installation-report-generator
[19:33] <Yasumoto> persia: ah, I see
[19:34] <RainCT> quadrispro: great, I'll have a look at it
[19:34] <quadrispro> RainCT, thank you
[19:34] <Yasumoto> persia: thanks
[19:34] <Schwitzd> hi all!
[19:35] <Schwitzd> ScottK: hallo :D
[19:36] <Schwitzd> ScottK: can you please look this backport? https://bugs.launchpad.net/hardy-backports/+bug/294180
[19:36] <RainCT> \o/ we are being invaded by italians    :)
[19:36] <quadrispro> lol
[19:37] <quadrispro> RainCT, he isn't italian
[19:37] <gouki> Can a package be deleted from REVU?
[19:37] <DktrKranz> RainCT, too late... we own you already
[19:37] <quadrispro> isn't true Schwitzd ? :D
[19:37] <persia> gouki, Yes, but usually they are just archived, unless there's an overriding reason to delete them.
[19:37] <jdong> whatever happened to "don't judge a nick by its TLD"?
[19:37] <jdong> or however that old saying went
[19:38] <Schwitzd> quadrispro: :D
[19:38] <RainCT> jdong: I judge them by the channel list in /whois :D
[19:38] <DktrKranz> jdong, its TLD and its surname are indicative ;)
[19:38] <DktrKranz> *his
[19:38] <gouki> persia, I was asking because I uploaded a package that I learned yesterday can't be included anywhere because of its license.
[19:38] <gouki> I already commented saying not to bother looking at that package.
[19:38] <RainCT> gouki: URL?
[19:39] <persia> Ah, so it really can't even be included on REVU :)  Which package?  I'll kill it.
[19:39]  * RainCT leaves it for persia :)
[19:39]  * persia leaves it to RainCT, who can probably kill it faster
[19:39]  * persia types too slowly :)
[19:39] <gouki> RainCT, http://revu.ubuntuwire.com/details.py?upid=3836
[19:40] <persia> RainCT, Where's my nuke button?
[19:40] <RainCT> persia: it's in the list of archived packages, only
[19:40] <joaopinto> regarding REVU,   	 festor90@gmail.com has vanished from internet for a couple of months
[19:40] <gouki> And, BTW, I just uploaded my first package, so if any kind soul wants to take a look: http://revu.ubuntuwire.com/details.py?upid=3863
[19:40] <ScottK> Schwitzd: Looking
[19:41] <Yasumoto> gouki: ouch, man :( licensing for the loss..
[19:41] <persia> RainCT, Be nice to have on the package page, if the package was already archived.
[19:41] <gouki> Yasumoto, yeah :S
[19:41] <RainCT> persia: yep, I'll add it to the fast links at the top-right
[19:41] <joaopinto> gouki, you don't need usr/sbin on debian/dirs :P
[19:42] <gouki> joaopinto, thank you :) Will fix it right now.
[19:42] <RainCT> gouki: nuked and deleted :)
[19:42] <gouki> RainCT, thank you :)
[19:43] <joaopinto> not sure that debian/copyright is acceptable, you just trimmed down the usual GPL description to a 2 lines reference
[19:43] <pochu> Laney: thanks, acked
[19:43] <ScottK> Schwitzd: Approved.  It still needs to be manually backported by an archive-admin.  Would you please edit the bug to include the exact version you tested.
[19:43] <gouki> joaopinto, I wasn't sure of what part of the license I should paste.
[19:43] <gouki> joaopinto, what's the normal procedure on that part?
[19:43] <RainCT> gouki: the two first stanzas of the header (and the third one, if you want) + the "you can find this in.. on Debian systems"
[19:44] <joaopinto> gouki, and there is something wrong with your debian/docs :P
[19:44] <gouki> RainCT, OK. I'll change this right now.
[19:44] <gouki> joaopinto, not a suprise :P What's wrong?
[19:45] <persia> gouki, http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html or http://wiki.debian.org/Proposals/CopyrightFormat (your choice)
[19:45] <Schwitzd> ScottK: tks, i to immidiatly
[19:47] <joaopinto> personal comment, what an useless package :P
[19:47] <gouki> lolol
[19:47] <gouki> Indeed!
[19:47] <gouki> Heheh
[19:48] <joaopinto> gouki, I would replace that lengthy debhelper debian/rules with a 5 lines CDBS rules, but that's just me
[19:48] <Schwitzd> ScottK: done :D
[19:48] <persia> Um, there's already a package in the archive that does that.  Also does crashes for ProDOS, Amiga, etc.
[19:48] <gouki> joaopinto, you got me lost there :S Any pointers?
[19:48] <persia> Considering the wide number of use cases for such a thing, do we need two?
[19:49] <ScottK> Schwitzd: OK.  Now it's a matter of waiting for an archive admin.
[19:49] <RainCT> How many bsod programs are there?
[19:49]  * RainCT has written one too.. https://launchpad.net/bsod XD
[19:50] <Schwitzd> ScottK: tnk a lot ;)
[19:50] <persia> Hundreds, but I only know of one in the archive (although I've not played with it in months, and have forgotten the name)
[19:50] <persia> It was good because it supported *lots* of different operating systems, so you could pick your crash, or get a random one.
[19:51] <persia> Given that this one can only do windows, it just seems less good.
[19:51] <joaopinto> gouki, in my opinion a shorter debian/rules is easier to review, you can achieve that with CDBS, https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
[19:52] <gouki> Well, I only packaged it to have some feedback (and I did get some). So feel free to ignore it :)
[19:52] <RainCT> yep. mine is customizable through text files and command line options :P
[19:53] <gouki> Well, can I still upload it with changes made so you guys take a look at it?
[19:53] <gouki> Just not the CDBS ones, as I still have to read on that.
[19:54] <persia> gouki, The other alternative if you want a short debian/rules (which is often easier to maintain) is to use the features of debhelper 7.  Most of the guides are for debhelper 5.
[19:55] <gouki> persia, OK, I'll look into it.
[20:11] <DRebellion> What is the current Standards-Version?
[20:11] <RainCT> DRebellion: 3.8.0
[20:11] <DRebellion> RainCT, thanks ;)
[20:14] <iulian> Well, the current one is 3.8.0.1, some people use it and some don't. As far as I know it's better to use 3.8.0 instead of 3.8.0.1 for now.
[20:14] <RainCT> persia: there's now a "nuke" link on the details page of archived packages (and details.py shows proper error messages -ie, with page header and footer- for wrong links) :)
[20:16] <persia> RainCT, Wow!  That was fast.  Thank you.
[20:18] <gregor> youtube-dl, nicovideo-dl, metacafe-dl and all the others "video downloaders"... please package them to one package/programm, easyer install and only one command, to get videos from different sites.
[20:19] <persia> gregor, The issue is that they all have different upstreams, with different release cycles, etc.
[20:19] <persia> Perhaps creating a package that depends on all of them, and integrates well with one or more of the front-ends would be a useful way to meet your goal?
[20:20] <sebner> persia: /me is curious. how could this be done? repack all sources into 1 tarball and then package it with black magic?
[20:20] <persia> sebner, Um, no.  That's not how it's done.
[20:20] <persia> That's a recipe for disaster.
[20:20] <sebner> persia: meta package, I see
[20:20] <persia> Create a new package.  Depend on the individual packages.  Add some glue code to make it do the right thing.
[20:21] <ScottK> persia: Just because it's a recipe for disaster really has little bearing on if someone's done it that way or not.  ;-)
[20:21] <persia> I don't think there's enough of a reason for a meta-package, because the command-lines are all different.  Better to include a wrapper script, and maybe some viewer integration so you pass it a URL, or a search string, or something, and it does it's magic (using the individual downloaders).
[20:22] <sebner> persia: I see. thank you :)
[20:22] <persia> ScottK, Whether someone has done it has no relation to how it is done.  While I admit to there being many correct ways to do things, that's not one of them.
[20:22] <sebner> ScottK: like *matix? ^^
[20:23] <ScottK> persia: Agreed.
[20:23] <ScottK> sebner: No.  That's worse.  That's just idiocy.
[20:23] <persia> Some people choose to use checkinstall, for example.
[20:23] <persia> That's also not how it's done.
[20:23] <sebner> heh
[20:24] <superm1> so given flash is in the partner component now, i wonder if it's more worthwhile to nuke the flashplugin-installer package from multiverse for jaunty and push to have partner get enabled by that FF thing
[20:24] <superm1> asac, what do you think about that?
[20:25] <sebner> superm1: our flash installer package will fetch the official one from the partner archive
[20:25] <sebner> he has holidays btw ^^
[20:25] <superm1> sebner, it does?
[20:25] <persia> superm1, That's unfortunate for derivatives (as opposed to flavours).
[20:25] <sebner> superm1: it will
[20:25] <superm1> sebner, i didn't think a deb's postinst could install another deb
[20:25] <superm1> persia, why so?
[20:25] <persia> a deb postinst can do anything root can do.  It shouldn't install another deb.
[20:26] <sebner> superm1: I don't know how it will work but that's the plan
[20:26] <persia> superm1, because it's not clear that e.g. Mint can use partner.
[20:26] <sebner> wb Daviey
[20:26] <sebner> wb DktrKranz
[20:26] <sebner> arg
[20:27] <DktrKranz> sebner, just pressed wrong button
[20:27] <DktrKranz> but thanks ;)
[20:27] <superm1> persia, are you sure there are licensing guidelines that go with using partner though?  I've never been aware of any EULA that has to be accepted to use the repository itself
[20:27] <superm1> sebner, is there a spec about this?
[20:27] <sebner> DktrKranz: I used to do the same at my beginning xchat time ^ ^
[20:28] <sebner> superm1: I don't really know, I'm also not involved. I'm just telling you the same what asac told me
[20:29] <persia> superm1, I may be wrong, but my understanding was that it was a resource provided for Ubuntu users, rather than anyone.  That said, I've been avoiding partner since before it was "commercial", so I may not be the best person to ask.
[20:32] <superm1> sebner, ah i was thinking you were.  Well if asac has a plan for it, i'm sure this will get a more thorough discussion at UDS including the technical difficulties to overcome if it really does need to grab the deb in the postinst.  I'd think probably what the implementation would really look like was apturl temporarily fetching from the partner repo instead of using the flashplugin-installer, but we'll see what really happens
[20:32] <sebner> superm1: yep
[20:34] <superm1> persia, well regarding avoiding partner, there's not much there anyhow, and i expect most of what is there would require a license key or EULA that is part of the application or packaging to use.
[20:36] <persia> superm1, Well, maybe.  I wouldn't be that surprised if it contained various free binary stuff that some vendor didn't want to package, and for which nobody volunteered to write a free installer wrapper.
[20:36] <persia> (where "free" is "gratis" rather than "libre")
[20:38] <superm1> i personally prefer a deb that is maintained by canonical employees on partner over a "wrapper/installer" deb that we maintain in multiverse.  at least debs that are being kept on partner will track all files as part of the package rather than doing activities in the postinst to put them in various places on your system
[20:41] <superm1> oh this is interesting, i didn't realize panda software had an AV client for linux being kept there.  ScottK were you aware that Clam AV had closed source competition? :)
[20:42] <sebner> ScottK is our AV hero =)
[20:42] <ScottK> superm1: Yes.  There's quite a bit of it.
[20:42] <superm1> ScottK, other than panda, what else?
[20:43] <geser> does fprot still have a linux version?
[20:43] <ScottK> I think avg has something, maybe trendmicro.  I don't recall for sure. fprot too.  If you look in the amavisd-new default config files/docs they tell you how to wire a pile of them into amavid-new
[20:43] <persia> superm1, Hrm.  I guess I see your point, and I'd agree Ubuntu users would be better served by dropping flashplugin-installer.  I'm just not sure how this affects MEPIS or Mint, but I suppose that's their problem, and they could maintain it from the last published source, or pull from upstream directly.
[20:44] <geser> and avast has a linux version of their virus scanner too
[20:44] <coppro> why should we drop flashplugin-installer?
[20:45] <superm1> coppro, i'm saying in favor of the flash plugin deb that's kept on the canonical partner repository.
[20:45] <coppro> oh
[20:45] <coppro> as long as I can install flash, I'm happy
[20:45] <superm1> coppro, eg http://archive.canonical.com/pool/partner/a/adobe-flashplugin/
[20:49] <bobbo> sebner: ping
[20:50] <sebner> bobbo: ahoi! how can I help you =)
[20:50] <bobbo> sebner: hey :)
[20:50] <bobbo> sebner: could i steal the cfingerd from you?
[20:50] <sebner> bobbo: but stealing is a crime O_o
[20:51] <sebner> hrhr
[20:51] <sebner> bobbo: of course you can! :)
[20:51] <bobbo> sebner: cool, thanks alot :)
[20:51] <DRebellion> Has anybody got any suggestions on formats/tools to help write manpages?
[20:52] <sebner> bobbo: to be honest I can't even remember what it's about. I merged/synced so many things .. I barely remember the name "cfingerd"
[20:52] <DRebellion> eg. docbook, pod, etc?
[20:52] <RainCT> DRebellion: You've info on POD at http://wiki.ubuntu.com/PackagingGuide/Howtos/PODManpages, but I recommend just using plain groff (or whatever it's called)
[20:53] <bobbo> sebner: hehe, i just got shouted at for not asking people before merging, so I am being extra careful :D
[20:53] <DRebellion> RainCT, ok, thanks
[20:53] <DRebellion> I will go with the plain groff then
[20:53] <sebner> bobbo: and that's really how it should be. Thx for asking :)
[20:54] <coppro> I thought it was nroff?
[20:54] <RainCT> DRebellion: here you've a random example upon which you can base yours http://paste.ubuntu.com/68987/plain/
[20:54] <DRebellion> RainCT, btw, http://wiki.ubuntu.com/PackagingGuide/Howtos/PODManpages doesn't exist ;)
[20:54] <RainCT> arr, copied the wrong link. it's http://wiki.ubuntu.com/PackagingGuide/Howtos/PODManpage
[20:54] <RainCT> coppro: maybe :)
[20:54] <sebner> RainCT: /myself uses plain gedit xD
[20:54] <ScottK> If it's Perl that's really how one shoule do it (POD2man)
[20:55]  * ScottK generally uses vim.
[20:55] <coppro> kate ftw
[20:55] <RainCT> geany :P
[20:55] <sebner> ScottK: ah. btw, I hope it was ok that I quoted you. (If you read my application already) :\
[20:55] <NCommander> hey ScottK
[20:56] <RainCT> coppro: yep, you're right
[20:59] <sebner> bobbo: and of course you can steal stuff from me because you are my Application mate ;P
[20:59] <ScottK> sebner: Sure.
[20:59] <ScottK> heya NCommander.
[21:00] <bobbo> sebner: rofl! Not heard that one before :D
[21:00] <NCommander> ScottK, so I dented the queue <g>
[21:00] <sebner> ScottK: ok thx. But in generel I tend to ask people before I do such stuff. Sry for that
[21:00] <ScottK> NCommander: Great.
[21:00] <sebner> bobbo: :P
[21:00] <NCommander> ScottK, how go things for you?
[21:01] <ScottK> sebner: If I say something in public, I think it's fair game.
[21:01] <ScottK> NCommander: I bit hectic.
[21:01] <sebner> k
[21:01] <NCommander> ScottK, ouch
[21:01] <ScottK> I/A
[21:01] <NCommander> sebner, I saw you MOTU application, yay :-)
[21:02] <sebner> NCommander: I already told you that I saw yours and I still want to hide ;)
[21:02]  * directhex hands NCommander cake
[21:02] <csilk> Any reason why why pbuilder would fail to create a build environment claiming > debootstrap failed?
[21:02]  * NCommander wonders if the cake is a lie
[21:03] <NCommander> csilk, are you trying to build a jaunty chroot?
[21:03] <ScottK> Daughter #1 and #3 have ballet in 1 hour.  Daughter #2 wants to go to the high school football game in 3 hours (same time as pickup for #1 and #3) and daughter #1 has a church ice skating trip in 4 hours.  Somewhere in there I have some monthly reports and invoices that are overdue.
[21:03] <csilk> NCommander, intrepid
[21:03] <NCommander> csilk, and you are running?
[21:03] <csilk> intrepid
[21:03] <NCommander> Odd
[21:03] <NCommander> What is the error?
[21:03] <sebner> ScottK: O_o
[21:04] <csilk> This works fine an my other machine which is the strange thing NCommander  > http://paste.ubuntu.com/68999/
[21:04] <csilk> *on
[21:04] <NCommander> *blink*
[21:04] <NCommander> Is there any more backscrool?
[21:05] <csilk> http://paste.ubuntu.com/69001/
[21:05] <sebner> ScottK: it's funny for me because for me your family represents the typical american family for use european. (well, though ballet is still strange) ^^
[21:05] <sebner> *use = us
[21:06] <ScottK> Well just recall that the perspective you get from over there of America is very much exaggerated.
[21:06] <ScottK> We had German exchange students living with us for four years and they were all very suprised when they got here.
[21:07] <sebner> heh
[21:07] <csilk> NCommander, any idea?
[21:07] <csilk> This machine is pretty much the same as my laptop where the intrepid pbuild environment has worked fine from day one
[21:07] <NCommander> YOu are running pbuilder with sudo, right?
[21:07] <csilk> of course
[21:08] <NCommander> No, not off hand I do
[21:08] <sebner> ScottK: to me it seems in america it's pretty common to take foreign exchange students, right? not like here ...
[21:08] <NCommander> ugh
[21:08] <NCommander> Whoever packaged this for Debian was an idiot. I can't figure out how to do a fakesync without making a native tarball
[21:08] <NCommander> (which is what the previous upload did)
[21:09] <ScottK> sebner: It depends.  I wouldn't say 'pretty common' but there are generally a few in most any large school.  They're staying with someone.
[21:11]  * sebner will exchange to american and live with ScottK and as reward he'll train ballet with this daughters :D :P
[21:11] <persia> NCommander, which package?
[21:11] <ScottK> sebner will go no where near ScottK's daughters.
[21:11] <sebner> xD
[21:12] <NCommander> persia, libdebug
[21:12]  * sebner can also wash his car instead =)
[21:12] <NCommander> persia, it looks like it was a native in Debian, then got diffed here, then NMUed into a proper orig.tar.gz, and now I'm trying to see if I can craft a version string thats greater than the old one, yet will still allow syncing
[21:13] <persia> NCommander, You can't.
[21:13] <NCommander> so just upload it as a native package?
[21:14] <persia> Personally, I think we ought always ubuntuize native packages as X.Y-0.0ubuntuZ, but everyone claims that NMUs of native packages aren't frequent enough to bother.
[21:14]  * NCommander already fakesynced two 
[21:15] <NCommander> So I'm going to say I agree w/ you
[21:15] <persia> Um.  it ought still be native.
[21:15] <persia> Yeah, 0.4.2-0.1 is a native package in sid.  No orig.tar.gz.
[21:16] <persia> NMUs for naive packages get -0.x versioning.
[21:16] <NCommander> d'oh
[21:16] <NCommander> I don't think I've ever read that before
[21:16] <persia> So you want 0.4.2ubuntu2 unfortunately.
[21:16] <NCommander> That's what I did
[21:17] <persia> `apt-cache showsrc libdebug` in a sid environment would have saved you some headache :)
[21:18] <NCommander> persia, out of curosity, do you know if/how syncs and backports are attributed to people?
[21:18] <NCommander> mr_pouit was attributed to the codeblocks backport, but he had nothing to do either the packaging or the backport itself O_o;
[21:18] <RainCT> NCommander: not sure, but I think archive admins tell the script they use for syncing who it should be attributed to
[21:19] <NCommander> RainCT, I've never had any of my syncs show up on my list of packages
[21:19] <persia> NCommander, It's Changed-By.  Some archive admins adjust it to be reporter or ACKer or something.  Others just leave the name in the last changelog entry.
[21:20] <NCommander> o_O;
[21:20] <NCommander> That package was acked by cody-somerville and LucidFox, and I did all the packaging on it
[21:20] <persia> NCommander, If you haven't then you've not had one of the regular archive admins.
[21:20] <NCommander> I don't think he even did an upload of the 0ubuntu2 version
[21:22] <persia> Well, it's about the .changes file.  If you think it's sufficiently wrong that you want to harass the archive-admins, go ahead.  Remember, they're all busy people, and less likely to prioritise your stuff if annoyed :)
[21:24] <mr_pouit> that's not a big issue, juste some weird magic
[21:24] <NCommander> lol
[21:25] <NCommander> persia, I already spam bombed the archive admins
[21:25] <NCommander> persia, I don't think they are so happy w/ me at the moment ;-)
[21:26] <ScottK> NCommander: Look at all the syncs and backports this guy has done, look at his LP ID and then tell me what you think happened: https://launchpad.net/~scottk/+related-software
[21:27] <Laney> He should apply for MOTU clearly
[21:29] <persia> Well, that's part of why the process isn't just about upload count as described by launchpad.
[21:29] <persia> Some people get in with ~10 uploads.  Others seem to require ~400 before being ready.  SpecialK would probably have to demonstrate a far number of non-backport non-syncs to be considered.
[21:30]  * NCommander wonders if persia missed the joke
[21:35]  * RainCT wonders if he has ever seen persia laughing :P
[21:35] <Laney> tickle him and see
[21:36] <NCommander> Is there a way to specify the default key to sign w/?
[21:36] <NCommander> I don't like having to look up my keys fingerprint everytime I sponsor something
[21:36] <RainCT> NCommander: you can use your email
[21:36] <RainCT> debuild .. -k<email address>   or whatever
[21:36] <NCommander> Oh
[21:36] <NCommander> Handy
[21:37] <sebner> RainCT: +1
[21:37]  * NCommander might just write a script around debuild/debsign sponsor-sign that uses DEBEMAIL
[21:37] <RainCT> \o/ I've got a +1.          For what is it? :D
[21:38]  * NCommander just learned the hardware to test build on both i386 and amd64
[21:39] <geser> NCommander: $ grep KEYID ~/.devscripts
[21:39] <geser> DEBSIGN_KEYID=0x968BD587
[21:39] <sebner> RainCT: for the joke about persia which isn't a joke ^^
[21:39] <NCommander> O_O!
[21:39]  * NCommander hugs geser 
[21:39] <RainCT> sebner: ah, that's plain truth :)
[21:40] <RainCT> actually, I'm pretty sure that persia is a bot :P
[21:40] <sebner> No O_o
[21:40] <sebner> hihi
[21:40] <geser> NCommander: I've also DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc" in .devscripts and use debsign when I've something worth uploading (that way I it's much harder to upload unfinished stuff)
[21:41] <NCommander> Oh, I love you now geser
[21:41] <sebner> geser: of course this also works with pdebuild?
[21:42] <NCommander> I dunno even what pdebuild does
[21:42] <geser> I guess, but I don't use pdebuild
[21:42]  * NCommander just builds a source package and builds that
[21:42]  * sebner also loves geser :P
[21:42] <sebner> NCommander: It runs debuild and pbuilder with just 1 commands
[21:43] <sebner> *command
[21:43] <NCommander> Handy
[21:43] <persia> Well, maybe.
[21:43] <james_w> the one issue with DEBSIGN_KEYID is that it will no longer catch typos in Changed-By:, but as that is generally just DEBFULLNAME or whatever, then it's not a big problem
[21:43] <sebner> the crap is that it installed a lot java stuff and eclipse
[21:43] <persia> I like to verify my source changes before starting to wait for a build to run.
[21:51] <geser> james_w: for sponsoring setting DEBSIGN_KEYID is a great help
[21:53] <persia> It's 8 characters representing 32 bits of data.  Should be easier to remember than your password.
[21:54] <persia> (At least I hope nobody here uses a password of 8 characters or less that contains no more than 32 bits of entropy)
[21:54] <persia> at least not for an account that has access to a secret key
[21:55] <james_w> geser: oh, I agree, it's fantastic, the failure case just occured to me. The benefit far outweighs the risk anyway.
[23:23]  * RainCT is doing his first upload to jaunty \o/
[23:51] <gouki> Can someone help me understand what went wrong here: http://paste.ubuntu.com/69050
[23:53] <persia> Could you paste the entire build log?
[23:54] <persia> Also, really, don't bother packaging that.  It's not worth it.  It's redundant, less functional than current alternatives, and you're surely going to get interested in something else and not maintain it.
[23:54] <gouki> persia, I just keep going with it because I had some good feedback from it (good as in I learned a few things).
[23:55] <persia> gouki, I can understand that, but it's useless.  If you want to learn, perhaps you'd like to work on a useful package?
[23:55] <pangloss> persia: care to suggest some?
[23:55] <persia> There's a few I'd like that I don't have time to chase, and I'd be happy to give you a pointer.
[23:56] <gouki> persia, sure. What do you suggest?
[23:56] <persia> pangloss, Sure you want one too?
[23:56] <pangloss> persia: yes
[23:56] <gouki> I also packaged a game, but it's giving me the same error as this bsod one. Which is already in REVU, BTW: http://revu.ubuntuwire.com/details.py?package=banihstypos
[23:57] <persia> OK.  First off, there's an official list of user-requested packages that's a good place to check, with 1424 current requests: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[23:57] <gouki> And yes, the name is correct :)
[23:57] <gouki> persia, I already went looking there, but I didn't found anything interesting (something I use). I read somewhere that one shouldn't maintain something that he doesn't use, so I didn't go for it.
[23:58] <persia> Ah, well, there's a difference between packaging something and maintaining something.
[23:58] <persia> It's good to use anything you package at least while you are packaging it.
[23:58] <persia> You don't necessarily have to maintain it, if you can find someone else to do it.
[23:59] <gouki> Sure. I didn't mean that in a rude way!
[23:59] <persia> On the other hand, the only reason to package something is either because you're going to want to use it, or you know someone else is going to want to use it, and you want to do work to make them happy.
[23:59] <gouki> persia, what are the ones you were thinking about packaging? It can be anything too complex, as I'm still trying to successfully build something :S