[00:05] <sistpoty> LaserJock: have an opinion to my post to -motu about SRUs done now? maybe you'd like to follow up?
[00:06] <sistpoty> jdong, TheMuso, imbrandon ^^ ?
[00:14] <LaserJock> sistpoty: done
[00:14] <sistpoty> thanks LaserJock
[00:17] <sistpoty> LaserJock: I'm not too sure if I understand your response. If the archives are open, it would be possible to upload a fix for intrepid (or otherwise sync one)?
[00:18] <sistpoty> LaserJock: or do you mean that we shouldn't wait on syncs getting performed in the first bits of intrepid, due to possible delays when waiting for a fix in hardy?
[00:19] <LaserJock> well, I don't want to force people to do syncs/merges before the toolchain has settled down, etc.
[00:19] <LaserJock> I believe the schedule for 8.04.1 is pretty quick
[00:20] <persia> Why not?  If such a sync/merge introduces some issue with the toolchain, we can fix that.  I'd rather have an unstable dev platform than have untracked critical bug fixes.
[00:20]  * persia thought 8.04.1 was for October
[00:20] <LaserJock> well, I'd rather get the SRU done
[00:20] <persia> Why not do both?
[00:20] <sistpoty> LaserJock: ah, k, that explains
[00:20] <LaserJock> because honestly we're already fighting to get people to do SRUs in the first place
[00:21] <slangasek> persia: July, not October
[00:21] <persia> For gutsy, ScottK pushed everything into hardy the day it opened, and afterwards we followed the "fix in hardy first" rule.
[00:21] <LaserJock> having them do 2 uploads rather than 1 is quite a bit
[00:21] <slangasek> (eew, trying to do a point release at the same time as a regular release, shudder)
[00:21] <persia> slangasek: Ah.  That matches the outstanding RC list better :)
[00:21] <LaserJock> especially if there are problems testing on Intrepid, etc.
[00:22] <LaserJock> I guess I would summarize my position with "let's be sane" :-)
[00:22] <persia> OK.  I can see that, and as long as there's an open intrepid task, maybe it makes sense for a short time.
[00:22] <slangasek> I hate being sane
[00:22] <LaserJock> if MOTU SRU sees that it should be trivial to get a sync/merge in Intrepid go ahead an have that done
[00:22] <LaserJock> but if I'm going to make people go through 3 weeks work to get an SRU in that could take 1 week without dealing with Intrepid
[00:23] <LaserJock> I have a hard time justifying that added burden to be honest
[00:23] <persia> Well, doesn't that match the normal model?  For SRUs where the issue doesn't exist in the current development release (and not do to a patch, but an API transition or something), the "fix in dev first" rule is often overlooked.
[00:24] <LaserJock> well
[00:24] <LaserJock> ssshhhh
[00:24] <persia> heh
[00:25] <LaserJock> you can't say that when the RM is looking ;-)
[00:25] <persia> I'd think the RM would agree that it's better to not FTBFS in a stable release, even if the ABI switched back, and the old source builds in the dev release, but I may be mistaken.
[00:26] <persia> s/ABI/API/
[00:26] <slangasek> I will neither agree nor disagree with a statement that I can't seem to parse :-)
[00:27] <sistpoty> heh, /me just wants to give people s.th. that they can work on right now *g*
[00:28]  * persia seconds sistpoty: Now is the best time to get testers for SRUs for hardy.
[00:28] <LaserJock> totally
[00:29] <sistpoty> yeah, and /me will in a few minutes give slangasek s.th. to put through the queue :P
[01:03] <sistpoty> slangasek: mind to approve xmms-crossfade from hardy-proposed? (it's a rebuild only)
[01:44] <sistpoty> lol, there's a lp team canonical-smokers *g*
[01:45] <wgrant> Can we avoid the SRU waiting period for upgrade failures?
[01:45] <wgrant> Particularly for trivial missing Conflicts/Replaces on python-*.
[01:46] <sistpoty> wgrant: well, that's motu-sru to decide imho
[01:46] <slangasek> sistpoty: hrrm, why are you not listed on https://launchpad.net/~motu-sru/+members as a current member if you're asking me to approve packages through hardy-proposed? :)
[01:46] <slangasek> oh, it's acked by jdong, ok :)
[01:46] <sistpoty> slangasek: because I've already got an ack from them ;)
[01:46] <sistpoty> heh
[01:46]  * jdong grins at the connotation of "oh. jdong acked it."
[01:47] <sistpoty> haha
[01:47]  * sistpoty is usually quite good when it comes to buerocracy... I'm german :P
[01:51] <LaserJock> sistpoty: haha
[01:59] <sistpoty> thanks slangasek!
[02:17]  * sistpoty goes to bed... gn8 everyone
[02:17] <wgrant> Night sistpoty.
[02:24] <Kafka> what is motu ?
[02:26] <ScottK> Kafka: https://wiki.ubuntu.com/MOTU
[02:26] <ScottK> Good evening everyone.
[02:26] <wgrant> Morning ScottK.
[02:27] <ScottK> Re: SRUs, I personally think MOTUs should be sensible enough we don't need a motu-sru team, but it doesn't seem I'll get my wish on that.
[02:27] <wgrant> ScottK: 'should' being the keyword there.
[02:27] <ScottK> Yep.
[02:28] <ScottK> I think it'd be fine to leave -proposed uploads open and then use peer pressure to 'encourage' people to learn better habits.
[02:28] <ScottK> But that's just me.
[02:29] <jdong> ScottK: I'm not so sure about that though, while reviewing the SRU queue it's taken at least one interation on average before version numbers are correctly mangled, etc
[02:30] <jdong> ScottK: I personally would like easier SRU'ing too but I think that's a cultural/social mentality change rather than a process change
[02:30]  * ScottK notes that one member of the MC thought it appropriate to upload untested stuff to -proposed to find out if it worked.
[02:31] <ScottK> I will confess to having almost completely lost interest in doing SRUs since the new team was stood up.
[02:32] <jdong> ScottK: personally I wouldn't mind a much more liberal SRU policy that just bars backwards-incompatible changes, i.e. slightly more conservative than Fedora
[02:33] <jdong> i.e. I'm looking at the new KTorrent point-releases and I'm tempted to do those as SRUs
[02:33] <jdong> but that'll probably raise more eyebrows than I want
[02:33] <ScottK> Aren't those in Main anyway?
[02:33] <jdong> ScottK: even more unfortunately, yes.
[02:36] <ScottK> Are the mirrors starting to calm down yet?
[02:36] <jdong> nope
[02:38] <ScottK> My desktop still has my original Kubuntu install from two years ago (with Automatix - before I knew better).  Once things calm down a bit, I'm going to see how well that upgrades and maybe file some bugs/do some SRUs.
[02:38] <wgrant> Bad ScottK.
[02:38] <ScottK> I was new.  I didn't know better.
[02:38] <wgrant> At least it's dead now.
[02:38] <ScottK> Yep.
[02:39] <ScottK> Is Edgy eol yet?  The 26th is the day, right?
[02:40] <slangasek> the 26th, so I guess it won't be moved around until Monday :)
[02:41] <wgrant> Hm, it's the 26th UTC now. I suppose Edgy is dead.
[02:41]  * wgrant wonders how many security tasks it has open.
[02:42] <kees> none now!
[02:42] <wgrant> Haha.
[02:42] <slangasek> :-)
[02:42] <wgrant> Good riddance.
[02:42] <jdong> lol
[02:42] <wgrant> Edgy has some 129 tasks open. Ew.
[02:43] <pwnguin> i wonder how much attention stuff gets after 12 months
[02:44]  * ScottK deletes his edgy pbuilder chroot tarball.
[02:44] <wgrant> pwnguin: SRUs: not much. Security: as much as the rest, as long as the code isn't too different.
[02:45] <ScottK> Backports, not much either (people pretty much stop asking).
[02:45] <wgrant> I can't imagine the type of people that want backports would be running older releases.
[02:45] <pwnguin> is abiword likely to get a backport /sru?
[02:45] <nxvl> ScottK: i update my system every 4/6 months :D
[02:45] <jdong> wgrant: typically interest dies down in exponential decay when a new release is available
[02:46] <ScottK> Speaking of which ...
[02:46] <jdong> wgrant: at most requests come in for the n-1th release if the nth release is problematic
[02:46] <wgrant> pwnguin: It will definitely not be SRUed to 2.6.
[02:46] <wgrant> jdong: Aha.
[02:46] <ScottK> slangasek: Would you be willing to put on your archive admin hat and do some backports stuff?
[02:46] <jdong> pwnguin: SRU is highly unlikely, but I'd be happy to coordinate backports :)
[02:47] <pwnguin> jdong: dont quote me on this, but at one point it was looking to be MIR'd
[02:47] <wgrant> Can we please get *-changes to show copies between pockets?
[02:47] <jdong> pwnguin: yeah I understand there was also a major update planned that missed Hardy
[02:48] <jdong> pwnguin: and BTW if it's MIRed it's less likely to get SRU's :D
[02:48] <wgrant> Hmmm.
[02:48] <wgrant> abiword source is in main, binary are in universe.
[02:48] <wgrant> *binary is
[02:48] <wgrant> Or *binaries are.
[02:49] <pwnguin> i dont know what happened, but someone's slowly working on a ppa for 2.6. a few users are angry, but really, abiword doesn't do release engineering that I can see
[02:50] <pwnguin> i dont use it myself; im more interested in the new release of desmume
[02:53] <ScottK> Phere this from Misc development news (#7):
[02:53] <pwnguin> you misspelled ph33r
[02:53]  * wgrant wonders how the CDBSesque debhelper 7 is.
[02:53] <ScottK> debhelper v7 - In this version I've  tried to learn some things from cdbs, and the result is a new "dh"  command which can be used to create debian/rules files that are as short as 3 lines for many packages.
[02:54] <ScottK> Apparently that's a feature goal (being CDBS like).
[02:55] <pwnguin> well, if it means more people can write packages right the first time
[02:55] <wgrant> ScottK: It hopefully won't be as much of a black box, though.
[02:55] <ScottK> Yeah.  Of course hope isn't much of a plan.  We'll see.
[02:57] <pwnguin> he seems to be a smart guy
[02:57] <wgrant> He is.
[03:00] <pwnguin> jdong: so SRU might be on temporary reprieve, what about backports?
[03:02] <pwnguin> desmume released on the 22nd
[03:02] <jdong> pwnguin: ok, who has packages so far?
[03:02] <jdong> who == upstreams
[03:03] <pwnguin> what?
[03:03] <ScottK> Is it in Debian yet?
[03:04] <pwnguin> thank you for translating
[03:04] <pwnguin> looks like no
[03:05] <pwnguin> unfortunately, it's a bit of pita to even get the build deps from ubuntu archives atm
[03:05] <jdong> pwnguin: sorry for the unclear wording
[03:06] <jdong> pwnguin: right now I will consider for hardy-backports packages that are (1) in Debian already (2) in a PPA with an implicit contract that they are to be uploaded to Intrepid
[03:08] <pwnguin> so presumably the ppa would be from someone with upload priv's
[03:09] <ScottK> And (as the core-dev I'm guessing he'll ask to upload it to backports) I'll add that if it's in a PPA, the packaging needs to be derived from Debian's.  Don't fork the package.  I won't upload that.
[03:10] <ScottK> The best thing might be to offer to help the Debian Maintainer get his upload done sooner.
[03:10] <pwnguin> thats what i was thinking
[03:10] <pwnguin> debian games handles it
[03:11] <ScottK> "Hi.  We're from Ubuntu and we're here to help."
[03:11] <pwnguin> heh
[03:14] <Hobbsee> "and wearing our bullet proof vests, just in case you were wondering"
[03:16] <jdong> "May we suggest changing the background of your application to orange and brown..."
[03:16] <ScottK> There's enough people on brainstorm suggesting Kubuntu do that.
[03:17]  * ScottK took a little time today to hunt through brainstorm today.
[03:17] <ScottK> I was honestly looking to get fired up to implement something for Intrepid.
[03:17] <ScottK> The result was, yawn.
[03:17] <pwnguin> make me an onscreen keyboard for gdm
[03:18] <ScottK> I don't run Gnome.  Odd of me being interested in developing for it are pretty low.
[03:18] <pwnguin> kubuntu uses kdm?
[03:18]  * ScottK decides to catch up on BOFH.
[03:18] <ScottK> Yes.
[04:18] <Drezard> hey?
[06:31] <LaserJock> quiet evening
[06:57] <LaserJock> man, how can a calculator be so sucky?
[06:57] <LaserJock> how hard can it be, honestly
[06:59] <LaserJock> 2,,560.06 != 2,560.06
[07:22] <Arelis> Can i post broken packages here?
[08:00] <LaserJock> dang, earthquakes
[08:00] <wgrant> LaserJock: How significant?
[08:05] <LaserJock> 5.0 just now
[08:05] <LaserJock> really shook things
[08:06] <LaserJock> we've had something like 400 of > 1.0 in the last 2 months
[08:06] <LaserJock> but in the last week it's been 1 or 2 you could feel ever day or so
[08:06] <LaserJock> it's creeping me out
[08:07] <highvoltage> LaserJock: omg
[08:11] <geser> good morning
[08:19] <LaserJock> highvoltage: yeah, not cool
[08:19] <LaserJock> highvoltage: http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/US2/39.41.-121.-119_eqs.php
[08:20] <LaserJock> that's all about 5 miles from me
[08:32] <LaserJock> darn, there's another one
[08:47] <LaserJock> woah, a water flume broke in the earthquake
[08:47] <LaserJock> looks like a waterfall on the TV
[08:48] <wgrant> Fun.
[08:49] <LaserJock> alright, well I'm gonna try to get some sleep
[08:49] <LaserJock> my stomach doesn't like the shaking though
[08:50] <laga> :/
[10:30] <Iulian> G'morning
[10:32] <jpatrick> morning Iulian
[10:44] <Le-Chuck_ITA> Hi there, if I have patched a source package (say rhythmbox) how can I know if it uses dpatch? Or am I wrong and dpatch does not require specific support from a package?
[10:48] <Le-Chuck_ITA> forget it
[10:54] <CrippledCanary> what should the target be for a hardy SRU hardy-proposed or just hardy
[11:11] <Le-Chuck_ITA> hi all again, a quick question: how would you version a ppa package so that newer ubuntu versions DON'T supercede the PPA but it's still clear on which ubuntu version the ppa package is based?
[11:12] <Le-Chuck_ITA> something like 0.11.5-0ubuntu7~myppa will be superceded 0.11.5-0ubuntu8
[11:20] <Le-Chuck_ITA> ping :)
[12:33] <emgent> heya
[12:43] <Iulian> Hi emgent
[13:56] <tuxmaniac> is there any way to share my packages for the current release?
[13:57] <tuxmaniac> LP PPA allows uploads to only development release and not current release
[14:29] <Amaranth> tuxmaniac: err, since when?
[14:29] <Amaranth> tuxmaniac: I was building feisty packages during gutsy development (backports)
[14:32] <tuxmaniac> Amaranth: I got this automated email. Part of which is pasted here http://paste.ubuntu-nl.org/64515/
[14:41] <bddebian> Heya gang
[15:00] <ScottK> tuxmaniac: I'm going to guess you tried to upload to Ubuntu and not to your PPA.  That's the message you get when you do that.
[15:14] <fargiolas> hey, i'm the author of gnome-mastermind, I've just solved an issue that happened with recent cairo versions (so with hardy) and made the game look really ugly. Is there a way to push this release into hardy without wait for ubuntu next release?
[15:33] <fargiolas> nobody in? :(
[15:34] <laga> fargiolas: you need to do a stable release update. let me get you the link
[15:35] <laga> https://wiki.ubuntu.com/StableReleaseUpdates
[15:38] <fargiolas> laga: do i need to first submit a bug report about the problem I've fixed and mark it as fixed?
[15:40] <laga> fargiolas: no, i think you need to open a bug and leave it open. it'll be marked as fixed when it's uploaded AFAIK
[15:41] <laga> but i'm not very experiencied with SRUs :/
[15:49] <ScottK> fargiolas: File the bug, attach your patch, and then subscribe the motu-sru team.  One of them will let you know if they think it is appropriate for an SRU.
[15:50] <tuxmaniac> ScottK: heh. true. thanks for the info. got accepted now
[15:51] <tuxmaniac> :-)
[15:52] <fargiolas> ScottK: thanks, does it matter if instead of the patch i attach a link to new release?
[15:52] <ScottK> fargiolas: It needs to be a minimal patch to fix the problem, so yes.  We sometime do micro-release updates, but it's very rare.
[15:53] <fargiolas> I'll attach both svn diff and link to release
[16:23] <fargiolas> ScottK: submitted, #222580
[16:26]  * fargiolas hopes everything is ok
[16:28] <fargiolas> sru wiki page talks about preparing an updated package but I doubt it should be me to do this.. I'm not a ubuntu developer I don't even know where to start
[16:28] <ScottK> fargiolas: The report looks appropriate.  Up to motu-sru to decide if they think it's worth a stable update.
[16:29] <ScottK> fargiolas: If motu-sru approves it, then I think someone can probably be found to package the fix.
[16:29] <fargiolas> ScottK: good, so it's a minor fix but since it is a game, having ugly graphical glitches is bad! let's hope sru team will agree :)
[16:30] <fargiolas> ScottK: thanks for your hints
[16:30] <ScottK> You're welcome.  I hope it works out.
[17:06] <CrippledCanary> I have found a bug (and filed it https://bugs.launchpad.net/ubuntu/+source/smstools/+bug/221973)
[17:06] <ubotu> Launchpad bug 221973 in smstools "smstools folder under /var/run isn't recreated after reboot" [Undecided,New]
[17:06] <CrippledCanary> I also made a debdiff and what should I do next to get it in to a SRU
[17:07] <ScottK> subsribe motu-sru to the bug.
[17:07] <ScottK> subscribe even
[17:08] <CrippledCanary> even... even who?
[17:08] <ScottK> subscribe motu-sru to the bug.
[17:08] <CrippledCanary> just did that
[17:08] <ScottK> I just misspelled it the first time.
[17:09] <ScottK> Then you wait for them to approve it.
[17:09] <CrippledCanary> Ok...
[17:10] <CrippledCanary> I know that it probably is a bit hectic these days but how long does it usually take before someone does anything with it?
[19:54] <RainCT> hey
[19:55] <highvoltage> hey RainCT
[19:55] <RainCT> I warn you, if you ever run a packaging jam, DO NOT show the espeak! lol
[19:55] <highvoltage> heh. espeak ftw
[19:56] <LaserJock> hi highvoltage and RainCT
[19:56] <highvoltage> howdy LaserJock
[19:58] <RainCT> pers 1: "did you know that 'archive' is pronounced 'arkive'?"; pers 2: "what? really?"; pers 1: "yeh"; pers 2: "really??"; me: "Ubuntu comes with a text-to-speech installed by default. try 'espeak archive'". for the next 20 minutes you were hearing espeak's voice from everywhere xDDD
[19:58] <RainCT> Hi LaserJock
[19:58] <LaserJock> highvoltage: we had two more little earthquakes last night
[19:58] <LaserJock> 3.somethings
[20:00] <highvoltage> LaserJock: that must be nerve-wrecking. how are you guys doing there?
[20:00] <highvoltage> LaserJock: any damages so far?
[20:00] <LaserJock> highvoltage: not here, just rattled dishes and things
[20:01] <LaserJock> at the epicenter (like 5 or so miles away) it broke some windows and some cracks in walls apparently
[20:02] <slangasek> huh. where is "5 miles away" in your case?
[20:05] <LaserJock> slangasek: well, http://quake.wr.usgs.gov/recenteqs/Maps/120-39.htm
[20:05] <highvoltage> reno, isn't it?
[20:05] <LaserJock> west Reno is where they're hitting
[20:06] <slangasek> ah
[20:06] <LaserJock> the 4.7 last night was a pretty good shake
[20:06] <LaserJock> I think that's the largest I've been in
[20:07] <LaserJock> but the really concerning part is just how many we've been having
[20:08] <LaserJock> it seems like we're having a big increase in severity and frequency
[20:13] <LaserJock> is intrepid open yet?
[20:13] <LaserJock> seems like Hardy was open like the day after Gutsy was out the door
[20:15] <smarter> LaserJock: IIRC, it was two weeks after gutsy release
[20:15] <smarter> but keep an eye on http://archive.ubuntu.com/ubuntu/dists/
[20:23] <smarter> If I want to maintain a package I made in universe, can I just create a branch in code.lp.net/~myusername and link to it in a Vcs-Bzr field?
[20:24] <smarter> or should I create a lp.net/<application> for every app?
[20:26] <LaserJock> these are existing apps?
[20:26] <smarter> yes
[20:26] <LaserJock> well, either/one/ or none would work :-)
[20:27] <LaserJock> it's often good to register the project on LP
[20:28] <smarter> even if I'm not the project leader at all?
[20:29] <LaserJock> sure
[20:29] <LaserJock> anybody can register a project
[20:30] <smarter> ok
[20:31] <LaserJock> smarter: but it's not required by any means
[20:31] <LaserJock> you don't even have to put your bzr branch anywhere or use bzr
[20:31] <smarter> yes, but I like bzr :)
[20:31] <smarter> and it's the recommended way to make your bzr branch public?
[20:32] <LaserJock> I don't think there's a recommended yet
[20:32] <LaserJock> but it wouldn't hurt, that's for sure
[20:33] <smarter> okay, thanks for your help
[20:46] <jdong> *urgh* I should change that
[20:46] <jdong> you can tell I haven't started up xchat in YEARS
[20:48] <Iulian> Haha
[20:48]  * Iulian wonders why he put that quit message.
[20:49] <laga> heh
[20:50] <highvoltage> jdong: what do you usually use? the irc client of the future?
[20:50] <jdong> irssi :)
[20:50] <highvoltage> yes, that's it
[20:50] <jdong> started xchat to remind myself of the interface of chanserv.py
[20:51] <jdong> I'm aiming to clone it in perl this weekend
[20:51] <highvoltage> what does it do?
[20:51] <highvoltage> oh, of course, d'oh!
[20:51] <highvoltage> sorry, had a long day :)
[20:51] <jussio1> heya all
[20:52]  * jussio1 slips quassel into jdong's pc
[20:52]  * Iulian is forced to use 'running on CYGWIN_NT-6.0 i686'
[20:52] <Iulian> Just for a couple of days...
[20:53] <highvoltage> Iulian: http://www.irssi.org/
[20:53] <highvoltage> you get irssi for windows too :)
[20:53] <jdong> Iulian: why not use SUA if you're running NT6?
[20:56] <Iulian> highvoltage: That's what I'm using right now.
[20:57] <Iulian> jdong: SUA?
[20:58] <jdong> Iulian: Services for Unix Applications
[20:58] <Iulian> Aww
[20:58] <jdong> Iulian: it's a POSIX layer directly in the kernel
[20:58] <jdong> gonna run quite a bit faster than Cygwin
[20:58] <jdong> I've heard pkgsrc works with it too
[20:59]  * Iulian has to do some testing with it.
[21:09]  * Iulian *yawns*
[21:29] <CyberMatt> question what does dpkg-genchanges: failure: cannot read files list file: No such file or directory mean
[21:29] <CyberMatt> more specifically what did i do wrong
[21:51] <CyberMatt> nevermind got it sorted
[22:43] <guja_nebeska> Hello.
[22:43] <guja_nebeska> I'd like to start with Ubuntu development. Start learning basics, and when I became experienced, than do more serious stuffs.
[22:43] <guja_nebeska> Suggestions? Thank you.
[22:44] <iulian> guja_nebeska: See topic.
[22:45] <guja_nebeska> https://wiki.ubuntu.com/MOTU/Contributing ?
[22:45] <iulian> Exactly
[22:45] <guja_nebeska> Any suggestions from you?
[22:45] <guja_nebeska> I am totaly begginer, but willing to learn.
[22:46] <LaserJock> guja_nebeska: what kinds of things would you like to do?
[22:47] <LaserJock> right now we're kinda at a slow time, finished up Hardy and waiting for Intrepid to get going, but there's a lot of bug work that needs to be done
[22:47] <guja_nebeska> LaserJock, well, basicly I am interested in helping Ubuntu community in any kind possible. Having in mind that I am begginer familiar with assembly and C language.
[22:47] <guja_nebeska> So, what begginer can learn and start working at that point.
[22:48] <guja_nebeska> If that's bug solving, than bug solving.
[22:48] <guja_nebeska> I need to learn first a lot.
[22:48] <guja_nebeska> But I am willing to do that.
[22:48] <guja_nebeska> I have time and will.
[22:49] <laga> that's great :) are you interesting in something special? lots of open source development happens because someone has a problem/need and fixes that
[22:50] <guja_nebeska> Well, I am interested in hardest thing that exists. But that's job of seriously pro programmers, I suppose. :o)
[22:50] <LaserJock> do you have a particular area of software you're interested in?
[22:50] <LaserJock> we have something like 30-40k open bugs right now
[22:50] <LaserJock> I'm sure they'd keep you busy ;-)
[22:51] <guja_nebeska> Let's say I am interested in p2p programes, internet programmes at all.
[22:51] <guja_nebeska> But as I said, I need to learn first about bugs, ways to solve them, etc.
[22:51] <megabyte405> go find an OSS one you use, and contribute to it by fixing a bug and sending the patch to their mailing list
[22:51] <LaserJock> well, we do have a P2P team I believe
[22:52] <megabyte405> as in, jump right into the action, using google frequently
[22:52] <sebner> LaserJock: true
[22:52] <megabyte405> most development takes place upstream
[22:53] <guja_nebeska> Okay. I will now go to follow the registration instructions.
[22:53] <guja_nebeska> If I have some questions, I'll ask here.
[22:54] <LaserJock> guja_nebeska: you might be interested in https://launchpad.net/~motu-p2p
[22:54] <LaserJock> specifically https://bugs.launchpad.net/~motu-p2p/+packagebugs
[22:54] <LaserJock> that might give you a launching point :-)
[22:55] <guja_nebeska> LaserJock, thank you, i'll check those links right now.
[23:00] <guja_nebeska> What do I need to know when fixing any bug?
[23:01] <guja_nebeska> Do I need to know any specific programing language?
[23:01] <LaserJock> not particularly
[23:01] <LaserJock> if it's a packaging bug you just need to know packaging
[23:02] <LaserJock> if it's a code bug it's good to have some programming knowledge so you can have a look at the actual bug
[23:02] <guja_nebeska> Sorry now for lame questions, but need to hear that in simple language. :o)
[23:02] <LaserJock> often times we're moving things between upstream (Debian or the software authors) and pulling back down fixes, etc.
[23:02] <megabyte405> guja_nebeska: it depends ont he project you pick.  For instance, AbiWord is written in C++, so if you've worked with a c-like language and object-oriented programming you can handle mostof the bugs eventually :)
[23:03] <LaserJock> well, what we do is take software from Debian or from the app's authors
[23:03] <guja_nebeska> For example: Someone has problems with dunno, pidgin.
[23:03] <LaserJock> and then we add in all the packaging "bits"
[23:03] <guja_nebeska> And it sends some bug report.
[23:03] <guja_nebeska> In bug report it says:
[23:03] <megabyte405> guja_nebeska: then you go fix it with Pidgin, and file a bug with the distributions to request that they update their version
[23:04] <guja_nebeska> That's my next question, how do I know where's the problem? Do I need to know exactly what's wrong with that part of Pidgin code and whats in conflict with Ubuntu architecture, or what?
[23:04] <guja_nebeska> I mean, I can't just start fixing bug if I don't know a thing.
[23:05] <LaserJock> so you need to do some testing perhaps, to verify the bug
[23:05] <LaserJock> then you can forward the bug upstream
[23:05] <LaserJock> or if you can fix it we can upload a fix and send it upstream
[23:06] <megabyte405> guja_nebeska: the bug could be in two places - it could be an ubuntu-only thing, or it could be a problem with the upstream code (pidgin) and depending on the problem, either could be likely
[23:07] <megabyte405> guja_nebeska: so if you're starting from the Ubuntu point of view, a launchpad bug, you first want to test it in another distribution, or with a manually compiled version (as opposed to the ubuntu package)
[23:07] <megabyte405> if you find it's upstream, then you find/file a bug upstream, and if you feel like it, go debug it and fix it
[23:07] <megabyte405> if you find it's ubuntu, then you try to figure out what might be causing the problem
[23:07] <RainCT> good night
[23:08] <guja_nebeska> megabyte405, and to do that, I need to be perfectly good knower of Ubuntu?
[23:08] <megabyte405> in either case, the final product is a patch sent to the appropriate folks, as high up as possible (that is, if it happens on Fedora as well as Ubuntu, get that patch to Pidgin and just mention it to ubuntu)
[23:09] <megabyte405> guja_nebeska: no, of course not - there is no complete expert.  You learn as you go, and such learning is easier when it's interesting to you, which is why I suggested finding an upstream project that you personally use - something interesting
[23:09] <megabyte405> you can't have the whole distribution in your mind at once to fix a bug - most bugs are a lot more narrow than that (the package, the upstream source, or dependent packages)
[23:09] <LaserJock> guja_nebeska: you just do what you can
[23:09] <guja_nebeska> Well, I am using Hardy on 64bit Intel based Macbook.
[23:10] <LaserJock> guja_nebeska: if you can't fix/figure out a bug just leave it alone
[23:10] <guja_nebeska> I am going to meet with lots of problems.
[23:10] <megabyte405> wouldn't imagine why
[23:10] <guja_nebeska> I solved yesterday iSight camera problem.
[23:10] <LaserJock> lots?
[23:10] <guja_nebeska> Well, no lots, but when you are begginer, it can be hard a bit. :o)
[23:11] <guja_nebeska> From dunno which reason, iSight was making problems on 64-bit intel.
[23:11] <guja_nebeska> And it took me few days to figure out why.
[23:11] <megabyte405> did you file a bug with your issue and how you solved it?
[23:12] <jdong> megabyte405: I believe he refers to bug 185634
[23:12] <ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634
[23:12] <megabyte405> ah, well then :)
[23:12] <guja_nebeska> Well, uvcvideo module was making some problem when I upgrade it from Gutsy to Hardy.
[23:12] <guja_nebeska> And, you see, I didn't read that page.
[23:12] <jdong> the way uvcvideo handles firmware loading changed from gutsy to hardy
[23:12] <jdong> but the userland tools to finish the job didn't get into hardy
[23:13] <jdong> *grumble*
[23:13] <megabyte405> jdong: nice job on the quick bug pull - you remind me of a individual we have in AbiWord who I swear can search bugzilla mentally faster than I can using a browser and keyboard shortcuts :D
[23:13] <megabyte405> ah, bugger - regressions suck
[23:13] <jdong> megabyte405: yeah, they do. I'm all for taking as much hackery as possible out of the kernel, but it sucks macbook users now have to resort to 3rd party packages to get their camera working
[23:14] <jdong> I think the best fix at this point is the fast track (grin) the isight-firmware-tools package to Intrepid and backport it
[23:14] <megabyte405> jdong: yeah that's a real bugger, esp. since this is a darn nice webcam - one of the best I've personally used (which means it's better than the cheapy ones I bought or inherited)
[23:14] <jdong> agreed
[23:16] <LaserJock> jdong: perhaps an SRU? :-)
[23:16] <jdong> LaserJock: haha "hey pitti, look away, we're about to add a hal firmware hook...."
[23:17] <LaserJock> I'm pretty sure we've done worse before but it's probably not good to get into the habit ;-)
[23:18] <jdong> LaserJock: at least not until we have official blessed policies regarding such matters
[23:18] <jdong> LaserJock: i.e. looking at the ktorrent-kde4 3.0.1->3.0.2, I'd personally rather just import the new version
[23:18] <jdong> though that won't fly well with our current policy
[23:19] <LaserJock> depends on the definition of "minimal"
[23:19] <LaserJock> i.e. "minimal change that makes it trivial to fix the bug" for instance ;-)
[23:20] <jdong> LaserJock: minimal inconvenience to the developer ;-)
[23:20] <LaserJock> exactly
[23:20] <jdong> LaserJock: the current verification procedures also makes it extremely difficult to fix rare crasher bugs
[23:20] <jdong> i.e. stuff that doesn't have an explicit test case
[23:21] <jdong> "Start a torrent.... wait 2 to 80 hours....."
[23:21] <LaserJock> yeah
[23:22] <LaserJock> I tend to think upstream testing of a particular upstream release should also be taken into account
[23:22] <LaserJock> since often times they get more real testing done than we will
[23:22] <jdong> LaserJock: indeed. And often times us doing a skim-through-svn-changesets backport means deriving a worse version than newest upstream too
[23:23] <LaserJock> precisely
[23:25] <LaserJock> however, I still need to figure out how to deal with the tendency to have "well, if you get the *latest* release you'll have even more bugs fixed" tendency
[23:25] <LaserJock> s/tendency//
[23:25] <jdong> LaserJock: well sometimes IMO following latest upstream versions is a distribution's best policy.
[23:26] <jdong> LaserJock: of course there's clearly things that doesn't apply to (server stack, volatile ABI/API...)
[23:26] <LaserJock> sure
[23:26] <jdong> but the Fedora update policy is pretty inspiring IMO
[23:26] <jdong> and we already have Backports which is somewhat chartered with the ability to implement Fedora's update policy
[23:27] <jdong> I think we should try Backports as a test base for universe new-point-release style updates
[23:27] <jdong> of course excluding things that would cause rev-dep ripples
[23:27] <jdong> the way we do SRUs on main isn't scaling all that well to universe
[23:27] <jdong> it seems like the average sentiment here is that we'd rather not fix a bug than go through the SRU procedure
[23:28] <jdong> and if it's between THAT an introducing new upstream versions, IMO the latter might indeed be better
[23:28] <laga> jdong: yeah. SRU has strict requirements.
[23:28] <laga> and is a lot of paperwork (IMHO)
[23:28] <LaserJock> I don't think the paperwork is all that much of a problem right now
[23:28] <LaserJock> but some other aspects could be
[23:29] <laga> LaserJock: well, getting a debdiff etc is annoying for me when I have a motu handy which can sponsor from a  bzr checkout directly. but that's a special case.
[23:29] <LaserJock> well, a debdiff should be trivial
[23:30] <jdong> the more I think about it, the more I think ScottK's idea with just allowing all MOTUs to upload to -proposed isn't a bad idea
[23:30] <jdong> maybe we can then put a REVU-style ACK/NACK mechanism on top of that
[23:30] <laga> LaserJock: it's an additional step. granted, i'm lazy.
[23:30] <LaserJock> laga: why is it additional?
[23:30] <jdong> laga: well QA'ing updates is important, and IMO (1) attaching a debdiff (2) getting 3 ACKs on the proposed build, are the two ESSENTIAL steps
[23:31] <LaserJock> jdong: yeah, it seems to me that testing is the most important aspect
[23:32] <laga> jdong: i'll agree with (2), and (1) is very convenient for anyone who reviews the ticket. i'll take back anything i've said about debdiffs then ;)
[23:32] <LaserJock> I do a debdiff on virtually every upload I do
[23:32] <LaserJock> just for me to check
[23:32] <jdong> LaserJock: me too. If nothing else, for a final sanity check
[23:32] <LaserJock> so uploading that to a bug is trivial
[23:32] <jdong> and I've definitely caught mistakes from doing so
[23:32] <laga> LaserJock: i usually use bzr diff, because everything i do is in bzr
[23:33] <LaserJock> laga: but that isn't the same as a debdiff
[23:33] <jdong> laga: well supplying a bzr diff would suffice too
[23:33] <LaserJock> although it's better than nothing for sure
[23:33] <jdong> laga: we're humans reviewing these things ;-)
[23:33] <jdong> we can cope
[23:33] <jdong> I just want to see the kinds of changes going in to make sure they are sane
[23:33] <jdong> and also scan for obvious versioning or distro-targeting bugs
[23:33] <laga> a debdiff will catch additional things, though. like additional files someone forgot to bzr add
[23:34] <LaserJock> and stuff done in the clean rule :-)
[23:34] <LaserJock> it amazing how much crap ends up in .diff.gz files from clean rules :-)
[23:34] <jdong> indeed
[23:35] <LaserJock> I was just looking at a SRU where the debdiff is 496KB
[23:35] <jdong> lol
[23:35] <LaserJock> and I think all but 4KB of that is autotools junk
[23:35] <LaserJock> although it's a new upstream release
[23:36] <LaserJock> so there's some little not-exactly-minimal bits
[23:36] <jdong> LaserJock: I'm tempted to let most of that slide for universe
[23:36] <LaserJock> but still, I'm pretty sure it's all automake 1.9 -> 1.10 stuff
[23:37] <LaserJock> jdong: then have a look at bug #222580
[23:37] <ubotu> Launchpad bug 222580 in gnome-mastermind "GNOME Mastermind grid is shifted to the right with new cairo releases" [Undecided,New] https://launchpad.net/bugs/222580
[23:37] <LaserJock> ;-)
[23:38] <LaserJock> I wonder if people are somewhat wary of doing SRUs because it's more of a long-term commitment
[23:38] <jdong> LaserJock: his diff definitely looks good
[23:39] <LaserJock> like rather than just sponsoring an upload you've got probably something like a week of going through the process
[23:39] <jdong> LaserJock: well my personal opinion on why people don't do SRUs is because as soon as we release one release our culture says it's "frozen" so let's go work on something new and shiny
[23:40] <jdong> I don't know how to "fix" that. I don't want to suggest yet-another-new-MOTU-team.... :D
[23:40] <LaserJock> I wish we had something like a developer survey where we could ask such things
[23:40] <jdong> but if giving hopefuls a cookie and badge makes them fix stable bugs for us...
[23:40] <jdong> :)
[23:40] <LaserJock> maybe SRUs are perceived to be harder than they are?
[23:40] <jdong> LaserJock: that's possible too
[23:41] <LaserJock> or people have been burned in the past with a different policy?
[23:41] <jdong> LaserJock: there isn't a 5-page wiki page and 1-page writeup to do for standard universe uploads
[23:41] <jdong> and some of the previous SRU policies have been... retentive.
[23:42]  * jdong walks down to central campus to get find a table and food
[23:42] <LaserJock> I'm also wondering about the backporting of fixes
[23:42] <LaserJock> we often just sync/merge, etc.
[23:42] <LaserJock> much MOTU activity isn't about doing code backports
[23:42] <LaserJock> that may make people hesitate
[23:43] <LaserJock> packaging bug SRUs should be easy though I'd think
[23:52] <crimsun> backporting fixes may not be entirely trivial
[23:52] <maix> hi
[23:52] <LaserJock> crimsun: exactly
[23:53] <LaserJock> maix: hello
[23:53] <crimsun> if they're not doing it because it's not trivial, however, that's bad.  They can always ask for assistance.
[23:54] <maix> i have a package, which i downloaded from launchpad (version 6-1) and then patched it. but the question is: what version do i have to give to it in order that i always get an update if they or debian or ubuntu releases a new version
[23:54] <maix> i thought: if they patch it the new version will be 6.1, if debian does it will be 6-2, if ubuntu does it will be 6-1ubuntu1; is that right?
[23:55] <LaserJock> right
[23:55] <maix> so i should name it 6-1ubuntu0patched1
[23:55] <maix> would that work?
[23:55] <LaserJock> well, there might be some other versions if it has a security fix or something like that
[23:55] <maix> eg?
[23:55] <LaserJock> if it had a security fix I think it'd be 6-1ubuntu0.1
[23:55] <nxvl> ubuntu0patched1?
[23:56] <nxvl> maix: no, it would be 6-1ubuntu1
[23:56] <LaserJock> maix: it may seem weird but but 6.-1ubuntu0.0patched1 might work well
[23:56] <maix> nxvl, i don't want to upload it to universe, it's just locally
[23:56] <nxvl> oh ok
[23:56] <crimsun> use '+'
[23:56] <LaserJock> 6-1 not 6.-1 there
[23:57] <nxvl> or ~
[23:57] <LaserJock> yeah, that's better
[23:57] <nxvl> 6-1ubuntu1~local`
[23:57] <nxvl> 6-1ubuntu1~local1
[23:57] <LaserJock> 6-1ubuntu0~patched1
[23:57] <nxvl> or ~patched1
[23:57] <maix> i've some time ago read in a manpage or a wiki or some similar stuff the rules how dpkg or apt or so determines which version is newer; but i cannot find it anymore. someone an idea?
[23:57] <LaserJock> I think you'd still maybe want ubuntu0 there
[23:58] <nxvl> LaserJock: actually it shoud be ubuntu1 intead of ubuntu1
[23:58] <crimsun> really, updates _should_ be 6-1ubuntu0.foo
[23:58] <nxvl> LaserJock: ubuntu1 > ubuntu1~patched1
[23:58] <LaserJock> nxvl: yes, I know
[23:59] <LaserJock> but ubuntu1~patched1 > ubuntu0 right?
[23:59] <LaserJock> so you'd want ubuntu0~patched1
[23:59] <crimsun> ubuntu1~patched1 sorts before ubuntu0.1, which is incorrect.
 if it had a security fix I think it'd be 6-1ubuntu0.1 -> but 6-1ubuntu0patched1 would be lower than that, wouldn't it?