[00:00] <LaserJock> sebner: he's an uber-MOTU
[00:00] <jdong> sebner: you don't want to take away his upload powers ;-) trust me...
[00:00] <sebner> rofl
[00:00] <sebner> ^^
[00:00] <sebner> I want to become the Master of the Merges :D
[00:00] <ajmitch> jdong: why is that?
[00:00] <wgrant> ajmitch: Is rcbugs running against intrepid yet?
[00:01] <ajmitch> wgrant: no, it's a little early for that
[00:01] <LaserJock> ajmitch: cause you da man!
[00:01] <jdong> ajmitch: because that means more work than the rest of us ;-)
[00:02] <ajmitch> jdong: heh, not really
[00:02] <persia> wgrant: Surely we want to run rcbugs against hardy until at least DIF, as every Debian change gets a merge listing.
[00:02]  * ajmitch will break it to run against both, anyway
[00:03] <ajmitch> once I un-hardcode some stupidity
[00:03] <LaserJock> yeah, actually at the moment the RCbugs list may be helpful in spotting SRUs
[00:03] <persia> Cool.  That makes it better for all.
[00:03]  * LaserJock has SRU on the brain :/
[00:03] <persia> LaserJock: Oughn't most of the entries remaining on the rcbugs list qualify for SRU?
[00:03] <jdong> LaserJock: which is a good thing :)
[00:04] <sebner> pochu: is there a reason why you constantly ignored my offer that you sponsor my merges? ^^
[00:04] <LaserJock> persia: I would think so, hence why it'd be a good list to have around
[00:04] <LaserJock> persia: as we may want to look at this regardless of the presence of an Ubuntu bug
[00:05] <LaserJock> s/this/that/
[00:05] <pochu> sebner: lol, where did you offer that? mail, irc?
[00:05] <persia> LaserJock: Right.  If it's not an Ubuntu bug, it ought get a comment.
[00:05] <pochu> sebner: I don't recall seeing that :)
[00:05] <sebner> pochu: 2 times in irc. classroom and classroom-chat
[00:06] <sebner> if somebody don't want to he/she won't see^^
[00:06] <pochu> sebner: sorry, I guess there was too many noise ;) feel free to ping me for them, specially if they are python or gnome related
[00:07] <sebner> pochu: ^^ unfortunately not. just normal merges. :8
[00:08] <ajmitch> persia: python-lp-bugs should help a bit for automating that
[00:08] <ajmitch> ScottK had a suggestion earlier for looking up linked debian bugs on LP
[00:08] <sebner> pochu: but if you check the sponsors list you may find something you want to review. the next days I'll try to fill it ^^
[00:09] <ogra> .oO( smells like ajmitch in here )
[00:09] <pochu> sebner: I'm not subscribed to the u-u-s mailing list... I just look at the bug list from time to time, so i'm not sure I'll be able to look at yours...
[00:10] <ajmitch> ogra: all lies
[00:10] <ogra> :)
[00:10] <ogra> hey
[00:10] <ajmitch> you saw nothing...
[00:10] <sebner> pochu: ok. np then
[00:10] <pochu> sebner: so if nobody looks at them, feel free to ping me ;)
[00:10] <ajmitch> hi :)
[00:10] <zul> ogra: all crispy like?
[00:10] <sebner> pochu: well usually I have the problem that I have too many that there always can look at one ^^
[00:10] <ogra> lol
[00:12] <persia> ajmitch: Right.  I was thinking of the cases where either a bug didn't affect Ubuntu as we hadn't merged the affected version, or it was fixed in Ubuntu, but the bugs not linked in LP.  Having an autolink for LP is a great thing though, and ought reduce the effort required to keep the comments up-to-date.
[00:15] <ajmitch> I'll look up what previous suggestions have been made
[00:18] <ffm> So, how easy is it to take a ubuntu package and get it in debian?
[00:19] <ffm> Also, can a package have two maintainers, or does that get into the too-many-chefs issues?
[00:19] <LaserJock> ffm: it can be fairly easy and that's called co-maintaining and it's fine
[00:19] <ffm> LaserJock, Ah. kk.
[00:20] <LaserJock> MOTU maintain universe packages and I've not heard of too many people complainging about too-many-chefs
[00:20] <sebner> gn8 folks :)
[00:24] <ffm> How hard is it to get J. Random Python Library into main once it's in universe?
[00:24] <ffm> Assuming the package is not esoteric or a security package, and is well polished.
[00:24] <LaserJock> well, it depends on if it's needed
[00:25] <ffm> LaserJock, "needed"?
[00:25] <ffm> LaserJock, I mean it's useful for education...
[00:25] <LaserJock> generally a library is going to get pulled into Main because something else depends on it
[00:26] <LaserJock> what library?
[00:26] <ffm> LaserJock, python-gasp (not yet in universe). http://edge.launchpad.net/gasp-code (featured lp.net project)
[00:27] <LaserJock> hmm
[00:27] <LaserJock> I might consider that for Edubuntu if we get more similar learning tools for programming
[00:29] <LaserJock> but it needs to get into Universe first :-)
[00:29] <ffm> LaserJock, ok. (The dev on this helped write the edubuntu spec, btw)
[00:29] <LaserJock> which spec
[00:31] <ffm> LaserJock, This was back in 05-06 when there wasn't really all that much of edubuntu. I'm not sure which one exactly.
[00:33] <ajmitch> persia: ok, half-done for being run for multiple
[00:33] <ajmitch> multiple (ubuntu) releases, that is
[00:37] <ffm> How hard is it to start co-maintaining a package? (say, tor, that's always needing new maintainers IIRC)
[00:39] <LaserJock> ffm: not hard usually
[00:39] <LaserJock> you just gotta start contributing patches and help out
[00:40] <LaserJock> often times a current maintainer will ask if you want to become a comaintainer if they think you're ready
[00:44] <ffm> LaserJock, Would it be considered in edubuntu if there was a book to go along with it? (gfdl, of course). (oh, and it was the original edubuntu spec I was talking about)
[00:45] <LaserJock> well, a book would be cool to have
[00:45] <LaserJock> but I'm more thinking along the lines that we'd want a suite of programming education software
[00:45] <ffm> LaserJock, Like Scratch, Alice, LOGO, etc?
[00:49] <LaserJock> maybe
[00:50]  * norsetto goes to bed
[00:50] <LaserJock> we had a Summer of Code project for a python learning app, that would be something
[00:50] <porthose> gad what is the command to update po files.  I cant' remember :(
[00:51] <LaserJock> porthose: intltool-update perhaps?
[01:38] <nxvl> ScottK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478972
[01:38] <nxvl> ScottK: that's what you ask me to do, didn't it?
[01:41]  * nxvl runs bbl
[01:47] <morten> hi, i have a quick question about package-naming (versions). I'm packagin version 1.0~rc3 (upstream), with no changes (just added the debian/ folder), should the version be package-1.0~rc3-1 or package-1.0~rc3-0ubuntu1 or just package-1.0~rc3 ?
[01:47] <jdong> morten: -0ubuntu1
[01:48] <morten> ok, thanks :)
[01:48] <jdong> morten: -1 is reserved for Debian's usage, raw version numbers are reserved for natively debian/'ed packages.
[01:48] <morten> ok
[02:00] <ajmitch> nxvl: 'whislist' may be an issue :)
[02:02] <jdong> Showing 1-24 of 4,294,967,296 Songs
[02:02] <jdong> hmm.
[02:02] <jdong> lucky query, or too suspicious to be accidental?
[02:02] <jdong> nope. just lucky. got 4.9mil the next attempt
[02:02] <slangasek> depends on whether 2^32 is your lucky number?
[02:03] <jdong> slangasek: it's one of those numbers that makes us cringe when we see it outputted, no? :)
[02:03] <slangasek> because it's much, much more likely to be an integer bound than an actual number of query results... :)
[02:04] <jdong> :)
[02:35] <ffm> Where do I see the hoops I jump through to get my package in intrepid?
[02:35] <coppro> I'm trying to make my first library package
[02:35] <coppro> is there good documentation somewhere
[02:38] <LaserJock> coppro: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[02:38] <LaserJock> ffm: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[02:38] <ffm> LaserJock, Merci,
[02:39] <coppro> thanks
[03:08] <bddebian> Heya gang
[03:09] <LaserJock> hi bddebian
[03:10] <bddebian> Hi LaserJock
[03:32] <nxvl> ajmitch: but it is whislist, not even important :D
[03:33] <ajmitch> s/whis/wish/
[03:34] <ajmitch> I'm surprised that the BTS didn't just reject that bug
[03:35] <ajmitch> though on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=tinyerp-server it shows up in the outstanding normal bugs
[03:42] <x1250> Hi: I'm developing a little python script for posting in paste.ubuntu.com. I want this script on ubuntu universe. I have some experience with packaging (two packages for KDE Debian Team, KDE4 experimental) so I can make the package myself. Well, as I said, I have experience working with debian packagers, although little, this package would be for arch=all (interpreted).
[03:44] <nxvl> ajmitch: yes, sorry!
[03:44] <nxvl> ajmitch: why whould bts reject it?
[03:48] <ajmitch> because it's not a valid severity, but thatnkfully it looks like the BTS will accept pretty much anything
[03:50] <RAOF> x1250: Is this script something that could not be accomplished easily by modifying the existing 'pastebinit' package?
[03:52] <x1250> RAOF: Yeah, didn't know that package. Then I'll improve it till mine is better.
[03:53] <x1250> or more flexible
[03:54] <RAOF> Or you could improve pastebinit, of course :)
[03:58] <x1250> well, yeah, I can do that too :)
[04:20] <ScottK> nxvl: Did you look at the latest Debian package and provide patches against that or did you give them the change that Ubuntu made to an older Debian version?
[05:29] <nxvl> ScottK: yep
[05:29] <nxvl> ScottK: i downloaded the packages from MoM, i did the merge from newest debian
[05:29] <nxvl> ScottK: and separate the patches by file
[05:30] <ScottK> nxvl: Then yes.  That sounds like what I wanted you to do.
[05:31] <nxvl> ScottK: so now i can delete it from my ToDo?
[05:31] <ScottK> nxvl: Thanks for looking after that.
[05:31] <ScottK> Yes.
[05:31] <ScottK> You may as well submit your merge for sponsorship too then.
[05:31] <nxvl> ScottK: :D
[05:31] <ScottK> Then if the Debian maintainer picks up the patches, we can sync later.
[05:31] <nxvl> ScottK: i will better wait for an answer from the DD
[05:32] <nxvl> ScottK: and then , depending on that to upload the debdiff or request sa sync
[05:32] <nxvl> scot	i will ping him tomorrow
[05:32] <nxvl> ScottK: i will ping him tomorrow
[05:33] <tbielawa_> Is anyone in here working towards becoming a MOTU?
[05:33] <nxvl> im going for today
[05:33] <nxvl> see you tomorrow
[05:33] <nxvl> tbielawa_: yep
[05:33] <tbielawa_> I just laid it out in stone today and I'm pretty siked about it
[05:34] <tbielawa_> I work in the CS department at wvu where I'm going to school. we run it on ubuntu servers so I'm pretty close with it, we do packaging for all our system configs too
[05:35] <ScottK> nxvl: I'd say get your merge uploaded and then wait.  No need to ping the DD right away.
[05:35] <ScottK> tbielawa_: There are a number of people working on that.  I don't think except for nxvl any are around at the moment.
[05:36] <ScottK> tbielawa_: Welcome.  Let us know if you need help or to have questions answered.
[05:36] <tbielawa_> thanks man!
[05:36] <tbielawa_> I want to work towards getting on the motu-science team
[05:37] <ScottK> LaserJock is often around this time of day.  He's a good person to talk to about that.
[05:37] <nxvl> ScottK: ok, i will do this tomorrow
[05:37]  * nxvl updates his ToDo and goes away
[05:37] <ScottK> I found that the best way to get to be a MOTU was to dive in and get to work.
[05:37] <tbielawa_> heh, I see his name on the wiki page, that's awesome that he comes around theis place
[05:37] <ScottK> nxvl: Thanks.
[05:38] <nxvl> ScottK: you are welcome
[05:38]  * nxvl HUGS ScottK 
[05:38] <nxvl> ScottK: btw, when are you arriving to Prague?
[05:38] <nxvl> ScottK: are you going for FOSS Camp?
[05:38] <ScottK> nxvl: I think I'm there for part of it.
[05:39]  * LaserJock stumbles in
[05:39] <nxvl> ScottK: when are you arriving?
[05:39] <tbielawa_> crazy timing that LaserJock has
[05:39]  * ScottK looks it up.
[05:39]  * ScottK hopes he wasn't carrying a laser
[05:39] <LaserJock> you never know
[05:39] <LaserJock> :-)
[05:39] <nxvl> tbielawa_: you need to keep in mind that we are from around the world
[05:40] <nxvl> tbielawa_: so maybe for you is a crazy hour but from him is a regular one
[05:40] <nxvl> :D
[05:40] <tbielawa_> I like that aspect about the FLOSS community
[05:40] <tbielawa_> the crazy timing I was think of in a 'speak of the devil' type maner :)
[05:40] <LaserJock> tbielawa_: I gotta run for a quick shower and I'll be back if you're still up we can discusss your MOTU Science future ;-)
[05:40] <tbielawa_> yes! I'll be around
[05:41] <nxvl> mm
[05:41] <ScottK> nxvl: I'm wrong.  I get in late on the 18th.
[05:41] <nxvl> ScottK: mm for the end of FOSS Camp
[05:41] <nxvl> ScottK: but just in time for the FOSS Camp beers :D
[05:42] <ScottK> That or collapsing from jet lag.
[05:42] <nxvl> nop
[05:42] <ScottK> The beer might help with that though.
[05:42] <tbielawa_> :D
[05:42] <nxvl> i wrong as always with the dates
[05:42] <nxvl> :S
[05:42] <nxvl> just fro the pre-UDS beers
[05:42] <nxvl> :P
[05:42] <ScottK> nxvl: Have you flown to Europe before?
[05:42] <nxvl> ScottK: never
[05:43] <nxvl> ScottK: the 2 times i have go out from Peru where to disney at the age of 7 and to Punta Cana for my prom trip
[05:43] <nxvl> i spend 5 days drunk at dominican republic
[05:43] <nxvl> :D
[05:43] <nxvl> it was a nice trip
[05:43] <nxvl> :P
[05:44] <ScottK> Flying east a half dozen time zones is (at least for me) extremely painful from a jetlag perspective.  Much worse than flying north/south or west.
[05:45] <nxvl> ScottK: yep, my return trip seems to last 4 hours, with the timezone changes
[05:45] <nxvl> and more or less 24 hours for going to
[05:45] <nxvl> well
[05:45] <nxvl> im out now
[05:45] <nxvl> i'll be back in an hour or so
[05:45] <nxvl> see you
[06:01] <tbielawa> ahhh, killed my ghost
[06:18] <LaserJock> tbielawa: k, back
[06:18] <tbielawa> cool
[06:18] <LaserJock> tbielawa: so, you're interested in MOTU Science?
[06:18] <tbielawa> yep!
[06:19] <tbielawa> I think it fits in closely to what I do now
[06:19] <tbielawa> I work as a sys admin in the cs department at wvu (i'm also a jr there in the cs program)
[06:20] <LaserJock> cool
[06:20] <LaserJock> I'm a PhD chemistry student at University of Nevada
[06:20] <tbielawa> We run the network on ubuntu servers and desktop stations. THe fun part is packaging it all so it's automated. We're in the process of creating packages for differnet courses now so profs can have them installed on demand
[06:20] <tbielawa> That's a lot of chemisty
[06:21] <tbielawa> I really love the community aspect of ubuntu and that the motu's play so I'm trying to get my feet wet in the big pool.
[06:22] <LaserJock> cool
[06:22] <LaserJock> tbielawa: have you seen the MOTU Science wiki page?
[06:22] <tbielawa> yep, have it bookmarked
[06:23] <LaserJock> k, and do you have a launchpad account?
[06:23] <tbielawa> Yes, it's tbielawa, got my keys on there too
[06:24] <LaserJock> tbielawa: k, then if you feel like jumping in join https://launchpad.net/~motuscience
[06:25] <LaserJock> you'll be getting sent all the bugmail for the science packages
[06:25] <LaserJock> so you might want to make sure to have a filter set up in your email client ;-)
[06:28] <tbielawa_> sorry about that LaserJock, wireless was dying
[06:28] <tbielawa_> To answer your question, yes I do have a launchpad account. name is tbielawa on there too
[06:29] <LaserJock> tbielawa_: did you see what i said after that?
[06:30] <tbielawa_> no, I miseed whatever you said
[06:30] <nxvl> LaserJock: is there any way to filter LP e-mails by team?
[06:30] <LaserJock> nxvl: yes
[06:30] <LaserJock> couple different ways
[06:31] <LaserJock> tbielawa_: ok, here's what I said:
[06:31] <LaserJock> tbielawa: k, then if you feel like jumping in join https://launchpad.net/~motuscience
[06:31] <LaserJock> you'll be getting sent all the bugmail for the science packages
[06:31] <LaserJock> so you might want to make sure to have a filter set up in your email client ;-)
[06:31] <nxvl> LaserJock: how?
[06:31] <nxvl> LaserJock: i almost die trying to
[06:31] <LaserJock> nxvl: if you can filter on headers check the X-Launchpad-Rationale header
[06:32] <nxvl> LaserJock: and it's driving me crazy to have different teams bug on the same folder
[06:32]  * nxvl check
[06:32] <LaserJock> if you can't (gmail for instance) use the footer text of the bugmail
[06:32] <tbielawa_> app submitted
[06:34] <nxvl> LaserJock: X-Launchpad-Message-Rationale: you mean
[06:35] <LaserJock> nxvl: that could be it
[06:35] <LaserJock> tbielawa_: welcome aboard :-)
[06:36] <tbielawa_> Thanks LaserJock!
[06:37] <tbielawa_> Im glad summer break is the week after next.
[06:37] <LaserJock> I was too
[06:37] <tbielawa_> Should give me a good opportunity to get into this
[06:37] <LaserJock> until I found out I'd be teaching chemistry lab this summer
[06:37] <tbielawa_> L)
[06:37] <tbielawa_> ohhhhh, not your favorite thing to do?
[06:38] <LaserJock> well, I'm trying to finish up my dissertation (as you can tell) so it's not great time-wise
[06:39] <tbielawa_> ya that makes sense
[06:41] <LaserJock> well, right now we're just barely getting going on intrepid
[06:41] <LaserJock> the archive just opened for general uploads
[06:43] <tbielawa> that makes the motu a bunch of busy people then
[06:43] <LaserJock> it does
[06:43] <tbielawa> you in particular with all that going on
[06:44] <LaserJock> http://merges.ubuntu.com/universe.html shows us the packages that we need to merge
[06:44] <LaserJock> so right now packages that Ubuntu hasn't touched are being automatically synced from Debian unstable
[06:45] <tbielawa> I'm not entirely sure what you're saying
[06:45] <tbielawa> these are the ports from debian then?
[06:45] <LaserJock> but package that we've modified (have "ubuntu" in the version) have to be manually merged over
[06:45] <LaserJock> ok, so Ubuntu is based on Debian
[06:45] <tbielawa> true
[06:45] <jdong> hmm I've touched 3 things, 1 of which can't be merged for the foreseeable future anyway :)
[06:45] <LaserJock> so at the beginning of each release we take the current packages from Debian unstable and rebuild them in Ubuntu
[06:45] <jdong> *whew*
[06:46] <LaserJock> that's syncing
[06:46] <LaserJock> if we haven't modified the source at all the syncing is done automatically
[06:47] <tbielawa> and relevant changes made in the -ubuntu changes are merged over then manully?
[06:47] <LaserJock> but if Ubuntu has modified it, then we have to manually merge the packages
[06:47] <LaserJock> right
[06:47] <tbielawa> thats much clearer now, thanks
[06:48] <LaserJock> so we have a tool called Merge-o-Matic (MoM for short) that keeps track of what needs to be merged and actually makes an programatic attempt at doing the merges
[06:48] <tbielawa> ! :)
[06:48] <tbielawa> 828 outstanding. Is that a hefty stack?
[06:48] <LaserJock> however, much of the time we need to do things by hand, and we always check anyway
[06:48]  * jdong is weird and loves merging by hand with version control systems
[06:48] <LaserJock> it is
[06:48] <StevenK> There's 500 odd in main
[06:49] <jdong> holy crap why does claws's source package pump out a bazillion binaries?
[06:49] <jdong> isn't that really taking modularization to absurdity?
[06:49] <tbielawa> 0_o
[06:49] <LaserJock> tbielawa: as the release progresses and Debian maintainers upload new packages we might have new packages to merge or have to remerge
[06:50] <LaserJock> jdong: because it's special :-)
[06:50]  * tbielawa nods
[06:50] <LaserJock> tbielawa: in reality all this work is being done  by a relatively few people
[06:50] <LaserJock> so that's why we love help :-)
[06:51] <tbielawa> I wouldn't be here if this wasn't something I was looking forward to helping
[06:51] <tbielawa> :)
[06:51] <jdong> tbielawa: generally at this point of a release cycle, Debian has been doing active work for several months on packages while we've been frozen and fixing bugs in existing features/packages...
[06:51] <jdong> tbielawa: after this big flood of merges, merging becomes much more pleasant :)
[06:51] <tbielawa> jdong: does it get into a flow? ubuntu develops one season debian freezes, then it switches?
[06:52] <jdong> with Debian's long release cycles, I've actually not witnessed a Debian freeze since I've gotten involved with Ubuntu development ;-)
[06:52] <tbielawa> ha, that's the truth
[06:52] <jdong> but certainly when Debian is imminent to release, their unstable repos do slow down
[06:53] <jdong> in fact I had to jump to a more aggressive distro back when they were freezing up 3.0
[06:53] <jdong> 3.1 rather
[06:53] <tbielawa> so, @all. If I wanted to try and make a dent in this stack this weekend, what would be the first steps I take?
[06:53] <tbielawa> I can package, that's not a concern
[06:53] <tbielawa> I guess, I'm more looking for a... spot to throw anything I merge. REVU?
[06:53] <jdong> tbielawa: there is a wiki page with very verbose instructions on how to handle merging
[06:53]  * tbielawa nods
[06:54] <jdong> tbielawa: on the big picture scale, (1) Figure out what Ubuntu did to the old debian version (2) Figure out what Debian has done since the old Debian version (3) Decide which changes are worth keeping from the old Ubuntu version and port those patches on top of the new Debian version
[06:54] <ScottK> tbielawa: Many MOTU consider it polite that if you are going to merge a package they touched last you check with them first.
[06:54] <jdong> tbielawa: but as ScottK said, it's a good idea to talk to the last-touched-by person
[06:55] <LaserJock> https://wiki.ubuntu.com/UbuntuDevelopment/Merging seems like the current wiki page for learning merging
[06:55] <ScottK> tbielawa: It is a good practice anyway as it will often save you work.  As an example, there are 9 packages that are on the merges list with my name on them that I've already asked to have synced.
[06:55] <tbielawa> So, the items listed might even have already been completed!
[06:56] <ScottK> Right.
[06:56] <ScottK> That is updated on a periodic, so it will inevitably lag.
[06:56] <LaserJock> tbielawa: a good idea is to first check the package's Launchpad page to see if there is a merge or sync bug
[06:56] <tbielawa> I think that contacting the last-touched-by folks would be a good way to start to interact and meet more of the motu's also
[06:56] <LaserJock> before you start launching into a big effort
[06:57] <LaserJock> yep
[06:57] <tbielawa> ha, ya
[06:57] <warp10> Heya all
[06:57] <tbielawa> hello
[06:57] <ScottK> Hello warp10
[06:57] <LaserJock> basically, if you're not sure ask
[06:57] <LaserJock> we don't bite
[06:57] <LaserJock> ...usually
[06:57] <tbielawa> worst that'll happen is some one says 'rtfm n00b' ;)
[06:57] <warp10> hi tbielawa, ScottK
[06:57] <ScottK> tbielawa: That's a good point.  Getting approved to be a MOTU is as much (if not more) about people trusting you and wanting to work with you than about technical skills.
[06:58] <tbielawa> I understand that sentiment
[06:58] <tbielawa> developing a ring of trust. makes me think of gpg keys for some reason
[06:58] <ScottK> ;-)
[06:59] <ScottK> Bonus points for good collaboration with Debian too.
[06:59] <LaserJock> I guess we should make sure the merging page is up-to-date huh? :-)
[07:00] <tbielawa> I did one bug fix today
[07:00] <LaserJock> very much bonus points for working with Debian
[07:01] <tbielawa> it's a silly one. there was a typo in the slocate package so I went and submitted a debdiff on 155-61
[07:01] <LaserJock> there is a Debian Science group, though they are more of a user group than specifically packaging team like MOTU Science
[07:02] <LucidFox> Hmm, pbuilder create fails for intrepid
[07:02] <LucidFox> bug #225531
[07:02] <tbielawa> (*155061) How are the debian devs to work with
[07:03] <ScottK> LucidFox: I'm pretty sure that'll work if you have a deboostrap that knows about Intrepid.
[07:03] <ScottK> LucidFox: Bug 225526
[07:03] <tbielawa> have you guys felt much animoscity from them. I heard rumors that some are angry that 'ubuntu isn't giving back' (whcih I don't understand)
[07:03] <LucidFox> oh, wait... it's a bug in debootstrap then, not pbuilder
[07:03] <LaserJock> tbielawa: it very much depends on the developer
[07:03] <LaserJock> tbielawa: the vast majority are helpful and friendly, a few are not-so-friendly and vocal :-)
[07:04] <ScottK> LucidFox: We need the new one backported.
[07:04] <tbielawa> LaserJock: got'cha
[07:04] <jdong> tbielawa: the vast majority of Debian developers I've interacted with in the process of forwarding bugs have been very friendly
[07:04] <ScottK> tbielawa: Debian is very much a collection of individuals with individually varying opinions.
[07:04] <LaserJock> tbielawa: the more we work with them and help them the more friendly they are, in general
[07:05]  * ScottK has never had any problems.
[07:05] <tbielawa> I saw in a wiki page some where that it stressed making links on debian or any other upstream projects trackers about issues we find
[07:05] <ScottK> Only if they are relevant to Debian.
[07:05] <LaserJock> tbielawa: yeah, in Launchpad if you either forward a bug to Debian or find an existing Debian bug for the issue you can link to it
[07:05] <tbielawa> right
[07:05] <ScottK> Also Debian tends to want upstream bugs reported straight upstream and not to their BTS.
[07:06] <tbielawa> I have a question now about upstream bugs
[07:06] <tbielawa> https://bugs.launchpad.net/ubuntu/+source/slocate/+bug/155061 the typo came from upstream, should that get forwarded to... whoever is upstream for slocate?
[07:06] <ScottK> Although that varies maintainer to maintainer too.
[07:08] <ScottK> The kids' computer finally finished upgrading, so I'm going to bed.
[07:08] <ScottK> Good night all.
[07:08] <tbielawa> g'nite ScottK
[07:08] <LaserJock> ScottK: night
[07:08] <tbielawa> nice to meet you
[07:08] <LaserJock> my server upgrade is about done
[07:08] <LaserJock> I'll probably be heading to bed as well soonish
[07:09] <tbielawa> same applies here. it's 2 on a week day...
[07:09] <LaserJock> welcome to MOTU Land :-)
[07:09] <tbielawa> Thanks
[07:09] <LaserJock> some of us eat-breathe-sleep this stuff
[07:09] <LaserJock> others don't
[07:09] <tbielawa> irc?
[07:10] <LaserJock> that's the beauty of working in Ubuntu
[07:10] <tbielawa> ?
[07:10] <LaserJock> you can do as much as you're able when you're able
[07:10] <tbielawa> Sounds like a pretty good job to me :)
[07:11] <LaserJock> yeah .... but the pay sucks ;-)
[07:11] <tbielawa> my day job that does pay is sort of like an extension of this
[07:11] <tbielawa> We're migrating from dapper to hardy.
[07:11] <LaserJock> yeah, that's kind of a nice position to be in
[07:12] <tbielawa> Well, i'm doing most of the leg work. Other staffers are moving userland desktops and work stations to gutsy, right now Im investigating hardy and kvm :)
[07:12] <LaserJock> my research has nothing to do with computers so it's just a rather obsesive hobby
[07:12] <tbielawa> LaserJock: I wouldnt' trade it for the world
[07:13] <tbielawa> must be quite obsesive if you're the motuscience leader
[07:13] <LaserJock> well ...
[07:13] <LaserJock> if it was only MOTU Science that I did it'd probably be ok ;-)
[07:14] <LaserJock> though I haven't been doing as much as I used to
[07:14] <tbielawa> I'm going to call it quits now
[07:15] <tbielawa> It's been great getting to know you and onto the science motu team!
[07:15] <tbielawa> I'll see you all later on today most likely
[07:15] <LaserJock> yes, thanks for joining
[07:15] <ethana2> Ogle is crashing constantly
[07:15] <ethana2> my mom is near crying
[07:16] <ethana2> There is no launchpad entity for it
[07:17] <jdong> well as a short-term solution, to prevent more crying family members, I'd suggest trying another DVD player like VLC
[07:17] <ethana2> What should I use for navigating DVD's with menus and multiple episodes of things?
[07:17] <jdong> but ogle on launchpad is https://edge.launchpad.net/ubuntu/+source/ogle
[07:17] <ethana2> ...with pulseaudio.
[07:17] <ethana2> VLC failed miserably with PA, has it been fixed?
[07:17] <ethana2> k
[07:18] <jdong> ethana2: as of 12 apr 2008's upload, it's supposed to use the pulseaudio output by default
[07:18] <ethana2> ok, got a crash logged in terminal
[07:18] <jdong> I've heard pretty good reports of VLC+pulse
[07:18] <ethana2> so the version in ubuntu stable right now, correct?
[07:18] <ethana2> ogle: dvdreadblocks only got 157, wanted 263
[07:18] <jdong> ethana2: correct. Hardy shipped with that version
[07:18] <ethana2> FATAL [ogle_mpeg_ps]: dvdreadblocks failed
[07:19] <ethana2> ok good
[07:19] <jdong> ethana2: please file a bug on this, but it seems like either ARCCOS copy protection or a scratched DVD at this point
[07:19] <jdong> but let's make sure. I know little about ogle specifics
[07:19] <jdong> ethana2: also attach the last 30 or so lines of dmesg as a textfile
[07:19] <ethana2> it needs to be 100% fault tolerant
[07:19] <ethana2> alright, will do
[07:20] <jdong> ethana2: indeed I agree crashing is the wrong behavior for encountering unreliable DVDs
[07:20] <ethana2> absolutely
[07:20] <ethana2> my dad switches to the windows drive every time they want to watch a movie
[07:20] <ethana2> because of bugs like this
[07:21] <jdong> ethana2: Linux DVD players in general don't seem to handle bad blocks very well
[07:21] <jdong> ethana2: that's something I'd like to see more work towards
[07:22] <jdong> of course, the fact that arccos encrypted DVDs purposely plant malformed data and unreadable blocks certainly doesn't help us!
[07:22] <ethana2> That makes sense
[07:23] <jdong> yay movie industry ;-)
[07:24] <LaserJock> anybody happen to know off-hand how one would make an RSS feed out from a mailing list?
[07:24] <LaserJock> s/from/of/
[07:25] <jdong> LaserJock: cat -R ~/Maildir | perl -pi 's/^Subject:(.*. .... (joking)
[07:26] <LaserJock> I was thinking today that it would be nice to make a SRU tester RSS feed
[07:27] <LaserJock> so I was thinking if you triggered off of a -changes email
[07:27] <jdong> LaserJock: I think SRU testing would benefit from a more ticket-oriented-type of interface
[07:27] <LaserJock> then maybe did some fancy stuff
[07:27] <jdong> LaserJock: i.e. if launchpad could export RSS feeds of queries
[07:27] <jdong> LaserJock: i.e. verification-* tags
[07:27] <LaserJock> well
[07:27] <LaserJock> I was thinking of using something like http://mozilla.qa.ubuntu.com/ as well
[07:28] <TheMuso> jdong: So how do standard DVD players play those DVDs then if they are different, or are they not that different?
[07:28] <jdong> TheMuso: apparently standard DVD players happen to skip over and ignore such areas of the disk
[07:28] <jdong> TheMuso: i.e. they pay no attention to filesystem structures, they dead reckon to areas of the discs they assume contain certain content
[07:28] <TheMuso> jdong: Right.
[07:28] <jdong> so arccos just has to corrupt the UDF data structure
[07:29] <jdong> and Linux will spew bloody murder all over it
[07:29] <jdong> LaserJock: that is certainly beautiful (qa.mozilla)
[07:29] <jdong> LaserJock: I would love to see that used for SRU, and possibly even backports
[07:29] <TheMuso> So thats a violation of the standard surely.
[07:30] <LaserJock> the thing I'm trying to think about is if we should kinda shy away from directing testing people to bug reports
[07:30] <jdong> TheMuso: pfft. standards. ;-)
[07:30] <LaserJock> but rather have a nice page with the Test Case info and a place to "me too"
[07:30] <TheMuso> jdong: heh
[07:31] <LaserJock> and have all the pending SRUs together
[07:31] <LaserJock> basically a smashup of http://people.ubuntu.com/~ubuntu-archive/pending-sru.html and http://mozilla.qa.ubuntu.com/
[07:31] <jdong> TheMuso: the "workaround" for arccos is usually doing a no-ECC rip of the DVD, zeroing in unreadable areas, then using a VOB ripping tool to scan the disk raw for vobs, then reassemble into another ISO...
[07:31] <jdong> TheMuso: nasty to say the least.
[07:32] <TheMuso> jdong: You're not wrong.
[07:32] <TheMuso> How common are arcos disks?
[07:32] <jdong> TheMuso: all Sony/BMG discs, a lot of Disney and disney-subcompany discs
[07:32] <jdong> TheMuso: a lot of hot-demand movies now that I think of it.
[07:33] <jdong> TheMuso: I was converting DVDs for my little sister's movie collection to her iPod touch and 90% of the discs I had to rip were arccos'ed
[07:33] <TheMuso> Right that is a pain.
[07:33] <jdong> *grumble*
[07:33] <LaserJock> oh...
[07:33] <TheMuso> So do all Linux players choak on them?
[07:34] <LaserJock> I've never though of putting a DVD on my iPod
[07:34] <LaserJock> doh
[07:34] <LaserJock> jdong: how much space does a DVD generally take?
[07:34] <ethana2> 5 GB
[07:34] <jdong> LaserJock: a rip to ipod's screen size takes less than 400MB per 2hr movie for unnoticeably degraded quality
[07:35] <jdong> LaserJock: I recommend using handbrake for such tasks
[07:35] <LaserJock> wow
[07:35] <jdong> LaserJock: a rip that can be outputted to a TV with acceptable quality is roughly double that size
[07:35] <jdong> LaserJock: H.264 is wonderfully efficient like that :)
[07:35] <jdong> LaserJock: and that's what makes apple's iPod the best portable video player on the market...
[07:35] <LaserJock> I've got a 30GB 5th gen iPod Video that I have like 5GB of music on
[07:36] <ethana2> What really bugs me
[07:36] <ethana2> is that i want to back up a DVD
[07:36] <ethana2> and it wants me to freaking transcode it
[07:36] <ethana2> then I found dd
[07:36] <ethana2> ...but I'd very much like a gui frontend for that
[07:37] <ethana2> ....and removing file system corruption garbage and CSS while it does that would be nice.....
[07:37] <ethana2> a DVD image sterilizer?
[07:38] <jdong> ethana2: the problem with coding up something like that is... you make it too good the feds will be after you.
[07:38] <jdong> ethana2: handbrake handles these tasks admirably (ripping DVDs) but doesn't work around arccos
[07:38] <LaserJock> sounds like something a crazy MIT student would do ;p
[07:39] <ethana2> anyone here live in a nation with sane laws?
[07:39] <jdong> LaserJock: haha unfortunately the institute's administration is disappointingly disrespectful of students' rights
[07:39] <ethana2> obscure pacific islands?
[07:39] <jdong> ethana2: said places don't even have access to encrypted dvds ;-)
[07:39] <ethana2> *cough* images
[07:39] <ethana2> oh no
[07:39] <jdong> ethana2: and said places make *A LOT* of money decrypting said DVDs and selling you money
[07:39] <ethana2> heh
[07:39] <jdong> it for money
[07:40] <StevenK> People sell you money?
[07:40] <ethana2> piracy for fair use
[07:40] <ethana2> full circle, eh?
[07:40] <ethana2> and then the industry complains
[07:40] <ethana2> idiots.
[07:41] <ethana2> Well, I filed the bug
[07:42] <ethana2> I always get so frustrated because my mom doesn't blame this crud on the movie industry
[07:43] <ethana2> 'well, windows plays it just fine, i guess it's linux's problem'
[07:44]  * jdong wonders what kind of patching it'd take to get, say, VLC to turn off subchannel ECC
[07:44] <ethana2> what is subchannel ECC?
[07:45] <jdong> ethana2: optical drives try to conpensate for read errors by slowing down, rereading, and applying parity correction algorithms
[07:45] <ethana2> hmm
[07:45] <jdong> ethana2: all this is great for data discs where losing one bit is unacceptable
[07:45] <jdong> ethana2: all this is really awful for DVDs where you'd rather lose 0.1 seconds of video than have the movie stall
[07:45] <ethana2> so it is known to actually help
[07:45] <ethana2> ah
[07:45] <ethana2> makes sense, yeah
[07:46] <jdong> ethana2: most windows media players turn off ECC and simply toss out undecodable frames
[07:46] <jdong> ethana2: I'm tempted to think we shoul ddo the same though I've never tried it to see what'd happen
[07:46] <ethana2> i don't suppose they'd be able to do that via wine?
[07:46] <ethana2> sounds like we should
[07:48] <TheMuso> jdong: Well I always play dvds in totem-xine, and I probably have a few Sony DVDs, mostly TV series and haven't had a proble,
[07:49] <jdong> TheMuso: consider yourself lucky then
[07:49] <ethana2> heh, yeah
[07:49] <jdong> TheMuso: that's why I tend to have every DVD playing software installed on my systems
[07:49] <TheMuso> jdong: heh
[07:49] <jdong> ethana2: nah we have commands that we can issue the drive directly to turn off ECC
[07:50] <jdong> ethana2: but there's technical implications of doing it messily, hence why I need to test out what it does exactly :)
[07:52] <ethana2> well there's lindvd
[07:53] <ethana2> but what are we going to do when we're dealing with blu-ray
[07:53] <ethana2> and our entire OS is deemed non-kosher by the **AA?
[07:53] <ethana2> AACS + BD+ + HDCP
[07:54] <ethana2> I hope HD video doesn't mess with Ubuntu conversion
[07:54] <ethana2> that would be horrible
[07:54] <ethana2> yeah, I should probably leave this channel now, I finished what I came here for
[07:55] <ethana2> good night, all
[07:55] <ethana2> 'night, jdong
[07:55] <tbutter> Is revu working? My upload yesterday did not work.
[07:56] <wgrant> tbutter: What was the package?
[07:57] <tbutter> wgrant: jodviewer
[07:57] <wgrant> tbutter: OK, I can't see it anywhere. Are you in the revu-uploaders group?
[07:58] <tbutter> yes, i uploaded previous versions of the package
[07:59] <tbutter> should i try it again?
[08:00] <wgrant> I see an upload a few hours ago - it succeeded.
[08:00] <poolie> hello motus
[08:00] <wgrant> Hey poolie.
[08:00] <poolie>  <poolie> i accidentally uploaded bzr-1.4rc1 to our PPA
[08:01] <poolie> it should of course have been called 1.4~rc1 instead
[08:01] <tbutter> wgrant: http://revu.tauware.de/details.py?package=jodviewer
[08:01] <poolie> what's the most appropriate number for 1.4 final so that it supersedes this one?
[08:01] <tbutter> it says february 11.
[08:01] <wgrant> poolie: You'd probably want an epoch, but epochs are almost always mistakes.
[08:02] <wgrant> The correct course of action is to very carefully check your version numbers before you upload, of course.
[08:02] <LaserJock> poolie: can you delete the package?
[08:02] <LaserJock> if it just happened you might be able to delete it without harm
[08:02] <wgrant> tbutter: Huh, you're right, yet I can see a directory timestamped yesterday.
[08:02] <LaserJock> not sure though
[08:02] <wgrant> I'll poke further.
[08:02] <poolie> wgrant: apt-get install timemachine?
[08:02] <wgrant> poolie: Correct.
[08:02] <poolie> but i shall do that in future
[08:03] <poolie> LaserJock: I can delete it, but people may have it already installed
[08:03] <poolie> i did it a while ago
[08:03] <LaserJock> ah
[08:03] <poolie> apparently deletion is not a good fix for bad version numbers anyhowe
[08:03] <LaserJock> no, not really
[08:03] <wgrant> Well, you can either introduce an epoch and have it there for eternity, or use a horrid version until 1.5, like 1.4rc1+really1.4.0
[08:03] <poolie> an epoch seems like a big hammer to use...
[08:04] <poolie> yeah i thought something like 1.4really would be better
[08:04] <LaserJock> wgrant: is 1.4.1 > than 1.4rc?
[08:05] <wgrant> LaserJock: No.
[08:05] <LaserJock> s/than/
[08:05] <wgrant> Otherwise 1.4.0 would be as well.
[08:05] <wgrant> Which would be even better.
[08:05] <jdong> wgrant: are you suggesting quiet deletion over an epoch?
[08:05] <LaserJock> sure, just hoping
[08:05] <wgrant> jdong: Was I?
[08:05] <jdong> wgrant: I thought that's how I read it
[08:05] <soren> dpkg --compare-versions 1.4.1 gt 1.4rc && echo Yes, it is.
[08:05] <soren> Yes, it is.
[08:05] <wgrant> I never mentioned deleting anywhere.
[08:06] <jdong> wgrant: sorry wrong quote attribution
[08:06] <LaserJock> jdong: I said it
[08:06] <jdong> IMO dpkg should detect downgrade scenarios
[08:06] <jdong> i.e. by tracking origin of packaging
[08:06] <wgrant> Hm, that's strange logic.
[08:07] <jdong> and noticing when packages are installed from a certain origin
[08:07] <jdong> and that origin now has an older package.
[08:07] <jdong> well s/dpkg/apt/
[08:07] <LaserJock> ok, so 1.4.0 should work?
[08:08] <LaserJock> by dpkg --compare-versions 1.4.0 gt 1.4rc && echo Yes, it is.
[08:08] <wgrant> LaserJock: It seems so. But that doesn't make sense.
[08:08] <LaserJock> why not?
[08:08] <wgrant> Why isn't 4rc > 4?
[08:08] <LaserJock> because it has a letter
[08:08] <LaserJock> and not a .
[08:09]  * wgrant reads policy
[08:09] <wgrant> I never thought it would work like that.
[08:09] <jdong> btw, dear hardy deities, I love the prominent forum link on the start page
[08:10] <LaserJock> I'm off to bed
[08:10] <LaserJock> night all
[08:10] <jdong> though I also prefer some human contact and apparently soliciting that is against the policies of the linked places ;-)
[08:10] <wgrant> Night LaserJock.
[08:10] <soren> poolie: So, in summary: You don't need to do anything. 1.4.0 is considered greater than 1.4rc1.
[08:11] <wgrant> tbutter: Sorry, can you please try the upload again?
[08:12] <tbutter> wgrant: done
[08:13] <poolie> soren: normally we call it just 1.4 but if 1.4.0 works that's great
[08:13] <poolie> thanks very much
[08:14] <lifeless> poolie: 1.4.0 will work
[08:14] <lifeless> poolie: don't use an epoch
[08:19] <poolie> lifeless:  "if it works" was a rhetorical conditional
[08:23] <wgrant> tbutter: There seems to be an issue with your REVU account, which is causing the acceptance script to crash.
[08:25] <tbutter> wgrant: is there any way for me to fix it?
[08:26] <wgrant> tbutter: No, I'm working on it.
[08:30] <poolie> i gave this tip <http://sourcefrog.net/weblog/software/launchpad/ppa-dput-protection.html> to someone using PPAs today
[08:30] <poolie> i find it answers well; any suggestions/corrections?
[08:33] <soren> poolie: I'd rather do something like:
[08:33] <soren> [DEFAULT]
[08:33] <soren> default_host_main = myppa
[08:33] <soren>  
[08:33] <soren> [myppa]
[08:33] <soren> fqdn = ...
[08:33] <soren> etc.
[08:34] <wgrant> tbutter: Aha, a code change broke it a few days ago. This is why we don't reindent huge blocks of code at a time...
[08:35] <wgrant> RainCT had a very, very unlucky space which broke the logic.
[08:37] <wgrant> tbutter: Your upload is there now.
[08:37] <tbutter> wgrant: thanks
[08:39] <tbutter> wgrant: the debdiff is empty
[08:41] <poolie> soren: i think having a default with this command line syntax is a bit of a misfeature
[08:42] <poolie> but iswym, it might be better to at least change the default to a dead end, rather than breaking ubuntu
[08:42] <StevenK> poolie: Why? dput <.changes> goes to your default, and dput <place> <.changes> goes to place
[08:43] <poolie> i understand how it work
[08:43] <poolie> works*
[08:43] <poolie> but people just seem to easily forget it
[08:43] <poolie> til you get trained, i suppose
[08:44] <poolie> perhaps with ppas it's more common to have multiple targets?
[08:44] <StevenK> I have targets for the archive, security, my ppa, the ubuntu-mobile ppa and Debian.
[08:45] <StevenK> So I'm not exactly sure what you're getting at
[08:46] <tbutter> wgrant: fixed now. thanks
[08:46] <poolie> i am just observing it seems to cause someone confusion on #launchpad every week or so
[08:46] <wgrant> tbutter: That breakage was caused by an app being missing from the new serve.
[08:46] <wgrant> *server
[08:46] <StevenK> poolie: So they configure their default to their PPA and just use dput <.changes> ?
[08:47] <poolie> i don't want a default
[08:48] <poolie> i would rather type 5 extra characters every time than have it go to the wrong place
[08:48] <poolie> this is just an admittedly hacky way to get that behaviour
[09:11] <superm1> jdong, man it looks like the guy who ships handbrake-gtk (rippedwire) hasn't updated his debs for hardy.  how's your nice little packaging effort coming on that?
[09:15] <\sh> hooohoo...ibex opened...preparing pkg mirrors...
[09:19]  * StevenK updates his local mirror config
[09:45] <\sh> do we have debootstrap in hardy backports already?
[10:07] <sebner> good morning :)
[10:07] <sebner> \sh: around?
[10:07] <\sh> sebner, somehow...
[10:08] <sebner> \sh: ^^, I'm not sure. Could it be that you commented to the false universe application?
[10:08] <\sh> sebner, yesyes...I already posted it to the list ;)
[10:09] <\sh> somehow the applications need to put their names in the subject ;)
[10:09] <sebner> \sh: ^^ np np
[10:09] <x1250> -> /usr/bin/fakeroot: 166: debian/rules: Permission denied
[10:09] <x1250> should I run debuild as root?
[10:10] <wgrant> x1250: chmod +x debian/rules
[10:10] <\sh> sebner, and the doomed part: stefan and steve ;)
[10:10] <x1250> wgrant: thanks
[10:11] <\sh> sebner, everytime I have something to do with people from oversees, they name me "Steven" or "Steve" ;)
[10:11] <sebner> \sh: well, so I'll keep my "Stefan" ;:)
[10:14] <sebner> \sh: it's just that persia told me it's better to have as much backing as possible otherwise I wouldn't have said anything because in my heart I know that you did mean me xD ^^
[10:14] <Mez> \sh, added you to collab-maint on alioth
[10:14] <\sh> sebner, it will go as planned ;)
[10:14] <\sh> Mez, thx :)
[10:15] <Mez> s/added you/got you added/
[10:15] <sebner> \sh: ^^ hope so
[10:15] <\sh> run debmirror run
[10:20] <sebner> \sh: a somehow stupid question. I'll start merging soon. Am I allowed to use already my proposed @ubuntu mail adress since I hate this hellboy thing ^^
[10:21] <\sh> sebner, if it's on your key why not...
[10:23] <x1250> should I ignore this? I guess its because it expectos unstable?
[10:23] <x1250> E: pastebin_0.1-1_i386.changes: bad-distribution-in-changes-file hardy
[10:23] <x1250> *expects
[10:24] <sommer> is it possible to add a ppa to pbuilder?
[10:27] <sebner> \sh: k, thanks :)
[10:27] <sebner> x1250: yep but it should be intrepid now
[10:27] <\sh> sommer, you need to add your ppa to your pbuilder sources.list file which you are using
[10:28] <x1250> sebner: thanks
[10:28] <sommer> \sh: ah, cool
[10:28] <sommer> \sh: is that seperate from the system sources.list?
[10:29] <\sh> sommer, yes...you copied normally the sources.list file to /etc/pbuilder/<whereever> and this file you need to adjust...and then pbuilder --override-config update
[10:30] <sommer> \sh: ooohhh, don't think I ever actually copied the file, will do though... thanks
[10:30] <\sh> sommer, just follow the pbuilder howto from the wiki...
[10:36] <x1250> ok, I'm getting on error and two warnings from lintian. I wonder if I can just ignore them all: http://paste.ubuntu.com/9432/
[10:36] <x1250> one*
[10:37] <\sh> x1250, copyright-lists-upstream-authors-with-dh_make-boilerplate <- this you need to fix
[10:37] <x1250> \sh: ok, thanks
[10:42] <emgent> hello
[10:43] <\sh> hey emgent go and start rocking intrepid :)
[10:45] <emgent> heheh \sh :)
[11:08] <x1250> is there any man editor other than gedit?
[11:08] <x1250> :P
[11:22] <CrippledCanary> where do I go to get a sponsored upload of bug #224241 ?
[11:22] <CrippledCanary> ubuntu-universe-sponsors is already subscribed
[11:27] <james_w> CrippledCanary: it's just a case of waiting then
[11:28] <CrippledCanary> ok.... i wanted to be sure that I didn't miss anything
[11:35] <Riddell> which wiki page describes how to apply for motu?
[11:35] <jpatrick> UbuntuDevelopment I believe
[11:36] <jpatrick> aha: https://wiki.ubuntu.com/UbuntuDevelopers
[11:37] <Riddell> that has a "Joining the ubuntu-core-dev team" section, but no joining motu section
[11:38] <Riddell> oh, it's hidden under Contributing Developers
[11:50] <_ruben> hmm .. this is from an auto-generated dependency list: Depends: libc6 (>= 2.6-1), libdumbnet1, procps (<< 3.2.8), procps (>= 3.2.7), lsb-base (>= 3.0-6)
[11:50] <_ruben> looks a bit odd, the double mention of procps
[11:51] <RainCT> _ruben: that's necessary to specify that you only want versions 3.2.7-3.2.8~
[11:52] <_ruben> hmm .. and gutsy got 1:3.2.7
[11:53] <_ruben> how does this shlibs:Depends thing work?
[11:57]  * persia reorders the UbuntuDevelopment page to avoid anything being "hidden"
[11:57] <persia> Err.  UbuntuDevelopers
[12:10] <persia> Riddell: Is https://wiki.ubuntu.com/UbuntuDevelopers#JoiningMOTU more clear?
[12:11] <Riddell> persia: yes, now it just need appropriate links from MOTU and MOTU/Council etc
[12:11] <persia> OK.  I guess my next activities are outlined then :)
[12:14] <sebner> persia: around?
[12:22] <persia> Riddell: https://wiki.ubuntu.com/MOTU already links to that page from "What does it take to become a MOTU?".  I've updated https://wiki.ubuntu.com/MOTU/Council to have links to all four groups.
[12:31] <sebner> nxvl: around?
[12:33] <persia> sebner: It's a good idea to provide some context when highlighting people.  Many regular channel participants simply ignore contentless pings.
[12:33] <sebner> persia: ah sry.
[12:33] <sebner> nxvl: ping, would you mind if I merge the newest beagle version? Since I already asked the last uploader :P
[12:35] <sebner> persia: would you mind taking a look at https://edge.launchpad.net/ubuntu/+source/wammu ? Debian fixed the first issue but didn't bumped the python-control versioning. How should I deal with it? Make it to a sync again?
[12:36] <persia> sebner: If you're hunting merges, feel free to take uqm and uqm-content.  I think one is a sync, but I haven't looked at them in a while.
[12:37] <sebner> persia: sry, uqm?
[12:37] <persia> The Ur-Quan Masters.  A quite excellent game in need of a merge for intrepid.  For extra points, follow up with importing the externally hosted packages with the archive admins.
[12:38] <\sh> W: Failure trying to run: chroot /tmp/schroot-H11754 mount -t proc proc /proc
[12:38] <\sh> WAAH
[12:38] <persia> \sh: Backport in progress...  Alternately, upgrade (but it's not safe)
[12:38] <\sh> persia, it's more ubuntu-dev-tools :)
[12:38] <persia> sebner: Why was the python-control dep bumped?  That looks like a new change you introduced.
[12:39] <persia> \sh: Are you sure?  I thought it was debootstrap
[12:39] <\sh> persia, yes..it's debootstrap...but I have the 1.0.9 from intrepid
[12:39] <sebner> persia: because of https://bugs.edge.launchpad.net/ubuntu/+source/wammu/+bug/204895
[12:39] <\sh> persia, regarding the changelog it's just ln -s gutsy intrepid
[12:39] <persia> Ah.  No idea then: I thought I read that the new debootstrap fixed it.
[12:39] <\sh> so it should work
[12:40] <\sh> persia, I'll bug colin
[12:41] <persia> \sh: Please report your results.  Be nice to have a guide to preparing an intrepid dev environment around.
[12:42] <persia> sebner: Hmm.  I guess it depends on how the transition was worked around.  If it can build with earlier versions, it doesn't need the strict dep (note that building with an earlier version may mean it cannot be installed with a later version).  If it doesn't build with the earlier version, and the Debian package doesn't have the strict dep, that's a bug in Debian, as it would break Debian backports, and should be reported as such.
[12:43] <\sh> persia, will do :)
[12:44] <persia> \sh: Good luck :)
[12:46] <\sh> persia, grmpf ;)
[12:46] <\sh> persia, this happened when using new deboostrap for creating a hardy chroot
[12:47] <persia> \sh: Ah.  That's extra frustrating.
[12:48] <\sh> persia, a sudo chroot <chroot dir>  brings "bash exec format error" so during debootstrap it tells me "mount exec format error"...so something really serious is bugged up
[12:48] <sebner> persia: k, thx. I'll check
[12:48] <persia> \sh: Excellent.  It being really broken makes it that much easier to track...
[12:49] <sebner> persia: and thx for the ur-quan stuff. for now I have *really* enough merges to do ^^
[12:50] <persia> sebner: No problem.  I've about 15 more assigned, so let me know if you're running dry.  There's a few I know will be tricky, but most are just backports of Debian changes and might be syncs.
[12:51] <sebner> persia: kk, first I'll do mine and later geser's ~50 ones ^^ I'll let you know if I need some but thanks very much for the offer :)
[12:51] <persia> sebner: Heh.  If you're already chasing geser's, you've plenty :)
[12:53] <RainCT> is Intrepid's archive already open?
[12:54] <sebner> RainCT: yep
[12:55] <RainCT> Oh, nice. Was there any announcement?
[12:55]  * RainCT wonders if he is missing some mailing list
[12:55] <sebner> RainCT: I don't think so but really crazy people like me check LP 100times every day ^^
[12:55] <\sh> persia, ok..intrepid debootstreap + chroot works as expected...now for the hardy one (doing now all manually)
[12:55] <sebner> RainCT: https://edge.launchpad.net/ubuntu/intrepid
[12:56] <\sh> RainCT, topic #ubuntu-devel
[13:00] <persia> RainCT: There'll likely be an email when everything is done, and the autosync starts.  At this point, the archives are open mostly because it was convenient to do so, rather than because all the intrepid prep is done.
[13:02] <\sh> DON'T INSTALL DEBOOTSTRAP from INTREPID YET !
[13:03] <emgent> uhm
[13:03] <\sh> emgent, revert your install ;) and downgrade to hardy one ;)
[13:04] <emgent> argh
[13:04] <emgent> ok, i go to eat
[13:04] <\sh> lol
[13:04] <emgent> see you later people :)
[13:04] <\sh> looks like it doesn't like the --arch switch
[13:07] <james_w> \sh: it's not http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363049 is it?
[13:09] <\sh> james_w, somehow it looks like it...but it's different here
[13:10] <\sh> james_w, sudo debootstrap hardy hardy_chroot <-- works as expected on amd64... sudo debootstrap --arch=amd64 hardy hardy_chroot <--- doesn't work and throws exec format errors (at debootstrap time for the mount command)
[13:10] <persia> +
[13:10] <\sh> james_w, I'm trying to reproduce this now with --arch=i386 and --arch=amd64 for intrepid
[13:11] <persia> Could still be the same bug, but just a different call environment, and different arches on the default mirror
[13:11] <\sh> but for hardy we had a similiar bug last time for hardy when I remember correctly
[13:11] <ScottK> I'm still using LaserJock's original pbuilder script and it doesn't use --arch.  So no wonder I didn't see it.
[13:12] <\sh> ok...--arch=i386 works
[13:12] <persia> \sh: Maybe.  I don't think debootstrap has worked properly for me since edgy, but I've always assumed that was my fault.
[13:13] <ScottK> That and I'm on i386 boxes anyway.
[13:14] <\sh> ScottK, well, it wouldn't be a big deal...but using sbuild + i386 +amd64 on amd64 box it is not nice to have e.g. intrepid-i386 , intrepid, intrepid-lpia ...because it worked before with --arch=amd64 and it should work now ;)
[13:15]  * persia isn't so concerned about intrepid-i386: it's a rare case that something that works for amd64 and lpia wouldn't work for i386.
[13:17] <ScottK> Agreed (should work now) - Fortunately it seems a highly qualified community developer is motivated to solve the problem.
[13:20] <\sh> forget about it
[13:20] <\sh> see #u-d
[13:20] <\sh> I kill my wife
[13:20] <\sh> and I hate my life
[13:20] <laga> hans?
[13:20] <\sh> she will get an official tabu for my office
[13:21] <laga> ah
[13:21] <laga> ;)
[13:22]  * laga needs to refrain from making distasteful jokes about hans reiser
[13:23] <\sh> between saying and doing there is a difference...when I would have killed all people I wanted to kill, hell...I would be imprisoned long time ago ;)
[13:23] <sebner> \sh: too late
[13:23] <ffm_> Hey, how do I go about gettting a package in ubuntu + debian?
[13:24] <sebner> persia: It's building with python-control 0.5 so I suppose we can sync it :)
[13:24] <geser> ffm_: get it included in Debian and then let it sync to Ubuntu
[13:24] <sebner> geser: I'll merge scite, ok?
[13:24] <geser> sebner: sure
[13:25] <sebner> geser: just wondering why you introduced this FTBFS fix since it doesn't FTBFS with the new debian version nor with the old debian version here
[13:25] <persia> sebner: Right.  As a lesson, it's a good idea to test things to make sure they really need dependency bumps.  Sometimes for integration purposes, it's better to recompile against a newer version, even when there's not a strict requirement.  In these cases, it's better not to enforce the build-dep if a backport would still work properly.
[13:25] <\sh> cu later...reinstalling
[13:25] <sebner> \sh: hf
[13:26] <sebner> persia: blame ScottK :P He forced me to bump it IIRC
[13:26]  * persia blames ScottK, but notes that sometimes a strict build-dep is required during a transition, just to avoid race conditions
[13:26] <sebner> ^^
[13:28]  * Hobbsee blames persia
[13:28] <persia> Hobbsee: Always a safe bet :)
[13:28] <Hobbsee> so, did anything interesting happen?
[13:29] <persia> Just a merge that can be a sync because we introduced a change that is no longer necessary
[13:29] <Hobbsee> oh good
[13:31] <sebner> uhh just 1 more and I have me first 10 full xD
[13:31] <ScottK> sebner: Which package are we talking about?
[13:31] <sebner> ScottK: wammu
[13:31] <geser> sebner: the FTBFS only happened on amd64 (see http://buildd.debian.org/fetch.cgi?pkg=scite;ver=1.75-1;arch=amd64;stamp=1197285793)
[13:31] <persia> ScottK: Based on sebner's test report, it doesn't actually need a strict build-dep on python-central 0.6.
[13:32] <geser> sebner: and looking at the scite changelog my fix got included in the Debian package
[13:32] <ScottK> Right.  The impact of building with an earlier version is it ships an empty /usr/lib dir in the .deb
[13:33] <geser> sebner: so it looks like a sync now
[13:33] <persia> ScottK: Ah.  Should that block backports?
[13:33] <ScottK> persia and sebner: I agree on wammu.  The impact of using the earlier version is minor and not worth maintaining.
[13:33] <ScottK> persia: No.  It shouldn't.
[13:33] <sebner> geser: ah totally missed that. sry. Will file a sync bug now :)
[13:34] <ScottK> I agree wammu is a sync now.
[13:34] <sebner> ScottK: fine. thx
[13:38] <ffm_> Uh, debian is a bit difficult for me to get into.
[13:38] <ffm_> How about getting my package into ubuntu for now...
[13:39] <persia> ffm_: The process is essentially the same.  Generate a candidate that is fully policy compliant (Debian has fewer policy requirements), and get someone to upload (in Debian you only need one ACK, rather than two).
[13:39] <persia> For Ubuntu, see !revu
[13:41] <ffm_> persia: However debian wants my real name.
[13:41] <persia> ffm_: So does Ubuntu
[13:41] <ffm_> persia: I'm a minor with parents who don't want to be able to google my name.
[13:42] <Amaranth> I never understood why people hide their names
[13:42] <Amaranth> ffm_: Then you can't get a package uploaded
[13:42] <ffm_> Amaranth: I wouldn't but I'm required to.
[13:42] <persia> ffm_: In that case, you'll need to work with someone else to have them take responsibility for your package.
[13:42] <ffm_> Amaranth: What if I could get a person who _did_ disclose their real name to sponser me?
[13:43] <Amaranth> ffm_: Then they would have to take responsibility for that package (fixing bugs, etc) and hope you would actually do it in their place
[13:43] <persia> ffm_: That works for both Debian and Ubuntu, but the person who does disclose their real name has to take responsibility for the package (perhaps as your proxy).
[13:43] <persia> Essentially, someone has to accept the upstream license, and extend a license to the distribution.  In many jurisdictions, it is hard for a minor to do this anyway.
[13:44] <persia> Amaranth: It's not so much about fixing bugs (although that is good), as the legal requirements for extending a license to the distribution.
[13:44] <persia> (distributions are granted licenses by uploaders, rather than by upstreams)
[13:44] <ScottK> Where in our policy does it say we need a real name?
[13:45] <james_w> ffm_: you can file an RFP in Debian ("Request for packaging"), and if it is interesting it will be picked up.
[13:45] <ffm_> persia: It's a GFDL book. I'll gladly disclose my name to canonical (they know it already) and have my parents sign and mail a release or what's required.
[13:45] <persia> ScottK: Inhereited from Debian policy, and no exception confirmed.
[13:45] <Amaranth> persia: I'm more worried about more and more new junk being uploaded without someone taking care of it when there aren't enough people to deal with the junk we have now
[13:45] <ScottK> persia: Not quite correct.
[13:45] <persia> Amaranth: I agree it's a concern, just not one about the name.
[13:45] <ScottK> persia: In Debian name is only verified for DDs/
[13:46] <ScottK> No one verified my name before they sponsored my stuff here or in Debian.
[13:46] <persia> ScottK: No?  I thought it was a requirement.  Interesting.  I wonder how SPI justifies the licenses for Debian software without the requirement.  Maybe it's never been tested.
[13:46] <ScottK> Anyonymous copyright is valid.
[13:46] <persia> ScottK: Well, depends on the jurisdiction.  Where you live, it's not.
[13:46] <ffm_> Fedora has the same policy.... :(
[13:46] <ffm_> persia: What about the USA?
[13:46] <ScottK> How does anyone who hasn't got their key signed get something uploaded?
[13:46] <persia> (or at least so is my reading of the relevant statutes)
[13:47] <ScottK> persia: I think that's not correct, but I need to depart for a $WORK meeting so we can debate another time.
[13:47] <persia> ffm_: My reading is that pseudonymous copyright is honored there, but not anonymous copyright, but you'd want counsel for an opinion.
[13:47] <ScottK> Ah.
[13:47] <ScottK> Sorry.  I agree with that.
[13:47] <ffm_> ScottK: What if I signed my pseudonymous key with my personal key (signed by people in the SWOT) and sent it to a canonical employee, who then signed and published that key (without my signature attached).
[13:48] <ScottK> Look at the upstream author's history for clamsmtp.
[13:48] <persia> ScottK: Makes sense.  Also, I agree with your point about verification: it's that I believe it to be a possible source of liability, which is fine as long as nobody is intentionally unable to disclose a name was there a question with licensing.
[13:48] <ScottK> ffm_: There's no verification that the key you put in LP has your actual legal name on it.
[13:49] <persia> ffm_: Have you registered your psuedonym?  In most states in the USA it's about a $10 fee at the local city hall, and then any questions I raise about not using your real name are likely to be moot.
[13:50] <persia> And, as ScottK says, we don't verify, although we do reject obvious handles preferring at least believable pseudonyms for new packages.
[13:50] <ScottK> persia: Have we ever actually done that?
[13:51] <ScottK> I know LP requires a real looking name for their beta test team and has booted people because of it, but I didn't think Ubuntu did.
[13:51]  * ScottK really needs to leave ....
[13:51] <persia> ScottK: Yes.  I've seen several comments on REVU (not all mine) requesting a real name in the changelog.  I suspect we're covered by "reasonable doubt" in common-law jurisdictions, and "limited dilligence" in civil law jurisdictions with that practice, but that's not legal advice.
[13:51] <sebner> ScottK: bye bye ^^ may want to take a look at my application?
[13:52] <persia> ScottK: Go to your meeting.
[13:52] <ffm_> persia: my psedonym is 'ffm'.
[13:52] <persia> Oh, and Ubuntu doesn't care for most cases, just new packages.  Contributors can have any LP name they like.
[13:53] <ffm_> persia: If someone else uploads it, I don't get credit for my work.
[13:54] <persia> ffm_: That's likely insufficient to cause anyone to believe that the reviewer didn't notice.  At least I'd be concerned about advocating such a package, although I can't speak for everyone, and most importantly, not for the archive admins who are the final arbiter as to whether Ubuntu will accept any offered package.
[13:54] <ffm_> persia: Can a maintainer be psedunonymous?
[13:54] <persia> ffm_: How do you mean?  There's no reason the changelog can't say "Thanks to ffm for the initial packaging", it's just that someone else has to sign it.
[13:55] <laga> ffm_: if it's not your real name, would you actually get "credit" at all? t'd stll be your pseudonym in there
[13:55] <Hobbsee> ffm_: i used a psuedonym for ages in ubuntu.
[13:55] <Hobbsee> ffm_: made no real difference.
[13:55] <Hobbsee> ffm_: your identity isn't much different, depending on how many words you're using to define yourself.
[13:55] <ffm_> laga: yeah, I would.
[13:56] <persia> ffm_: Yes.  There's at least one Debian Developer who acts strictly according to a legal pseudonym, but it needs to be registered.  In Ubuntu, we don't have maintainers, as such, but the initial packager may be pseudonymous as long as we either don't notice (unlikely in your case at this point), or it is a registered pseudonym.
[13:56] <persia> (as previously noted, this is neither legal advice, nor a guide to the eventual actions of the archive administrators)
[13:57] <ffm_> persia: I don't think city hall will allow me to register "FFM", especially as a minor.
[13:57] <ffm_> persia: I understand.
[13:58] <persia> ffm_: As a minor, you'd just need parental consent to register a pseudonym, as I understand it, for some set of jursidictions (that's actually decided state-by-state in the USA).  I'm less sure about the use of "FFM", but there are some strange legal pseudonyms out there.
[13:58] <Hobbsee> ffm_: give them a false name?
[13:58] <ffm_> Hobbsee: I doubt they'd accept "Fire Fox Man" (what FFM originally stood for) either.
[13:59] <Hobbsee> ffm_: your parents won't let you put your name on your key, but use an alias for everything else?
[13:59] <persia> Actually, I suspect "Fire Fox Man" would be acceptable, although it may have trademark issues, depending on the use to which you intended to put it.
[13:59] <Hobbsee> that's what i did
[14:00] <ffm_> Hobbsee: I'm not sure... I'll have to ask...
[14:00] <ffm_> persia: What, with mozilla? They'll thank me for the advert.
[14:00] <persia> ffm_: Also, you can do lots of bugfixes and revision uploads without any hassle about your name: it's just new packages that get sticky (due to the bit about "This package was debianised by (insert name here)"
[14:00] <Hobbsee> ffm_: might be worth doing so.
[14:00] <Hobbsee> persia: i wouldn't have expected there to be a problem until the requiring of keysigning, for motu-ship
[14:01] <persia> Hobbsee: For working on Ubuntu, I believe there is no problem until keysigning.  For new packages, I've seen a few packages in REVU be rejected for not having a real name.
[14:01] <Hobbsee> persia: really?
[14:01] <Hobbsee> persia: who rejected them?
[14:02] <persia> Really.  I forget who, etc.  Grep "Real Name" in the REVU mailing list archives.
[14:02] <Hobbsee> persia: following launchpad's lead, i really see no reason why an alias can't be used, prior to the key signing for MOTUship.
[14:02] <Hobbsee> s/prior/modulo/
[14:02] <persia> I know I left at least one comment along those lines, but I don't think I was the sole culprit.
[14:03] <persia> Hobbsee: See backscroll about my opinion on that.  I believe it to be about someone granting Ubuntu the license to distribute the software.
[14:04] <Hobbsee> ScottK: LP has stopped requiring it.
[14:04] <Hobbsee> (finally)
[14:04] <Hobbsee> persia: if that's hte case, then all real names should be verified.
[14:05] <persia> Hobbsee: Likely.  That's up to Ubuntu's counsel (if any) to determine and impose.
[14:05] <ffm_> Hobbsee, persia , thanks for the help.
[14:05] <Hobbsee> ffm_: it shouldn't really be an issue.
[14:05] <Hobbsee> bah.
[14:06] <laga> i'd get rather annoyed at my parents if they didn't let me use my name. i mean, it's mine. but of course, i'm sure they have reasons for doing so.
[14:07] <jcastro> ok, we have 2 open slots for openweek that just opened up @1600 and 1700 UTC
[14:07] <jcastro> if anyone wants to run a session please let me know
[14:07] <Hobbsee> laga: they certainly have a point.
[14:08] <Hobbsee> laga: then again, i choose not to use my real name as much as possible (at least, modulo going to sevilla for a UDS)
[14:10] <laga> Hobbsee: i used to do the same, but for debian/copyright and debian/changelog i don't want to use a pseudonym
[14:10]  * Hobbsee just doesn't do new packages.
[14:11] <sistpoty> hi folks
[14:11] <laga> yay.
[14:12] <iulian> Yikes!
[14:13] <Daviey> :o
[14:18] <sebner> heya sistpoty
[14:18] <sistpoty> hi sebner
[14:18] <sebner> sistpoty: got my mail?
[14:18] <sistpoty> sebner: hm? regarding universe contributors application?
[14:18] <sebner> sistpoty: right :)
[14:19] <sistpoty> sebner: yeah... but I've been lazy so far and haven't answered yet :P
[14:19] <sebner> sistpoty: I see ^^
[14:21] <bddebian> Heya gang
[14:21] <sistpoty> hi bddebian
[14:21] <sebner> heya bddebian
[14:21] <bddebian> Hi sistpoty, sebner
[14:27] <iulian> Boo bddebian!
[14:27] <bddebian> Heh, hello iulian
[14:28] <guja_nebeska>  I want to be Ubuntu developer. I am relativly beginner, and I am asking from You to give me some advice and literature to read and learn Ubuntu so I can develop that OS.
[14:28] <guja_nebeska> I am C and C++ programmer, but don't know as much about Ubuntu as programming.
[14:28] <guja_nebeska> So, please, give me some ebook adivces, books, links, anything.
[14:28] <guja_nebeska> I'd be very grateful for any kind of help.
[14:28] <guja_nebeska> Thank You.
[14:29] <jcastro> thekorn: ping
[14:30] <RainCT> Hi guja_nebeska
[14:30] <guja_nebeska> Hi RainCT.
[14:30] <RainCT> guja_nebeska: what are you interested in? Packaging / bug fixing, creating new applications for Ubuntu, working on existing applications..?
[14:31] <guj4_n3b3sk4> RainCT, creating new applications.
[14:31] <guj4_n3b3sk4> But:
[14:31] <guj4_n3b3sk4> I don't know much about Linux OS and Ubuntu.
[14:31] <guj4_n3b3sk4> I think I need 1st to learn lots about that.
[14:31] <guj4_n3b3sk4> So I can build some applications.
[14:31] <guj4_n3b3sk4> Right?
[14:33] <persia> guj4_n3b3sk4: We don't tend to build a lot of new applications in Ubuntu, it's more about maintaining the existing packages, and adding new ones from various sources.
[14:33] <guj4_n3b3sk4> persia, then that kind of stuff.
[14:33] <persia> If you really want to work on new software, you'd do best to just dig in and write it (and once it's good we're happy to help get it into Ubuntu).
[14:33] <guj4_n3b3sk4> Anything that can be interesting and having work to do.
[14:34] <persia> Ah, good.  In that case, we've heaps and heaps of stuff to do.
[14:34] <RainCT> guj4_n3b3sk4: well, then this isn't the right channel (#ubuntu-motu is about packaging), but anyway.. is there anything specific you would like to know about? For stuff with GUI, look at GTK+ (or Qt if you use Kubuntu). http://ubuntuforums.org/forumdisplay.php?f=39 might also help
[14:35] <persia> I'd recommend reviewing https://wiki.ubuntu.com/MOTU/Contributing, and looking at the ~35,000 open bugs.  There's likely quite a few that are bugs in C or C++, most commonly due to people not checking for error conditions being returned by functions.
[14:35] <guj4_n3b3sk4> Well, if I want to solve some of those bugs, I need to be very familliar with Ubuntu system, right?
[14:35] <persia> Not necessarily.
[14:36] <guj4_n3b3sk4> What knowledge do I need to have?
[14:36] <persia> As an example, let's say there is some game you play that crashed.  You'd only need to understand enough about that game's code to fix the crash.  As you fix more, you'll develop an undersanding of the entire system, and of the processes we use to get the patches available to everyone.
[14:37] <persia> You really don't need any specific knowledge, only a willingness to learn, a desire to investigate any issues, and the ability to discover information from online sources.
[14:38] <guj4_n3b3sk4> If that's so, can you give some "bug training pages"? Like the easiest bugs and it's fixes?
[14:38]  * jdong looks at poolie's latest planet post...
[14:38] <jdong> it's a good idea, I do it by default...
[14:38] <jdong> IMO it should be default behavior though
[14:39] <persia> https://bugs.launchpad.net/ubuntu/+bugs is the list of open bugs, and https://wiki.ubuntu.com/Bugs talks about tracking them down.  For the most part, each bug has a unique solution, so that's a bit harder.
[14:39] <Hobbsee> jdong: because scripts should not be allowed to work, at least for some people?
[14:39] <persia> You might want to take a look at https://wiki.ubuntu.com/UbuntuOpenWeek for some current discussions about various aspects of Ubuntu, and the logs may provide some guidance as to how to help.
[14:39] <jw2328_> guj4_n3b3sk4: look for bugs with the "bitesize" tag, they should be easy to start with
[14:39] <jdong> Hobbsee: the one regarding setting dput.cf to default to a nonexistent target?
[14:40] <Hobbsee> yes
[14:40]  * jdong thinks setting default to nonexistant is useful to prevent accidentally uploading to the wrong spot
[14:40] <guj4_n3b3sk4> jw2328_, any link to that?
[14:41]  * Hobbsee doesn't like the thought of merging it each time the package gets updated.
[14:41]  * persia likes having a default set
[14:42] <persia> Hobbsee: We already have a significant merge to dput.cf, so it's not a lot extra
[14:42] <jw2328_> guj4_n3b3sk4: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[14:42] <Hobbsee> persia: i meant every user, but yes
[14:43] <persia> Hobbsee: Well, it only happens for those ~1000 people with dput installed, and only when we change the defaults.
[14:43] <Hobbsee> right, eyah
[14:52] <gnomefreak> shouldnt envy be in multiverse instead of uni? since its installing drivers and building modules for it? and we are unablet o support the drivers or modules?
[14:53] <gnomefreak> nvidia=glx-* are the same thing but they cant be put in uni
[14:54] <persia> gnomefreak: It's not about support, it's about licensing.  If envy works without requiring the download of packages for which the license is inappropriate, it can be in universe.  If it doesn't, it needs to be in multiverse.  Depends on whether it's automatic, or a result of user action.
[14:55] <persia> The base test is whether a user could conceivably use envy in a way that didn't require non-free software.
[14:55] <persia> (and yes, licensing often impacts supportability)
[14:55] <gnomefreak> but isnt that the point it is installed and building nonfree items
[14:56] <gnomefreak> assuming that the python part of the script is free?
[14:56] <gnomefreak> atleast if i remember right it is py
[14:57]  * persia looks for an example package
[14:57] <gnomefreak> persia something like say the hardware installer in main?
[14:59] <persia> gnomefreak: That's a fairly direct comparison, and doesn't provide much parallax.  I'd argue that they are both free or non-free for the same reasons, but want to look for something else as a determinant.
[15:00] <gnomefreak> persia: ok
[15:00] <gnomefreak> i just dont want people getting the idea we support the drivers or the install of the drivers, apt-cache show doesnt say anything about installing restricted drivers
[15:01] <persia> BSD w/advertising is enough for non-free, right?
[15:01] <persia> s/non-free/multiverse/
[15:02] <gnomefreak> for multi it should be
[15:03] <persia> gnomefreak: As in, anything with the advertising clause can't be universe?  Oh well.  I thought I had an example.
[15:05]  * gnomefreak doesnt have a problem with it its the support end where user says you support envy but not the drivers that it gets.  we have worked hard and long to get people to not use official drivers from the .run script and that is all envy does is grab the .run and run it afaik
[15:05] <gnomefreak> does it atleast remove the modules and drivers when you remove envy?
[15:07] <devfil> persia: ping
[15:10] <ScottK> persia: 4 clause BSD (with the advertising clause) is DFSG free, but not GPL compatible.
[15:11] <ScottK> gnomefreak: I think the difference is that the drivers have to be put into multiverse by an Ubuntu dev and agreed by the archive first.
[15:11] <persia> ScottK: OK,  Any idea why basilisk2 is contrib/multiverse then?  The only thing I can see is that it requires an old apple ROM image, which would be a good match for envy/jockey.
[15:12] <gnomefreak> ScottK: ok i get it
[15:12] <ScottK> gnomefreak: Not sure how well this will work, but it's way better than the original upload that updated from Alberto's PPA and gave a non-developer access to arbitrarily update end users systems.
[15:12] <gnomefreak> ScottK: persia thanks
[15:13] <ScottK> persia: No.  No idea (no time to research it just now either).
[15:13] <ScottK> persia: A few months ago someone asserted 4 clause BSD was non-free on debian-devel and got a serious beat down as a result.
[15:13] <devfil> persia: this bug https://bugs.edge.launchpad.net/baltix/+source/wxwidgets2.8/+bug/133888 in ubuntu was fixed but in baltix it is in "New", what should be is status?
[15:14] <persia> gnomefreak: I'm not likely to research it either, but if you want to track it down, you might use it as an argument to either demote envy&jockey or promote basilisk2.
[15:14] <ScottK> The summary of the discussion was it's technically DFSG free (because it was part of the defined set of DFSG licenses when DFSG was approved), but really not a good choice for free software.
[15:15] <ScottK> devfil: You can ignore the baltix part.
[15:15] <gnomefreak> persia: im gonna grab souce and see if it removes the full install drivers + modules
[15:15] <persia> devfil: No idea.  I don't track baltix.  If it exists, you might try #baltix.
[15:15] <persia> gnomefreak: Regardless of how well it works, I can't see any reason why the component should be different than basilisk2.
[15:16] <devfil> ScottK, persia: ok, thanks
[15:16] <persia> devfil: In general, once you close the Ubuntu tasks for wxwidgets, feel free to unsubscribe from the bug.
[15:16] <persia> (and thanks for your efforts with the library: it's really nice to see it being properly maintained)
[15:17] <devfil> persia: ok
[15:17] <gnomefreak> its more widely used?
[15:17]  * persia notes for those not watching, that devfil == dfiloni
[15:17] <persia> gnomefreak: How does that affect anything?  I can see it for a restricted/multiverse argument, but not for a universe/multiverse argument.
[15:18] <gnomefreak> well even that makes sense since our drivers are in restricted not multi anymore
[15:19] <persia> gnomefreak: Right.  Something that gets a lot of use, and can be supported (even as closed source) can be restricted.  I believe the TB limits this to drivers at the current time.  Most non-free stuff gets put in multiverse.
[15:20] <gnomefreak> ah ok i see it now its all making sense
[15:20] <persia> gnomefreak: Best check with the archive admins,  If you need a definitive answer, ask elmo, but ask the archive admins first.
[15:23] <ScottK> jdong: I also set my upload target to a non-existent target in dput.cf, but I don't think we should change the package defaults.
[15:24] <jdong> ScottK: do we encourage doing so in setting up a default environment?
[15:24] <jdong> ScottK: with PPAs and revu around, it's really easy to upload to the default when one means the others
[15:25] <ScottK> True.  I also discovered that if you completely unset the target it send it to Debian.
[15:25] <persia> jdong: The presumption is that anyone who has permission to cause an issue when uploading to ubuntu by accident has a procedure in place to avoid such mistakes.
[15:25] <ScottK> Which is why I changed my default.
[15:26] <ScottK> persia: Or in my case will put them in place after they mess up once.
[15:26] <Hobbsee> andi t's a development release, which means that you can always revert if you really screw up
[15:26] <ScottK> Yep.
[15:26] <jdong> I suppose
[15:26] <persia> ScottK, Hobbsee: Well, sure.  That's why it's a presumption, rather than a requirement.
[15:26] <ScottK> kde-guidance has a debian/changelog entry that says "Revert upload intended for PPA".
[15:27]  * jdong nods
[15:27] <ScottK> jdong: Changing dput defaults in a way that would affect every developer is not something we should do lightly.
[15:27] <persia> jdong: All that said, be very, very careful, and don't make another changelog like that :)
[15:27] <jdong> lol I've never done it (yet) ;-)
[15:27] <ScottK> That was me.
[15:27] <jdong> (watch, now that'll curse me to do it)
[15:28]  * persia would be especially opposed, as >90% of uploads are to Ubuntu default repo, and it's easier not to type it.
[15:28] <ScottK> Worse I did it during one of the soft freezes.
[15:49]  * sladen tries to remember to set it to 'unpublished' and only change to the upload distro when it's ready
[16:09] <sebner> heya afflux
[16:10] <afflux> hi sebner :) how was your 1st may? ;)
[16:12] <sebner> afflux: calm, and yours? ^^
[16:12] <afflux> a rather long night ;)
[16:13] <sebner> afflux: ^^. btw I hate new bugsquad members -.- they do wired stuff with my bug repots
[16:13] <sebner> *reports
[16:13] <afflux> huh
[16:14] <sebner> afflux: bug 225669
[16:14] <sebner> afflux: why the hell does he set it to Confirmed and assigned it to MOTU media?
[16:14] <ScottK> sebner: Let me have a look.
[16:14] <sebner> ScottK: hm?
[16:15] <afflux> hm, never saw that name
[16:15] <sebner> afflux: ^^
[16:16] <ScottK> He's not on IRC right now.
[16:17] <sebner> ScottK: I suppose he is pretty new and confused ^^
[16:17] <afflux> joined bugsquad on tuesday
[16:17] <afflux> I think we should add some notes to the HowToTriage pages for bugs used by developers for their "todo list"
[16:17] <afflux> or motu tasks in general
[16:17] <sebner> afflux: would be nice :)
[16:18] <persia> afflux: Please do.
[16:18] <sebner> persia: are you never sleeping? ^^
[16:18] <persia> sebner: I sleep at least 40 hours a week.
[16:19] <sebner> persia: ~6 per day. horrible :P
[16:20] <jdong> that's 3x as much as I sleep...
[16:20] <jdong> yikes.
[16:22] <persia> jdong: It's a location thing.  Despite perception, Tokyo is a sleepier place than Boston.  The trains stop earlier and start later.
[16:24] <jdong> persia: interesting. didn't know that
[16:25] <sebner> persia: I would be really interested in how old you are and how you look like :)
[16:26] <jdong> is this what the "if you prefer some human contact" part of the start page means?
[16:26] <jdong> *hides*
[16:27] <persia> sebner: Look me up next time you come to Tokyo then :)
[16:27] <sebner> persia: hmrpf. so never I suppose ^^
[16:28] <persia> Well, that's about how often I've been to Hermagor ;)
[16:29] <sebner> persia: well, at least Vienna should be possible ;)
[16:30] <persia> To be honest, I've only ever been in Innsbruck in Austria.
[16:31] <sebner> persia: why that O_o
[16:34] <persia> Close to the Arlberg Pass?  Anyway, well off-topic :)
[16:34] <sebner> persia: for skiing? , yeah true ^^
[16:40] <Konam> The package gnome-subtitles isn't working as expected on my system. It crash when I try to create a new sub and doesn't open subs that I already have on my hdd
[16:42] <persia> Konam: You likely want #ubuntu-bugs, and you'll want to have first searched (and maybe reported something) from https://bugs.ubuntu.com/ubuntu/+source/gnome-subtitles/+bugs
[16:43] <Konam> persia oh, sorry
[16:43] <Konam> I thought that this channel was to report this kind of stuff
[16:43] <Konam> and since the maintainer of that package are the motus I thought that I have to come here, not ubuntu bugs
[16:45] <persia> Konam: No problem.  This is where we tend to coordinate the MOTU work, but #ubuntu-bugs is where the team that keeps track of all the bugs chats about the bugs, and duplicates, etc.
[16:46] <Konam> got it
[16:58] <Konam> persia it seems that the problem isn't in the motu package, a getdeb package have the same problem too, it must be something on my system but I don't know what
[16:59] <persia> Konam: Hmm..  getdeb is specifically unsupported, and ubuntu-backports recommended for the same purpose.  You might try asking in #ubuntu (user support channel).
[16:59] <Konam> persia yeah, I know. I was just telling you for the record, not asking for support ;)
[17:00] <persia> Konam: Sorry if I give the perception that I'm sending you away: it's just that I know nothing about that package, and want to point you towards people who might be able to help :)
[17:00] <ScottK> Konam: For the record getdeb developers have been asked to participate in official Ubuntu development and work in backports, but declined because the official quality standards are to hard to meet from their perspective.
[17:00] <laga> hum. i'd like to do an SRU for a native package which doesn't have a patch system. is it ok for the changes to end up in the .dff.gz? for intrepid, the package wll be fixed "properly".
[17:01] <ScottK> laga: Generally yes, but do note that native packages dont' have a .diff.gz.
[17:02] <Konam> ScottK I know. What I'm trying to say is that the ubuntu-motu package and the getdeb package are giving me the same problems so I think it got something to do with my system.
[17:02] <laga> ScottK:  sorry. of course, it's not a native package.
[17:02] <persia> Further, native packages ought never have a patch system.
[17:02] <laga> yes. that'd be silly. :)
[17:03] <ScottK> Konam: OK.  Just read more of the backscroll.
[17:03] <ScottK> Konam: I remember something about that package.  There may be a pending update for it.  I'd encourage you to look for your issue in existing bug reports.
[17:04] <persia> laga: The basic rule is to use the existing patch system.  If the packages stores changes outside debian in diff.gz, then your new patches should also be in the diff.gz.  If the package doesn't have any patches (rare), I'd recommend looking at other packages by the same Debian maintainer to select a patch system, in the expectation that this would maximize your chances of getting the fixes into Debian easily.
[17:04] <persia> If it's an Ubuntu-local package with no patch system and no changes in diff.gz, you get to select the patch system as the first person to generate a patch.
[17:05] <laga> persia: it's a mythbuntu package. since we're upstream, there is no reason for a patch system
[17:05] <laga> but thanks for the instructions, i'll keep them in mind!
[17:05] <ScottK> For an SRU, I think the preference is not to introduce a patch system if one isn't already present.
[17:06] <persia> laga: In the specific case of mythbunth, you're dealing with Ubuntu-local non-native packages (and thank you for having them be non-native).  Add any patch system you like for the SRU: I'd recommend diff.gz, given that upstream is all in VCS, and you'll likely be creating an SRU branch.
[17:07] <persia> ScottK: Doesn't that depend somewhat on the package?  I thought that when backporting SRU fixes from Debian, it was encouraged to use the same patch system as used in Debian for the fix, even if that meant introducing something.
[17:07] <laga> persia: i'm not creating an SRU branch, i'm currently the only one comitting fixes which are for the SRU
[17:08] <ScottK> persia: If you're pulling a patch from Debian and they added a patch system for it, then I agree that's the low risk approach.
[17:08] <persia> laga: Ummm...  There's a release branch, and then new work.  Won't the changelogs differ between the intrepid upload and the hardy-proposed upload?  To support another SRU for the same package, won't you want to branch it in your VCS so you can easily do the next one?
[17:09] <persia> (note that this is mythbuntu-specific advice: most packages in Ubuntu universe don't have dedicated Ubuntu packaging in a VCS, and oughtn't)
[17:10] <laga> persia: you're right. creating a branch for hardy is the most sane approach. i'll do that later, though. the current SRU debdiff is almost ready :)
[17:10] <persia> ScottK: Right.  I agree it's a rare case, but want to preserve the "keep the existing patch system" and "minimize non-automated" changes memes.  I really don't like SRUs that deviate significantly from the fix as applied elsewhere or SRUs that include hand-monkeying with autotools stuff to minimize the debdiff.
[17:10] <ScottK> Yes.
[17:11] <persia> laga: Please commit your change to a branch in BZR and pull the created package from BZR to generate the debdiff, just to ensure repeatability.  This procedure was missed a few times for some of the Ubuntu native packages previously (pre-Dapper), and there were some odd regressions.
[17:12] <laga> persia: done.
[17:13] <persia> laga: Thanks :)  Also, you guys might want to follow the new package format discussions.  If LP can handle the BZR-format packages, it ought make things easier.
[17:13] <laga> i've committed and created a fresh checkout afterwards, that should be good enough.
[17:14] <persia> laga: Ought be.  I suspect best practice involves setting some flags and using bzr-builddeb, but I'm not familiar with that tool.
[17:14] <laga> i've never used t either
[17:14] <laga> SRU first, learning new things afterwards :)
[17:15] <persia> Anyone familiar with best packaging practices with BZR willing to review laga's work to make sure the next mythbunth SRU goes smoothly?
[17:16] <laga> seriously: the debdiff looks sane, i've used the same orig.tar.gz which is already in hardy-proposed.  i don't see what could have gone wrong :)
[17:17] <afflux> will packages that are new in debian be automatically synced into intrepid or would that need a sync request?
[17:17] <james_w> persia: sure, give me a pointer.
[17:17] <persia> laga: Do you have a URL for james_w?
[17:17] <laga> yes, in a few..
[17:17] <ScottK> afflux: Ones with no differences between Debian/Ubuntu will be automatically sync'ed
[17:18] <persia> afflux: Things in contrib and non-free need manual review (to decide if they are universe or multiverse).  Everything in Debian main will autosync.
[17:18] <ScottK> afflux: I missed New in your question.  Yes.  They will.
[17:18] <afflux> okay thanks!
[17:23] <laga> james_w: https://bugs.launchpad.net/ubuntu/+source/mythbuntu-control-centre/+bug/221921/comments/7 - here's the debdiff. do you also need the upstream branch?
[17:24] <james_w> you want me to check that your changes are reflected in the bzr branch correctly?
[17:25] <laga> i have no clue what persia wants :) the debdiff should be OK.
[17:28] <persia> james_w: If you would, please.  mythbuntu is doing everything non-native in BZR, and I'd like to make sure that the SRU practices match their general packaging practices.
[17:28] <laga> https://code.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-control-centre
[17:28] <laga> here's the upstream branch
[17:29] <laga> james_w: revision 214 is what's in regular hardy.
[17:29] <persia> laga: I'm sure the debdiff is perfect, and that the debdiff is the preferred form of review by the SRU team: I just remember flamewars over SRUs not being in VCS properly for other packages, and want to try to keep you from getting hit.
[17:30] <laga> persia: ah, now i understand your concerns. i'm being a little bit thick today, didn't get enough sleep.
[17:30] <laga> as i said, the SRU was built from a fresh checkout. let's see what james_w says
[17:31] <james_w> yes, it looks like your debdiff corresponds to the changes in bzr.
[17:31] <persia> Are there any tags that need to be added?  I know many SVN maintainers use tags, but I don't know much about the BZR packaging workflow.
[17:31] <persia> (and don't know what bzr-buildpackage expects)
[17:32] <james_w> no, nothing should be required.
[17:32] <james_w> this is a native package?
[17:32] <james_w> ah no, you said it wasn't.
[17:33] <persia> james_w: Thanks.
[17:33] <laga> james_w, persia: thanks everyone for their feedback :)
[17:33] <james_w> no problem.
[17:33] <persia> laga: Sorry for the confusion.  I'm just paranoid about these things.
[17:37] <laga> no problem :)
[17:38] <persia> So, I failed to actually get much of anywhere with bug #194924 for hardy, and it's been up to date in Debian for a while.  Anyone think we ought do an SRU, or just a backport when the autosync runs?
[17:39] <persia> Essentially, the hardy package is incompatible with everyone else (Windows, Mac, Debian, SuSE, Fedora).
[17:42] <ScottK> persia: So really the only solution is to upgrade?
[17:42] <persia> ScottK: Well, it's the easiest solution.  I suppose one could try to backport the communications protocol, but I'd think that would be higher risk.
[17:43] <ScottK> Agreed.
[17:43]  * persia should probably have milestoned this bug sometime earlier
[17:43] <ScottK> persia: How about we do a source backport straight to hardy-backports and then after testing get it copied into -updates?
[17:44] <ScottK> If it's upload the current package in Sid, I can do that.
[17:44] <persia> ScottK: Works for me.  Would you mind giving it a shot, and commenting on the bug so the interested parties can test?
[17:44] <ScottK> persia: I'll upload it, but won't have time to coordinate testing.
[17:45] <persia> ScottK: Given the bug history, I think that if the -backports availability is noted in the bug, it will get sufficient testers.  I'll try to watch it a bit, and poke if it doesn't get enough in a week or two.
[17:46] <ScottK> OK.  Then someone will have to approach pitti and ask him to copy it at some point.
[17:46] <persia> Probably needs some motu-sru attention, but I think jdong was the person who pointed me at it in the first place, so that oughtn't be a big issue.
[17:47] <persia> Right.  I'm up for doing that, if it gets sufficient positive responses to testing.  If people complain, then I'm tempted to leave it in -backports.
[17:47] <ScottK> Sounds reasonable.
[17:48] <persia> Note that the awkward bit is that Dapper <-> Hardy is compatible now, but with this it won't be.  It might be a good idea to leave it in -backports until almost .1 just to let people migrate.  Maybe I'll send an email to the ML once it's in backports to get more opinions.
[17:55] <ScottK> If it breaks upgrades, I'd be tempted to leave it in backports period.
[18:02] <ScottK> persia: You mean dapper <-> hardy synchronization, not dapper -> hardy upgrades, right?
[18:07] <squentin> How should recommended optional dependencies be specified ? I though the ones in Recommends were installed by default, but it seems it's not the case with synaptic (see bug #8896)
[18:13] <nxvl> Intrepid server are officialy open, didn't them?
[18:18]  * pochu starts requesting syncs
[18:18] <pochu> nxvl: yes, see /topic in -devel
[18:23] <ScottK> persia: Unison hardy-backport uploaded.  Now we wait for an archive-admin to accept it.  Today it pitti's day, but he's on vacation, so maybe slangasek will accept it on Monday.
[18:23] <bddebian> Oh crap I was supposed to test an upload for Riddell
[18:27] <nxvl> pochu: wooho \o/o
[18:27]  * nxvl crates pbuilder chroot
[18:28] <sebner> nxvl: I merged the new beagle version, ok?
[18:29] <pochu> sebner: feel free to merge libbeagle too (I was the last to touch it) ;)
[18:31] <RoAkSoAx> where can i find a list of server related packages to merge?
[18:32] <sebner> pochu: I feel free ^^ just wondering why it's not on DaD
[18:32] <sebner> RoAkSoAx: http://dad.dunnewind.net/universe.php
[18:32] <RoAkSoAx> thanks sebner  :)
[18:32] <sebner> RoAkSoAx: mind the comments on the right side! ;)
[18:33] <nxvl> sebner: yep, there is no problem :D
[18:34] <pochu> sebner: it's in main
[18:34] <nxvl> sebner: i just did it for my talk :D
[18:34] <sebner> pochu: uhhh main. I don't want to touch main xD seems to be a sync though
[18:35] <sebner> nxvl: ok, great then :D
[18:35] <pochu> sebner: right, I'll ask seb128 to sync it then :)
[18:35] <sebner> pochu: hey.
[18:35] <pochu> sebner: I didn't even look at our changelog :P
[18:35] <sebner> pochu: let me file a sync bug :P
[18:36] <sebner> pochu: where?
[18:36] <pochu> where what?
 sebner: I didn't even look at our changelog :P
