[00:05] <Jazzva> Could someone take a look at the patch in bug 219303? Thanks :)
[00:05] <ubotu> Launchpad bug 219303 in gnome-voice-control "Problem with OAFIID:GNOME_VoiceControlApplet while adding VoiceControl to GNOME Panel" [Undecided,Confirmed] https://launchpad.net/bugs/219303
[01:25] <Jazzva> ScottK, thanks for the ack. There was one other problem (which I missed), but I fixed it now, and uploaded the new debdiff.
[01:37] <ScottK> OK.
[01:38] <ScottK> Susbcribe ubuntu-universe-sponsors if you haven't.
[01:38] <ScottK> Jazzva: ^^
[01:39] <Jazzva> I will...
[01:49] <emgent> Fujitsu: ping
[01:49] <emgent> heya ScottK
[01:50] <emgent> I'm thinking to import wordpress 2.5 in hardy. possible exception?
[01:52] <TheMuso> emgent: Cutting it a bit close don't you think?
[01:53] <emgent> TheMuso: yes i know :|
[01:55] <emgent> TheMuso: lenny use wordpress (2.5.0-1)
[01:56] <emgent> now in ubuntu  wordpress | 2.3.3-1ubuntu1 | hardy/universe | source, all
[02:02] <TheMuso> Well considering hwo many people use wordpress, why wasn't it updated earlier?
[02:08] <Amaranth> i thought wordpress got removed from debian for being a security nightmare :P
[02:09] <RAOF> Gah!  Gmail's spam filter would be more useful if it didn't flag DDs offering to help with the Gnome-Do Debian package as spam.
[02:31] <emgent> Amaranth: nah..
[02:31] <emgent> TheMuso: i dont know. in the last time i follow wordpress but i'm not motu yet.
[02:32] <emgent> anyway i will talk for other people at UDS for found a solution.
[02:32] <emgent> no i go to sleep, see you later
[02:32] <emgent> s/no/now/
[02:36] <nxvl> i find easier to install wordpress from upstream than from apt
[02:36] <nxvl> so i don't think is needed
[02:37] <nxvl> is not so hard to install it to be a package
[02:37] <emgent> nxvl: false.
[02:38] <emgent> debian/ubuntu wordpress support multiuser wordpress
[02:38] <emgent> it`s a very good reason for me.
[02:39] <emgent> anyway now i should sleep, we can talk at UDS
[02:39] <emgent> night all.
[02:39] <nxvl> multiuser as in one instalation for several domains?
[02:39] <emgent> yes. see docs.
[02:39] <emgent> night
[02:44] <crimsun> Fujitsu: essentially the env vars are unnecessary
[02:46] <crimsun> Fujitsu: BTW, there're so many whitespace-only (i.e., spurious) changes; we could do without those
[04:08] <nxvl> does anyone know what happened with dad?
[04:08] <nxvl> DaD*
[04:11] <jdong> went off with MoM?
[04:12] <icanhas> jdong: i had to refrain from that so badly.
[04:13] <jdong> lol
[04:14] <nxvl> heh
[04:14] <nxvl> i'm blogging this
[04:16] <icanhas> nxvl: i'm bashing this
[04:24] <ScottK2> nxvl: The intent was to merge the code with MoM now that MoM has been open sourced.
[04:24] <ScottK2> nxvl: The MoM source is in it's own project on Launchpad now.
[04:24] <nxvl> ScottK2: oh! that's why MoM has the cool features DaD have
[04:24] <nxvl> :P
[04:24] <nxvl> had*
[04:24] <ScottK2> Does it?
[04:24]  * ScottK2 looks
[04:24] <nxvl> yup
[04:25] <nxvl> now it has "Last Uploader" field
[04:25] <nxvl> which hadn't
[04:25] <StevenK> ScottK2: launchpad/merge-o-matic ?
[04:25] <StevenK> Er, launchpad.net
[04:25] <ScottK2> Ah.
[04:25]  * ScottK2 was still looking for comments.
[04:26] <ScottK2> Sounds right.
[04:27] <nxvl> ScottK2: yes, that's isn't merged
[04:27] <nxvl> :(
[04:27]  * nxvl codes
[04:28] <ScottK2> StevenK: Would you be available to help me figure out why my new clamav postinst is failing?
[04:29] <TheMuso> The last uploader field has been there for quite a while now.
[04:29] <StevenK> ScottK2: Sure. What's the issue?
[04:29] <ScottK2> The error is /var/lib/dpkg/info/clamav-base.postinst: 454: Generated: not found
[04:29] <ScottK2> Line 454 is esac
[04:30] <StevenK> Then it's somewhere in that block.
[04:30] <StevenK> ScottK2: Add set -x to the postinst and re-run?
[04:30] <StevenK> ScottK2: Pastebin what it spits out
[04:30] <ScottK2> OK
[04:31] <nxvl> TheMuso: it can, but i has opened MoM after some months
[04:31] <nxvl> :P
[04:32] <nxvl> ScottK2: line number are referencial, the correct line isn't always shown
[04:32] <StevenK> I usually take it to be a block, and set -x it
[04:33] <ScottK2> OK.
[04:33] <nxvl> StevenK: yep, that's better
[04:33] <nxvl> StevenK: i use -x to
[04:33] <nxvl> :D
[04:33] <nxvl> too*
[04:35] <ScottK2> StevenK: http://paste.ubuntu-nl.org/63889/
[04:36] <nxvl> ScottK2: it seems to be an issue with the comment
[04:36] <nxvl> :S
[04:37] <ScottK2> Which is bizarre.  Comment is in the previous version unmodified.
[04:37] <nxvl> ScottK2: it's on the archives or it's a change you are testing?
[04:37] <StevenK> Personally, I'd use a heredoc there
[04:37] <nxvl> woohooo Ice Age is on TV \o/
[04:38] <ScottK2> nxvl: The previous version is in the archives.
[04:38]  * nxvl downloads
[04:39] <ScottK2> StevenK: Currently we use the Debian clamav package unmodified, so I'm trying for minimal change as I'd like to both keep it that way and not have sgran say, "Here you maintain it then."
[04:39] <nxvl> ScottK2: have you change posinst?
[04:39] <ScottK2> Yes.
[04:39] <nxvl> can you upload it please
[04:39] <ScottK2> I'll pastebin the diff.
[04:39] <nxvl> :D
[04:40] <ScottK2> http://paste.ubuntu-nl.org/63890/
[04:40]  * ScottK2 curses upstreams who randomly rearrange config options for no clear reason.
[04:45] <ScottK2> StevenK or nxvl: any suggestions.
[04:45] <StevenK> ScottK2: Can you pastebin the postinst?
[04:46] <ScottK2> Sure.
[04:47] <ScottK2> StevenK: http://paste.ubuntu-nl.org/63891/
[04:48] <StevenK> It looks syntactically correct to me.
[04:49] <StevenK> ScottK2: What does sh -n <postinst> give you?
[04:49] <ScottK2> I found a problem in the depenencies, that I need to check out, maybe that's what's giving me trouble.
[04:49]  * ScottK2 tries
[04:51] <ScottK2> StevenK: With or without the set -x?  Without set -x there is no output
[04:52] <nxvl> i think i have it
[04:52] <nxvl> on line 169 at http://paste.ubuntu-nl.org/63889/ there should have "" after and before the #
[04:53] <ScottK2> Ah.  Looking
[04:54] <nxvl> try changing the "s on lines 28{7,8} for 's
[04:55] <ScottK2> nxvl: Change echo "#Automatically Generated by clamav-base postinst" > $DEBCONFFILE to echo ""#Automatically Generated by clamav-base postinst"" > $DEBCONFFILE
[04:55] <ScottK2> Sorry, it's late and I'm tired.
[04:56] <nxvl> that happends often
[04:56] <ScottK2> Is that what you meant?
[04:56] <nxvl> i have had really stupid missings when i work on something for to much time
[04:56] <nxvl> ScottK2: yep
[04:56] <nxvl> ScottK2: or use ' intead of "
[04:57] <ScottK2> OK.
[04:57] <jdong> err, line 225
[04:57] <jdong>     scanarchive="$RET
[04:57] <ScottK2> I'm rebuilding with the dependency corrected, I'll try that first and if that doesn't get it, I'll try that.
[04:57] <jdong> that looks like a problem
[04:57] <ScottK2> Ah.
[04:58] <nxvl> oh!
[04:58] <jdong> rest of the script looks good
[04:58] <nxvl> that's why the "s aren't recognized correctly
[04:58] <jdong> transposed "'
[04:58] <jdong> those are nasty
[04:58] <jdong> often times don't trip an error till it's way too late
[04:58] <ScottK2> jdong: Wins the cookie.  Thanks a bunch.
[04:58] <jdong> no prob :)
[05:01] <ScottK2> Thanks StevenK and nxvl too.
[05:01]  * nxvl HUGS ScottK2 
[05:06] <jdong> vim was the magic silver bullet... I noticed at the end all the highlighting was screwed up so I backtracked to the first line that started happening
[05:17]  * ScottK2 makes a note.
[05:34] <jetsaredim> if i'm updating a package for a new upstream, I want to remove all of the old junk in the existing package except for the debian dir right?
[05:37] <nxvl> mmm
[05:37] <nxvl> not really
[05:38] <nxvl> you want to keep the changes which upstream hasn't include
[05:38] <nxvl> they can be on the debian dir if a patchsystem has been used or on the parent dir
[05:40] <nxvl> so you need to check is a patch system is used or not
[05:56] <jetsaredim> nxvl: this is for essenailly a complete re-write of the package
[05:56] <jetsaredim> also - just checking - what is the policy on version numbering for alpha/beta and svn +/~
[06:01] <nxvl> ?
[06:04] <nxvl> version~svnversion
[06:06] <jetsaredim> i thought it was like ver+b#~svn#
[06:06] <RAOF> jetsaredim: Basically, the goal is to both (1) Give a useful, monotone increasing version number, and (2) ensure that the eventual release has a higher version number than any of the pre-releases.
[06:07] <jetsaredim> sure
[06:07] <ScottK2> jetsaredim: If it was + then it would have a higher version number than the final release.  This is painful.
[06:07] <jetsaredim> so how does one express beta revision releases?
[06:07] <RAOF> There are two obvious options here: oldversion+svn$REVISION => newversion on release, or newversion~svn$REVISION => newversion on release.
[06:08] <ScottK2> final~beta
[06:08] <RAOF> Or newversion~beta1 => newversion, etc.
[06:08] <ScottK2> RAOF types faster than me.
[06:08] <jetsaredim> so - if its beta and comes from svn?
[06:09] <ScottK2> Your call.
[06:09] <RAOF> Is it really beta and comes from SVN?  Beta implies some form of release :)
[06:09] <jetsaredim> rh
[06:09] <jetsaredim> 8eh
[06:09] <jetsaredim> damn can't type
[06:09] <jetsaredim> i'm updating a package with new upstream
[06:10] <RAOF> Yes, fair enough.
[06:10] <jetsaredim> current package version is 1.1.0~b11+svn317
[06:10] <jetsaredim> new is 1.2 beta20 svn 561
[06:11] <RAOF> So, the actual status is: there was a 1.2 beta 20 release, and we're packaging r561 which is later than that beta?
[06:11] <dholbach> good morning
[06:11] <RAOF> (Of course, it doesn't matter _too_ much, as long as it's monotone increasing and obvious to someone.  IE: you).
[06:11] <jetsaredim> RAOF: I'm grabbing it from svn and the version number they are using is 1.2b20
[06:11] <RAOF> dholbach: Hood morning.
[06:12] <dholbach> hi RAOF
[06:12] <jetsaredim> dholbach: almost time for bed here ;)
[06:12] <RAOF> Ah.  The old "insane upstream" problem.
[06:12] <jetsaredim> indeed
[06:12] <dholbach> hehe
[06:12] <ScottK2> jetsaredim: THen how about 1.2~b20
[06:12] <ScottK2> Good morning dholbach.
[06:12] <dholbach> hi ScottK2
[06:12] <dholbach> how are you guys doing?
[06:12] <ScottK2> Tired and heading to bed soon.
[06:12]  * jetsaredim same
[06:13] <dholbach> I'm at the second cup of coffee - so things should be good quite soon :)
[06:13] <RAOF> I'd suggest 1.2~b20+svn561, which says to me "this is b20 + some more svn development of what will become 1.2"
[06:13] <jetsaredim> ok
[06:13] <jetsaredim> that follows the current numbering
[06:13] <RAOF> Indeed.  It does have that advantage :)
[06:13] <jetsaredim> i suppose i can live with that
[06:14] <dholbach> nxvl: thanks for the fix for 5-a-day - uploaded to PPA
[06:14] <jdong> I think the choice between oldversion+svnrev vs newversion~svnrev depends on the maturity of the product :)
[06:15] <superm1> well more so on how often it is updated
[06:15] <jdong> i.e. whether it's 10 revs from the last stable release or 10 revs TO the next stable release :)
[06:15] <superm1> i dont like it when there are combinations of both
[06:15] <superm1> that makes more confusing
[06:15] <jdong> superm1: well they say different things
[06:16] <dholbach> I always make use of the version in configure.ac
[06:16] <superm1> well i mean something like  1.2~b20+svn561
[06:16] <jdong> 1.2+svn1234 says it's essentially version 1.2 but with some svn chansets
[06:16] <superm1> which makes sense (jdong^)
[06:16] <jdong> 1.3~svn1234 means to me it's ALMOST 1.3
[06:16] <nxvl> dholbach: :D
[06:16] <dholbach> if they bumped it up to the next version already, but didn't release, I make it <next version>~svn<date>
[06:16] <superm1> when i read that i think, well this is 1.2 snapshot 20 + some fixes
[06:16] <superm1> but i dont know if that would be accurate
[06:17] <jdong> superm1: taht's how I'd read the version number too
[06:17] <jdong> I'd only use that versioning scheme if that's how it's supposed to read
[06:17] <dholbach> superm1, jdong: isn't there any upstream file that states the current version?
[06:17] <jdong> I don't know; I'm speaking hypothetically here :D
[06:17] <jetsaredim> superm1: yea - that's what it is
[06:17] <dholbach> (or the version that currently lives in svn?)
[06:17] <nxvl> btw
[06:17] <superm1> this package in question i dont know, i just jumped in when i saw ugly version numbers light up
[06:17] <nxvl> when is going to start the debian import time?
[06:18] <jdong> ack the FreeBSD idle loop is really ticking me off
[06:18] <jdong> (no pun intended)
[06:19] <jdong> the bloody thing fires off 15% CPU usage idle in timer ticks
[06:19] <superm1> i try to only start tacking on versions for +svnXYZ or such when I am working closely with upstream personally
[06:19] <jdong> how do people in the Real World (tm) stand virtualizing these things?
[06:22] <JohnPhys> Is there any way a freeze exception could be granted to get the fix to Bug #195052 into hardy?  It seems as though it's already been fixed in the inkscape source
[06:22] <ubotu> Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Undecided,Fix released] https://launchpad.net/bugs/195052
[06:23] <jdong> JohnPhys: idn what our present release mgmt policy is, but I expect it to be just release-critical bugs
[06:24] <jdong> JohnPhys: that bug has a simple fix but I'm not sure we can argue it's release critical. Perhaps hold for a stable release update to hardy-updates after release?
[06:26] <jdong> I am disappointed that such a bite-sized trivial bug didn't get caught on mar 30 when it was still easy to upload it in :(
[06:26] <JohnPhys> jdong:  Thanks for your info.  I should have been watching it more closely, I didn't notice that ubuntu wasn't listed in the "also affects" (I added it about a week ago, at kees' suggestion).
[06:27] <nxvl> dholbach: you are going to include 5-a-day into intrepid?
[06:27] <jdong> JohnPhys: yeah, I definitely want to do this fix as a stable release update for Hardy soon after release... it's such a simple fix
[06:27] <JohnPhys> jdong:  I'll be watching that bug on my spare partition hardy install, as it prevents me from upgrading (latex equations in inkscape are nice for thesis figs :) )
[06:27] <jdong> poke me if I forget.
[06:29] <JohnPhys> jdong:  Will do, thanks again for your effort/interest on this.  I ran into bug #205667 while investigating this one.  That bug is more serious, but there's no fix yet (causes a nice fantastic inkscape crash).
[06:29] <ubotu> Launchpad bug 205667 in inkscape "Inkscape crashes when using 3d box after attempting to render latex, gears, tree, barcode, maybe others." [High,Triaged] https://launchpad.net/bugs/205667
[06:29] <JohnPhys> so I expect it will be some time before that gets fixed.  Luckily, I don't need the 3d box tool :)
[06:29] <jdong> JohnPhys: ah, very nice.... crashers are always fun :)
[06:30] <dholbach> nxvl: yeah, why not
[06:30] <ajmitch> dholbach: 10 a day!
[06:31] <superm1> i saw something in an apport changelog that apport gets turned off during release.  as people file bugs during a release is the standard going to be "please turn on apport and refile" then?
[06:31] <jdong> 30 a day... OR ELSE...
[06:32] <dholbach> lrwxrwxrwx 1 root root 4 2006-08-23 17:28 /usr/bin/30-a-day-or-else -> 5-a-day
[06:32] <ajmitch> just put in special code for jdong
[06:33] <dholbach> if user == "jdong":
[06:33] <dholbach>     ...
[06:33] <JohnPhys> jdong:  I've uploaded a backtrace to that one, and bryce has looked at it, so hopefully there will be some movement on it soon.  I wish I had some programming ability, so that I could help rather than constantly pester devs about issues I find :).  Anyway, thanks again, I'll be sure to check in again on that latex rendering bug after hardy is released.
[06:33] <jdong> JohnPhys: thanks for your help!
[06:36] <jetsaredim> ﻿how do I clear a bzr push lock?
[06:37] <JohnPhys> jdong:  Thanks to all the devs!  without you, I'd be stuck in vista on my laptop!  anyway, I'm off!
[06:37] <dholbach> jetsaredim: bzr break-lock
[06:39] <jetsaredim> dholbach: hrm - try that and still says locked
[06:39] <jetsaredim> been held for something like 20 min
[06:39] <dholbach> jetsaredim: try asking in #bzr
[06:39] <jml> jetsaredim: if it's bzr+ssh, then when you hit Ctrl-C after getting a lock message, bzr keeps trying to take the lock
[06:40] <jml> because an SSH process stays around after bzr itself goes away
[06:40] <jetsaredim> jml: awesome
[06:40] <jml> jetsaredim: is that what's happening with you?
[06:40] <jetsaredim> yea
[06:40] <jml> jetsaredim: cool :) kill the ssh process and break the lock.
[06:41] <jml> jetsaredim: this has been raised as a bug. I *think* it's fixed (poolie told me it was), but I haven't got around to verifying.
[06:41] <jetsaredim> ahh
[06:41] <jetsaredim> gotcha
[06:44] <jetsaredim> jml: actually - it looks like this is locked on the server side
[06:45] <jml> jetsaredim: hmm. hop on to #bzr and we can debug this further.
[06:46] <warp10> Good morning
[06:50] <geser> good morning
[06:53] <dholbach> hi geser, hi warp10
[06:53] <warp10> hey dholbach!
[06:54] <geser> Hi dholbach
[07:27] <\sh> moins
[07:29] <geser> Hi \sh
[07:30] <\sh> I wonder if I should blog about my adventures installing windows xp yesterday...actually it took me (with catching the drivers for the board for network etc., installing all security updates etc.) around 4 hours..while this morning installing ubuntu on the same machine it was only 30 mins and I had a running OS with all needed apps
[07:35] <RAOF> \sh: Installing windows is so horribly boring, long, and tedious.  But I'm not sure that anyone in your blog's target audience wouldn't know this :)
[07:36] <\sh> RAOF, yepp
[07:36] <elmargol> Windows is a pain in the a...
[07:39] <elmargol> Took me about an hour to remove every spyware application wich was preinstalled by dell
[07:41] <\sh> fun part...I just have recovery cds at home...no real OEM...and I wanted to use the license on another computer...so I just had to download from somewhere else an OEM installation media...
[07:42] <\sh> so actually I found at home round about 7 official windows xp license product keys...but no single simple OEM installation media
[07:45] <geser> what is also fun is to install win xp on a sata drive where win xp needs a driver disk and you have no floppy drive in the pc anymore
[07:46] <RAOF> Yeah.  I built my last system with a floppy drive with the express purpose of making sure windows was installable.
[07:47] <\sh> geser, oh with this I had luck...the only thing that worked was the sata recognition of the onboard sata
[07:48] <\sh> but the intel nic wasn't recognized :(
[07:50] <jetsaredim> RAOF: sad that you would need to do that
[07:51]  * jetsaredim hasn't needed windows for about 6 years
[07:51] <RAOF> jetsaredim: I was a gamer at one point :P
[07:52]  * jetsaredim has wii/ds/psp/ps3 for that
[07:54] <elmargol> I have a PC for games and a notebook for everything else
[07:58] <\sh> jetsaredim, If my tax application would run on wine, everything would be ok...but sadly, all tax apps I've used weren't working with wine :( and I'm sick and tired of this, but no chance to have a good tax app on linux...
[07:58] <jetsaredim> \sh: you try kmymoney?
[07:59] <jetsaredim> i assume you mean quicken or something
[07:59] <jetsaredim> i don't have much need for such things
[07:59] <\sh> jetsaredim, no...not account managing software...tax software for doing my tax application :)
[08:00] <jetsaredim> ah - turbotax?
[08:00] <\sh> jetsaredim, as I have still a company, i need to do more then the private stuff for german taxes
[08:00] <jetsaredim> oh
[08:00] <jetsaredim> like accounting software
[08:00] <jetsaredim> gotcha
[08:00] <jetsaredim> well - now you see a hole in the market
[08:00] <jetsaredim> maybe you can develop some software to fill the void
[08:01] <\sh> jetsaredim, oh tax software is special..there are some regulations...
[08:01] <jetsaredim> yea - that was a joke
[08:02] <jetsaredim> i don't have much need for such apps, so for me its not a big deal, plus I have an accountant
[08:02] <\sh> accountants are thieves..;)
[08:03] <\sh> at least some of them in germany are..
[08:03] <jetsaredim> i don't mind paying a little extra to not have to deal with all of the numbers
[08:03] <jetsaredim> and figuring out all of the in-and-out of the tax code in the us
[08:04] <\sh> actually it's easy...and fun, that I learned accounting during my economics studies in my early ages..so it's not a big deal, with the right software at hand
[08:04] <jetsaredim> i would imagine not
[08:04] <jetsaredim> my problem would be with keeping up with all of the changes
[08:05] <jetsaredim> they revise the tax code here every year
[08:05] <jetsaredim> anyhow
[08:05] <jetsaredim> this is not really motu discussion
[08:05] <jetsaredim> sorry all
[08:05]  * jetsaredim -> lurks
[08:09] <\sh> damn...28 billions increase of google market price .. hell
[08:14] <superm1> jetsaredim_, you still here?
[08:48] <Fujitsu> crimsun: Of course, I wasn't going to apply all hunks. Thanks.
[08:48] <Fujitsu> emgent: Pong.
[09:05] <\sh> gnarf...
[09:06] <\sh> can somebody confirm that releases.ubuntu.com (gallium) is somehow borked? I have a good ping time, but port 80 is slower then a 300 baud modem
[09:08] <\sh> ok..using the dailies
[10:25] <\sh> danm...when I see MoM and counting my name..../me needs a day with more then 24h
[10:43] <\sh> rock...claws-mail 3.4.0 ;9
[10:43] <\sh> anyone wants to file an FFe ?? ,-)
[10:45]  * Fujitsu stabs \sh dead.
[10:45] <\sh> harhar
[10:47] <\sh> but...reading colins article about claws-imap implementation..http://www.colino.net/wordpress/archives/2008/04/17/claws-mails-imap-implementation/ gives me a warm feeling..this should work in kmail and evo too
[10:48] <Fujitsu> Hm, that looks nice. Why don't we have a nice shiny uncrap IMAP lib?
[10:48] <Fujitsu> Might make Evo's IMAP less useless.
[10:49] <\sh> Fujitsu, and hopefully tells kmail no to crash on deleting lots of emails from my imap server :(
[10:50] <Fujitsu> Indeed.
[10:50] <Fujitsu> Unfortunately, Claws and Thunderbird are horribly ugly :(
[10:51] <\sh> and did I ever tell you, that twitter via xmpp sucks ... and it sucks more when you only have 140 chars for your message :(
[10:52] <\sh> [11:51:08 AM] Twitter Bot: Oops! Your update was over 140 characters. We sent the short version to your friends (they can view the entire update on the web).
[10:52] <Fujitsu> Twitter sucks anyway, though.
[10:53] <broonie> It's really useful for arranging social stuff at short notice but falls down badly otherwise.
[10:54] <Fujitsu> Hmmmmmm. That SDL PulseAudio fix that worked for me a few days ago doesn't work now :S
[11:00] <LucidFox> cd #ubuntu-ja
[11:00] <LucidFox> oops
[11:35] <spacepluk> Hi, I've updated a package and uploaded it to my PPA. Now what? :P
[11:43] <spacepluk> should I upload the package to REVU?
[13:05] <zul> anyone from the release team around?
[13:07] <Hobbsee> limcore's comments in his channel make me oh so tempted to say no, though....
[13:07] <Hobbsee> just out of sheer spite
[13:09] <Hobbsee> seems a bit petty to decline something for an entire distribution, just because of one guy
[13:10]  * ScottK remembers the CoC and quits typing.
[13:21] <Ubluzok> Hello everybidy
[13:22] <Ubluzok> Can you tell me smth about start to developing smthng for ubuntu?
[13:23] <Ubluzok> Oh, I asked not a regular question
[13:24] <Ubluzok> I think that I'm wery skillful in network technologies... suck routing, switching and VoIP and I can be a consultant for a lot of projects
[13:24] <Ubluzok> Can you point on it?
[13:25] <Ubluzok> Hey is there anybody?
[13:25] <mok0> ! contribute
[13:25] <ubotu> To contribute and help out with Ubuntu, see http://www.ubuntu.com/community/participate
[13:28] <Ubluzok> mok0: :lol:
[13:28] <Ubluzok> ubotu: thanks
[13:28] <ubotu> You're welcome! But keep in mind I'm just a bot ;-)
[13:29] <mok0> Ubluzok: you don't have to thank him :-)
[13:29] <Ubluzok> mok0: ^)
[13:29] <Ubluzok> mok0: I know.... but I don't know that it a bot:)
[13:30] <zul> Hobbsee: ping!
[13:31] <zul> Hobbsee: so LP: #219343 ebox debug is turned on so it can display debug information however this information can also display things like passwords and if the user isnt careful enough then they can put their passwords in launchpad, not good
[13:32] <mok0> Ubluzok: we use him a lot around here... a kind of slave labour that prints links etc
[13:34] <ScottK> \sh: Just read your blog.  I should tell you about my accidental deployment of Hardy into production a few weeks ago.
[13:34] <zul> Hobbsee: this affects both libebox and ebox
[13:36] <mok0> ScottK, a strange new bug report on matplotlib surfaced today. I can't reproduce it: bug 220137
[13:36] <ubotu> Launchpad bug 220137 in matplotlib "python: matplotlib window does not show graph in interactive mode" [Undecided,New] https://launchpad.net/bugs/220137
[13:41] <ScottK> mok0: I'm looking at it.
[13:42] <mok0> Thanks, ScottK
[13:42] <Hobbsee> zul: as discussed, +1
[13:42] <Hobbsee> ScottK: please add that to your list
[13:43] <zul> Hobbsee: thanks Ill upload it now
[13:43] <ScottK> zul: Which ebox package is this in?
[13:43] <zul> 0.11.99
[13:43] <zul> ebox and libebox
[13:43] <ScottK> OK.  Thanks.
[13:44] <zul> Hobbsee: uploaded
[13:44] <Hobbsee> zul: cool.  i can't accept, unfortunately
[13:45] <zul> Hobbsee: thats fine
[13:45] <Hobbsee> LP is borken :(
[13:47] <ScottK> Need an opinion ...  ~3 weeks ago I got the setools package unforked from Debian, but had to put transitional packages to get Hardy users back on the restored Debian binary package names.
[13:48] <ScottK> The question is, is 3 weeks enough for that.
[13:48] <Fujitsu> Yes.
[13:48] <ScottK> Thanks.
[13:48] <Fujitsu> We're a devel release. People can't be expecting to get away with not upgrading new SELinux stuff for three weeks.
[13:51] <ScottK> That's what I was thinking, but I was getting could feet.  I thought I'd double check before I asked to have the upload accepted.
[13:52] <ScottK> zul: Was it libebox - 0.11.99-0ubuntu3?
[13:54] <zul> ScottK: yep
[14:04] <ScottK> mok0: bug commented.
[14:04] <mok0> ScottK: I'll take a look in a minute
[14:08] <Fujitsu> mok0: I can reproduce bug #220137.
[14:08] <ubotu> Launchpad bug 220137 in matplotlib "python: matplotlib window does not show graph in interactive mode" [Undecided,New] https://launchpad.net/bugs/220137
[14:08] <mok0> Fujitsu: aha
[14:09] <mok0> Fujitsu: did you copy the python lines into a script?
[14:10] <Fujitsu> I just used:
[14:10] <Fujitsu> from pylab import *
[14:10] <Fujitsu> ion()
[14:10] <Fujitsu> plot([1, 2, 3])
[14:11] <rexbron> jcastro: care to hop in #ubuntu-bleedingedge?
[14:11] <mok0> Fujitsu: I get a nice graph
[14:12] <Fujitsu> Huuuh.
[14:12] <Fujitsu> Must be some GTK setting somewhere?
[14:12] <mok0> Fujitsu: Is your system up-to-date?
[14:12] <Fujitsu> I upgraded about 12 hours ago.
[14:12] <mok0> Fujitsu: ok
[14:13] <mok0> Fujitsu: I am running under kde4... I wonder if the WM has something to do with it
[14:17] <Fujitsu> ScottK: OK to upload a new release of soundconverter which exists just to fix two crashers I forwarded? http://pastebin.com/f11d3ce5a is the changelog.
[14:17] <ScottK> Fujitsu: Approved due to sense of humor in the changelog.
[14:17] <Fujitsu> Heh.
[14:17] <Fujitsu> Thanks.
[14:18] <ScottK> cody-somerville: Is the xfce4-session upload in unapproved OK by you?
[14:18] <mok0> If a package needs another one just to build the source package, how should that be described? In Build-Depends?
[14:20] <Hobbsee> mok0: yes
[14:20] <ScottK> I was thinking broken, but that too.
[14:22] <cody-somerville> ScottK, The one by lionel, eh?
[14:22] <cody-somerville> ScottK, then yes
[14:22] <ScottK> Yes.
[14:22] <ScottK> Thanks
[14:23]  * Hobbsee bleeps
[14:23] <Hobbsee> mok0: you really are a MOTU, aren't you?
[14:24] <mok0> Hobbsee: yes, but I still have a lot to learn
[14:28] <sebner> mok0: want to upload something?
[14:28] <sebner> mok0: upload = ACK
[14:29] <Hobbsee> mok0: afaik, there isn't a separate list for what's required to build the source, but the stuff required to build the source is usually also required to build the binary
[14:29] <mok0> sebner: I've got several things on my hands right now
[14:29] <sebner> k, np
[14:30] <mok0> Hobbsee: I've had the problem a few times, that even though a package is not required to build the binaries, it is still required to build the source package. There should be a field for in in debian/control
[14:31] <Hobbsee> mok0: ubuntu accepts pre-done sources, and doesn't require rebuilding them.  But yes, it migth be ncie
[14:31] <spacepluk> Hi, I've updated the ardour package but I don't know what to do to get it reviewed.
[14:31] <broonie> mok0: Search the debian-policy archives, it's been discussed.
[14:31] <mok0> broonie: ok, thanks
[14:32] <ScottK> mok0: I'm interested to know what you find.
[14:43] <rexbron> siretart: Is the debian packaging branch on launchpad for ffmpeg is current use?
[14:49] <siretart> rexbron: no
[14:50] <Fujitsu> ScottK: I actually got an IRC ack from Hobbsee for bug #216117 a couple of days ago.
[14:50] <ubotu> Launchpad bug 216117 in audit "[CVE-2008-1628] buffer overflow in lib/audit_logging.c" [High,In progress] https://launchpad.net/bugs/216117
[14:51] <Hobbsee> Fujitsu: i think that already got on the accepted list, no?
[14:51] <Fujitsu> It did.
[14:51] <ScottK> Fujitsu: Fair enough.  I had no way of knowing that when going through unaccepted though.
[14:51] <Fujitsu> Indeed.
[14:51] <ScottK> Change the comment to please mark IRC ack's in the bug then.
[14:52] <Fujitsu> Will do in future - sorry.
[14:52] <Hobbsee> ScottK: sorry, we expected to be able to sohve it thru by me straight away.
[14:53] <Hobbsee> ScottK: of course, launchpad, having run out of sacrifices, made that impossible
[14:53] <ScottK> Right.
[14:54]  * ScottK makes note to ensure processes assume LP will break at the worst possible time.
[14:54] <Fujitsu> As usual.
[14:55] <Hobbsee> ScottK: they've actually found the breakage now.
[15:08] <ScottK> Dear vorian: re Bug #220026 - You can't just subscribe the archive.  Let's talk.
[15:08] <ubotu> Launchpad bug 220026 in ubuntu "Please sync chm2pdf 0.9-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/220026
[15:09] <Hobbsee> ScottK: looks like he forgot to read man requestsync.
[15:09] <Hobbsee> or any of the documentation
[15:10] <ScottK> lool: Did you have an ack from motu-release ack for Bug #215844?
[15:10] <ubotu> Launchpad bug 215844 in elisa-plugins-ugly "Please sync elisa-plugins-ugly 0.3.4-3 from Debian unstable/incoming to fix missing dependency on gstreamer0.10-plugins-bad" [Undecided,New] https://launchpad.net/bugs/215844
[15:11] <sebner> ScottK: well, he is a debian guy and wants his package in ubuntu :)
[15:11] <ScottK> sebner: That's not how the process works.
[15:11] <sebner> ScottK: I know. just funny
[15:11] <ScottK> OK.
[15:11] <sebner> ScottK: will you answer him or should I?
[15:12] <ScottK> Answer who?
[15:12] <sebner> ScottK: ah sry. vorian is here.
[15:14] <lool> ScottK: Hmm I did not; I thought it was obvious enough, but sorry, I should have asked for a freeze exception
[15:14] <emgent> ScottK: it`s possible apply exception to wordpress ?
[15:14] <ScottK> lool: It is.  Sorry to be pedantic, but you know how it is.
[15:15] <ScottK> emgent: Dunno.  I'm just trying to get unapproved sorted right now.
[15:15] <emgent> now in hardy we have 2.3 and lenny have wordpress 2.5
[15:15] <Fujitsu> emgent: Not at this stage.
[15:15] <Fujitsu> The changes are big.
[15:15] <emgent> yes i saw
[15:15] <emgent> ok i will wait
[15:15] <Fujitsu> I don't know why we have Wordpress in the archive at all.
[15:16] <ScottK> Fujitsu: I'd ack the removal bug.
[15:16] <ScottK> ;-)
[15:16] <Fujitsu> A bit late for that :(
[15:17] <lool> ScottK: That's fine; could we look into this now?
[15:17] <emgent> Fujitsu: wordpress packages in ubuntu/debian permit multiuser in one installation
[15:17] <Fujitsu> emgent: They also permit security vulnerabilities.
[15:17] <ScottK> lool: I just ack'ed it.
[15:17] <lool> ScottK: Thanks
[15:17] <emgent> Fujitsu: True
[15:18] <Fujitsu> Night all.
[15:18] <ScottK> Good night Fujitsu
[15:19] <emgent> night Fujitsu
[15:19] <RainCT> Fujitsu: gn8
[15:20] <ScottK> Ohhh.  We have bug supervisor's now.  "The bug supervisor for chm2pdf (Ubuntu) has been subscribed to this bug."
[15:21] <sebner> ScottK: how many and what ACK's are necessary for a package removal? just curious ..
[15:22] <Fujitsu> ScottK: It was renamed a couple of weeks ago, as structural-subscriptions means multiple people can subscribe to a pillar's bugs, so `bug contact' wasn't really a proper description.
[15:22] <RainCT> sebner: MOTU ACK + motu-release ACK afaik
[15:22] <RainCT> sebner: (or at least that's what I needed for the removal fo mozilla-firefox-adblock and some other extension)
[15:22] <sebner> RainCT: ah. k
[15:23] <ScottK> Fujitsu: 'supervisor' sounds a lot different than 'subscriber' though.
[15:23] <Fujitsu> ScottK: Rightly so. Supervisor is just the renamed Contact.
[15:23] <Fujitsu> It entails extra permissions.
[15:23] <ScottK> I see.
[15:24] <ScottK> I don't see any listing of who the supervisor is.
[15:24] <Fujitsu> Should be on the pillar page.
[15:24]  * Fujitsu looks.
[15:24] <Fujitsu> `Bug supervisor:    Ubuntu Bugs'
[15:24] <Fujitsu> (on /ubuntu)
[15:25] <ScottK> Don't see one here: https://bugs.edge.launchpad.net/ubuntu/+source/chm2pdf/+bug/220026
[15:25] <ubotu> Launchpad bug 220026 in chm2pdf "Please sync chm2pdf 0.9-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed]
[15:25] <ScottK> Fujitsu: How do I sign up to be a bug supervisor?  I don't see that either?
[15:25] <Fujitsu> SourcePackages aren't pillars. They don't have a supervisor.
[15:26] <dholbach> you mean  https://bugs.launchpad.net/ubuntu/+source/gedit/+subscribe ?
[15:26] <Fujitsu> If you head over to the Bugs tab of a pillar or SourcePackage, or DistroSeries, or DistroSeriesSourcePackage, you should have a link to subscribe to the bugmail.
[15:26] <Fujitsu> Or use the much nicer URL which dholbach produced.
[15:27] <Fujitsu> Rather than battling LP navigation.
[15:27] <ScottK> Then in what context does "The bug supervisor for chm2pdf (Ubuntu) has been subscribed to this bug." make sense.  There is no chm2pdf (Ubuntu) bug supervisor?
[15:28] <Fujitsu> I considered filing a bug about that message last week. I suspect it is there to indicate that the supervisor and subscribers are implicitly subscribed.
[15:28] <Fujitsu> The supervisor being inherited from the distro.
[15:29] <ScottK> In this particular case the bug went from Ubuntu to chm2pdf(Ubuntu) so I'd expect supervisors to be unchanged if I understand you correctly.
[15:29] <ScottK> There shouldn't be a message at all then.
[15:29] <Fujitsu> No, people could be subscribed to chm2pdf.
[15:30] <Fujitsu> Oh, well, the supervisor is unchanged, right.
[15:30] <ScottK> So the old message about subscribers would be right, but the supervisor context is unchanged.
[15:31] <Fujitsu> Correct.
[15:31] <Fujitsu> It should also probably say `implicitly subscribed' or similar.
[15:31] <ScottK> Now if I go to https://bugs.launchpad.net/ubuntu/+source/python-dns/+subscribe all I see is subscription options.  Nothing about supervisor.
[15:31] <Fujitsu> Right. The supervisor is only on the distro or distroseries.
[15:32] <Fujitsu> (or project or projectseries)
[15:32] <Fujitsu> Hm, no supervisors on series, actually.
[15:32] <Fujitsu> The supervisor is defined by the owner or driver or similar of the project. Not by themselves.
[15:32] <Fujitsu> Just like the old Bug Contact.
[15:32] <ScottK> OK.  You said SourcePackage earlier, so I'm confused again.
[15:32] <Fujitsu> 00:25:57 < Fujitsu> SourcePackages aren't pillars. They don't have a supervisor.
[15:33] <Fujitsu> Subscription != supervisor
[15:33] <Fujitsu> Although the latter entails the former.
[15:33] <ScottK> Ah.  Got it.
[15:34]  * ScottK suddenly remembers he thinks the LP U/I is FUBAR and lacks credibility on the topic.
[15:34] <Fujitsu> IMO it should all be done by the structural subscriptions mechanism, dropping the Bug Supervisor field, and letting the driver mark subscribers as privileged or otherwise.
[15:36] <Fujitsu> That would hopefully make more sense, as there'd be one place and one term for subscribers.
[15:46] <zul> ScottK: I would like to get this one in as well https://bugs.edge.launchpad.net/ubuntu/+source/ebox-usersandgroups/+bug/220262
[15:46] <ubotu> Launchpad bug 220262 in ebox-usersandgroups "ebox-usersandgroups fails to intialise slapd directory" [Undecided,New]
[15:47] <ScottK> zul: Ack'ed
[15:47] <zul> ScottK: thanks
[16:02]  * Hobbsee ponders envyng some more
[16:03]  * Hobbsee thought a negative ack was clear enough.
[16:04]  * Hobbsee *really* doesn't like a non-MOTU being able to change a stable distro at his own whim, just by changing his PPA>
[16:04]  * jpatrick now knows why Hobbsee's system keeping exploding
[16:04] <Hobbsee> jpatrick: i don't use it.
[16:04] <jpatrick> :)
[16:05] <Hobbsee> still, that's a good way of avoiding SRU's.  add lines to MOTU PPA or something, push updates to there, no SRU required.
[16:06] <Hobbsee> jpatrick: i learnt, after my marvell wifi card.
[16:08] <ScottK> Hobbsee: I completely agree about EnvyNG.
[16:08] <Hobbsee> ScottK: wish there were veto powers.
[16:09]  * ScottK is thinking we need a spec on policy for updates from outside the official repositories or something.
[16:09] <Hobbsee> ScottK: it's just another piece to add to the discussion about whether I have continued interest in MOTU, in it's current state.
[16:09] <Hobbsee> and the state it's likely to turn out to be.
[16:10] <Hobbsee> ScottK: it's now done for all hardy users.
[16:10] <Hobbsee> ScottK: there's no actual way to stop it now, as i'm sure that a new version will be updated to the ppa, so people can safely dist-upgrade to intrepid.
[16:11] <Hobbsee> ScottK: it's too late to pull the intrepid version - once it's in hardy, they have root access to the hardy systems, and anything dist-upgraded can be tampered with, without user intervention.
[16:11] <ScottK> Hobbsee: If there's a policy change that recognizes the security risks with the current approach, then an SRU/security upload could fix it.
[16:11] <Hobbsee> ScottK: yes, if they chose to pull it.
[16:12] <Hobbsee> ScottK: then again, the chances of that happening, after the current debate about it....
[16:12]  * ScottK ponders filing a bug about it.
[16:12] <Hobbsee> ScottK: then again, i'ts not infeasible that while the discussion about pulling it was occuring, the makers would add other ways of ensuring that it stays on the system.
[16:13] <ScottK> Ture.
[16:13] <ScottK> Ture/True
[16:13] <Hobbsee> ScottK: you'll need to be awful fast - release is soon
[16:14] <Hobbsee> ScottK: all the safety procedures about what happens if a MOTU goes bad (dev release can be reverted) goes out the window with this approach.
[16:14] <ScottK> Yep.
[16:14]  * ScottK is asking in #ubuntu-hardened (security).
[16:15] <Hobbsee> i'd still prefer to see it SRU'd each time, or at least looked over by a core dev if it doesn't follow all the procedures.
[16:15] <Hobbsee> even though there's more pain and annoyance doing it that way
[16:16] <ScottK> Agreed.
[16:17] <Hobbsee> ScottK: i guess this is the difference in thoughts - the people who agreed to it tend to agree that people will stay good, and will always DTRT.
[16:17] <Hobbsee> whereas we are aware that may not be the case.
[16:20] <Hobbsee> ScottK: i'd suggest you find some mega awesome way of getting it seen, because we're just going to run out of time here
[16:21] <cody-somerville> hmm?
[16:21] <ScottK> Hobbsee: I'm sort of hoping someone on the other channel will get excited.
[16:22] <Hobbsee> ScottK: i'm discussing it with jcastro here too
[16:22]  * Hobbsee looks up the bug
[16:22] <ScottK> K.
[16:24]  * Hobbsee cries
[16:24]  * Hobbsee doesn't want to use that abomination of a page
[16:25] <Hobbsee> https://bugs.edge.launchpad.net/ubuntu/+bug/210112
[16:25] <Hobbsee> there we are
[16:25] <ubotu> Launchpad bug 210112 in ubuntu "FFe for EnvyNG" [Undecided,Fix released]
[16:28] <Hobbsee> ScottK: remember, you must mention the word "veto" apparently.
[16:29] <ScottK> Well I got sick of arguing, which I probably shouldn't have.
[16:29] <kees> hola, can someone from motu-release review (and hopefully approve) bug 220273?
[16:29] <ubotu> Launchpad bug 220273 in mythtvfs-fuse "Please sync mythtvfs-fuse 0.5.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/220273
[16:31] <Hobbsee> ScottK: so you compromised the archive?!?!?
[16:31] <Hobbsee> ScottK: (all this applies to me too, though)
[16:31] <ScottK> I'm not sure.
[16:31] <Hobbsee> effectively
[16:31] <ScottK> I said I'm not going to approve it and I think it's a bad idea.
[16:31] <Hobbsee> if the guy turns bad, the entire archive is screwed.
[16:31] <Hobbsee> right.  so the others compromised it
[16:32] <ScottK> I'm more comfortable with that perspective.
[16:32] <Hobbsee> ScottK: if this is the new way of MOTU, then dude, i'm so not interested in playing ball.
[16:32] <Hobbsee> I have better things to do than turn this into an rpm-hell land.
[16:33] <ScottK> So far there's only been one person I've seen pushing for volume over quality.  I think the community as a whole is pretty against going down the bad road.
[16:36] <Hobbsee> ScottK: true.  but i don't think this is the same thing.
[16:36] <ScottK> I think it's "let's do it the easy way rather than the right way".  It's related.
[16:37] <Hobbsee> yeah
[16:37] <Hobbsee> ScottK: hey, now if you filed a removal bug, and i ack'd it, do you think they'd do it?
[16:37] <mok0> How long does it take from the time a build has completed, till it is available for new package builds?
[16:38] <Hobbsee> even better, kees could file the bug after his reactions in -hardended, and we could both ack it
[16:38] <ScottK> Hobbsee: I doubt it.  I think getting someone with a security perspective fired up about it is our best bet.
[16:38] <ScottK> Yep.
[16:38] <Hobbsee> heya dendrobates!
[16:38] <ScottK> It may be at this point changing permissions on the PPA is the best way.
[16:38] <dendrobates> Hobbsee: hi
[16:39] <Hobbsee> while they're out of the control of canonical, or core devs / motu, there's no guarentee that will help.
[16:39] <Hobbsee> as in, those actual teams, or subsets, not the users.
[16:39] <Hobbsee> er, not the developers in those teams
[16:39] <kees> so, my take on envyNG is that it fixes more than it breaks.
[16:39] <Hobbsee> kees: unless the developer goes bad.
[16:39] <Hobbsee> kees: or decides to take advantage of his free ride into ubuntu
[16:39] <ScottK> Yes, but in a really bad way from a security perspective.
[16:40] <kees> Hobbsee: true, but that's no different than before -- he was already providing updates to people directly.
[16:40] <emgent> heya kees :)
[16:40] <Hobbsee> kees: doesn't mean it's official, and doesn't mean it's supported by ubuntu.
[16:40] <kees> heya emgent
[16:40] <ScottK> kees: So any 3rd party crack is OK in the repos because it was distributed 3rd party before?
[16:40] <Hobbsee> kees: while third party packages can be blamed for dist-upgrades that they've caused, etc, the stuff in ubuntu is expected to actually work.
[16:41] <kees> Hobbsee: AIUI, the long-term goal has been to help get Alberto as close to motu as possible, which has proven a difficult process.
[16:41] <kees> ScottK: In general, I don't agree with that.  envy is a bit of a special-case.
[16:41] <Hobbsee> kees: i'm not comfortable with one person having direct access to the archive, no matter what they do.
[16:41] <ScottK> kees: What's the difficulty?
[16:41] <Hobbsee> speaking of which, i should get the chan contact of this chan changed to the irc council, instead of it being as me, for the same reason.
[16:42] <ScottK> kees: I'm not sure how it's a special case.  If it's ok to give non-developers access to updates, then it's OK.
[16:42] <ScottK> If it's not OK, then something needs to change.
[16:42] <Hobbsee> may as well throw out the SRU process if you were going to do that, too.
[16:42] <kees> ScottK: I think the "problem" is one of not having a "volatile".  envy's problems are the same as clamav's.
[16:43] <Hobbsee> kees: do we have clamav updates being pulled from a ppa too?
[16:43] <ScottK> kees: Yep.  And so I expend a lot of effort to work within the system.
[16:43] <ScottK> Hobbsee: We do not.
[16:43] <Hobbsee> good.
[16:43] <Hobbsee> hi tseliot, your package is being discussed.
[16:43] <cody-somerville> :(
[16:43] <kees> Hobbsee: no, but my point is, there is a need for "constantly updated package", that this seems to be similar to.
[16:44] <tseliot> Hobbsee: yes, I picked that up
[16:44] <ScottK> Agreed, but the solution is not hand out access to non-developers.
[16:44] <kees> please note, I'm not saying I'm happy about this, I'm saying I'm more comfortable with it being envyng than just some random package
[16:44] <Hobbsee> kees: so, SRU it.  last i checked, the requirements had been lessened.  If they're still not good enough, then they need fixing further, not circumventing.
[16:44] <Hobbsee> i see the point that it needs updating, i'm disagreeing with the way it happens.
[16:44] <imbrandon> hrm can i revert a whole working copy to a previous version ( svn )
[16:44] <kees> Hobbsee: right, that would be my quesiton as well -- why can't everything go into universe?
[16:45] <Hobbsee> kees: the stuff in the PPA?
[16:45] <kees> Hobbsee: right.
[16:45] <Hobbsee> kees: it gets updated a lot, apparently.
[16:45] <kees> clearly there isn't a distributability problem since it's in a PPA.
[16:45] <Hobbsee> apart from that, i'm unsure
[16:45] <ScottK> The only answer we got when the FFe was being reviewed was a bunch of Canonical people have reviewed this and it's good.  Please approve.
[16:46] <kees> since those things don't have external deps (like clamav) it should be trivial to rev them when they need it.
[16:46] <Hobbsee> I hate to think of mass-user systems being compromised if tseliot's ssh key / LP account does.
[16:46] <tseliot> Hobbsee: as I said, EnvyNG is updated only if there are bugs.
[16:46] <ScottK> All the more reason to not work around the system.
[16:46] <ScottK> tseliot: That's irrelevant to the question.
[16:47] <Hobbsee> tseliot: meant the drivers themselves
[16:47] <tseliot> ﻿Hobbsee: ah, ok
[16:48] <Hobbsee> tseliot: the main problem is that people don't want to trust, for the next 5 years, with no path of recourse, that the archive, by your account, won't get compromised.
[16:48]  * kees goes to comment on the bug
[16:48] <Hobbsee> whether that's by you, or someone else.
[16:48] <ScottK> kees: FYI, I ack'ed your mythtvfs-fuse sync for motu-release.
[16:48]  * kees hugs ScottK
[16:48] <ScottK> kees: We'll need more than that as it's already in the archive.
[16:48] <Hobbsee> tseliot: it backs people into a very tight corner, in the event that anything goes wrong.
[16:49] <Hobbsee> because they can't do anything.
[16:49] <Hobbsee> (short of ditching your LP account)
[16:50] <Hobbsee> or handing control to someone else, reverting the changes, and then ditching your LP account.
[16:50] <tseliot> Hobbsee: envyng --uninstall-all would do it
[16:50] <ScottK> tseliot: Depends on what it had installed.
[16:50] <Hobbsee> tseliot: which could have a rm -rf / in it, if someone (or you) compromised your account - which had gone thru no QA checks at all.
[16:50] <tseliot> ScottK: can you give me an example?
[16:51] <Hobbsee> it's almost a rootkit waiting to happen.
[16:51] <kees> ScottK: right, I'm going to talk to dholbach and pitti.
[16:51] <kees> ScottK: I suspect the best course is to move the drivers into universe, and do an SRU of envyng.
[16:51] <ScottK> kees: Yes.  Please.  (probably multiverse though).
[16:51] <kees> ScottK: right, yes
[16:52]  * Hobbsee scratches head
[16:52] <Hobbsee> does ppa allow stuff that falls into multiverse?
[16:52] <ScottK> Hobbsee: I think it does now.
[16:52] <Hobbsee> ah right
[16:52] <Hobbsee> not when i last saw the documentation, and helped write it
[16:53] <ScottK> If the drivers could go into Universe/Main, there wouldn't be a need for Envy at all.
[16:54] <tseliot> ScottK: would this be done for Hardy?
[16:54] <kees> I think that's an issue of a split between "well tested" and "bleeding edge"
[16:54] <ScottK> OK.
[16:55] <ScottK> I'm personally more worried about getting the trust boundry right.
[16:55] <leileilol> hm
[16:56] <leileilol> i'm about to release openarea-0.7.6 am i too late for this to be in the hardy repository? :(
[16:56] <ScottK> tseliot: That'd be my hope.
[16:56] <sebner> leileilol: yes
[16:56] <ScottK> leileilol: Unless it's only bug fixes and there's a MOTU that's really motivated to help get it in, yes.
[16:56] <tseliot> ScottK: then DKMS would have to be moved to main too
[16:57] <ScottK> IIRC DKMS is a management tool for stuff you still have to grab yourself.
[16:57] <leileilol> :(
[16:57] <kees> ScottK: lirc uses it.
[16:57] <leileilol> well 0.7.0 is incompatible with 0.7.6 servers and the versa
[16:57] <james_w> can anyone reproduce https://bugs.edge.launchpad.net/ubuntu/+source/aalib/+bug/218868 ?
[16:57] <ubotu> Launchpad bug 218868 in aalib "libaa1-dev uninstallable; causes FTBFS in other packages" [Critical,New]
[16:58] <james_w> is it amd64 specific?
[16:58] <ScottK> leileilol: Wouldn't it be better to call that 0.8 then.
[16:58] <ScottK> kees: Right, so another reviewed package uses it as a management tool.  No problems there.
[16:58] <leileilol> no because i'm saving that version number for a august 8 release
[16:59] <ScottK> Well breaking compatiibility in last digit releases is really confusing.
[17:00] <ScottK> leileilol: Get it into intrepid and then ask for a backport.
[17:02] <tseliot> ﻿ScottK: who (in your opinion) should update these drivers every time that a new version is released (e.g. by NVIDIA)?
[17:03] <Hobbsee> tseliot: anyone will do.  just by someone who actually goes thru code review.
[17:03] <ScottK> IMO nothing should get automatically installed in a user's system without a review by an actual Ubuntu develeper.  In the case of released systems such updates should go through the SRU/security/backports process.
[17:03] <Hobbsee> and those who have upload rights should be doing the code review
[17:08] <tseliot> Hobbsee: what if a user doesn't want to update the driver (e.g. if the latest driver contains a regression)? EnvyNG is something which you install only if you want the latest driver. Uploading the driver to main would force users to pinpoint the package version.
[17:08] <ScottK> tseliot: But updating EnvyNG would not do that.
[17:08] <Hobbsee> tseliot: i've got absolutely on problem with the concept of envyng.
[17:08] <ScottK> If the updates were all in Universe
[17:09] <Hobbsee> tseliot: i just think that *all* of it's updates should go through a comprehensive QA review, like it does for SRU in universe.
[17:09] <Hobbsee> like any other package
[17:10] <ScottK> Personally, I think EnvyNG hands the least open source friendly video company a lot of cash, so I'm not a fan, but this is entirely separate from my political reservations about it.
[17:10] <tseliot> Hobbsee: I have no problem with that. Finding someone who can review them would mean wasting the time of the kernel team, I guess.
[17:10] <Hobbsee> tseliot: so be it.
[17:10] <Hobbsee> tseliot: i'd prefer that, and to be sure of the quality of the archive, than the alternative.
[17:11] <tseliot> ﻿ScottK: my laptop has an Intel card, guess why...
[17:11] <ScottK> Mine too.
[17:11] <ScottK> So do all of my less than a handful of years old desktops.
[17:11] <tseliot> ﻿Hobbsee: let the kernel team decide about this. BenC reviewed the current packages but he's a very busy man.
[17:12] <Hobbsee> tseliot: i'm fairly sure that the kernel team will prefer a bit extra reviewing, compared to a possible compromised archive.
[17:12] <Hobbsee> last i checked, they don't sponsor fixes from anywhere, just to get them in.
[17:12] <ScottK> I'm confident that kees will approach the question with an appropriate sense of paranoia.
[17:13] <Hobbsee> tseliot: if you scrwe up, for eg, (and lets face it, we all do), you have no second chance - it goes straight to users stable systems.
[17:13] <Hobbsee> it being "official", that's usually bad for the ubuntu name.
[17:15] <kees> ScottK: I will try.  :)  It sounds like the "testing" problem is less of an problem than the "package sanity" issue.  envy is designed specifically to get bleeding-edge drivers, so obviously, only limited testing is possible (which is why the restricted drivers exist -- stability).  just making sure the drivers themselves are sanely packaged sounds like it needs a quick SRU-like review from motu or core-dev.
[17:15] <ScottK> Agreed.
[17:16] <ScottK> I'm mostly worried about the question of something other than the real driver getting directly provided to end users.
[17:16] <ScottK> kees: ^^
[17:17] <tseliot> ﻿kees: I agree with you
[17:17] <kees> ScottK: right, I'm with you there.  :)  I'm lumping this under "package sanity".
[17:17] <ScottK> OK.  We're on the same page then.
[17:18] <kees> tseliot: cool, we'll get this sorted out.  people want envy, we just need to make sure it's all happy.  :)
[17:18] <ScottK> Much like the flash-nonfree md5sum needs to be SRU'ed each time they update.
[17:19] <tseliot> ﻿kees: ok then ;)
[17:24] <mok0> ScottK, did you close bug  137519 in the changelog?
[17:24] <ubotu> Launchpad bug 137519 in sshfs-fuse "Please sync sshfs-fuse 1.9-1 (universe) from debian unstable (main)" [Unknown,Fix released] https://launchpad.net/bugs/137519
[17:24] <ScottK> It's a sync, so now.  Archive admins do that.  It just got done.
[17:24] <ScottK> now/no
[17:25] <mok0> Ah, ok
[17:45] <laga> how frozen are the archives?
[17:45] <mok0> laga: only bugfixes, and everything needs approval
[17:46] <laga> ah, that's good enough for me
[17:52] <mok0> I have a whole bunch of source packages that I need to recompile for hardy. What's the best way to do that?
[18:04] <elmargol> mok0: pbuilder or ppa
[18:04] <mok0> pbuilder
[18:05] <mok0> elmargol: I am writing a script this very minute
[18:06] <RainCT> mok0: I started writing a script for this for ScottK (but I'm not sure if I finished it.. :S)
[18:06] <mok0> RainCT: heh
[18:07] <RainCT> mok0: here it is: http://paste.ubuntu.com/7681/
[18:07] <mok0> ah, cool python
[18:08] <mok0> RainCT: thanks! I will take a look at it
[18:09] <RainCT> mok0: you create a file with a list of packages, run "./script_name file_list.txt" (and optionally as 2nd argument a directory - else it will create one in /tmp and tell you it's name),  and it will download the packages (with apt-get source), build them with pbuilder-dist, and stores the build logs
[18:10] <DktrKranz2> mok0: you may want to look at rebuildd too
[18:11] <mok0> DktrKranz2: Thx. Not much info in the manpage
[18:11] <mok0> :-)
[18:11] <DktrKranz2> heh
[18:12] <DktrKranz2> as usual, mine for deb-o-matic needs love too
[18:14] <RainCT> DktrKranz2: does rebuildd do the same as my script? (being more advanced, of course)
[18:15] <DktrKranz2> RainCT: TBH, don't know. IIRC, that program is meant to rebuild packages already in the archives
[18:15] <mok0> RainCT: It looks like it's the same thing
[18:15]  * DktrKranz2 leaves, back to aDSL-less status now \o/
[18:16] <RainCT> damn, why do I end up rewriting everything? LOL
[18:27] <RainCT> ScottK: could you have a look at bug #204600 please? (it's pretty trivial)
[18:27] <ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Low,Confirmed] https://launchpad.net/bugs/204600
[19:29] <nixternal_> anyone able to provide any additional MOTU/Packaging talks for OpenWeek?
[19:59] <afflux> I got a bit stuck with packaging: I'm using cdbs with python-distutils, I want to produce two packages: one python-foo, one python-foo-doc. The documentation is not built using distutils but by another command. How do I tell cdbs to 1.) use the other command for building the docs, 2.) install the distutils stuff to the python-foo package and the doc stuff to python-foo-doc?
[20:06] <RainCT> afflux: run that command in debian/rules (in the build/binary-package-name:: target)
[20:07] <afflux> what's target?
[20:08] <RainCT> afflux: section.. just write that and on the next line (indented) the code you want to run
[20:08] <afflux> hm, will check that
[20:08] <RainCT> afflux: and if cdbs puts the distutils stuff into the wrong binary package, there's a variable to overwrite that
[20:08] <afflux> *try
[20:08] <RainCT> (but I don't know which)
[20:10] <RainCT> afflux: (fyi, if the documentation was also installed by distutils then what you would have to do is use that variable to let it install the stuff in debian/tmp and then put it in the packages using install files)
[20:22] <ScottK> RainCT: Ack.
[20:23] <RainCT> ScottK: thx
[20:26] <zul> nixternal: your blog has blinded me..
[20:27] <nixternal> :)
[21:22] <RainCT> how can I test if a quilt patch applies?
[21:23] <sebner> RainCT: quilt push -a
[21:23] <sebner> RainCT: though all patches will be applied
[21:24] <RainCT> doesn't work.. No patches in series
[21:24] <RainCT> but there are patches listed in debian/patches/series
[21:24] <sebner> RainCT: and are there patches in debian/patches? ^^
[21:24] <RainCT> of course
[21:25] <sebner> wired
[21:29] <ScottK> Going through here: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=&build_state=depwait&start=0&batch=50 and fixing anything that's Universe and depwait on i386 or amd64 would be really handy and I'd ack fixes for that.
[21:30]  * ScottK is already taking care of python-omniorb
[21:30] <albert23> RainCT: did you export QUILT_PATCHES=debian/patches?
[21:43] <RainCT> albert23: thanks
[22:11] <kees> Hobbsee, ScottK: as a temporary work-around to bug 174038, do you mind if I upload a no-change version bump for mobile-player and mobile-application-service ?
[22:11] <ubotu> Launchpad bug 174038 in soyuz "bad md5sum in Packages file" [Undecided,Confirmed] https://launchpad.net/bugs/174038
[22:26] <RainCT> good night
[23:10] <vorian> ScottK: I didn't intend on sending that bug... sorry for the spam
[23:11] <vorian> ScottK: i marked it invalid