[18:36] <pochu> ah, aptitude changelog libbeagle
[18:36] <pochu> to look at our diff ;)
[18:36] <sebner> pochu: hmm? I haven't touched libbeagle yet
[18:37] <pochu> sebner: nevermind
[18:37] <pochu> see you later!
[18:37] <sebner> pochu: ^^, ok let me file a sync bug :)
[18:37] <sebner> pochu: are you sure it's a sync or should I investigate further :)
[18:44] <nxvl> does anyone has an idea of which packages provides vim's changelog syntax highlighitng?
[18:45] <james_w> nxvl: hi
[18:45] <james_w> vim I think
[18:46] <RoAkSoAx> nxvl, this might help ya' http://ubuntuftw.blogspot.com/2007/08/habilitar-syntax-highlighting-en-vim.html
[18:47] <norsetto> vim? bah, real men use binary editors
[18:48] <sistpoty> nxvl: vim-runtime
[18:48] <sebner> heya norsetto
[18:48] <sebner> sistpoty: ha!!!!!1
[18:48] <norsetto> hey sebner
[18:48] <sistpoty> hi sebner
[18:49] <squentin> Nobody to answer my question ?  How should recommended optional dependencies be specified ? I though the ones in Recommends were installed by default, but it seems it's not the case with synaptic (see bug #8896)
[18:49] <sebner> norsetto: you may want to add a comment on my application
[18:49] <sebner> sistpoty: you too :P
[18:49] <norsetto> sebner: on the wiki you mean?
[18:49] <sebner> norsetto: no, https://lists.ubuntu.com/archives/motu-council/2008-April/001072.html
[18:50] <sebner> norsetto: but you are also invited to add something on the wiki :)
[18:50] <norsetto> sebner: ah! The question is, do we REALLY REALLY want you around? hmmmm
[18:51] <sebner> norsetto: ^^, feel free to write your honest opinion :)
[18:52] <norsetto> sebner: what if I say no? Will you disappear?
[18:52] <sebner> norsetto: hmm. no. I will spam u-u-s even more :P
[18:52] <sistpoty> sebner: answered in the mc-thread ;)
[18:52] <sebner> sistpoty: ah finally ^^. no. thanks :)
[18:52] <norsetto> sebner: ach, have no choice then
[18:53] <nxvl> sistpoty: thanx
[18:53] <sistpoty> nxvl: at least from my guess that it's in /usr/share/vim/vim71/syntax/debchangelog.vim
[18:53] <sebner> norsetto: ^^
[18:54]  * nxvl HUGS norsetto without a reason
[18:55] <nxvl> :D
[18:55] <norsetto> nxvl: must be all the hair, but people usually finds me huggable :-)
[18:55] <geser> nxvl: and check if you have vim or vim-tiny, I'm not sure if vim-tiny has syntax highlighting
[18:56] <nxvl> geser: the file sistpoty send me is what i was looking for
[18:57]  * nxvl fix bug and prepares patch
[18:57] <sebner> does anybody know when this gcc upgrade thing is compleated?
[18:57] <nxvl> norsetto: when are you arriving Prague?
[18:57] <ScottK> FYI for people looking for stuff to do: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003743.html
[18:58] <norsetto> nxvl: as planned, let me check my reservation
[19:00] <norsetto> nxvl: in principle landing 18 May 13:40
[19:03] <nxvl> norsetto: so you are not going to make it fro FOSS Camp
[19:04] <nxvl> norsetto: btw
[19:05] <nxvl> norsetto: RoAkSoAx (Andres Rodriguez) is a Peruvian new contributor, he's part of the Peruvian LoCo Council also, and of course a friend of mine
[19:05] <nxvl> norsetto: so please help him when you can, i will apreciate that very much
[19:12] <nxvl> ScottK: plase take a look at Bug #225834
[19:15] <jdong> nxvl: that's not properly formatted for hardy or intrepid
[19:15] <jdong> nxvl: IMO the first debdiff should be targeted against intrepid
[19:15] <jdong> then one for hardy-proposed
[19:16] <nxvl> jdong: so, you are saying: merge vim, add the highlight and then ask for a SRU?
[19:17] <jdong> nxvl: preferably, yeah
[19:17] <nxvl> jdong: ok i will do that
[19:17] <jdong> nxvl: alternatively you can attach a SRU for hardy (which has target hardy-proposed) and correct versioning scheme
[19:17] <jdong> s/has/requires/
[19:18] <jdong> nxvl: both would earn brownies points :)
[19:18] <nxvl> mm i think i'm using the correct versioning scheme
[19:18] <jdong> sorry, yes, the versioning scheme is correct
[19:18] <jdong> just s/hardy/hardy-proposed/
[19:18] <ScottK> Actually I think it should be intrepid then hardy-backports.
[19:19] <ScottK> I don't think it qualifies for SRU.
[19:19] <jdong> I think a backport would be decent too
[19:19] <ScottK> If people are wanting to use tools updated to know about Intrepid on Hardy, they shoud look in backports.  I think that's reasonable.
[19:20] <ScottK> devscripts is already updated and I've asked for debchroot.
[19:20] <nxvl> well
[19:20] <ScottK> err
[19:20] <ScottK> debootstrap
[19:20] <nxvl> keep in mind this is my first post release time
[19:20] <ScottK> nxvl: No problem.  Not being critical.  Educating you.
[19:20] <nxvl> so i don't know how this -proposed or -backpored things goes on
[19:21] <jdong> nxvl: backports directly pulls from Hardy; -proposed works as per !sru
[19:21] <nxvl> ScottK: i don't feel i'm being critical, i'm just remaining you so you can gave me a little more information
[19:21] <nxvl> :D
[19:21]  * nxvl HUGS jdong and ScottK 
[19:21] <ScottK> nxvl: OK.  I thought you were worried I was being critical of you.
[19:21] <ScottK> https://wiki.ubuntu.com/StableReleaseUpdates?action=show#head-9bac29d96da353649a97b4b1918c0b382b79a000
[19:22] <jdong> https://help.ubuntu.com/community/UbuntuBackports
[19:22] <jdong> and that's backports.
[19:23] <nxvl> so, what you area saying is that my distribution should be hardy, but hardy-proposed
[19:23] <nxvl> or as ScottK says hardy-backports
[19:23] <nxvl> am i right?
[19:23] <jdong> nxvl: well what scott is saying is that hardy-proposed's policy (SRU) will likely not allow for this low-impact feature addition
[19:23] <ScottK> nxvl: Distribution should be intrepid.
[19:23] <jdong> nxvl: i.e. it's not a critical bug in Hardy
[19:23] <ScottK> Right.
[19:24] <slytherin> Do we have any tag like proposed-sru for bugs so that one can decide which bugs to work on?
[19:24] <jdong> nxvl: but Hardy Backports does allow such updates liberally
[19:24] <ScottK> So get it in intrepid and then ask for a backport
[19:24] <jdong> nxvl: hardy backports prefers to use things directly from intrepid
[19:24] <jdong> nxvl: so the best action is to fix it in Intrepid first, then req a backport
[19:24] <ScottK> slytherin: I'd look at the motu-sru bug list.
[19:24] <nxvl> ScottK: yes, i mean after the intrepid inclusion
[19:25] <ScottK> nxvl: From there the archive admins will do it automagically straight from intrepid.  No debdiff needed.  They have a tool for that.
[19:25] <jdong> nxvl: requesting a backport from intrepid involves simply opening up a bug report in the hardy-backports product on Launchpad
[19:26] <nxvl> ScottK: but for the diff or for the whole package?
[19:26] <ScottK> nxvl: For the whole package.  We only need to mess with source if the package needs changes to specifically to be backported.  We try and avoid that.
[19:27] <slytherin> ScottK: I am looking for bugs that need debdiffs and ﻿may qualify for sru.
[19:27] <ScottK> Then no.  I don't think we have such a tag.
[19:27] <nxvl> ScottK: ok, thanks!
[19:29] <nxvl> i will perform the marge later today
[19:29] <nxvl> :D
[19:30] <nxvl> i'm going for now
[19:30] <nxvl> thanks!
[19:43]  * sistpoty is off again... cya
[19:52] <sebner> heya jono :D
[19:52] <jono> hi sebner
[19:56] <pochu> sebner: it's a sync, our change is included in Debian here:
[19:56] <pochu>    * debian/python-beagle.install:
[19:56] <pochu>      + Make the python module path python version independent to make it
[19:56] <pochu>        possible to change the default python version with a rebuild only.
[19:57] <persia> ScottK: Yes, current Dapper <-> Hardy is compatible for sync.  Upgrades should work, but break compatibility.  I'm not sure of the right solution for -updates, but having it in -backports should help come to a conclusion.
[19:57] <sebner> pochu: Yeah, I checked ^^
[19:57] <pochu> ok, thank you
[19:57] <sebner> pochu: the problem is that I can't test build it because of this uncompleted gcc upgrade thing
[19:57] <ScottK> persia: I'm guessing the ideal solution would be to put the current Unison in dapper-backports.
[19:59] <persia> ScottK: That might make sense.  To push the backport all the way back, and then look at pushing the new one to hardy -updates so that Hardy <-> Intrepid, etc. is working.  From what I understand, unison is planning to avoid this sort of thing in the future, where possible (which ought be easy for a project now in "maintenance mode").
[20:00] <ScottK> persia: Yes, although Unison was in maintenance mode in 2005 when I last used it, so no guarantees.
[20:00] <persia> ScottK: Really depends on whether some graduate student decides it's a good topic for another thesis :)
[20:00] <ScottK> Exactly.
[20:01] <ScottK> I've still got Dapper here, so I'll look into it.
[20:01] <ScottK> After all, it was developed at the University I attended ...
[20:02] <ScottK> pochu: Thanks for forwarding.
[20:03] <norsetto> any kind soul willing to test bug 221399?
[20:04] <james_w> Is there a standard DEB_BUILD_OPTIONS for compiling in debugging information?
[20:04] <james_w> should I use nostrip for that? Or use "debug" or similar?
[20:04] <james_w> This is extra stuff, over and above the symbol information that is covered by "nostrip"
[20:06] <sebner> pochu: should I file the bug nevertheless?
[20:07] <pochu> sebner: let's wait until we can ensure it still builds
[20:08] <geser> james_w: why not use the existing dbg-sym packages?
[20:08] <sebner> pochu: great. thanks
[20:09] <sebner> geser: you merges suck. My wiki page says that I want to merge hot new stuff. you only have ~5-6 new upstream versions :P
[20:09] <james_w> geser: this is more than the symbol table that is provided there. The program has an --enable-developer ./configure argument that adds more stuff to the code that is useful when debugging.
[20:09] <geser> ah
[20:13] <geser> sebner: then edit your wiki page :)
[20:14] <sebner> geser: hrhr
[20:14] <ScottK> sebner: Merge courier if you want an challenge.  I'm sure mok0 wouldn't mind.
[20:14] <sebner> ScottK: WOOOW! O_o
[20:15] <sebner> God bless DaD ^^
[20:15] <ScottK> sebner: I'll warn you that the guy before mok0 that I suggested it to gave up on being a MOTU after he tried.
[20:15] <sebner> geser: may you also want to add a comment on my application?
[20:16] <sebner> ScottK: well if I'm not able to merge it I will be sad and ashamed but I won't quit ;)
[20:16] <sebner> ScottK: or do you plan to get rid of me?
[20:16] <ScottK> No.  Just warning you.
[20:16] <ScottK> Also no need to be ashamed if it doesn't work out.  It's an advanced merge.
[20:17] <sebner> ScottK: well I'm here since 4 months ;)
[20:17] <norsetto> an eternity ...
[20:17] <sebner> norsetto: ^^
[20:18] <persia> I think it's more about having done > 100 merges than about the 4 months, really.
[20:20] <sebner> persia: well. the final statistic said I did 134 uploads for hardy
[20:23] <ScottK> sebner: Did you see my clamav mail?
[20:24] <sebner> ScottK: yes, don't worry you'll make it ^^. I have enough todo with courier now :)
[20:34] <LaserJock> hmm
[20:34] <LaserJock> what do we think about pushing changes to Debian rather than merging?
[20:34] <sebner> geser: ah I just realised that you also commented on my application. thanks :)
[20:35] <geser> sebner: are you happy now? :)
[20:35] <sebner> LaserJock: we think reducing the delta is great
[20:35] <sebner> geser: yes. makes me smile :)
[20:35] <LaserJock> it seems to me that we are  pretty early into Intrepid so we have plenty of time to sync
[20:35] <LaserJock> sebner: I was just looking at one of your merge bugs
[20:35] <sebner> But it seems that norsetto failed :P
[20:35] <LaserJock> * Merge from debian unstable, remaining changes: - debian/control: Fix a typo in the package description.
[20:36] <norsetto> sebner: I'm simply moderated
[20:36] <sebner> LaserJock: yep that was a stupid one
[20:36] <sebner> norsetto: np ^^
[20:36] <LaserJock> surely that is a diff we can send upstream
[20:36] <sebner> LaserJock: see my comment ^^
[20:36] <LaserJock> sebner: yes, but maybe we should do it *this* time :_0
[20:36] <LaserJock> :-) rather
[20:37] <sebner> LaserJock: ask the previous uploader for *not* doing it ;)
[20:38] <LaserJock> gmsh is probably the same way
[20:38] <x1250> Where is wxpython on hardy? people say python-wxgtk2.8 is on universe in gutsy, but on hardy universe there is no such package. Searching for wx results in no python related package on hardy universe.
[20:38] <LaserJock> in fact, maybe we should spend a week or so trying to get rid of diffs?
[20:38] <sebner> LaserJock: yeah my goal was to wait until they got accepted and uploaded and then report all back
[20:38] <ScottK> x1250: It's there.
[20:39] <LaserJock> sebner: but why not do it before and turn a merge into a sync?
[20:39] <sebner> LaserJock: because merging is a lot more fun than syncing!
[20:39] <LaserJock> lol
[20:39] <LaserJock> that's not a terribly convincing argument ;-)
[20:39] <sebner> LaserJock: for me it is ^^
[20:40] <ScottK> sebner: We need to actively keep the diff with Debian to a minimum or eventually we'll be a fork from Debian, not a downstream
[20:40] <ScottK> sebner: Pushing stuff upstream to Debian is less fun, but IMO more important.
[20:40] <sebner> LaserJock: Nevertheless. Stop complaining and start uploading and I'll take care that all important changes will make there way to ubuntu
[20:40] <sebner> ScottK: yeah I know. I'm just joking. :)
[20:40] <ScottK> OK.
[20:41] <sebner> ScottK: Reducing the delta is also one of my goals ;)
[20:41] <LaserJock> sebner: I know you're being light-hearted, but please don't tell me what to do :-)
[20:41] <ScottK> x1250: https://launchpad.net/ubuntu/+source/wxwidgets2.8/2.8.7.1-0ubuntu3/+build/542753
[20:41] <sebner> LaserJock: it was more a good meaned advice ^^
[20:42] <pwnguin> i hate autotools this much: [[20:42] <LaserJock> I would rather we *not* upload any more than we need to
[20:42] <pwnguin> #
[20:42] <pwnguin> #
[20:42] <pwnguin> configure.ac:190: required file `${PO_MAKEFILE}.in' not found
[20:42] <pwnguin> ack, sorry =/
[20:43] <sebner> LaserJock: though we are still at the very start? Ok I can live with it if you reject all of them
[20:44] <x1250> Uhm ScottK, strange thing, I aptitude updated and now I see a lot more wx related packages. And there it is: python-wxgtk2.8
[20:44] <LaserJock> that we are at the start is all the more reason to turn a merge into a sync
[20:44] <LaserJock> we have time for Debian to take changes
[20:44] <ScottK> x1250: Dunno what to tell you.  It's been there all along.
[20:44] <LaserJock> later on we won't have time and we'll just have to download
[20:44]  * ScottK agrees with LaserJock.
[20:44] <norsetto> x1250: thats scottk magic for you
[20:44] <LaserJock> s/download/upload/
[20:45] <LaserJock> sebner: I'm not going to reject your merges, I just may not upload them
[20:45] <sebner> LaserJock: that means you won't do anything?
[20:45] <LaserJock> which, considering how much I upload these days, is not really any lose ;-)
[20:45] <LaserJock> I might leave a comment on the bug, but that'd be it
[20:46] <LaserJock> if another MOTU feels differently they can sponsor the upload :-)
[20:46] <sebner> LaserJock: k, you'll decide and I'll do what you want
[20:46] <ScottK> sebner: I think he already suggested focus on getting stuff fixed in Debian.
[20:46] <pochu> sebner: see it this way: as we are at the beginning of the cycle, there is no harm in waiting a bit to see if Debian incorporates our changes, and if they do, sync the package. If they don't, we have some months to merge the package, but we should aim to sync it.
[20:46] <LaserJock> well, we need a good way to say "hang on I'm waiting for Debian"
[20:47] <ScottK> LaserJock: That's one reason Dad has a spot for comments.
[20:47] <LaserJock> sebner: what I would suggest would be for bugs that Debian might easily take (and feel free to ask if you don't know), would be to open the merge bug, assign yoruself, and forward your diff to Debain
[20:48] <LaserJock> if Debian takes it you just convert the merge bug into a sync bug
[20:48] <LaserJock> if not then we'll upload the merge
[20:48] <LaserJock> in any case, the only way we're gonna get stuff upstream is to force it
[20:49] <sebner> LaserJock: thanks for the advice :) I'll keep it in mind for my future work
[20:49] <LaserJock> sebner: it's just my opinion, but in my experience people often do a "upload now and talk to debian later" and they never end up doing it
[20:50] <sebner> LaserJock: you know what my passion is ;) no to be serious, you are totally right
[20:50] <LaserJock> well, I know merging is fun
[20:50] <norsetto> is it!?
[20:51] <ScottK> The unitary diffs from Ubuntu that appear on packages.qa.debian.org are really hard to digest (sometimes they confuse me even when I did the Ubuntu upload).
[20:51] <LaserJock> but actually, sending stuff upstream is pretty much the same
[20:51] <LaserJock> norsetto: ohhh yeah!
[20:51] <LaserJock> merging is MOTU Hopeful crack!
[20:51] <ScottK> Breaking stuff down into a sensible bug report with a good patch makes getting stuff into Debian much easier.
[20:51]  * norsetto definition of fun seems to be not in line with common knowledge
[20:51] <ScottK> sebner: I've also seen people get MOTU before on the basis of lots of merging and little bug/new package work and then not do so well after.
[20:52] <LaserJock> norsetto: what's your idea of fun?
[20:52] <sebner> ScottK: that's also why I want to wait still some time before even thinking of applying
[20:52] <norsetto> LaserJock: packaging wise, is bug hunting actually
[20:55] <LaserJock> I agree
[20:55] <LaserJock> but bug hunting often is not so fast-paced gratification
[20:55] <LaserJock> blasting through 10+ merges a day gets your blood pumping
[20:56] <LaserJock> or maybe I'm a nerd/freak
[20:56] <sebner> LaserJock: I feel the same. I files >20 bug reports as you may can see
[20:56] <sebner> *filed
[20:58] <LaserJock> after a while though you start to realize crack isn't all that great for you
[20:58] <LaserJock> :-)
[21:10] <Son26> hi
[21:12] <LaserJock> sebner: that edenmath.app diff (simply s/calcualtor/calculator/) has been with us since Edgy!
[21:13] <sebner> LaserJock: Yes and I will be the one who is killing it
[21:13] <LaserJock> ScottK: do you have any feeling on how we can deal with unresponsive Debain maintainers?
[21:13] <sebner> LaserJock: just wondering why nobody before me did ;)
[21:13] <LaserJock> my guess (since the last upload was by Debian QA) is that the Debian maintainer is pretty inactive
[21:14] <ScottK> Package is probably orphaned or nearly so then.
[21:14] <LaserJock> so how do we go about getting things fixed upstream in these situations
[21:14] <ScottK> If it's a true upstream bug, bypass Debian and report it to the upstream.
[21:14] <LaserJock> are these cases where we just have to bite the bullet and keep the diff?
[21:14] <LaserJock> not true upstream
[21:14] <LaserJock> in the short description the Debian maintainer just has a typo
[21:14] <ScottK> If it's a packaging bug keep the diff or someone care enough to hijack the package in Debian.
[21:15] <LaserJock> it's too bad Debian QA can't step in on things like that
[21:15] <ScottK> Is there some team that the package would be good in?
[21:15] <LaserJock> well, s/can't/doesn't/
[21:15] <ScottK> Someone might hijack the package in some team's name.
[21:15] <LaserJock> it's a Gnustep
[21:15]  * ScottK has no idea.
[21:15] <LaserJock> I don't know if Gnustep packages are team maintained
[21:16] <LaserJock> I'm not sure who even uses them anymore
[21:16] <ScottK> When I started with MOTU, I'd have uploaded that fix.  Now I think I'd just send it to Debian and not worry.  It's not worth maintaining a diff for.
[21:16] <LaserJock> exactly
[21:17] <LaserJock> ah, the package is oraphaned in Debian but has somebody interested in adoption
[21:17] <LaserJock> and this particular bug was already filed by Kmos :-)
[21:17] <norsetto> scottk, LaserJock: what would you do for a debian maintainer that answers "I couldn't care less, its your problem" ?
[21:17] <Son26> ?
[21:18] <ScottK> Ah.  So I'd contact that person and encourage them.  Offer some assistance in getting it fixed up.
[21:18] <LaserJock> Son26: what's up?
[21:18] <ScottK> norsetto: Either maintain the diff or if it qualifies as a serious bug in Debian NMU the package.
[21:18] <norsetto> scottk: its a bug upstream, but doesn't show in debian
[21:19] <ScottK> Ah.  Then get upstream to fix it.
[21:19] <ScottK> In those cases I don't normally even report them to Debian.
[21:19] <norsetto> scottk: upstream doesn't even have a bug tracker :-)
[21:19] <norsetto> scottk: yes, sensible approach
[21:19] <LaserJock> do they have a mailing list or email address?
[21:19] <ScottK> Email the author.  Hope for the best.  Maintain the diff in the meantime.
[21:20] <norsetto> LaserJock: not that I could find
[21:20] <LaserJock> sounds like we're fairly stuck with it :-)
[21:20] <LaserJock> I certainly don't mind maintaining diff that we need to
[21:20] <norsetto> LaserJock: yes, thats the conclusion I came too :-(
[21:20] <LaserJock> I'm just finding quite a bit of diff that is uneccesary to keep in Ubuntu
[21:21] <LaserJock> it also makes it look like we don't give back
[21:21] <LaserJock> or communicate with upstreams
[21:22] <LaserJock> sebner: did you see that the bug has already been filed in Debian?
[21:22] <LaserJock> 178 days ago
[21:22] <sebner> LaserJock: sry, which one?
[21:22] <LaserJock> edenmath.app
[21:22] <LaserJock> the "calculator" typo
[21:23] <sebner> LaserJock: yes, so what can we do?
[21:23] <LaserJock> well, we can do one of two things
[21:24] <LaserJock> we can just ask for a sync and leave the typo there until Debian fixes it
[21:24] <LaserJock> or we can upload your merge and keep the diff
[21:24] <LaserJock> oh
[21:25] <LaserJock> actually it's been adopted by a team
[21:25] <sebner> LaserJock: we should send them a remindert
[21:25] <LaserJock> perhaps if you bug them they'll upload a fix
[21:25] <sebner> -t
[21:25] <sebner> LaserJock: As I said ^^
[21:26] <sebner> LaserJock: I'll do that tomorrow. thanks. I'm afk
[21:26] <LaserJock> so you want to email Debian GNUstep maintainers
[21:29] <norsetto> albert23: bedankt for bug 221399
[21:32] <albert23> norsetto: nessun problema
[22:57] <sebner> gn8 folks
[23:00] <norsetto> g'night all
[23:45] <Syntux> night
[23:48] <LaserJock> Syntux: btw, I thought your country was named after *me* ;-)
[23:48] <LaserJock> but a Jordanian in my lab told me this was not the case :-)
[23:51] <ScottK> My younger brother was born on December 7.  When he was little I showed him Franklin Roosevelt's speech about December 7, 1941 being a day of infamy.  I glossed over the 1941 part and told him the President was talking about him.
[23:51] <ScottK> I was a great older brother, wasn't I.
[23:52] <LaserJock> hahaha
[23:52] <ScottK> persia: Current unison doesn't build on dapper.  It'd need someone who cares to look into what needs to be done to make it build/run.
[23:52] <ScottK> LaserJock: I'm not kidding.
[23:53] <crimsun> where does it fail?
[23:53] <Syntux> LaserJock, HAHA you got a Jordanian in your lab?
[23:53] <persia> ScottK: Can you paste a buildlog?
[23:53] <ScottK> crimsun: debian/rules:22: /usr/share/cdbs/1/class/ocaml.mk: No such file or directory
[23:53] <Syntux> LaserJock, what do you do for livin ?
[23:53] <ScottK> I can't even build the source package.
[23:54] <LaserJock> ScottK: were we wanting to do a new upstream release for Hardy?
[23:54] <persia> heh.  That's going to be fun.
[23:54] <ScottK> And yes, I did install ocaml-nox
[23:54]  * Syntux thought they do testing on mouses not Jordanians :p
[23:54] <LaserJock> Syntux: I"m a PhD Chemistry student, and yes
[23:54] <Syntux> LaserJock, his name is Iyas ?
[23:54] <ScottK> LaserJock: Yes and we didn't get it, so I'm having it shoved in hardy-backports.
[23:54] <LaserJock> Syntux: no, Ali
[23:54] <LaserJock> ScottK: why didn't you get it?
[23:55] <Syntux> cool, anyway Good night
[23:55] <ScottK> I'm not sure.  I will plead -ENOTIME to look into it before release.
[23:55] <ScottK> I seem to find out the "And if you don't upgrade you will be incompatible with the whole fricking world" stuff after we release.
[23:55] <LaserJock> ScottK: what I mean is, are you trying to do an SRU?
[23:55] <mkrufky> slangasek: ping
[23:56] <slangasek> mkrufky: hi
[23:56] <mkrufky> you just marked bug 99107 as invalid
[23:56] <mkrufky> the firmware shipping with ubuntu is not compatable with the drivers in the ubuntu kernel
[23:57] <slangasek> mkrufky: I marked it as invalid /for intrepid/...
[23:57] <slangasek> there is no linux-ubuntu-modules-2.6.22 package in intrepid
[23:57] <persia> LaserJock: Ne unison isn't compatible with old unison for syncs.  Everyone else has new unison.  We're looking first at a full suite of backports, and if that is clean, maybe doing an SRU for hardy at some point.  The trick is balancing it so that people upgrading to hardy don't have it break while people using hardy as LTS can still use it.
[23:57] <slangasek> mkrufky: if this still affects Ubuntu 8.04 and intrepid, then we need to open separate tasks in launchpad pointing to the correct packages
[23:58] <mkrufky> ah, ok
[23:58] <mkrufky> ubuntu 8.04 is OK
[23:58] <slangasek> ok, great :)
[23:58] <LaserJock> persia: wouldn't getting it into -updates ASAP help rather than hinder the situation?
[23:58] <mkrufky> 8.04 has the correct firmware -- size 376836
[23:58] <mkrufky> gutsy was never fixed
[23:58]  * slangasek nods
[23:59] <LaserJock> persia: we are breaking compatibility with Dapper if we upgrade Hardy?
[23:59] <mkrufky> a simple firmware replacement ... who do i have to {ping} to get that fixed?
[23:59] <LaserJock> persia: and what if we upgrade Dapper as well?
[23:59] <mkrufky> slangasek: the firmware shipping in 8.04 needs to also ship in gutsy
[23:59] <persia> LaserJock: Well, that's one option.