[00:00] <crimsun> nxvl: I'm around if you need assistance.
[00:07] <bmk789> im doubting theres any kind of video tutorial on packaging is there?
[00:07] <nixternal> yes there is
[00:07] <nixternal> code.google.com
[00:08] <bmk789> on ubuntu packaging?
[00:10] <nxvl> crimsun: nice, i quite lost
[00:10] <nxvl> crimsun: i have generated the debian.debdiff and ubuntu.debdiff
[00:10] <nxvl> crimsun: i see a lot of changes
[00:10] <giovani> wikipedia fundraised
[00:10] <giovani> fundraiser
[00:10] <giovani> just started
[00:11] <nxvl> crimsun: in debian.debdiff there MUST be changes since it's a new version so i didn't need to see they, didn't i?
[00:11] <nxvl> crimsun: in the debian.debdiff what i need to do is to check is the changes in ubuntu.diff are in there, didn't i?
[00:12] <nxvl> well, time to go home, back in some minutes
[00:13] <crimsun> nxvl: I lack backscroll, can you tell me which merge you're doing?
[00:22] <LeRoutier> good night ppl
[00:24] <tonyyarusso> aww man, did Thunderbird support in tracker just miss the deadline by like two weeks for Gutsy?
[00:28] <RAOF> It's still experimental, isn't it?
[00:28] <RAOF> As in: you can turn it on in the config file, but there's deliberatly no UI for it yet?
[00:29] <tonyyarusso> RAOF: I think there's actually a checkbox in the UI, but it's greyed out for now.
[00:29] <tonyyarusso> You might be right though.
[01:02] <zul> imbrandon: ping
[02:15] <tonyyarusso> Can someone tell me how to use reportbug to submit to the Debian BTS?  Even with the --bts option it's going to Ubuntu still for me.
[02:18] <tonyyarusso> oh, nvm.  Different syntax.
[02:31] <superm1> jdong, you here?
[02:31] <jdong> superm1: yes sir
[02:31] <superm1> jdong, okay so were we going to push forward with that SRU?
[02:32] <jdong> superm1: have not received a response from pitti yet
[02:32] <superm1> jdong, ah i see
[02:32] <superm1> mail or ping?
[02:32] <jdong> superm1: mail
[02:32] <superm1> jdong, mkay.  slangasek might also be good to talk to instead if you don't hear from pitti soo
[02:33] <superm1> *soon
[02:33] <jdong> superm1: ok, I'll wait a day or two for pitti before bugging others... it's a long story :)
[02:33] <jdong> superm1: I'm currently working on two minor issues uncovered by launchpad testers
[02:33] <superm1> okay then i won't dwelve into asking too much :)
[02:34] <superm1> jdong, wonderful that's good
[02:34] <jdong> yeah, turns out we need to make sure user has either the (universe) icedtea stack or a multiverse sun-java* stack
[02:34] <superm1> jdong, just ping me when your ready to proceed then
[02:34] <jdong> the GCJ one runs like 100x slower for hash checking
[02:34] <superm1> yikes
[02:34] <jdong> which kinda sucks for torrenting to the point of unusability
[02:35] <superm1> well depend on icedtea then?
[02:35] <jdong> nobody is gonna wait an hour to hash-check a 100MB file :)
[02:35] <jdong> superm1: did exactly that, alt-dep on sun-java*
[02:35] <superm1> the problem is making sure that they are active then eh?
[02:35] <jdong> superm1: and modified the launcher to bypass alternatives and directly look in /usr/lib/jvm for a preferred runtime
[02:35] <superm1> set to the default one
[02:35] <superm1> ah good
[02:35] <jdong> :)
[02:35] <superm1> two steps ahead of my thought process.  i like it.
[02:35] <jdong> superm1: now working on a 3-liner to suppress an annoying error box that Azureus pops up about its updater not being able to write to /usr/lib :)
[02:37] <StevenK> jdong: You can't disable the updater?
[02:38] <StevenK> Oh look, we start talking about Azureus, and RAOF turns up...
[02:38] <jdong> StevenK: well, I don't want to totally disable the updater... Azureus uses it to update plugins users can put in ~/.azureus
[02:39] <jdong> StevenK: I only need to suppress the SWT update check -- the only update checked that's in a system location
[02:39] <StevenK> jdong: Ah, so you'd prefer to castrate it.
[02:39] <RAOF> StevenK: Drawn by dark callings, yes
[02:39] <StevenK> RAOF: :-)
[02:39] <jdong> :)
[02:45] <jdong> ok, verified to solve SWT update nag..... Wow I love it when a 3-liner patch is functional and not hackish :)
[02:48] <pwnguin> it still infuriates me that the eclipse package uses JAVA_HOME
[02:52] <jdong> pwnguin: my ability to package azureus 3.0.3.4 (a 3-month-old update to Azureus) is being hampered by that big elephant.
[02:52] <jdong> don't get me started.
[02:52]  * ajmitch hugs java
[02:52] <ajmitch> so much fun
[02:53] <jdong> lol
[02:53] <jdong> ajmitch: why does it seem like most of the time it's our packaging that's the curse?
[02:53] <jdong> ajmitch: for some reason fedora/mandriva java packaging looks so crisp and clean....
[02:53] <jdong> one build script, 2 or 3 minor patches....
[02:53] <jdong> instead of our huge debian/ jungle with dh_eclipse_magical_ecj_thingie
[02:54] <jdong> and like a bazillion patches
[02:54] <pwnguin> last time i looked at azureus (some time ago, mind you) there seemed to be an attempt to get azurues to build to a native app
[02:54] <ajmitch> jdong: I can't say, I won't touch any of it
[02:54] <jdong> pwnguin: there was with the 2.5.0.0-repack packaging too
[02:54] <pwnguin> fedora's committed to ecj, no?
[02:54] <jdong> pwnguin: they're not committed to anything
[02:54] <jdong> pwnguin: F7 included icedtea beta, I'm not sure what they're doiung with F8
[02:55] <pwnguin> what i mean is, they heavily support the use of free software and if non-free is broke, shurgs abound
[02:55] <jdong> pwnguin: that is correct
[02:55] <jdong> pwnguin: they used to heavily use GCJ
[02:55] <pwnguin> i imagine they're all up in icedtea
[02:55] <pwnguin> which is great
[02:55] <jdong> pwnguin: and that's where we got our initial Azureuses, with like 50 patches to get it to half-compile
[02:56] <pwnguin> when you say "we"
[02:56] <pwnguin> universe, or debian?
[02:56] <jdong> universe
[02:56] <jdong> pwnguin: and the part that converts it to "native" produces like a 10MB thing for a 1MB Jar
[02:56] <jdong> using 1+GB RAM in the process
[02:56] <pwnguin> heh
[02:56] <pwnguin> sweet
[02:56] <jdong> and I honestly CANT see the final thing any faster than the interpreted thing
[02:56] <jdong> maybe 1.5x faster
[02:56] <pwnguin> i doubt that
[02:56] <jdong> but considering it was 100x slower than Sun to begin with?
[02:56] <jdong> not a ground-breaking improvement
[02:57] <pwnguin> so only 50x slower ;)
[02:57] <jdong> and for the case of Azureus, unacceptable
[02:57] <jdong> the hash checking process off a laptop hard drive should NEVER be CPU bound -- always IO bound
[02:57] <pwnguin> heh
[02:58] <pwnguin> i guess the set of java developers unioned with developers committed to free software was exclusive with those who actually know how to write code
[03:00] <jdong> could be
[03:00] <jdong> pwnguin: but Fedora also heavily customizes their GCJ chain
[03:00] <jdong> pwnguin: I don't doubt that when Fedora compiled Auzreus with GCJ, it actually worked acceptably well
[03:01] <jdong> pwnguin: I don't think we have the same manpower going into the Ubuntu GCJ stack -- that's all
[03:02] <pwnguin> is there a smart way to go about finding patches in fedora?
[03:02] <pwnguin> theres some host called koji that seems to host things, but its a bit unwiedly
[03:04] <jdong> pwnguin: hmm I'm just unpacking srpm's
[03:04] <jdong> they have patches well laid out similar to a debian/patches thing
[03:05] <pwnguin> finding srpms alone is a challenge ;)
[03:26] <jdong> pwnguin: look on a fedora mirror.
[03:27] <jdong> I was just thinking, and everyone bear witness:
[03:27] <jdong> If Azureus upstream ever becomes evil with the Vuze crap and Debian has to fork it, I want credit for naming it DartFrog
[03:27] <jdong> :)
[03:27] <jdong> that is all.
[03:29] <ScottK> jdong: Are you going to send you updater patch to Debian in a bug?
[03:29] <joeamined> hi
[03:29] <jdong> ScottK: yeah, good idea. I'll have to *grumble* navigate their BTS
[03:29] <joeamined> i'm a student in computer engineering and i'd like to contribute to ubuntu
[03:30] <StevenK> Cheques can made payable to ....
[03:30]  * StevenK hides
[03:37] <ScottK> joeamined: Dive in and get to work.
[03:37] <jdong> ScottK: okie dokie, submitted to Debian BTS
[03:37] <ScottK> jdong: That's a good downstream.
[03:37] <ScottK> pat, pat, pat.
[03:38] <jdong> ScottK: lol :) if only their bug tracker was more friendly :)
[03:38] <StevenK> Meh, debbugs isn't that bad.
[03:38]  * ScottK likes it better than Launchpad.
[03:38] <StevenK> It's better than Bugzilla
[03:38] <ScottK> At least I don't have to wait an eternity everytime I click on something.
[03:38] <pwnguin> joeamined: if you've got pet bugs, you could try fixing one
[03:39] <ajmitch> bugzilla is great
[03:39] <joeamined> yep
[03:39] <jdong> StevenK: for one, I saw ZERO space shuttle graphics throughout the entire bug filing process.
[03:39]  * ScottK thinks joeamined needs to fix his IRC client.
[03:40] <ajmitch> jdong: that's unfortunate, perhaps you should sponsor a debian developer to visit the ISS
[03:41] <StevenK> Hah, Thunderbird.
[03:41] <StevenK> "Personal has 2 new messages", yet it shows four of them
[03:42] <jdong> StevenK: it's thunderbird :)
[03:42] <jdong> StevenK: more seriously it probably has the Seen flag marked by the client for some reason
[03:43] <jdong> rather than just NEW
[03:44] <StevenK> What I think happened is I didn't check the last time it appeared
[03:57] <ScottK> Good $TIMEOFDAY Hobbsee.
[03:57] <Hobbsee> hiya ScottK
[03:58] <imbrandon> man filtering join/parts really cuts down the traffic in here :)
[03:58] <imbrandon> heya Hobbsee
[03:58] <Hobbsee> hiya imbrandon
[03:58] <Hobbsee> imbrandon: indeed!
[03:59] <ajmitch> Hobbsee!
[03:59] <Hobbsee> ajmitch!
[04:14] <jdong> whoo, got another success report on LP that my azureus package worked
[04:23] <jcastro> jdong: are you coming to fosscamp/uds?
[04:23] <jdong> jcastro: I'll be at UDS
[04:23] <jcastro> cool
[04:23] <imbrandon> along with all his crack :)
[04:23]  * Hobbsee waves to jcastro
[04:23] <jcastro> hi Hobbsee
[04:23] <ajmitch> so far to swim...
[04:23] <imbrandon> jcastro, i sent that email off
[04:24] <jcastro> ajmitch: good thing there's the panama canal, otherwise you'd have to go the long way around
[04:24] <jcastro> imbrandon: \m/
[04:24] <imbrandon> lol
[04:24]  * Hobbsee starts to wonder if compiz is *not* the battery life hog.
[04:24] <ScottK> Good night all.
[04:24] <imbrandon> night
[04:24] <jdong> imbrandon: ha I've been clean for the past year or two, right? :)
[04:24] <persia> good night scottk
[04:24] <ajmitch> jcastro: yeah, I'm pretty glad about that, otherwise I'd have to leave last week :)
[04:25] <ajmitch> jdong: you want an honest answer?
[04:25] <jdong> ajmitch: uh oh :)
[04:25] <imbrandon> jdong, lol , r u serouis ? hehe
[04:25] <jdong> :) I love you guys too :P
[04:25] <ajmitch> imbrandon: harsh
[04:25] <imbrandon> :P
[04:26] <ajmitch> jdong: we wuv you too, really
[04:26]  * imbrandon watchs jdong rebuild the archive with -Os
[04:26]  * ajmitch recalls fondly funroll-loops.org
[04:26]  * imbrandon hugs jdong, but we still lub u
[04:27] <ajmitch> and I think that someone revived that page from the depths of the internet
[04:27] <imbrandon> ajmitch, hahah yea, i JUST seen that site the other day
[04:27] <jcastro> ajmitch: I have the source somewhere.
[04:27] <jdong> ajmitch: that was hilarious
[04:27] <ajmitch> blame our canonical friend ;)
[04:27] <jdong> ajmitch: and to think I used to be a gentoo user before coming to Ubuntu
[04:27] <jcastro> ajmitch: although I can neither confirm nor deny my involvement
[04:27] <ajmitch> jcastro: sure..
[04:28] <jdong> so you guys have got to give me at least the Warty cycle to cool down :D
[04:28] <jdong> and stop trying to port portage to Ubuntu
[04:28] <ajmitch> jdong: warty?
[04:28] <imbrandon> << .... >> ...... O_o
[04:28] <jdong> ajmitch: ok fine it lasted a bit thru hoary too
[04:28] <ajmitch> ah, breezy, dapper, edgy, feisty...
[04:28] <jdong> yeah
[04:28] <imbrandon> ummm i recall it all the way to edgy
[04:28] <ajmitch> !jdong
 jdong: yes, but you're FULL OF CRACK!
[04:29] <imbrandon> lol
[04:29] <imbrandon> !nixternal
[04:29] <ubotu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
[04:29] <jcastro> is that apt-build thing still around?
[04:29] <pwnguin> hahaha
[04:29] <jdong> imbrandon: well backports was not integrated into the central archives until mid-breezy....
[04:29] <imbrandon> :P
[04:29] <nixternal> glad you think that is funny!
[04:29] <nixternal> !visternal
[04:29] <nixternal> that one is better though
[04:29] <nixternal> when it works
[04:29] <pwnguin> did you really rebuild the archive with -Os imbrandon?
[04:29] <imbrandon> pwnguin, no
[04:29] <StevenK> nixternal: We'll be wanting to collect at UDS...
[04:29] <jdong> imbrandon: but I've been using same versioning, building, and QA'ing tactics since about halfway thru hoary :)
[04:29] <pwnguin> aww
[04:30] <jdong> imbrandon: and I did break a few flash plugins in edgy.... shhhhhhh :)
[04:30] <nixternal> I will be over in the corner wearing my rPath and Foresight Linux T-shirts!!!
[04:30] <nixternal> come find me :)
[04:30] <jdong> pwnguin: I'd love to try it :)
[04:30] <nixternal> if you find me, I will give you money!
[04:30] <imbrandon> hah
[04:30] <jcastro> nixternal: the glow in the dark green shirt?
[04:30] <nixternal> that is one of them :)
[04:30] <nixternal> although it doesn't glow all that well anymore
[04:30]  * imbrandon hugs his kubuntu shirts
[04:30] <imbrandon> and hat
[04:31] <nixternal> I wear shirts that I get for freeeeeeeee
[04:31] <nixternal> so far Fedora, Debian, openSUSE, and Foresight have all obliged with kindness :)
[04:31] <nixternal> my Kubuntu shirt I bought off of Cafepress now says K   n u
[04:31] <jdong> nixternal: aww I want a green suse shirt :)
[04:31]  * imbrandon hands nix a Windows Vista T
[04:31] <ajmitch> someone please buy this man a vista shirt
[04:32] <nixternal> I have a Bad Vista t-shirt, that is enough
[04:32] <nixternal> and my GPLv3 t-shirt that loves to start drama
[04:32] <elkbuntu> bad ajmitch, BAD!
[04:32] <pwnguin> jdong: i wonder how hard it would be. ive seen a few packages with a debug and relase pairing of build rules
[04:32] <ajmitch> elkbuntu: why, it's nixternal?
[04:32] <nixternal> I got a couple of Ubuntu shirts, but I gave them away
[04:32] <jdong> pwnguin: I'd just wrap gcc at the /usr/bin/gcc level and forget screwing with each package
[04:32] <nixternal> why send shirts for a boy to a grown ass man?
[04:32] <elkbuntu> ajmitch, yes, precisely. isnt he enough on his own?
[04:32] <ajmitch> elkbuntu: good to see you around as well :)
[04:32]  * elkbuntu runs from nixternal
[04:32] <jdong> pwnguin: just filter out all the other -O flags and replace with -Os
[04:32] <pwnguin> heh
[04:33] <pwnguin> sounds good
[04:33] <elkbuntu> ajmitch, well yeah, they fired me yesterday, so now i got unexpected time on my hands
[04:33] <jdong> and that's probably why I'm the resident crackpot :)
[04:33] <ajmitch> elkbuntu: *ouch*
[04:33] <StevenK> elkbuntu: :-(
[04:33] <imbrandon> :(
[04:33] <jdong> :(
[04:33] <elkbuntu> im a terrible arse kisser apparantly
[04:33] <ajmitch> I can imagine
[04:33] <jdong> elkbuntu: practice makes perfect?
[04:33] <nixternal> imbrandon: I found out today that my future in any kind of MMA is not feasible...I got cage time at the gym and went against a guy, 75 lbs. lighter, but he was a muay thai guy...lets just say, I couldn't grab him, as he was punching and kicking faster than I could blink
[04:33] <elkbuntu> i blame it all on the open source community
[04:33]  * jdong ducks
[04:33]  * imbrandon gets back to the fatx patch
[04:34]  * jdong would like to blame his C+ in differential equations on that too
[04:34] <elkbuntu> ajmitch, i made the mistake of answering a question asked by an interim trainer honestly, and she took it as a personal attack on the normal trainer, and dobbed, and the rest is history
[04:34] <ajmitch> elkbuntu: you speak your mind far too freely?
[04:34] <elkbuntu> ajmitch, basically
[04:34] <ajmitch> fun
[04:35] <jcastro> nixternal: you could always drop kick people at LoCo meetings and such.
[04:35] <imbrandon> lol
[04:35] <ajmitch> where to from here?
[04:35] <pwnguin> jdong: i was thinking it might be possible to set a default CFLAGS, but id have to reveiw a few packages to see if they add or replace CFLAGS
[04:35] <jdong> pwnguin: well packages who seriously need certain cflags tend to set it themselves
[04:35] <nixternal> jcastro: I almost had to do that yesterday at the LoCo/Release Party/Install Fest/Soon to be a cage match
[04:35] <elkbuntu> i havent told the folks yet, they were burying granddad yesterday and i didnt think it would be an appropriate time. i'm saving the 'you fail at life' lecture for this evening
[04:35] <pwnguin> jdong: right, but they can either do = or +=
[04:36] <ajmitch> ugh
[04:36] <StevenK> elkbuntu: Double :-(
[04:36] <StevenK> elkbuntu: I've been fired once, it isn't fun. :-(
[04:36] <imbrandon> pwnguin, depends on the package
[04:36]  * persia notes that nearly every package using automake sets cflags, and that *lots* of the C programs in Ubuntu use automake
[04:36] <jcastro> elkbuntu: condolences
[04:36] <elkbuntu> StevenK, well, all i could say was 'if you had have told me this an hour earlier, i could have made it to my grandfather's funeral'... the expression on their faces was priceless
[04:36] <pwnguin> in that case, replacing gcc would probably be the way to go ;)
[04:37] <lifeless> elkbuntu: :(
[04:37] <elkbuntu> jcastro, thanks :) good to see you back with us again :)
[04:37] <imbrandon> tis whats done when you use distcc in a pbuilder
[04:37] <StevenK> elkbuntu: I'll bet.
[04:38] <jcastro> elkbuntu: :D
[04:38] <imbrandon> autoreconf -i
[04:39] <imbrandon> err
[04:39] <ajmitch> jcastro: and now you're stuck with us
[04:39] <elkbuntu> so i now have like 3 or so weeks to find a new job before i run out of monies
[04:39] <jcastro> ajmitch: heh, the joke's on you!
[04:40] <ajmitch> jcastro: "oh god, make the pain stop!" sort of joke?
[04:40] <jcastro> heh
[04:40] <ajmitch> elkbuntu: I hope you manage to get something sorted out asap, I know it's not easy there
[04:41] <RAOF> Hobbsee: Surveys say that compiz has approximately no impact on power usage.  Look elsewhere for your poor battery life :P
[04:41] <elkbuntu> ajmitch, heh, i spent yesterday pounding pavement, and ended up mildly dehydrated... i should probably head off and compound it now eh :P. cyas
[04:42] <lifeless> elkbuntu: good luck.
[04:42] <lifeless> elkbuntu: and don't think of indian takeaway
[04:43] <ajmitch> elkbuntu: bye, and good luck
[04:43] <Hobbsee> RAOF: which means somewhere in gnome.  any pointers on where to look?
[04:44] <pwnguin> powertop?
[04:44] <Hobbsee> pwnguin: looked there.  nothing overly out of the ordinary.
[04:45] <pwnguin> depends on your definition of ordinary
[04:45] <Hobbsee> like, nothing that wasnt there under kubuntu too
[04:45] <pwnguin> well
[04:45] <pwnguin> for simple diagnostics
[04:46] <pwnguin> i have a gnome panel applet
[04:46] <pwnguin> that monitors CPU and network load
[04:46] <Hobbsee> the load's not that high.  it's just my battery live getting nuked.
[04:46] <Hobbsee> and i'm unsure as to why
[04:46] <pwnguin> as reported by what?
[04:47] <Hobbsee> htop and the like
[04:47] <Hobbsee> (comparing this to kubuntu, so the kernel and all that should be the same)
[04:47] <pwnguin> im sorry, i meant, battery life as reported by what?
[04:47] <Hobbsee> erm.  gnome power manager, i think it is
[04:47] <Hobbsee> acpi -V
[04:48] <Hobbsee> (as well)
[04:48] <jcastro> Hobbsee: tracker or beagle indexing away perhaps?
[04:48] <pwnguin> if they were, they'd show up
[04:48] <Hobbsee> jcastro: purged tracker.
[04:48] <Hobbsee> no beagle installed either
[04:49] <pwnguin> the problem is, and i should really file a bug on this, iowait on multiload applet is indistinguishable from black (it's slightly blue)
[04:49] <pwnguin> i usually turn it to yellow
[04:49] <pwnguin> as iowait basically means disk access not cpu hunger
[04:50] <lifeless> OTOH disk == power
[04:50] <pwnguin> sure
[04:50] <pwnguin> but when you want to know what the problem is
[04:50] <jdong> Hobbsee: gnome-power-manager does that weird logarithmic-profiling estimation thing
[04:50] <jdong> Hobbsee: it doesn't listen to ACPI estimates
[04:50] <pwnguin> iowait gives you a hint
[04:51] <jdong> and tacker should not index on battery either
[04:51] <jdong> Hobbsee: oh silly me, I should've read your scrollback
[04:51] <jdong> hit me.
[04:51]  * StevenK deals jdong a card
[04:51] <jdong> :)
[04:51] <pwnguin> its possible the battery is simply aging
[04:52] <jdong> pwnguin: I think it's a feature that iowait blends in
[04:52] <pwnguin> jdong: a stupid feature
[04:52] <jdong> pwnguin: otherwise people would look at it and say ZOMG MY CPU IS LOADED!!!11111
[04:52] <pwnguin> which is why i make it yellow
[04:52] <Hobbsee> pwnguin: sure, but in that case, why did it drop around 40 mins in a week?
[04:52] <jdong> pwnguin: I oddly make it yellow too
[04:52] <Hobbsee> when switching DE's?
[04:52] <pwnguin> heh
[04:52] <jdong> Hobbsee: ok, can you install acpitool?
[04:53] <jdong> Hobbsee: then under KDE, run acpitool -B a few times, do the same under GNOME, and look at the discharge rate being reported
[04:53] <jdong> determine if they are actuallly different between GNOME and KDE
[04:53] <jdong> if so, then we've got an actual problem at our hands
[04:53] <Hobbsee>     Remaining capacity : 1694 mAh, 52.24%, 01:13:01
[04:53] <Hobbsee>     Design capacity    : 4800 mAh
[04:53] <Hobbsee>     Last full capacity : 3243 mAh, 67.56% of design capacity
[04:53] <Hobbsee>     Capacity loss      : 32.44%
[04:53] <Hobbsee> sheesh!
[04:53] <jdong> 23:53 < Hobbsee>     Last full capacity : 3243 mAh, 67.56% of design capacity
[04:53] <jdong> EEW
[04:53] <Hobbsee> yeah...
[04:53] <pwnguin> hmm
[04:54] <pwnguin> if thats accuate
[04:54] <pwnguin> we have an answer
[04:54] <Hobbsee> jdong: that'll require booting to kde.
[04:54]  * jdong does a calculation
[04:54] <imbrandon> time for a new battery
[04:54] <Hobbsee> imbrandon: seems so.
[04:54] <pwnguin> battery life falls off steeply
[04:54] <Hobbsee> pwnguin: yeah, but not by a *week*
[04:54] <pwnguin> sure by a week in the last stages
[04:54] <jdong> 1694*(1+13/60)
[04:54] <jdong> 2061.03333333333333332204
[04:54] <Hobbsee> and not when the recent preceeding weeks ahd no visible drop off.
[04:55] <jdong> 2061mA drain if ACPI time accurate is correct
[04:55] <jdong> Hobbsee: what kind of CPU and video card, what level of display brightness?
[04:55] <pwnguin> acpi time isnt accurate at the start
[04:55] <pwnguin> give it a few minutes of running on battery
[04:55] <jdong> pwnguin: it represents correct for the current battery discharge rate
[04:55] <jdong> pwnguin: and spikes of 2061mA are suspicious
[04:55] <jdong> unless she's got a dedicated GPU of some sort
[04:56] <pwnguin> i think hobbsee was telling me to buy intel
[04:56] <jdong> my macbook usually draws 1300 idle, 2000 under firefox rendering loads
[04:56] <imbrandon> ok guys ........
[04:56] <imbrandon> [22:52] <imbrandon> anyone know why i would get this .... debian/scripts/misc/oldconfig: line 66: /home/brandon/files/xbox/kernel/ubuntu-image/linux-source-2.6.22-2.6.22/debian/scripts/misc/splitconfig.pl: Permission denied
[04:56] <imbrandon> [22:52] <imbrandon> when running the updateconfigs
[04:56] <imbrandon> [22:53] <imbrandon> *debian/rules updateconfigs
[04:56] <imbrandon> [22:55] <imbrandon> ( and yea i ran it with sudo fwiw )
[04:56] <pwnguin> Present rate       : 20808 mW
[04:56] <jdong> imbrandon: script not chmodded +x?
[04:56] <jdong> the .pl thing
[04:57] <jdong> pwnguin: divide that by approximately 11.7 volts?
[04:57] <imbrandon> no idea
[04:57] <jdong> 1778.46153846153846153846
[04:57] <jdong> mA
[04:57]  * jdong checks that W/V = A
[04:57] <ajmitch>     Remaining capacity : 3076 mAh, 100.0%
[04:57] <ajmitch>     Design capacity    : 4400 mAh
[04:57] <ajmitch>     Last full capacity : 3076 mAh, 69.91% of design capacity
[04:57] <ajmitch>     Capacity loss      : 30.09%
[04:58] <ajmitch> awesome
[04:58] <jdong> yes it is
[04:58] <jdong>     Remaining capacity : 4546 mAh, 100.0%
[04:58] <jdong>     Design capacity    : 4800 mAh
[04:58] <jdong>     Last full capacity : 4546 mAh, 94.71% of design capacity
[04:58] <jdong> recalled battery FTW!
[04:58]  * ajmitch has had this laptop for >18 months now
[04:58] <jdong> ajmitch: that's very impressive, and you probalby use it a lot too
[04:58] <ajmitch> yeah
[04:58] <pwnguin> why is my output so different?
[04:59] <ajmitch> so I don't think it's doing *too* badly yet
[04:59] <pwnguin>    Remaining capacity : 38193 mWh, 100.0%, 02:09:17
[04:59] <pwnguin>     Design capacity    : 50760 mWh
[04:59] <pwnguin>     Last full capacity : 37141 mWh, 73.17% of design capacity
[04:59] <jdong> pwnguin: batteries report in different units
[04:59] <pwnguin> fun
[04:59] <jdong> pwnguin: technically mWh is a proper unit of power consumption rate
[04:59] <jdong> pwnguin: while mAh is a unit of current * time = net current flow
[05:00] <jdong> pwnguin: but we can assume the voltage of a laptop battery to be the standard 11.7-12.0
[05:00] <lifeless> we can? why?
[05:01] <pwnguin> heh
[05:01] <jdong> lifeless: aren't most common laptops using cells around that voltage?
[05:01] <pwnguin> you have a point
[05:01] <mbt> Has anyone here setup a buildd for managing a small collection of packages?  Or perhaps an easier, more efficient auto-build system?
[05:01] <lifeless> jdong: I'm thinking of MID's
[05:01] <pwnguin> gnome reports the voltage at 11.3ish
[05:02] <jdong> lifeless: ok, those are probably very different :)
[05:02] <jdong> but I haven't seen many fullsized laptops with batteries not around 12V
[05:03] <pwnguin> is 11.25 "around 12?"
[05:03] <jdong> pwnguin: design voltage is around 12 :)
[05:03] <jdong> pwnguin: what it is when capacity is at 60%, I don't know :)
[05:04] <pwnguin> the ac adaptor claims to output 15V
[05:04] <jdong> pwnguin: well that goes through several DC-DC converters before entering the charging circuit
[05:05] <pwnguin> perhaps
[05:05] <pwnguin> my external battery says 10.8 DC
[05:05] <jdong> pwnguin: where does that plug into?
[05:06] <pwnguin> underneath
[05:06] <pwnguin> my main battery also says 10.8
[05:06] <jdong> ok, then around 11V :)
[05:07] <jdong> 10.8 / 3.6 = 3
[05:07] <jdong> I guess that's a 6-cell?
[05:07] <pwnguin> yea
[05:07] <pwnguin> they're both 6 cells
[05:07] <jdong> makes sense then
[05:08]  * ajmitch should get a new laptop :)
[05:08] <pwnguin> anyways
[05:08] <pwnguin> g-p-m has an annoying habit of blacking the screen instead of turning the light off
[05:08] <jdong> everyone should get a new laptop! whee!
[05:08] <pwnguin> which saves like nothing in power
[05:09] <jdong> pwnguin: that sucks
[05:09] <pwnguin> its not so bad
[05:09] <pwnguin> if i leave the laptop unattended, it's usually on power
[05:10] <pwnguin> and if i close the lid, it does turn the light off
[05:10] <jdong> pwnguin: that's good... I have to travel for the day with my laptop and charge when I get ack from classes
[05:10] <jdong> so I need decent battery life
[05:10] <imbrandon> unattended powered on laptop ? woot, and does this have your ~/.gnupg dir on it ? hehe
[05:11] <pwnguin> well
[05:11] <pwnguin> im talking like
[05:11] <pwnguin> in my bedroom
[05:11] <imbrandon> heh i'm just messin with ya
[05:11] <pwnguin> while im eating a sandwich in the kitchen
[05:11] <ajmitch> imbrandon could be like a redneck ninja & stealth into your bedroom, you know
[05:11] <jdong> imbrandon: security question, is it easy to decrypt the secret key when you have someone's ~/.gpg?
[05:12] <jdong> imbrandon: I would imagine that'd be a time-consuming process too
[05:12] <imbrandon> depends on the passphrase
[05:12] <StevenK> jdong: For all practical purposes, no. It's usually safer to be paranoid and revoke the key
[05:12] <imbrandon> persia claims a 40bit pass can be dont in 16 hours with normal moden PC
[05:12] <pwnguin> but you could nab my ssh keys
[05:12] <jdong> imbrandon: isn't the passphrase also key-hardened?
[05:12] <imbrandon> done*
[05:12] <pwnguin> what
[05:13] <pwnguin> at some point, you have to stop typing in passwords
[05:13] <StevenK> imbrandon: "40 bit pass" ?
[05:13] <jdong> imbrandon: specific to gnupg or in general?
[05:14] <imbrandon> jdong, he was talking in general, StevenK probably ment 40-bit length
[05:14] <imbrandon> not sure
[05:14] <pwnguin> well
[05:14] <jdong> imbrandon: I would expect a strengthened key to take longer to crack, even 5-char passwords
[05:14] <pwnguin> thats assuming the old rc challenges were equiv to one modern pc
[05:14] <pwnguin> crack.net broke a 40 in like 16 hours
[05:14] <StevenK> Hrm. My battery says "67.18%" too
[05:14] <jdong> yeah, GnuPG does use key-strengthening
[05:15] <jdong> so I'd bet that even in posession of a private key, without knowing the passphrase it's basically a dead end
[05:15] <jdong> unless you're the magnitude of a government
[05:15] <jdong> then anything's possible :)
[05:15] <imbrandon> jdong, even if the passphrase isnt guessed, the key is still considered compromised though was my point ;)
[05:15] <jdong> imbrandon: a symmetrically encrypted copy of the key is compromised
[05:16] <jdong> imbrandon: but if you had a passphrase-locked encrypted hard drive that was lost, would you consider the data compromised?
[05:16]  * imbrandon gives up
[05:16] <jdong> imbrandon: no no, I'm just trying to understand what you consider to be compromised
[05:17] <imbrandon> i'd have to hunt the debian doc i was reading way back
[05:17] <imbrandon> is what i was going from
[05:17] <pwnguin> i imagine the launchpad peoples would be better able to answer the question of security
[05:18] <jdong> all I'm saying is..... When people symmetrically encrypt their hard drives with dm-crypt and such, they consider their data to be safe even when their disk is lost
[05:18] <jdong> but when people lose their ~/.gnupg, the sky is falling and hell is freezing over
[05:18] <jdong> I fail to understand what's different between the two
[05:18] <pwnguin> key length?
[05:18] <jdong> pwnguin: I doubt people set bootup passwords to be nearly as long as a gnupg passphrase
[05:19] <pwnguin> i imagine the kind of person with a bootup password would
[05:19] <jdong> pwnguin: takes me nearly 20 seconds to type in my gnupg passphrase, wouldn't want to do that at boot :)
[05:19] <pwnguin> jebus
[05:19] <imbrandon> jdong, i see your point but i have no awnser , nor would i care to speculate
[05:19] <jdong> imbrandon: understood :)
[05:19] <imbrandon> 20 seconds? fck
[05:19] <jdong> imbrandon: it's a 25-character fairly random thing
[05:20] <pwnguin> does that make it more secure?
[05:20] <jdong> I just stuck like 4 pwgen passwords together
[05:20] <pwnguin> it gets hashed i thought
[05:20] <jdong> pwnguin: in a way, yes.....
[05:20] <imbrandon> K2r0L7x9 ??
[05:20] <ajmitch> pwnguin: it's there to impress the MIT ladies who he hangs round ;)
[05:20] <imbrandon> heh
[05:20] <jdong> pwnguin: if you are brute forcing a strengthened key, I'd argue that whether it's 5 chars or 100, it makes little difference
[05:20] <jdong> pwnguin: but if you are sitting next to me and I'm typing my passphrase, it makes a world of difference
[05:21] <pwnguin> i have no clue what a "strengthened" key is
[05:21] <jdong> pwnguin: hash the passphrase 100,000 times
[05:21] <jdong> pwnguin: so it takes like 1 second to guess each passphrase
[05:21] <jdong> pwnguin: makes brute forcing pretty impossible :)
[05:21] <pwnguin> no it doesnt
[05:21] <jdong> pwnguin: it's a serious deterrent
[05:21] <pwnguin> 0
[05:21] <pwnguin> 1
[05:21] <pwnguin> 2, 3, 4, 5 etc
[05:21] <jdong> pwnguin: each takes 100,000 times longer to try
[05:22] <pwnguin> they no longer correspond to meaningful passwords, but who cares?
[05:22] <imbrandon> to match the end hash ? why
[05:22] <jdong> pwnguin: a 5-char strenthened key would take the same time to brute force as a 500,000 char unstrengthened one
[05:22] <pwnguin> jdong: only if you bother trying 1 char hased pwds, then 2, and so on
[05:23] <jdong> pwnguin: well it amplifies the bitlength of your hash, regardless of your actual passphrase
[05:23] <jdong> pwnguin: so yes, if you are stepping through possible values of the key, it doesn't "make a difference"
[05:23] <jdong> but even like a 2-char password is like a 1024-bit or whatever key
[05:23] <jdong> it is a letdown to brute-forcers :)
[05:23] <pwnguin> assuming gpg doesnt truncate it
[05:23] <pwnguin> its not though
[05:24] <pwnguin> its a let down to dictionary attacks
[05:24] <pwnguin> and MAYBE brute force attacks starting from short passwords
[05:25] <pwnguin> the point brandon brought up was that the distributed rsa cracking broke a 40bit key in like less than a day (they got lucky, mostly)
[05:25] <jdong> pwnguin: well it surely makes 2-char passphrases just as hard to crack as 10-char ones
[05:26] <jdong> pwnguin: and I guess that was my ultimate point, you will have to search over the entire length of the key, regardless of the strength of your passphrase
[05:26] <imbrandon> snap, what have i done
[05:26] <imbrandon> lol
[05:26] <jdong> pwnguin: which in the case of GPG I'm betting governments aside people don't have the resources to do it
[05:26] <imbrandon> skynet
[05:26] <imbrandon> lol
[05:26] <jdong> :D
[05:27] <jdong> oh well, I'll go elsewhere hunting for answers to this
[05:27] <pwnguin> well, go look up how big a gpg passphrase is
[05:27] <imbrandon> that and getting time on a sun grid computer isnt tough
[05:27] <pwnguin> as far as when to revoke keys
[05:27] <pwnguin> thats a policy thing
[05:27] <pwnguin> no book can really prove your key secure
[05:30] <jdong> iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: ...
[05:31] <jdong> so it's SHA1 iterated 2000 times?
[05:31] <jdong> I think?
[05:31] <imbrandon> my passphrase is "killbill" :)
[05:31]  * imbrandon lol's
[05:31] <imbrandon> wonder how many people DO use dictionary passwords though
[05:33] <pwnguin> http://bash.org/?691
[05:33] <jdong> imbrandon: I bet a lot
[05:33] <ajmitch> p4ssw0rd
[05:33] <pwnguin> heh
[05:34] <pwnguin> psh security smurity
[05:34] <pwnguin> i use a fingerprint reader to log in
[05:34] <jdong> hahahaha
[05:34] <jdong> I don't understand why fingerprint readers are a good idea
[05:35] <pwnguin> because it's easier than typing in a password when you dont have a keyboard handy
[05:35] <jdong> why not authenticate with skin flakes, dirty socks, hair (for aging men), or any of the other things we leave around everywhere we go??
[05:35] <pwnguin> they're basically not
[05:35] <jdong> that's what I thought....
[05:35] <imbrandon> dna?
[05:35] <jdong> I thought the point of a authentication key was to use something that is idnetifiable to you, but others would not be able to obtain :)
[05:35] <pwnguin> imbrandon: what about my identical evil twin!?!
[05:35] <jdong> imbrandon: that would be a sucky ID too :)
[05:36] <StevenK> I thought identical twins had different fingerprints?
[05:36] <pwnguin> its a bit harder than you'd think to recover a fingerpritn
[05:36] <imbrandon> yea but it was kinda funny in judge dred
[05:36] <pwnguin> StevenK: but very similar dna :P
[05:36] <StevenK> imbrandon: I've not seen that.
[05:37] <imbrandon> pwnguin, but easier than you think to use it once you get it, photocopy your finger and use it on the scanner if you have the toshiba type
[05:37] <imbrandon> it WORKS heh
[05:37] <pwnguin> i do
[05:37] <pwnguin> i'll try that
[05:37] <imbrandon> StevenK, futureistic movie where the cops ( judges ) had guns that when fired put a "dna" stamp on the bullet so they would know who killed who
[05:38] <imbrandon> pwnguin, my little bro has one, a photocopy works 80% or more of the time on his
[05:38] <pwnguin> but most serious people suggest using fingerprints in two part auithentication
[05:38] <StevenK> imbrandon: Oh, I know the title, I've just not seen the movie
[05:38] <imbrandon> ahh
[05:39] <imbrandon> kinda corny, but its ok, better than some stuff
[05:39] <StevenK> Seems a bit like Fortress
[05:39] <StevenK> (Not in plot or storyline, but general feel)
[05:39] <imbrandon> ahh
[05:39] <imbrandon> not seen that one
[05:40] <imbrandon> man i need a new computer chair, this one sucks to sit at long peroids
[05:40] <StevenK> Oh that's right, Christopher Lambert is the main guy
[05:40] <imbrandon> mmmm lazyboy recliner with a arm tray for a external mouse and a macbook pro, mmmmmmmm
[05:41] <CarlFK> Where is the place to log suggestions?  (synaptic - in addition to "import key from file" add "dl key from url")
[05:41] <imbrandon> CarlFK, wiki/IdeaPool
[05:41] <CarlFK> thanks
[05:41] <imbrandon> np
[05:42] <imbrandon> i should have timed this build
[05:42] <imbrandon> its takin forever
[05:42] <imbrandon> all so i dont have to install windows
[05:48] <mneptok> the robs are multiplying
[05:50] <Hobbsee> as long as it's not hte mneptoks multiplying...
[05:51] <imbrandon> heh
[05:54] <ajmitch> what a disturbing thought
[06:03] <imbrandon> perhaps #ubuntu-classroom should be muted untill the talks
[06:09]  * Hobbsee composes a mail to the MOTU mailing list.
[06:14] <white> Hobbsee: I'll come to sydney btw :)
[06:15] <Hobbsee> white: woot!
[06:15] <white> a bit offtopic, but it just came into my mind :)
[06:15] <white> Hobbsee: i'll travel around a bit, when I come back from Germany :)
[06:15] <Hobbsee> :D
[06:15] <white> Hobbsee: I will be in sydney around the 7th of January
[06:17]  * Hobbsee rereads this, hits send.
[06:17]  * Hobbsee waits for the fur to fly
[06:17] <Hobbsee> ScottK: ^
[06:21] <Hobbsee> right.  mail send.
[06:21] <Hobbsee> s/send/sent/
[06:26] <nixternal> I don't think I will ever upload again... Hobbsee you scared me from even uploading to my PPA :)
[06:26] <Hobbsee> nixternal: :)
[06:26]  * Hobbsee hugs nixternal
[06:26] <nixternal> hehe
[06:26] <Hobbsee> nixternal: just test first.  it's not that hard.
[06:27] <Hobbsee> besides, for ppa's, people expect breakage, to some degree.
[06:27] <nixternal> I test everything, and then I use #ubuntu-chicago as my guinnea pigs
[06:27] <Hobbsee> then you're fine :
[06:27] <Hobbsee> * :)
[06:27] <nixternal> ya, but they aren't
[06:27] <nixternal> muhahahaha
[06:27] <Hobbsee> nixternal: haha
[06:27] <nixternal> suckahs fall for my rootkitted amarok2 packages all day long :D
[06:27] <Hobbsee> nixternal: really, we're not going to kill you for not finding a corner case.  but to not test it at *all*....
[06:28] <nixternal> oh, I totally understand...I want to make core-dev this next cycle, so I am a test-a-holic
[06:34] <Hobbsee> nixternal: :)
[06:46] <pkern> Nightrose: Nothing yet.
[06:47] <dholbach> good morning
[06:48] <ion_> Hi
[06:48] <ion_> Could someone please review http://revu.tauware.de/details.py?upid=298 and http://revu.tauware.de/details.py?upid=299? Thanks.
[06:49] <Hobbsee> good morning dholbach
[06:50] <dholbach> heya Hobbsee :)
[06:51] <Hobbsee> dholbach: i havent quit motu yet.
[06:52] <Hobbsee> but at this point, i'm starting to ponder doing all my merges now, incase i do.
[06:54] <dholbach> Hobbsee: having everything merged early is a good thing, but what has that to do with quitting MOTU?
[06:54] <Hobbsee> dholbach: have you seen the MOTU mailing list yet?
[06:54] <dholbach> which message are you referring to?
[06:55] <Hobbsee> gnumed-client SRU
[06:55] <dholbach> I hadn't read that
[06:56]  * elkbuntu notes that pounding footpaths is quick becoming a really ineffective way of looking for work
[06:57] <dholbach> I agree that we should emphasize the testing part of it
[06:57] <Hobbsee> dholbach: frankly, I cant see the point of being part of something that the people involved dont care about at all.  If our MOTUs don't care at all about QA, and prove that they don't, then the project is worthless.  It's intended to be helpful to our users - not to break our systems by throwing untested crap in there.  If it's a garbage dump of a whole bunch of stuff that might work, then I really can't see the point of being involved - nor
[06:57] <Hobbsee> why I might want to be affiliated with it.
[06:57] <Hobbsee> s/our/their/
[06:58] <Hobbsee> It would be better to go to somewhere like debian, where at least the Maintainers actually *care* about what they upload, and their users.
[06:58] <dholbach> Hobbsee: can you tell me how many uploads are untested or screw the systems?
[06:58] <superm1> ion_, i looked over 298.  Looks good to me.
[06:58] <superm1> hi everyone
[06:58] <dholbach> hi superm1
[06:58] <Hobbsee> dholbach: the one listed in that mail, the fiasco with audacious plugins.
[06:58] <dholbach> Hobbsee: I agree with you: we need to do more testing, but I really think you're exaggerating
[06:59] <dholbach> it's not that MOTU is an uncontrollable bunch of people who upload *random* crack
[06:59] <dholbach> really
[06:59] <ion_> superm1: Thanks
[06:59] <Hobbsee> looking at the sponsorship queue a couple of days ago, it looks like more were broken.
[06:59] <dholbach> you're not doing the team justics
[06:59] <dholbach> justice
[06:59] <superm1> dholbach, well except for jdong and RAOF and they're crack filled packages :)
[06:59] <Hobbsee> upstream fix to a stable release with no testing at all is crack.
[06:59] <dholbach> I wouldn't be that quick to judge on the whole team and the myriads of uploads we did and fixes we developed
[06:59] <Hobbsee> no, but a team is only as good as it's weakest link.
[07:00] <dholbach> Hobbsee: please calm down
[07:00] <Hobbsee> in the case of QA>
[07:00] <dholbach> geser is not the weakest link
[07:00] <Hobbsee> i'm perfectly calm...
[07:00] <Hobbsee> dholbach: disappointed, yes.  but completely calm.
[07:01] <dholbach> instead of yelling at people or considering to leave the team it'd make more sense to find out what we can do to improve our QA
[07:01] <Hobbsee> that's only worht attempting to do if you can get the high ups to actually implement it.
[07:01]  * imbrandon blinks
[07:01] <imbrandon> heya dholbach
[07:01] <superm1> ion_, regarding 299, you list two different bzr branches in debian/copyright and debian/control
[07:01] <dholbach> hey imbrandon
[07:02] <superm1> ion_, is that intentional?
[07:02] <dholbach> Hobbsee: we should discuss this instead of asking for policies how to deal with such people
[07:02] <dholbach> Hobbsee: as a team we'll find a way
[07:02] <Hobbsee> dholbach: my main problem with that is that such discussions usually turn out to be bikeshedding, or lost in the space of time, and nothing ever gets decided.
[07:03] <ion_> superm1: The branch in debian/control contains the packaging; the branch in debian/copyright contains the actual software.
[07:03] <superm1> ion_, ah okay.
[07:04] <dholbach> Hobbsee: I'm not going to accept that argument - if it were true we could stop all kinds of discussions
[07:04] <dholbach> if you're not interested in helping to find a measure, that's fine
[07:04] <Hobbsee> dholbach: i am, at least somewhat, but the question si more if i have the confidence that the decision will be reached?
[07:05] <dholbach> if you're not sure you want to, leave it, that's fine
[07:05] <Hobbsee> dholbach: what do *you* think we should do about our QA?
[07:05] <Hobbsee> particularly if we cant trust some of our MOTU's to DTRT
[07:05] <dholbach> let's discuss this rationally on the mailing list
[07:06] <dholbach> we CAN trust
[07:06] <dholbach> our processes are all based on trust
[07:07] <dholbach> I'll follow up on the mailing list
[07:07] <dholbach> Hobbsee: can we have a call about that?
[07:07] <Hobbsee> it seems that we trust people to DTRT, even if they obviously don't.  perhaps that works, perhaps that doesn't.  there's a very real risk of burying our proverbial heads in the sand, that way.
[07:07] <dholbach> geser did a mistake
[07:08] <dholbach> "all is lost" is not really where we're standing now
[07:08] <StevenK> Who said anything about that?
[07:08] <Hobbsee> StevenK: about which?
[07:08] <StevenK> I also didn't read that from Hobbsee's mail.
[07:08] <dholbach> StevenK: "we cant trust some of our MOTU's to DTRT"
[07:08] <elkbuntu> StevenK, the tone of the conversation
[07:08] <dholbach> that's not where we're standing at
[07:10] <dholbach> we can improve the SRU documentation, we can talk to individuals, we can make changes in the process of educating new MOTUs or come up with other ideas to raise awareness
[07:10] <dholbach> I believe that calling for sanctions or policies "how to deal with people who did wrong" is not going to help
[07:10] <Hobbsee> dholbach: i'm not meaning to convey an "all is lost" attitude here.  What i'm now pondering is whether I want to still be involved, based on what the MOTU attitudes seem to have changed to.
[07:10] <superm1> ion_, +1 on 299 also.  great work :)
[07:11] <dholbach> to you it seems that "all is lost"
[07:11] <ion_> superm1: Thanks again. :-)
[07:11] <dholbach> geser did a mistake, I haven't talked to him yet, he should have tested it
[07:12] <Hobbsee> dholbach: i'm also wondering why the attitudes have changed, and whether the MOTU's are happy with them having changed.
[07:12] <dholbach> Hobbsee: but viewing this as "the change in attitude MOTUs have gone through" is the wrong perception
[07:12] <Hobbsee> dholbach: why?
[07:12] <dholbach> because 1 person did 1 mistake
[07:12] <dholbach> we always had broken uploads in a while
[07:13] <dholbach> or somebody who took testing not seriously enough
[07:13] <dholbach> but calling the whole system broken because of that, is going too far
[07:13] <dholbach> geser is doing a very good job elsewhere
[07:13] <dholbach> but I, too, would have preferred it if this hadn't happened
[07:14] <Hobbsee> dholbach: granted, he does not speak for everyone.
[07:14] <Hobbsee> dholbach: but i'm surprised that *any* of our MOTU's did this.
[07:14] <elkbuntu> Hobbsee, why... they are still human, are they not?
[07:14] <dholbach> it has happened before and it will happen again
[07:15] <Hobbsee> i think that whether the system is broken, or people's level of apathy are different issues.
[07:15] <dholbach> but I trust our people, especially I trust them to learn and to fix their mistakes
[07:15] <dholbach> the system is not broken
[07:15] <Hobbsee> elkbuntu: no, they all turned into green aliens :P
[07:15] <Hobbsee> dholbach: indeed.  but people's level of apathy, on not calling them on their errors, may well be.
[07:16] <dholbach> I don't think that's what's happening
[07:16] <dholbach> I told you yesterday, that replying to the upload mail is what people have done in the past and still do
[07:16] <dholbach> it's happening
[07:17] <dholbach> we don't need a punishment policy
[07:17] <Hobbsee> dholbach: to make this clear, i'm *not* bitching about the fact that a possible regresison wasnt picked up.  I'm bitching over the fact that a guy willfully did not test at all - which i'm unsure if that classes as a "mistake"
[07:17] <Hobbsee> dholbach: yeah, because people came to me, and asked me what should be done about it, and i told them to reply to the upload mail to the MOTU ML>
[07:17] <elkbuntu> Hobbsee, error in judgement is still an error
[07:18] <dholbach> Hobbsee: bitching does not help
[07:18] <dholbach> please try to think about this in a rational way
[07:18] <jake123> hello. i know i'm totally in the wrong room, but i'm new to irc and trying to join #python but it says i need to be identified, even though i've set up a screen name and password. can anyone help? i know this has to be a stupid question, so forgive me
[07:18] <nixternal> !register > jake123
[07:18] <Hobbsee> dholbach: i am.  if i werent, i'd be going on a witch-hunt about geser :P
[07:19] <Hobbsee> jake123: /msg nickserv identify jake123 <yourfreenodepassword>
[07:19] <StevenK> Hobbsee: You get the flaming torches, and I'll get the pitchfo ... Ohhh
[07:19] <StevenK> :-P
[07:19] <Hobbsee> hehe
[07:20] <dholbach> we have different notions of bitching then
[07:20] <Hobbsee> dholbach: oh, indeed.  i don't think i used the right word there.
[07:20] <elkbuntu> Hobbsee, forgive me for saying this, but the impression you've managed to give *is* one of a witch-hunt
[07:20] <Hobbsee> elkbuntu: granted.  i'm attempting for this to be more general, but i've not seemed to have suceeded.
[07:20] <TheMuso> dholbach: To me, its not about making our processes better. You can tell people to do anything. Whether they will or not, or more to the point, whether they think about whether they should do something or not, and then whether they will or not, is another story.
[07:21] <Hobbsee> elkbuntu: which is why i'm trying not to mention geser by name, etc.
[07:21] <jake123> it doesn't seem to be doing anythign. what am i doing wrong guys?
[07:21] <Hobbsee> elkbuntu: (because others also did this close to release, and i havent mentioned them by name either)
[07:21] <TheMuso> We NEED to make sure that any update to a stable release must be tested, no questions asked.
[07:21] <Hobbsee> jake123: chekc your server window?
[07:21] <dholbach> let's make this a rational thread on the mailing list
[07:22] <imbrandon> jake123, the people in #freenode could probably help you more, thats the official help channel
[07:22] <elkbuntu> Hobbsee, i dont doubt that, nor the seriousness, but i agree with dholbach that this discussion is not going to achieve anything other than a dip in team morale
[07:22] <jake123> ok sry to bother u guys
[07:22] <imbrandon> np
[07:24] <persia> I'd like to suggest that even a rational discussion on the mailing list won't help much either: the policies have already been established.  If there is truly a cultural issue (apathy or inattention to process), that is best solved through repeated examples of best practice here, rather than another announcement about the right way to do things.
[07:25] <dholbach> we can highlight things in the documentation, we can talk to people, we can do repeated announcements and other things
[07:25]  * ajmitch reads scrollback & the motu mailing list
[07:25] <ajmitch> oh my
[07:26] <nixternal> lions, and tiger, and bears!
[07:26] <nixternal> s/tiger/tigers
[07:26] <TheMuso> dholbach: That does exactly nothing to get the message accross that testing is needed, IMO.
[07:26] <dholbach> but suggesting that "we can not trust" really hurts me, because I think that it's the core of our culture here
[07:26] <dholbach> TheMuso: suggestions?
[07:27] <TheMuso> dholbach: Not currently, but it is something I am certainly giving thought to.
[07:27] <dholbach> thanks a lot for that TheMuso
[07:27] <nixternal> I don't believe in common sense, I think it is a myth...but one would have to error not only on the side of caution but use common sense by instinct I would think when it comes to SRUs
[07:28] <nixternal> amarok2 is almost done building w/o any cmake link errors, so nevermind my giddiness :)
[07:28] <Burgundavia> oh joy
[07:28] <ajmitch> hello Burgundavia
[07:28] <Burgundavia> hey ajmitch
[07:28] <imbrandon> nixternal, nice
[07:28] <imbrandon> heya Burgundavia
[07:28] <nixternal> makeobj[0]: Leaving directory `/home/kde-devel/kde/build/KDE/extragear/multimedia/amarok'
[07:29] <nixternal> that means it worked...
[07:29] <ajmitch> Burgundavia: why the oh joy?
[07:29] <imbrandon> nixternal, got it packaged ?
[07:29] <Burgundavia> the previous discussion, ajmitch
[07:29] <nixternal> <unknown program name>(23590)/: KUniqueApplication: Cannot find the D-Bus session server
[07:29] <ajmitch> Burgundavia: ah, the excitement
[07:29] <nixternal> and that means I need to boot back into kde4 :)
[07:29] <nixternal> imbrandon: we already have it packaged in the repos
[07:30] <Hobbsee> persia: that was basically what i was thinking.
[07:30]  * dholbach gets some coffee
[07:30]  * imbrandon gets some Mt. Dew
[07:30] <ajmitch> dholbach: you'll need it :)
[07:30] <Burgundavia> Hobbsee: does the MOTU council not have something in place for dealing with issues of a packager not following QA
[07:30] <Burgundavia> ?
[07:31] <ajmitch> Burgundavia: it hasn't been needed
[07:31] <Burgundavia> ok
[07:31] <StevenK> And from what dholbach says, isn't needed.
[07:31] <persia> Hobbsee: While I agree with much of your sentiment, I can't also agree with your methods.
[07:31] <imbrandon> that and to what level do you hold the QA? it dosent degfault? not every bug ( or any bug ) will be caught in QA
[07:31] <Hobbsee> Burgundavia: nope.  there were vague discussions about it at UDS, but nothing ever came of them.  This si one of the great problems with MOTU - unpopular decisions tend to get put off, and dont get done.
[07:31] <nixternal> just hurry up and get the toolchain rolling...I have a list of merges here that will put the Sears Tower to shame
[07:32]  * ajmitch has no outstanding universe merges
[07:32] <Burgundavia> Hobbsee: it is not a problme just with MOTU, fear not
[07:32] <Burgundavia> now, the issue at hand is that something went to -proposed without a test by the uploader, yes?
[07:32] <nixternal> someone warned me of a Tellico merge the other night
[07:32] <Hobbsee> Burgundavia: oh, indeed.
[07:32] <persia> Burgundavia: More generally, there are no control mechanisms at all.  In many ways, that is nice, because it makes it easy to do things.
[07:33] <ajmitch> part of the 'problem' is probably that we run fairly loosely
[07:33] <nixternal> this cycle I have to get libhttp into debian as another name under the embedded project, sync it to Ubuntu, and hack the hell out of Plucker...which has been dead for a while, but people live by it it seems
[07:33] <persia> imbrandon: builds, installs, runs, addresses known issue, exits cleanly, removes, purges is a good minimum.
[07:33] <Burgundavia> correct me if I am wrong, but an upload to proposed without testing is an issue, but it was not as if it went to gutsy live
[07:33]  * Hobbsee notes that a pbuilder hook will test most of them.
[07:34] <Hobbsee> Burgundavia: indeed.  but it's still rather worrying
[07:35] <imbrandon> whoa hold on, this is for an upload to -proposed ? thats where the testing is SUPOSE to happen
[07:35]  * imbrandon looks perplexed
[07:35] <ajmitch> imbrandon: yes, but you'd generally expect at least a minimum of testing before it gets there
[07:36] <Burgundavia> from an outsiders perspective, if a package installs/uninstalls cleanly and starts, that is the only testing that needs to happen before it goes to -proposed
[07:36] <imbrandon> ajmitch, mimimum means many diffrent things, to me a patch that applies cleanly and it builds and installs is minimum
[07:36] <imbrandon> Burgundavia, exactly
[07:36] <Hobbsee> imbrandon: hopefully upgrades too
[07:36] <dholbach> StevenK: that's not what I said
[07:36] <ajmitch> imbrandon: ok, how about "appears to fix the problem"
[07:36] <dholbach> StevenK: I said a couple of times that we can talk to people
[07:36] <imbrandon> Hobbsee, heh yea but thats just a versioning issue, and sometimes those are tricky
[07:37] <ajmitch> given that MOTUs can't test everything, and may not be affected at all by the bug
[07:37] <Hobbsee> Burgundavia: the worrying part there is how many people are using -proposed as part of their regular reposet, so it seems we do need some QA in there at all
[07:37] <Hobbsee> imbrandon: granted.
[07:37] <persia> imbrandon: Testing does happen in -proposed, but an upload to proposed should receive the same level or pre-upload QA as any other upload.
[07:37] <nixternal> for instance, think of the smb4k bug where the dev patched it, it got uploaded into proposed, pushed into stable, and I ended up finding out the patch totally wipes out /etc/sudoers
[07:37] <Burgundavia> Hobbsee: if somebody uses proposed as part of their reposet, that is an issues
[07:37] <nixternal> so there definitely needs to be testing
[07:37] <Burgundavia> Hobbsee: we should make it so that the GUI tools warn if you try and install from -proposed
[07:38] <Burgundavia> other than that, it is not a major issue that I can see
[07:38] <Hobbsee> Burgundavia: it says "pre-released updates"
[07:38] <imbrandon> nixternal, thats just a failed system then because it should have been well tested by multi people before uplaoding to stable
[07:38] <Burgundavia> Hobbsee: does it pop up a warning on the update manager. The only people I can see being bitten by this are people who have added it accidentally or for another package
[07:39] <nixternal> that ended up being my first security fix, and the dev praised myself and kees for finding it and fixing it
[07:39] <nixternal> it twas a mess for sure
[07:39] <StevenK> I'd expect the uploader (and the bug fixer, if they aren't the same person) to have tested the package builds, installs, upgrades and has no regressions before it is uploaded.
[07:39] <Hobbsee> Burgundavia: it lists them as "proposed", but doesnt give a very big warning about it or anything, no.
[07:39] <Hobbsee> Burgundavia: the trouble with warnings is that people tend to ignore them.
[07:39] <imbrandon> so basicly this is breaking down to "where is the checklist that i NEED to do before i upload" i know there are unsaid ones but i mean a well defined one, if there isnt, thats the first step and nothing else can be done past that
[07:39] <Burgundavia> Hobbsee: that is a bug that needs to be filed
[07:39] <nixternal> it could have easily gone through a install/uninstall, run, shutdown like I keep seeing...that type of testing won't catch it...you would have to actually use it for about 15 minutes playing around with settings first
[07:40] <Hobbsee> Burgundavia: good point.  i only started using it < a week ago
[07:40] <imbrandon> Hobbsee, then fix the root of the problem, warn people not to use proposed except to test
[07:40] <Burgundavia> Hobbsee: however, the issue is thus: I think MOTU needs a small checklist of things to do before the updater pushes to -proposed
[07:40] <Hobbsee> imbrandon: that's a decent idea.  i thought we actualyl had a checklist.
[07:41] <nixternal> I would think the only ones using proposed are those with experience anyways...I don't use proposed, and I know many who don't as well
[07:41] <ajmitch> nixternal: people see shiny, new stuff
[07:41] <imbrandon> yea we cant bitch about something not being done if its not written policy to be done
[07:41] <nixternal> so warning someone that it is dangerous that already know it is dangerous is like telling me that cigars is bad for my health
[07:41] <nxvl> imbrandon: can u helping me with th merge i'm doing?
[07:42] <imbrandon> nxvl, i can try, you will have much more luck asking specific questions in here and we'll all try our best to point you in the right way
[07:42]  * Hobbsee would expect checking it to ensure it runs would be helpful
[07:42] <imbrandon> nixternal, fire will burn you
[07:42] <nxvl> imbrandon: ok, let's do so
[07:42] <nixternal> ya, so will the devil when I meet him one day
[07:42] <StevenK> Burgundavia: I really like that idea.
[07:43] <Hobbsee> !sru
[07:43] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[07:43] <imbrandon> StevenK, i said it first , hahahahah just playing
[07:43] <imbrandon> Burgundavia, speaking of, how ya been ltns
[07:44] <Burgundavia> school has been kicking my ass
[07:44] <TheMuso> I also think it wouldn't hurt having a easily findable list of the upgrade paths we support.
[07:44] <Burgundavia> got two midterms this week that were re-re-scheduled at the last minute
[07:45] <imbrandon> TheMuso, true , afaik its only release to next release and LTS to LTS
[07:45] <StevenK> imbrandon: Right.
[07:45] <imbrandon> but it might be good to have that prominate somewhere
[07:45] <ajmitch> Burgundavia: wonderful!
[07:45] <nixternal> Burgundavia: join the "school has been kicking my ass" club
[07:46] <nixternal> my dumb ass is doing 8 credit hours to complete my masters, and then for the hell of it, I decided to take 14 hours of compsci courses
[07:46] <imbrandon> uht ohhh, ohhh noes, last cigarette and i'm not going to the store this late, looks like its almost bedtime
[07:46] <nixternal> luckily, the 8 credit hours are field survey courses
[07:46] <Hobbsee> hm, the sru process doesnt say when the package should get uploaded to -proposed, for universe
[07:46] <nixternal> omg, did you hear that?
[07:47] <nixternal> my pillow just yelled out my name
[07:47] <nixternal> g'nite
[07:47] <ajmitch> goodbye mr nixternal
[07:47] <persia> If documentation is being updated, it may be worth taking a clos look at the SRU page.  It indicates that it should be uploaded (step 2), published (step 3), and then tested by the interested party (step 4.1)
[07:47] <ajmitch> yay for documenting common sense
[07:47] <imbrandon> Hobbsee, as soon as its debsigned? heh
[07:48] <Hobbsee> imbrandon: as in, as a step on that list.
[07:48] <imbrandon> Hobbsee, well since its the begingin of the process i would assume step 1, i need to go back and look
[07:49] <Hobbsee> imbrandon: it seems our documentation does instruct them to test, but perhaps after the upload to -proposed
[07:49] <persia> Hobbsee: I'd say that step 1 includes first testing, then bug cleanup, then (implied) upload.
[07:49] <imbrandon> Hobbsee, yes, and this is exactly what i said
[07:49] <imbrandon> :)
[07:49] <Hobbsee> persia: right
[07:50] <persia> Grr..  This page is really not written to be helpful for people who can upload directly.
[07:50] <TheMuso> persia: I was only thinking that earlier today.
[07:50] <imbrandon> only minimal testing needs to be done before upload , patch applys clean builds installs upgrades removes , then wider testing is done via -proposed, that is what that repo is for
[07:50] <persia> imbrandon: Can we add "runs" and "fixes reported issue" to that list?
[07:51] <StevenK> Along with "no regressions" ?
[07:51] <imbrandon> persia, sure if we come up with an "official" list for uploads, but if we add toooo much to the list wth is the point of -proposed, just upload it directly to -updates ;)
[07:51] <persia> StevenK: As much as I'm fond of QA, I think "no regressions" is something that may not be obvious to the uploader, even with basic testing.
[07:52] <StevenK> Okay, no serious regressions?
[07:52] <Hobbsee> imbrandon: seeing as the original uploader has to do the work in -proposed or -updates, the point is moot for then
[07:52] <persia> imbrandon: For others to test, with different configurations, and different use cases, to expose regressions, new bugs introduced, etc.
[07:52] <Hobbsee> the purpose of -proposed would be for other people to test it out, and do what persia said.
[07:52] <imbrandon> Hobbsee, i was being a cynic, i know the real point
[07:53] <imbrandon> but yea
[07:53] <persia> More explicity, applying and uploading a patch without verifying that it addresses the reported issue is just a waste of other people's time.
[07:53] <Hobbsee> persia: i think that's what i'm most annoyed about.
[07:53] <Hobbsee> time is precious, and to waste other people's time is incredibly rude.
[07:53] <ajmitch> persia: given in this case, the patch was supplied by upstream to fix the issue
[07:53] <Hobbsee> and it also reflects on the distro, of course
[07:54] <imbrandon> Hobbsee, kick ass i totaly agree with you two, but the real problem here is that is no where in writing so how do you enforce something thats not stated explisitly
[07:54] <persia> Hobbsee: If that is what is annoying you, you'll do better to complain about rudeness than trust.  If we can't trust each other, we have a huge issue.  If we're impolite, we can discuss, and address that rationally.
[07:54] <Hobbsee> imbrandon: granted.  we should all fix that.
[07:54] <Hobbsee> i thought it was there
[07:54] <imbrandon> great that would be a better use of our time than arguring about mis-trust and such
[07:54] <imbrandon> ;)
[07:55] <Hobbsee> imbrandon: although one kinda leads to the other...
[07:55] <persia> ajmitch: You may be correct.  I haven't looked at the patch, or tested it.  I trust geser more than I trust upstream, and his opinion weighs a lot more than the original inventor.  If upstream was always right, there'd be very little for us to do.
[07:55] <imbrandon> not exactly, my faith in ubuntu and -proposed hasent flickered, everyone views everything a tad diffrent, but i do agree we should get this going,
[07:56] <ajmitch> persia: right, the patch was to fix an incompatibility between the package in question & a python library it depended on
[07:56] <imbrandon> soooooo without further adue why dont we / you / someone sugest a starter list and we add it to the wiki or ML
[07:57] <imbrandon> brb checking kernel compile progress
[07:57] <Hobbsee> imbrandon: because i have to go to work :)
[07:57]  * persia suggests "Patch applies", "result builds", "package upgrades cleanly", "application runs", "reported issue cannot be reproduced", "package uninstalls cleanly", "package purges cleanly".
[07:57] <Hobbsee> persia: +1
[07:57] <StevenK> persia: +1
[07:58] <dholbach> thanks a lot persia
[07:58] <imbrandon> Hobbsee, heh yea RL sucks at times, but does that sound like a sane first step ?
[07:58] <Hobbsee> im
[07:58] <Hobbsee> imbrandon: yes
[07:58] <ajmitch> persia: it's adequate, if the person uploading can reproduce the issue in question
[07:58] <imbrandon> persia, looks good to me
[07:59] <ajmitch> often you'll have to rely on the testing of others to verify that the problem that they saw, is no longer present
[07:59] <imbrandon> ajmitch, yea that was one of my things sometimes i dont have the hardware to test a given issue but i can make a upload for others to test
[07:59] <persia> ajmitch: I agree completely.  If the uploader cannot verify, I'd hope they'd ask for testing here with a pointer to a candidate debdiff or the like.
[07:59] <imbrandon> but the others should be no brainers
[08:00] <ajmitch> persia: in that case, I'd suggest using PPAs
[08:00] <ajmitch> as controversial as they may be ;)
[08:00] <imbrandon> unless its non x86 hardware then ppa are useless
[08:00] <imbrandon> e.g. PPC only issue
[08:00] <imbrandon> or some such
[08:00]  * StevenK coughs abd hacks, ubuntuwire
[08:00] <StevenK> s/abd/and/
[08:01] <ajmitch> imbrandon: it doesn't matter, really - whatever crackful build system people want to use
[08:01] <imbrandon> StevenK, hehe yea i really wish we could have kept that going, maybe i'll spark some more intrest at UDS
[08:01] <TheMuso> If people really need PPC hardware to build/test stuff on, I would be happy to give access.
[08:01] <TheMuso> Granted its only a G4, but its something.
[08:01] <imbrandon> TheMuso, hehe yea it was justa  example when "sometimes" that one rule might be an issue
[08:01] <persia> ajmitch: Perhaps.  I don't know that we need binaries.  Most of us can apply a debdiff fairly easily.  PPAs or private builds are also acceptable for initial testing (in my opinion)
[08:01] <ajmitch> the majority of issues will be x86/amd64 anyway, and the suggestion to use PPAs doesn't mean it's the only thing that people are allowed to use
[08:02] <imbrandon> ok sounds like the majority of the use cases are solved, i think anything else we can do on a case by case
[08:02] <ajmitch> persia: right, most of us can, sometimes you'd want binaries for others to test, but that's blurring the line between pre-upload testing & -proposed
[08:03] <imbrandon> right there isnt much diffrence between own buld for someone else to test and -proposed
[08:03] <imbrandon> but ..
[08:03] <imbrandon> hrm
[08:03]  * imbrandon kicks gcc
[08:03] <ajmitch> except the level of 'official'
[08:03] <ajmitch> anyway, I can't really comment, not being active :)
[08:04] <nxvl> ok, i'm merging efax-gtk and i've generated the ubuntu.debdiff and debian.debdiff, but i'm not quite sure what to do now with them
[08:04] <nxvl> what i've understand
[08:04] <imbrandon> one thing that we might ask the archive admins to do is not sign the -proposed repo, thus you always get a warning aobut unauthenticaed when installing something from there
[08:04] <imbrandon> ajmitch / StevenK / persia ^^
[08:04] <StevenK> imbrandon: If that is even possible.
[08:04] <persia> imbrandon: The main difference I see is that once we push to -proposed, we invite random testing from lots of willing update testing participants (who are a great help to our SRU process).  I'd rather at least verify we're not breaking something before asking their help.
[08:04] <imbrandon> that might help to with "this is testing ONLY" repo
[08:05] <nxvl> is to look at ubuntu.debdiff and the see if the changes are in debian.debdiff, am i on the right way?
[08:05] <imbrandon> nxvl, yup
[08:05] <imbrandon> StevenK, it should be , the PPA's are unsigned
[08:06] <nxvl> imbrandon: and the only way to that is inspection?
[08:06] <StevenK> Do not compare PPAs with the offical archive.
[08:06] <imbrandon> yes
[08:06] <StevenK> They are nothing alike.
[08:06] <persia> imbrandon: I'd rather have -proposed sign.  it makes it safer for the -proposed testing participants (who often catch possible regressions during the testing period)
[08:06] <imbrandon> StevenK, well they both use soyuz etc , point is its "possible"
[08:07] <persia> nxvl: Depending on the nature of the different patches, you may find diff comparison tools useful.
[08:07] <nxvl> persia: wich tools?
[08:08] <StevenK> nxvl: Tools such as diffstat, interdiff and filterdiff
[08:08] <nxvl> mmm
[08:08] <nxvl> i have never heard about they before
[08:08]  * nxvl googles
[08:09] <persia> nxvl: They are in the patchutils package
[08:09]  * Hobbsee --> work
[08:09] <imbrandon> ok so is persia's checklist ok for the ML or should we go streight to the wiki and then the ML ?
[08:10] <persia> imbrandon: Best would be to put a draft on the wiki, and discuss during the next MOTU Meeting, but that's weeks away.  I'd suggest a ML post (in a new thread) noting that the wiki will be updated in 2 days unless there is opposition.
[08:11] <imbrandon> sounds good to me, i'll draft an email then while i'm waiting on this kernel to build, dholbach you OK with that ?
[08:11] <imbrandon> ( or anyone else )
[08:11] <RAOF> ion_: With regard to hardware-connected on revu - you ship an exportsrc script in debian/.  (1) It's not executable, which would be nice, and (2) could you instead make that a get-orig-source target of debian/rules?  That'd be a bit more standard.
[08:12] <persia> imbrandon: Thanks for drafting it.
[08:12] <RAOF> ion_: Other than that it seems a pretty inoffensive package ;)
[08:14] <imbrandon> persia, np , i'm just glad we could come up with something other than geser on a cross :)
[08:14] <ajmitch> heh
[08:14] <StevenK> imbrandon: Why not both?
[08:14] <StevenK> :-P
[08:14] <imbrandon> lol
[08:14] <ajmitch> I'm sure it wouldn't have gone *quite* that far
[08:14] <persia> imbrandon: Nah.  We don't really want that.  Someone else would have to do his 200 uploads for hardy.
[08:14] <imbrandon> :)
[08:15] <ion_> raof: I don’t think there’s a way to make it executable. dpkg-source only makes debian/rules executable after applying the diff. exportsrc not only exports a tarball out of the upstream branch, but also exports a diff out of the packaging branch and builds a source package out of them. That’s a lot more than what get-orig-source would do.
[08:15] <ajmitch> persia: I'd say that StevenK would, but he probably doesn't want to add to the 3498 he's already got lined up
[08:15]  * persia thinks StevenK's fingers aren't fast enough to upload any more packages
[08:15] <ajmitch> persia: you think wrongly
[08:17] <ajmitch> persia: http://xkcd.com/208/ <-- stevenk with his mad skills
[08:17] <nxvl> it will be wonderfull if documentation about the diffutils will be on https://wiki.ubuntu.com/MOTU/Packages/Merging since it's kind of needed
[08:17] <nxvl> IMHO
[08:18] <StevenK> ajmitch: Muahaha
[08:18] <persia> ajmitch: Yep.  The missing .desktop finding script on the wiki is the result of such a vine swing.
[08:18] <StevenK> And I didn't even write it!
[08:18] <dholbach> imbrandon: sure
[08:19] <StevenK> (... or did I?)
[08:19] <imbrandon> ajmitch, hahahah classic
[08:19] <persia> nxvl: That page is actually going away soon, and the target page is expected to have such information.  Apologies for the inconvenience whilst we remodel.
[08:20] <persia> StevenK: It's copyright you.  If you didn't write it, someone else did, and assigned it to you.  (searh for "owal" on https://wiki.ubuntu.com/MOTU/Packages/DesktopFiles)
[08:20] <siretart> morning
[08:20] <ajmitch> hi siretart
[08:21] <imbrandon> heya siretart
[08:21] <persia> morning siretart
[08:21] <siretart> heyha ajmitch && imbrandon && persia
[08:21] <StevenK> Hrm. I think I did write it - it looks like my Perl
[08:26] <StevenK> I think I need a database to keep track of the Ubuntu work I do. :-)
[08:27] <nxvl> persia: wich target page?
[08:27] <ajmitch> would there be one big enough?
[08:27] <persia> StevenK: Does LP not provide enough guidance?
[08:28] <persia> nxvl: I forget exactly: it's listed in the header block for that page.  I suspect it will end up somewhere in PackagingGuide, but you'll do best to check.
[08:28] <StevenK> LP can tell me which packages I've touched, not if I've spent 20 mintes writing a script like that, or if I've looked at a bug for 2 hours and given up in disgust.
[08:28] <nxvl> persia: can it be https://wiki.ubuntu.com/MOTU/Merging?
[08:28] <persia> Ah.  Proper time accounting, etc.  You could be the first ISO9004 compliant contributor :)
[08:29] <nxvl> persia: well, the point is that i will we bonderfull if that docs are somewhere in there, cause they help a LOT
[08:29] <StevenK> persia: I don't so much care about time accounting, just what I've touched.
[08:30] <persia> nxvl: The page you've just referenced will be merged into UbuntuDevelopment.  Once the current reorganisation is complete, there will be a review, and missing things will be added.  Would you mind keeping track of anything you think is missing, and checking once the reorganisation is complete?
[08:31] <persia> StevenK: Ah.  I was thinking about the 20 minutes & 2 hours (although due to the customer providing constantly changing requirements, I believe the script actually took 2 or 3 hours)
[08:32] <nxvl> persia: ok, i will do it so, where should i ask for these tools to be included? motu list?
[08:32] <BugMaN> hi all! :)
[08:32] <nxvl> persia: or motu-mentors list
[08:32]  * persia is pleased to discover the excellent instructions on using lpbugs to painlessly use Malone to track merge coordination in MOTU/Merging.
[08:33] <persia> nxvl: I'd suggest that you look at the results of the merge once is is complete, and add the notes where you feel they are appropriate, in the wiki directly.  If you'd like assistance or review in preparing the best text, this channel is a good place to ask (at the time you are preparing the text)
[08:36] <nxvl> persia: ok, when i lern how this tools work i will :D
[08:36] <imbrandon> persia, StevenK, ajmitch, dholbach , email sent please make sure it actualy hits the ML , i cant rember what mail i subscribed to the list from ( i think imbrandon@kubuntu.org and thats where i sent from )
[08:37] <persia> imbrandon: you hit :)
[08:37] <imbrandon> kk thanks
[08:37] <warp10> Hi all!
[08:39] <nxvl> ok, so what i need to do is use diff stat to see what files have been modified on ubuntu.debdiff, then filter this files on debian.debdiff with filterdiff, and the compare the result of it with ubuntu.debdiff using filter diff, doesn't i?
[08:42] <persia> nxvl: That's one of many, many, many ways to do it.
[08:42] <nxvl> persia: it's the simple way?
[08:42] <nxvl> or it is simpler ways to do it?
[08:44] <persia> nxvl: I don't think there's a simple way.  Both MoM and DaD are attempts to make the process simpler, but both still require human oversight.  From a cognitive perspective, you want to understand the new Debian changes, understand the Ubuntu variation, and divine the appropriate ideal solution.
[08:45] <persia> To do this you might use diff, you might use patch, you might use lsdiff, or filterdiff, diffstat.  It's a matter of how you understand it most easily.
[08:46] <nxvl> mmmm
[08:46] <nxvl> ok
[08:46] <nxvl> i will try that way
[08:46] <nxvl> persia: thx
[08:46] <siretart> time accounting for ubuntu work seems interesting
[08:46] <siretart> what do people use in this channel for time accounting?
[08:47] <gnomefreak> how do i get dput to upload everything but tarball
[08:47] <imbrandon> hrm i have never actualy thought about doing it
[08:47] <imbrandon> gnomefreak, debuild -S -sd ?
[08:47] <gnomefreak> it doesnt seem to give me a choice
[08:47] <imbrandon> iirc
[08:47] <gnomefreak> ok ill try
[08:47] <nxvl> what i'm not clear about its to filter more than one file using filterdiff
[08:48] <imbrandon> i have lost many years to ubuntu packages, never thought about tracking it in any "offical" way
[08:48] <imbrandon> kinda intersting
[08:49]  * persia doesn't want to do time accounting for ubuntu: it makes it a less efficient agent of procrastination
[08:49] <persia> nxvl: I believe it takes any regular expression.
[08:49] <nxvl> persia: perl regular expresions or bash ones?
[08:50] <persia> nxvl: I don't remember.  `man filterdiff`
[08:50] <nxvl> k
[08:51] <nxvl> it doesn't say
[08:51]  * nxvl googles
[08:53] <nxvl> i think a script will be better and less waste of time
[08:58] <persia> nxvl: The problem with a script is that it doesn't do a very good job of getting the information into your brain (and the automated solutions aren't good enough to not receive human review).
[08:59] <nxvl> persia: not a fully process script
[08:59] <nxvl> i wrote this: for i in $(diffstat ubuntu.debdiff | cut -d" " -f2); do filterdiff -i '*'$i debian.debdiff >> debian_merged.debdiff ; done
[08:59] <nxvl> persia: so what it only does is to extract the changes in both debdiffs
[09:00] <persia> nxvl: Ah.  Makes sense.  Be careful: sometimes two changes in different places can affect each other.
[09:00] <nxvl> persia: what im looking for, is to see what files have been modified in the 2 of them and wich changes have been made in debian package
[09:01] <nxvl> persia: now i will read the result debdiff and ubuntu debdiff to see what changes i need to do by hand
[09:01] <nxvl> persia: i'm on the right way?
[09:01] <nxvl> s/i'm/am i/
[09:03] <persia> nxvl: That's certainly one way to do it.  Just be careful: sometimes two changes don't cause a conflict, but cause behavioural issues.  (e.g. Ubuntu adds a new dh_install line in debian/rules.  Debian creates a debian/install file, and adds information there).
[09:04] <pkern> Does anyone have a clue wrt svn-buildpackage?
[09:04] <nxvl> persia: i'm uploading the debdiff's so u can have a look, can u?
[09:05] <persia> nxvl: I don't have the environment available right now to verify: I'd only be able to give it a causal look.  You'd do better to subscribe the sponsors team for initial feedback.
[09:06] <nxvl> persia: i only want u to give a casual look to see if i'm on the right way, not to do the process with me
[09:07] <persia> nxvl: OK then.  Which bug?
[09:08] <nxvl> https://bugs.launchpad.net/ubuntu/+source/efax-gtk/+bug/155950
[09:08] <ubotu> Launchpad bug 155950 in efax-gtk "Please merge efax-gtk (3.0.15-1) from Debian unstable (main)" [Wishlist,Confirmed]
[09:09] <persia> nxvl: I don't see the debdiff.
[09:09] <nxvl> http://nvalcarcel.aureal.com.pe/stuff/debian.debdiff
[09:09] <nxvl> http://nvalcarcel.aureal.com.pe/stuff/debian_merged.debdiff
[09:09] <nxvl> http://nvalcarcel.aureal.com.pe/stuff/ubuntu.debdiff
[09:09] <nxvl> there they are
[09:09] <persia> nxvl: Which would be your candidate revision?
[09:10] <nxvl> i'm not quite sure about you are asking
[09:10] <nxvl> you meen the new debian version?
[09:10] <nxvl> ah ok
[09:10] <nxvl> wich of the 3 i want you to look at
[09:10] <persia> Which of those debdiffs represents your work towards a new merged Ubuntu revision?
[09:10] <nxvl> it would be debian_merged
[09:11] <nxvl> debian.debdiff is the resoult of comparing the old and new version of debian
[09:11] <nxvl> ubuntu.debdiff of the old debian and old ubuntu
[09:11] <nxvl> and debian_merged the result of my script
[09:12] <persia> OK.  First, it's best practice to make a debdiff against the current Debian package, to make it easy to review the Ubuntu variation.
[09:12] <persia> Second, you'll want a changelog entry indicating you merged the package
[09:12] <BugMaN> nxvl: i suppose you can change maintainer field also
[09:12] <persia> Third, you'll want to list all the remaining Ubuntu variations in summary in the changelog entry.
[09:13] <nxvl> mm
[09:13] <nxvl> ok, for First
[09:13] <persia> Fourth, when preparing a debdiff, you'll want to try to avoid the /tmp/9f8xh9 references: it should apply with patch -p0 or patch -p1 (required for native packages).
[09:14] <nxvl> i was following https://wiki.ubuntu.com/MOTU/Packages/Merging
[09:14] <persia> Fifth, as this is not against the Debian package, it's difficult to know if either the standard Ubuntu variations (e.g. maintainer field, etc.) are done, so this isn't a complete review.
[09:14] <nxvl> and there they make ubuntu and debian debdiff's with old debian, and new ubuntu and debian
[09:15] <nxvl> so conclusion my work so far with debdiff's is wrong
[09:15] <nxvl> k
[09:15] <nxvl> then i will start once again
[09:15] <persia> Right.  That page shows lots of different diffs.  I don't think you're wrong, just not yet familiar.
[09:15] <nxvl> persia: yes, that is what im thinking :D
[09:16] <persia> There's no need to start over.  Your last patch, applied to the Ubuntu version, may well generate something very close to the final result you seek.
[09:16] <nxvl> persia: i'm on learning process and beeing wrong most of the time is part of it
[09:16] <nxvl> persia: yes, but i'm not comfortable with "very close" i want it the right way
[09:17] <persia> You'll just want to follow the last step listed above "Another Approach to Merging", where it indicates you should run `debdiff debian-revision.dsc candidate-revision.dsc > candidate-revision.debdiff`, and use the results thereof to request review & sponsoring.
[09:17] <nxvl> ok
[09:18] <nxvl> first of all, i have made NO changes so far
[09:18] <nxvl> i'm only recolecting information to start working
[09:18] <persia> nxvl: very close is a good thing.  Items 1 & 5 are really about the debdiff source.  Items 2 & 3 are just a little extra work you need to do.  Item 4 is probably an artifact of the diff process.
[09:18] <nxvl> in other words, see what are the changes i need to apply
[09:18] <persia> nxvl: If you're only collecting information, you're doing the right thing.
[09:19] <nxvl> ok, i'm kind of confused, so let's start again
[09:19] <nxvl> i have those 3 debdiff
[09:20] <persia> OK.  Do you understand the changes the Debian maintainer made?
[09:20] <nxvl> ubuntu.debdiff correspond to old debian against new ubuntu
[09:20] <nxvl> debian.debdiff correspond to old debian against new debian
[09:21] <nxvl> and debian_merged.debdiff is the resoult of filtering the files listed with diffstat on the ubuntu.debdiff on the debian.debdiff
[09:22] <nxvl> what i want to do with debian_merged.debdiff is the compare it to ubuntu.debdiff and see wich of the changes made in ubuntu, was also made in debian
[09:22] <huats> morning everyone
[09:23] <nxvl> other whing is thar debian.debdiff has also the changes to the source, say in other words the upstream changes, din't it?
[09:24] <nxvl> s/whing/thing/
[09:24] <persia> nxvl: It looks like there was an upstream change (at least there was a change to the upstream changelog)
[09:25] <nxvl> persia: it is a new version so it MUST have an upstream change, otherwise there will be no new version, don't you think?
[09:25] <persia> In this case, you might want to look at the Ubuntu variation between the Ubuntu package and the Debian ancestor package, and then check to see if you need to keep any of the changes.
[09:26] <siretart> does anyone know Jonathan Nelson <ciasaboark@gmail...>?
[09:26] <nxvl> persia: ok, then you are talking about the ubuntu.debdiff
[09:27] <persia> nxvl: Right.  Logically break down the changes in ubuntu.debdiff, and then check to see if they should be applied to the new Debian revision.
[09:29] <nxvl> persia: ok, tha changes made by ubuntu where to fix an icon problem LP #108746
[09:29] <ubotu> Launchpad bug 108746 in efax-gtk "no icon in kde menu" [Wishlist,Fix released] https://launchpad.net/bugs/108746
[09:29] <nxvl> so i think it MUST be aplied
[09:30] <nxvl> and some other changes concerning these bug
[09:30] <nxvl> like a .desktop patch
[09:31] <persia> huats: Do you have any suggestions for nxvl on this merge (it being an update for your change)?
[09:32] <huats> oh
[09:32] <persia> nxvl: OK.  You've broken it down.  Do any of the upstream or Debian changes (in the changelogs) appear to address any of the issues?
[09:32] <huats> let me see what has been said before :-)
[09:33] <nxvl> persia: so, what you are trying to say is that i need to look on the upstream and debian changelog to see if there is a solution for these problems?
[09:34] <nxvl> persia: or in debian.debdiff?
[09:34] <persia> nxvl: More to see if there is an upstream or Debian change that would resolve any of the issues resolved by Ubuntu.  You can look either in the changelog or the debdiff (the debdiff is more reliable, but harder to read)
[09:35] <huats> persia and nxvl  I am listening :-)
[09:36] <persia> nxvl: huats made the the changes from that bug report, and may be able to share information about previous coordination with upstream and Debian.
[09:37] <nxvl> huats: ok, what i'm trying to do is to merge efax-gtk-3.0.15-1ubuntu1
[09:37] <huats> nxvl: ok
[09:37] <nxvl> huats: it's my first time doing the merge job, so i'm kind of lost
[09:37] <nxvl> huats: i have undestand the changes u have been made
[09:38] <huats> nxvl: ok so may be we can both learn since I never did a merge too :-)
[09:38] <nxvl> huats: so now i need to look if either upstream or debian have patch your changes to, didn't i
[09:38] <nxvl> well
[09:38] <nxvl> thats what i need to do
[09:39] <huats> nxvl: I think that is the good way to do indeed
[09:39] <nxvl> i need to see if the changes have been made in the new release or if i need to do them once again
[09:39] <huats> exactly
[09:39] <nxvl> ok
[09:39] <persia> huats: when you made the changes before, did you send a bug report or patch to Debian or to upstream?
[09:40] <nxvl> so what persia is asking for is to tell me/us about the coordinations with upstream/debian for these changes
[09:40] <huats> so you need to have a look in the upstream changelog and the debian changelog to see if anything corrects the issue that my previous patch corrects
[09:40] <nxvl> huats: yup
[09:42] <huats> regarding the changes upstream and debian, I have to admit that I had not done it yet.... I was planning to do it after the gutsy realease...
[09:42] <huats> and there you are...
[09:43] <persia> huats: No worries.  When there is a bug filed, it makes merging easy, as one can check the external bugtracker to see if the patch was applied.  On the other hand, this is a better example for learning.
[09:45] <nxvl> it seems debian haven't patch it, according to the changelog
[09:45] <nxvl> it olny says "  * Update debian/menu according to the new menu policy.
[09:46] <huats> ok
[09:46] <huats> so there is a part of my changes that has been done
[09:46] <nxvl> huats: did you made any changes to debian/menu?
[09:46] <huats> nxvl: yep
[09:47] <nxvl> the debian/menu is the conflict package
[09:47] <huats> I quote the ubuntu changelog "* Modify debian/menu in line with new menu hierarchy"
[09:47] <nxvl> ok, the problem here is
[09:48] <nxvl> in debian it has: Applications/Network and in ubuntu Applications/Network/File Transfer
[09:49] <nxvl> so i think i need to keep the ubuntu one
[09:49] <nxvl> doesn't i?
[09:50] <huats> http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.2
[09:50] <huats> it is the doc for the menu spec
[09:50] <huats> so indeed I think the ubuntu one is the right noe
[09:50] <huats> and you can send that to debian as well...
[09:51] <persia> Specifically, it says for 'Network' "This is a three-level section, do not put entries directly here."
[09:52] <huats> persia: so I was right ?
[09:52] <nxvl> persia: so i need to put it in File Transfer
[09:52] <persia> huats: nxvl: Yes (to both questions)
[09:52] <nxvl> :D
[09:53] <huats> :-)
[09:53] <nxvl> k
[09:53] <nxvl> editing the changelog
[09:53] <persia> nxvl: Remember: you want to add to the changelog, not edit it.
[09:55] <norsetto> goooooooooooooooooooood morning
[09:55] <Lamego> hello
[09:55] <nxvl> persia: i'm editing it, since the las entry is from Merge-o-Matic and it explicit says to edit it
[09:56] <nxvl> norsetto: good morning, im almost done with efax-gtk
[09:56] <huats> norsetto: morning  my favorite italian guy
[09:56] <persia> nxvl: Ah.  That's safe then.
[09:56] <norsetto> hey nxvl, how is it with the merging?
[09:56] <dholbach> heya norsetto, hey lam
[09:56] <dholbach> lamego :)
[09:56] <norsetto> hiya dholbach
[09:56] <Lamego> dholbach, :)
[09:57] <nxvl> norsetto: im, now building
[09:57] <huats> do we have to merge file-roller ? in merge.ubuntu.com it is version 2.20.0-1 and I know that we have 2.20.1 in gutsy-proposed....
[09:57] <nxvl> norsetto: i'm done with tha changes, persia help me A LOT
[09:57]  * nxvl hugs persia 
[09:57] <norsetto> nxvl: good, was it difficult?
[09:58] <imbrandon> brb
[09:58] <persia> huats: We will likely want to do so.  MoM doesn't track -proposed, but the new file-roller should soon go to gutsy, and it will show up on MoM then.
[09:59] <persia> nxvl: While it's building, could you post the debdiff for huats and I to review?
[09:59] <Lamego> someone to look at bug 155314 for universe sponsorhsip ?
[09:59] <ubotu> Launchpad bug 155314 in twinkle "Unable to authenticate with SIP server" [Undecided,New] https://launchpad.net/bugs/155314
[09:59] <nxvl> norsetto: the changes where on my face, but i didn't see them cause i't was a lot of info coming to my head (the merging process + th changes)
[09:59] <nxvl> persia: what debdiff?
[09:59] <persia> nxvl debdiff between current Debian and target Ubuntu (the one you're building)
[09:59] <norsetto> nxlv: well, its your first one, you will see thats gonna be easier and easier for the next
[10:00] <huats> persia: so we'll merge it once -proposed appears right ?
[10:00] <persia> Lamego: Nothing to do right now: we're still waiting for the toolchain to settle for hardy uploads.  Apologies for the delay.
[10:00] <nxvl> persia: ok
[10:00] <persia> huats: Once hardy is open for general uploads.
[10:00] <norsetto> persia, huats, nxvl: did you guys decide something about the menu entry?
[10:01] <persia> norsetto: huats quoted Debian policy showing the Debian is buggy :)  nxvl is planning on filing a bug.
[10:01] <huats> :-)
[10:01] <norsetto> persia: devil huats :-)
[10:01] <nxvl> i will generate the .dsc file and the upload the debdiff
[10:01] <Lamego> persia, it's for gutsy-proposed
[10:01] <huats> norsetto: you showed me the doccumentation, it is your fault
[10:02] <persia> Lamego: Ah.  Sorry.  That's not clear from the report.  I'd suggest adding [SRU] to the bug title, and subscribing motu-uvf for approval (as usually we need the fix in the development release prior to posting to -proposed).
[10:02] <huats> norsetto: and I am quite sure you said "the holly reference" or something like that...
[10:03] <Lamego> persia, i have followed the SponsorShi process described on the Wiki :)
[10:03] <norsetto> huats: do we have a new lintian in gutsy? I remember seeing something, but that perhaps was linda
[10:03] <Lamego> none of your recommendations are described there :)
[10:03] <persia> Lamego: You followed it perfectly.  Unfortunately, we're in a strange sort of post-release freeze right now, so it's a little complicated (see #ubuntu-motu /topic).
[10:03] <Lamego> and why do you need it fixed on development, if develpment is not yet available :) ?
[10:04] <norsetto> huats: because that kind of things should be catched by lintian
[10:04] <persia> It's the policy.  It doesn't actually work for about 4 weeks every year, but we've not revised it sensibly.  Apologies for the confusion.
[10:04] <huats> norsetto: I think there is a new lintian
[10:04] <Lamego> argh, why do you keeping creating freezes an interim processes, despite of the well established documentation ?
[10:04] <huats> I can remember that some stuff were ok with the one on feisty and ko with the gutsy one....
[10:05] <norsetto> huats: well, I don't know if it covers the menu change still, gotta check the changelog
[10:06] <Lamego> persia, what is the reasoning for this post-release freeze ?
[10:06] <persia> Lamego: The documentation is at fault.  The ~2 week wait for archive open whilst the toolchain settles is old: we just keep forgetting to write it down.  I believe this is the first time we have a functioning freeze exception process for post-release: in the past it's been even worse.
[10:07] <nxvl> persia: https://bugs.launchpad.net/ubuntu/+source/efax-gtk/+bug/155950
[10:07] <ubotu> Launchpad bug 155950 in efax-gtk "Please merge efax-gtk (3.0.15-1) from Debian unstable (main)" [Wishlist,Confirmed]
[10:07] <persia> Lamego: The toolchain is bootstrapping (compilers, linkers, interpreters, etc.).  Once that becomes stable (should be soon), everything else gets pumped in and built.  If this freeze wasn't here, lots of things would FTBFS for no good reason.
[10:07] <nxvl> persia: posted the debdiff
[10:07] <nxvl> norsetto: i posted the debdiff, can u check it please
[10:07] <persia> huats: Do you see anything missing there?
[10:08] <huats> I have a look
[10:08] <norsetto> huats: no, it will not be cactched by our lintian, its even before policy change
[10:08] <Lamego> persia, you are talking about development, I am talking about current, the ~2 week after the release is the peridod on which you are more likely to get bugs reported by "non-development" users
[10:08] <nxvl> lintian says there are no commmon mistakes on mi dsc \o/
[10:09] <persia> Lamego: Yep.  That's why I'm so happy we have the motu-uvf workaround for this release.  The last couple were less pleasant, and there were no universe updates for a bit.
[10:09]  * nxvl wonders where have he left the cigarretes :S
[10:09] <Lamego> uff, doesn't uvf stand for upstream version freeze ?
[10:10] <Lamego> why do I need an uvf team to review a 4 lines patch :) ?
[10:10] <norsetto> nxvl, huats: ok, lets wait what huats will say
[10:11] <persia> Lamego: Yes, UVF stands for Upstream Version Freeze.  The reason this team is handling it is that we didn't have time to elect a new team prior to the implementation of the new process, and the members of that team volunteered to help with post-release processing.
[10:11] <Lamego> ok, I will wait for 2 weeks
[10:11] <Lamego> if someone looks at it, and I personally don't forget it also :P
[10:11] <persia> Lamego: OK.  If it's important, you could subscribe the team, and they'll probably hit it in a few days.
[10:12] <Lamego> ok, I will try
[10:13] <huats> persia norsetto  nxvl  as far as I see it is great
[10:13] <norsetto> huats: think again ......
[10:13] <persia> nxvl: huats: A few things about this candidate:
[10:13] <norsetto> huats, nxvl: I see few things which need to be corrected
[10:14] <persia> 1)  The Debian maintainer uses a different patch system than the Ubuntu variation.  We should extract the dpatch, and use the Debian maintainer's patch system.
[10:14] <huats> I'll have second look
[10:14] <persia> 2)  The debdiff is full of config{sub,guess}.  We should consider moving the refresh from the clean rule to the configure rule
[10:15] <persia> 3) The latest changelog entry doesn't specify all the changes retained / dropped clearly
[10:16] <huats> ok
[10:17] <huats> so the 3) I didn't know that we were allow do this kind of stuff :-)
[10:17] <huats> sorry I meant the 2)
[10:18] <norsetto> huats: for 2), for sure you need to clean manually your debdiff, but as persia said, its the fault of the DD package, not yours
[10:18] <huats> regarding the 3) it is the first merge I see, but indeed it appears important to rewrite the changes done ....
[10:18] <persia> huats: There are no limits to what we are allowed.  The more we vary from Debian, the more we take direct responsibility for the results.  As there are around 15,000 packages, we make efforts to match Debian policy as closely as possible to reduce this responsibility for each packge.
[10:19] <nxvl> ok
[10:19] <huats> ok
[10:19] <nxvl> let's go step by step, starting with 1)
[10:19] <norsetto> huats, persia, nxvl: please consider as well that this is for hardy, not gutsy (check the distribution in changelog)
[10:19] <nxvl> persia: where have yoo see it
[10:20] <huats> norsetto: I remember that you asked me to clean by hand every debdiff for flightgear
[10:20] <huats> :-)
[10:20] <norsetto> huats: yes, when you ask for a sponsor your debdiff _MUST_ only contains the relevant changes, no cruft added
[10:20] <huats> to remove the config{sub, guess}
[10:20] <nxvl> norsetto: fixed
[10:21] <huats> nxvl: you have clean by hand you debdiff ?
[10:21] <persia> nxvl: The quick and easy way to check is to do `lsdiff -z foo.diff.gz`  When there are entries in debian/patches, keep them there.  When there are not, if there are changes outside debian/ in diff.gz, make changes outside debian.  When debian/patches is empty and there are no changes outside debian/ in diff.gz, you may select a patch system.
[10:21] <nxvl> huats: am working on it
[10:21] <huats> it is useless to do that before you have finished to fix everything else
[10:21] <huats> it is the last thing to to
[10:22] <huats> to do
[10:22] <huats> since it'll be regenerated
[10:22] <nxvl> mm
[10:22] <nxvl> your right
[10:23] <huats> nxvl: start with the 1) point as persia points out
[10:23] <norsetto> huats: didn't I ask you to forward this to Debian? I usually did
[10:24] <huats> I am not sure that you were the one who uploads it...
[10:24] <huats> may be
[10:24] <huats> and as I said , I had planned to forward a  few fixes to debian after gutsy .... sorry....
[10:24] <nxvl> persia: u mean efax-gtk_3.0.15-1ubuntu1.diff.gz?
[10:25] <persia> nxvl: Yes.  In that case "foo" was to be replaced by "efax-gtk_3.0.15-1ubuntu1"
[10:25] <nxvl> ok
[10:25] <nxvl> so, i see many files, an there is some in debian/patches
[10:25] <persia> Er..  Rather "efax-gtk_3.0.15-1", as we want to determine how the Debian maintainer is managing patches.
[10:26] <huats> :-)
[10:26] <nxvl> k
[10:26] <nxvl> so, there are some files but there is no debian/patches
[10:27] <persia> nxvl: Files outside debian/ ?
[10:27] <nxvl> persia: yes 7 of them
[10:28] <persia> OK.  That means that the Debian maintainer does not use separated patches.  I don't think this is best practice for package maintenance, but some people do.  In the hopes that we can eventually merge everything back so we're not responsible for efax-gtk, we'll need to extract the dpatch, and apply it directly.
[10:29] <nxvl> mm
[10:29] <norsetto> persia: as you know, there we disagree, especially since we should teach good practices to new packagers, not just cope with DD bad practices
[10:30] <nxvl> that means patch by hand and remove the patches?
[10:30] <persia> nxvl: Yes.
[10:30] <nxvl> ok
[10:30] <norsetto> persia, nxvl, huats: I do think we should keep the patch system
[10:30] <nxvl> ok
[10:30] <persia> norsetto: Yes.  We disagree on this.
[10:30] <nxvl> now we have come to disagreements
[10:31] <nxvl> lets get to a middle point
[10:31] <persia> The argument in favor of keeping the patch system is that it makes it lots easier to add / remove patches when needed.
[10:31] <norsetto> persia: we disagree strongly, I will never excuse DD bad practices
[10:31] <persia> The argument against keeping the patch system is that it makes it impossible to merge back to Debian.
[10:32] <norsetto> persia: which is weak, because these changes should be merged back into debian
[10:32] <persia> norsetto: My largest objection is that a package should never, ever use two different patch systems simultaneously.  If we are to use a patch system, we should extract all the patches in the diff.gz, and place them in dpatches.  Having patches in both is likely to cause annoyance.
[10:32] <norsetto> persia: agreed, but in this case the package do NOT use a patch system
[10:33] <norsetto> persia: this is the difference, I do not consider inline as a patch system, its just crap
[10:33] <nxvl> can we take diff.gz and separate patches?
[10:33] <persia> norsetto: If we follow the Debian maintainer's practice, a patch to merge the changes back becomes available on packages.qa.debian.org.  If we install a second patch system (with entirely unpredictable results), the Debian maintainer will sensibly refuse to accept a clearly broken patch.
[10:34] <norsetto> persia: again we disagree, we should not enforce our choice, in this case we simply give back the .desktop file
[10:34] <persia> nxvl: Yes.  If you do so, you end up with a very nice package, that both norsetto and I would endorse.  On the other hand, it is a lot of work, and you will need to accept responsibility for keeping it up to date.
[10:34] <persia> norsetto: Huh?  If we're not enforcing our choice, why not follow heirs?
[10:34] <nxvl> persia: ok, so lets continue making a decision, tu much responsability for a new packager
[10:35] <nxvl> s/tu/to
[10:35] <norsetto> persia: we do use it for our revision, because thats the right thing to do
[10:35] <norsetto> persia: I don't see the need, and 99% is worng, to pass them our debdiff
[10:36] <norsetto> persia: thats the problem, you see it as our duty to enfore our choice, which I don't, we do our bit the correct way, and ask them to merge the changes back their way
[10:37] <nxvl> im agree with norsetto, it's better to do it the right way and ask DD to make it too
[10:38] <norsetto> nxvl: I think this is the only point were persia and I will keep disagreeing for the centuries to come :-)
[10:38] <nxvl> heh
[10:38] <nxvl> so, lets forget about 1) and continue with 2)
[10:39] <huats> nxvl: I think thet 1) is the main pb here...
[10:40] <nxvl> huats: but, 1) is a debian problem
[10:40] <nxvl> huats: the problem in 1) is that the DD made it the wrong way
[10:40] <nxvl> norsetto: i'm i right?
[10:40] <huats> :-)
[10:41] <nxvl> 4:40 on the morning i need to get some sleep
[10:41] <nxvl> i have class at 11 am, and the ubuntu Open Week speaches start at 10 am
[10:42] <persia> nxvl: There are arguments both ways about it.  Norsetto and I agree that the method used by the DD isn't preferable, but it's not really correct to call it "wrong".
[10:42] <nxvl> persia: ok, sorry about that
[10:42] <nxvl> mmm norsetto hase gone
[10:43] <norsetto> crappy rt2x00 module
[10:43] <nxvl> persia, norsetto: i really need to sleep i need to wake up un 4 hours, can u get into a decicion and let me know it by LP or e-mail so i can continue working these tomorrow?
[10:43] <nxvl> s/un/in
[10:44] <persia> norsetto: Anecdotally, I've had quite a few Debian maintainers merge my debdiffs.  Also, I argue that two patch systems is far worse than any chosen method (including sed scripts called from debian/rules)
[10:44] <nxvl> s/these/on these/
[10:44] <norsetto> persia: agreed, totally agreed, were we disagree is that the lack of a patch system IS a patch system
[10:44] <persia> nxvl: We're both officially correct, and other sponsors may disagree with either of us (we're both fairly strict about things).
[10:45] <persia> norsetto: What?  diff.gz, no?  All the patches can be extracted with filterdiff.  It's fairly annoying, and stores very little meta-data, but the upstream codebase is still pristine.
[10:45] <nxvl> persia: i know that, BUT what sould i do? do it your way or norsetto's way?
[10:45] <persia> nxvl: You should do it your way.  Either of our ways is likely acceptable.
[10:46] <norsetto> persia: I call a cat a cat
[10:46] <persia> norsetto: Yep.  Me too.  But I don't complain when people talk about felines.
[10:46] <norsetto> persia: and you know what is the policy about the .diff.gz, eh?
[10:46] <nxvl> i will contact the debian maintainer and discuss with him about that, i will try to change everything to the right way
[10:46] <persia> norsetto: It must contain all differences from upstream.  It should not contain changes outside debian/.
[10:46] <nxvl> s/right/best/
[10:47] <persia> nxvl: That's a perfect goal.  That sort of coordination results in the best quality packages for both Debian and Ubuntu.
[10:47] <nxvl> ok, so i will send an e-mail right now
[10:48] <persia> nxvl: Don't forget to also file the bug about the menu file.
[10:48] <nxvl> norsetto: despide on 1) what more are you disagree with? i mean on what sould i keep working
[10:48] <nxvl> persia: yes, i will, tomorrow
[10:48] <nxvl> :D
[10:49] <norsetto> nxvl: I didn't see anything else, was quite a good job :-)
[10:50] <nxvl> norsetto: thanks
[10:50] <huats> nxvl: you did a great work...
[10:51] <norsetto> also huats was a good help ;-)
[10:51] <norsetto> and thansk to persia for his good job too !
[10:51] <nxvl> norsetto: so, in your point of view, and dispide the disagreement, it is ready for being uploaded (we will not do that until i came to a decicion with the DD, but just to know how do i did it)
[10:51] <huats> nxvl: and with norsetto and persia you had 2 MOTU who are really nice with new contributors...
[10:51] <nxvl> huats: thnx
[10:51]  * norsetto hugs everybody
[10:51]  * huats too
[10:52]  * nxvl hugs everyone too
[10:52] <nxvl> grupal hug!!!
[10:52] <nxvl> :D
[10:52] <nxvl> y really love FS
[10:52] <persia> nxvl: There are a couple small points: #2 means you either need to run filterdiff, or move the config.{sub,guess} calls in debian/rules.  #3 is just note taking, and be sure to target hardy for the upload.
[10:53] <huats> persia:  nxvl  3) was to report the changes you merge in the changelog
[10:54] <persia> Right.
[10:54] <huats> the hardy target was supposed to be 4)
[10:54] <huats> :-)
[10:54] <nxvl> mm
[10:54] <nxvl> but
[10:54] <nxvl> the changes I made
[10:55] <nxvl> was only to edit the debian/menu
[10:55] <persia> nxvl: You'll want to record all the changes you made to the Debian package, which includes all the other changes you inherited from huats.
[10:55] <nxvl> and point 2) i don't find it on debdiff
[10:56] <nxvl> persia: ok, i undestand, so i will need to say "merge changes for revision #"?
[10:57] <persia> nxvl: You'll want to list the specific changes, so that the next person who is working on the package can see all the Ubuntu changes without going through the entire changelog.
[10:57] <persia> nxvl: I see config.guess starting from the first line of http://launchpadlibrarian.net/10126369/efax-gtk_3.0.15-1ubuntu1.debdiff
[10:58] <nxvl> persia: config.sub should be removed too?
[10:59] <persia> nxvl: Yes.  Personally, I like to remove them by moving the cp call to the configure: rule, but filterdiff satisfies most sponsor's requirements.
[11:00] <nxvl> persia: remove line 61 and 64 from debian/rules ?
[11:00] <persia> nxvl: I'm not actually following along here :)  Could you pastebin debian/rules for me to answer that?
[11:01] <nxvl> ok
[11:03] <nxvl> persia: http://nvalcarcel.aureal.com.pe/stuff/rules
[11:04] <persia> nxvl: No.  We need those to build.  I tend to move it up in the rules file (to around line 38), but filterdiff is also acceptable.
[11:04] <persia> (umm... "it" refers the the both stanzas between lines 60 and 65 inclusive)
[11:07] <huats> just an opinion on bug 151554
[11:07] <ubotu> Launchpad bug 151554 in webkit "libwebkitgtk0d" [Undecided,New] https://launchpad.net/bugs/151554
[11:08] <huats> is there something top do ? or will it be done automatically with the sync from debian ?
[11:08] <nxvl> persia: http://launchpadlibrarian.net/10126656/efax-gtk_3.0.15-1ubuntu1.debdiff
[11:08] <nxvl> persia: liek that?
[11:09] <persia> huats: That should be autosync'd from Debian shortly after the archive opens.  There may be a need to merge changes from the old libwebkitgdk package (that needs investigation).  I'd recommend watching the package sync when it starts, and processing a merge if you think it's required.
[11:09] <huats> persia: ok
[11:09] <nxvl> persia: sorry, dont open it, im kind of sleep
[11:09] <nxvl> persia: its the same debdiff
[11:09] <huats> that was my opinion too... happy to see it is your too
[11:10] <huats> do we know when the sync will be ?
[11:10] <persia> huats: Current best guesses are available from the Hardy Release Schedule on the wiki, although this schedule is subject to change based on UDS.
[11:10] <nxvl> persia:
[11:10] <nxvl> persia: http://launchpadlibrarian.net/10126685/efax-gtk_3.0.15-1ubuntu1.debdiff
[11:11] <huats> persia: ok
[11:11] <persia> OK.  Changelog needs to include the specific changes, not just reference a previous version.
[11:11] <nxvl> persia: so, u are saying to rewrite them?
[11:11] <nxvl> persia: but there are in the chagelog
[11:12] <persia> I still see "diff -u efax-gtk-3.0.15/config.guess efax-gtk-3.0.15/config.guess" at the top.  I'm not sure why.
[11:12] <persia> You need to repeat them.  You may summarise.
[11:12] <nxvl> me niether
[11:12] <nxvl> persia: o
[11:12] <persia> ("them" refers to changelog entries)
[11:12] <nxvl> persia: but, it's in there, but with no changes
[11:12] <nxvl> persia: yes, i know
[11:13] <nxvl> ok, removed lines 1 and 2
[11:13] <persia> nxvl: Even so.
[11:13] <nxvl> tomorow i will write to DD, fill the bug and correct changelog
[11:13] <persia> I'm still not happy about dpatch, but 1) I'm not the only sponsor around, and 2) you're planning to contact the DD
[11:13] <nxvl> now i need to sleep
[11:14] <persia> Other than that, it looks fine.
[11:14] <nxvl> persia: yes, that part will be fixed after contacting the DD
[11:14] <nxvl> persia: thnx
[11:14] <nxvl> persia: *HUGS*
[11:14] <persia> good night nxvl
[11:14] <nxvl> huats: *HUGS*
[11:14] <nxvl> norsetto: *HUGS*
[11:14]  * dholbach hugs y'all :)
[11:15] <nxvl> persia: heh, it will be good morning since its 5 o clock and the sun is rising
[11:15] <nxvl> :P
[11:15] <norsetto> huats: Bug 151554 is just a sync (note the package version). You can easily check the changelog too (https://launchpad.net/ubuntu/+source/webkit/)
[11:15] <ubotu> Launchpad bug 151554 in webkit "libwebkitgtk0d" [Undecided,New] https://launchpad.net/bugs/151554
[11:16] <persia> norsetto: Does it even need ubuntu-archive attention?  I think it will be automatic.
[11:16] <norsetto> persia: yes, it should be auto-synced
[11:20]  * norsetto hugs dholbach
[11:20]  * dholbach hugs norsetto back :)
[11:20]  * norsetto finds dholbach huggable, must be all that hair
[11:21] <dholbach> . o O { hair? }
[11:22] <norsetto> dholbach: everything is relative, everybody is hairy wrt me ;-)
[11:22] <ion_> O . o { hair? } would be valid Ruby code.
[11:22] <dholbach> ion_: that's not what I aimed for ;-)
[11:22] <persia> ion_: Why not '. o O { hair? }' ?
[11:23] <ion_> persia: ‘. o’ is a syntax error.
[11:23] <persia> (calling a method of the implicit object with an argument which is an inherited function with an argument that takes a single block as an argument)
[11:23]  * norsetto head is spinning
[11:23] <persia> Ah.  Right.  Space.  Grr...
[11:23] <persia> .o O { hair? }
[11:23] <ion_> persia: Well, ‘.o’ is a syntax error. :-)
[11:24] <dholbach> norsetto: don't worry - mine too :)
[11:25]  * dholbach -> lunch
[11:25] <persia> ion_: I was sure that could be used against the implicit object, but I can't duplicate now.  perhaps an exercise for tomorrow :)
[11:25] <ion_> persia: plain ‘o’ sends :o to ‘self’.
[11:25]  * norsetto feeds the cats
[11:26] <persia> ion_: Right.  I was thinking something like:
[11:26] <persia> def foo
[11:26] <persia> "Hello"
[11:26] <persia> sort
[11:26] <persia> end
[11:26] <persia> sort is called on "Hello" (which doesn't really do anything).
[11:27] <ion_> Sorry, it isn’t. :-)
[11:27] <ion_> That’s equivalent to def foo; "Hello"; self.sort; end
[11:27]  * persia imagines there is probably a way to override the meaning of . within the conext of a block, but is unwilling to try at this time
[11:28] <ion_> You can any_object.instance_eval &block
[11:28] <ion_> That way the block sees ‘self’ as the any_object.
[11:34] <huats> huats -> lunch
[11:50] <siretart> dholbach: thank you very much for your last email to ubuntu-motu@l.u.c
[11:56]  * norsetto hugs siretar
[11:57] <norsetto> guys be aware, I'm in a hug mood, stay clear if you don want to be hugged
[11:58] <proppy> ohayo
[11:58] <norsetto> dakoo-ta
[12:00] <proppy> norsetto: howdy ?
[12:01] <norsetto> proppy: can you come closer?
[12:01] <proppy> norsetto: yep np my times is yours
[12:01]  * norsetto hugs proppy!
[12:01] <proppy> :)
[12:02] <norsetto> proppy: so, how is it going with viewvc
[12:02] <proppy> norsetto: let me check in which state is it
[12:02] <proppy> norsetto: btw, did you log on root@lp152438.aminche.com ?
[12:02] <proppy> norsetto: or was is useless ?
[12:03] <norsetto> proppy: should I log on there?
[12:03] <proppy> If you want to check/debug/code on this bug, you can
[12:04] <proppy> I added your ssh keys
[12:05] <proppy> but you don't really have to :)
[12:09] <proppy> norsetto: the last change I've done is to fix viewvc-template script, not to add template_dir option if it's already here
[12:09] <proppy> norsetto: changeset here http://hg.lp152438.aminche.com/rev/843c8bf25841
[12:09] <proppy> norsetto: list of changes here http://hg.lp152438.aminche.com/
[12:10] <proppy> norsetto: so next is to put viewvc-template in the debian directory, call it from postin, and generate a debdiff ?
[12:13]  * siretart hugs norsetto back
[12:14]  * proppy hugs norsetto back
[12:18] <norsetto> proppy: sorry, I had a little issue here, let me check
[12:19] <norsetto> proppy: you keep shooting changelogs at me :-)
[12:20] <norsetto> proppy: didn't we agree last time that you were testing the script with a feisty->gutsy upgrade and then sending it to the DD?
[12:22] <proppy> norsetto: I should have put this somewhere not to forget about it :)
[12:23] <norsetto> proppy: whats the pass for root@lp152438.aminche.com?
[12:23] <proppy> norsetto: wait it is on http://lp152438.aminche.com/ wiki I've no excuse :)
[12:23] <proppy> norsetto: ssh root@lp152438.aminche.com -p 1622
[12:23] <proppy> norsetto: there is not pass, you're private keys should work
[12:23] <proppy> s/not/no
[12:25] <norsetto> proppy: its empty ....
[12:25] <proppy> norsetto: what is empty ?
[12:25] <proppy> norsetto: go in /home/www
[12:29] <norsetto> proppy: looks good
[12:29]  * norsetto wonders what reaction the DD will have at this
[12:29] <proppy> norsetto: I was thinking about adding the viewvc-template in the package
[12:30] <proppy> norsetto: and ship a debdiff to the DD
[12:30] <norsetto> proppy: the viewvc-template is the script which is called by the postinst?
[12:30] <proppy> norsetto: you mean what reaction the DD will have to the script or to lp152438.aminche.com ?
[12:30] <proppy> norsetto: which is to be called by the postinst
[12:31] <norsetto> proppy: to your work
[12:31] <proppy> norsetto: but I just noticed that the package do install viewvc-config to /usr/lib
[12:31] <proppy> norsetto: and then call it from post.inst
[12:31] <norsetto> proppy: yes, then you must add it in the package
[12:31] <proppy> norsetto: I don't feel confortable to install viewvc-template to /usr/lib
[12:32] <norsetto> proppy: the idea was to 1) file the dug about the upograde failing in Debian 2) attach the solution (adding the # and template_dir) 3) propose your script as a possible solution to 2)
[12:33] <norsetto> proppy: before going further, it might well be a waste of time continuing
[12:33] <norsetto> proppy: just test your script in the fesity-gutsy upgrade and see if it solves the issue
[12:33] <proppy> norsetto: what about reproducing the bug in debian ?
[12:34] <norsetto> proppy: actually, the best would be to have a sid chroot, install viewvcs and then upgrade to viewvc
[12:35] <norsetto> proppy: I'm going for lunch now, need some food to shred
[12:35] <proppy> norsetto: me too
[12:35] <proppy> norsetto: installing the debian chroot :)
[12:35]  * norsetto is going to kill some cheese and a sausage too
[12:36] <norsetto> proppy: see u later then, (A+)
[12:36] <proppy> norsetto: A_
[12:36] <proppy> +
[12:45] <fernando> moin all
[12:46] <StevenK> norsetto_limbo: You can't kill cheese.
[12:48] <markvandenborre> please have a look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/55646
[12:48] <ubotu> Launchpad bug 55646 in xorg "video playback problem on external monitor" [Undecided,Confirmed]
[12:48] <markvandenborre> I don't have the necessary hardware anymore to do anything about this
[12:48] <markvandenborre> and I'm not sure if this is still relevant with recent advances in X
[12:49] <markvandenborre> I want to act responsibly on the bugs I report
[12:49] <markvandenborre> is there anything I can do about this?
[12:54] <markvandenborre> same thing for https://bugs.launchpad.net/ubuntu/+source/gstreamer/+bug/43699
[12:54] <ubotu> Launchpad bug 43699 in gstreamer "totem-gstreamer dvd://01 refuses to play" [Medium,New]
[12:54] <markvandenborre> relevant hardware and software not available anymore
[12:54] <markvandenborre> hi EtienneG !
[12:56] <EtienneG> markvandenborre, my most best craziest MOTU pal !
[12:56] <markvandenborre> :)
[12:57] <EtienneG> what are you up to these days ?
[13:22] <ScottK> Good morning all.
[13:22] <ScottK> Looks like you all had "fun" whilst I was sleeping.
[13:24] <huats> ScottK: morning
[13:24] <ScottK> Hello huats.
[13:24] <StevenK> ScottK: ... Indeed.
[13:27] <cosmodad> hi all -- I've been doing quite some Debian packaging in the past and would like to build a Deb package for Ubuntu.
[13:27] <cosmodad> Question: How do you usually start off? Use a Debian src-rep, get the source and do the port?
[13:28] <cosmodad> If this is the wrong channel to ask this question (#ubuntu-dev seemed unappropriate), please let me know with a proper referal.
[13:28] <proppy> hello ScottK
[13:29] <ScottK> hello proppy
[13:29] <ScottK> cosmodad: Packages that are already in Debian get automatically synced.
[13:30] <persia> cosmodad: This is exactly the right place.  If the package is already in Ubuntu, you'd do better starting off with the Ubuntu source repositories.  If a package is already in Debian, wait a few weeks.  If the package is somewhere else, the procedure you describe sounds appropriate.
[13:30] <ScottK> Most of what we do here is package stuff that isn't in Debian yet (and often then push it into Debian) or deal with changes needed for differences between Ubuntu and Debian.
[13:30] <cosmodad> ScottK: precisely, I'd like to re-package uswsusp since Gutsy's version doesn't include s2ram.
[13:30]  * persia points at a few hundred Ubuntu local packages
[13:30] <ScottK> cosmodad: Does the version in Debian?
[13:30] <cosmodad> ScottK: yes.
[13:31] <persia> cosmodad: That was pulled intentionally.  Apparently it doesn't make sense with the Ubuntu kernel.  Have you been having success with it on an Ubuntu system?
[13:32] <cosmodad> persia: I used s2ram successfully on my machine using Feisty, and so did a lot of other people.
[13:33] <persia> cosmodad: from what I can see, it was pulled for Gutsy on August 20th.  I'm not certain of the reason.
[13:34] <cosmodad> persia: the changelog isn't very elaborate on this ("Don't build s2ram. It's not sensible on Ubuntu."), but numerous people have reported it worked fine, so I wanted to give it a try.
[13:34] <cosmodad> persia: it might possibly be a political reason to support a different suspending scheme, but this is the only one that works for me.
[13:35] <persia> cosmodad: Probably the easiest way is to pull the uswsusp source from Ubuntu and unroll the last change (patches are available from patches.ubuntu.com if reverting is not obvious).
[13:36] <cosmodad> persia: I'd prefer another upgrade to the latest version. Would you consider it easier/quicker to do the patch reversal and upgrade afterwards instead of re-Ubuntunizing the Debian package?
[13:36] <cosmodad> with the latter being at the up-to-date version already.
[13:36] <cosmodad> that is, the Sid package.
[13:37] <norsetto> morning ScottK
[13:37] <ScottK> Heya norsetto.
[13:37] <persia> Actually, yes.  re-Ubuntuizing the Debian package leaves you with no automated reversal.  reverting the last upload (patch -r) quickly gives you an Ubuntuised version with s2ram, from which you can alter the Debian revision.
[13:38] <persia> cosmodad: If you haven't already, I'd suggest you look at some of the Merging pages on wiki.ubuntu.com, which contain a couple of different methods for processing a merge (in this case, between the reverted Ubuntu package and the new Debian package)
[13:39] <markvandenborre> please have a look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/55646
[13:39] <ubotu> Launchpad bug 55646 in xorg "video playback problem on external monitor" [Undecided,Confirmed]
[13:39] <markvandenborre> I don't have the necessary hardware anymore to do anything about this
[13:39] <markvandenborre> and I'm not sure if this is still relevant with recent advances in X
[13:39] <markvandenborre> I want to act responsibly on the bugs I report
[13:39] <markvandenborre> is there anything I can do about this?
[13:40] <cosmodad> persia: that's good to know. One final thing: Is there a place I can get detailled information on why this binary (s2ram) was pulled out of the Gutsy package?
[13:40] <cosmodad> persia: a bug has been reported, but no rationale been giving (yet).
[13:40] <markvandenborre> I'm coming here since xvattr is in universe, but please point me to better places if there are any
[13:40] <cosmodad> given
[13:41] <persia> cosmodad: Aside from the changelog, there may be commentary in debian/README or debian/README-source.  If that is insufficient, you could try sending mail to the ubuntu-devel-discuss mailing list.
[13:42] <proppy> Is the 'package hint' in bash when 'command not found' is gone with gutsy ?
[13:42] <ScottK> No
[13:42] <cosmodad> persia: alright. Thanks for the starter
[13:42] <persia> proppy: it's still available.  You have to install the enabling package (which name I forget).
[13:43] <persia> cosmodad: Good luck with the testing.  If you get it working, and it works better for your hardware than the alternatives, please open a bug with details as to why it should be restored.
[13:44] <norsetto> was it command-not-found?
[13:45] <norsetto> !command-not-found
[13:45] <cosmodad> persia: I will consider. Elaborate testing with alternatives (apart from "uswsusp works almost out of the box, the alternatives don't"), however, will take a lot (too much?) of time.
[13:46] <norsetto> !ubotu
[13:46] <gnomefreak> universe packages need to follow SRU prcess correct?
[13:46] <gnomefreak> !info command-not-found
[13:46]  * norsetto hates ubotu with all his guts
[13:46] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
[13:46] <ubotu> command-not-found: Suggest installation of packages in interactive bash sessions. In component main, is standard. Version 0.2.8ubuntu2 (gutsy), package size 6 kB, installed size 96 kB
[13:46] <ScottK> gnomefreak: Yes.  That with the added provision that before the Hardy repos open you need a motu-uvf ack.
[13:46] <persia> cosmodad: If suspend doesn't work on your hardware with default gutsy, and does work with your hacked package (a report from 0.6~cvs20070618-1ubuntu1 would be even more compelling) that indicates that we've a hardware support issue, which should be raised for deeper discussion and review.  A bug is the best place for such discussion.
[13:47] <cosmodad> persia: I see.
[13:47] <persia> gnomefreak: scroll down on the SRU page: there are a couple variations in process for universe.
[13:47] <gnomefreak> ScottK: ok ty ill relay it to sponser
[13:47] <norsetto> !info command-not-found | proppy
[13:47] <ubotu> proppy: command-not-found: Suggest installation of packages in interactive bash sessions. In component main, is standard. Version 0.2.8ubuntu2 (gutsy), package size 6 kB, installed size 96 kB
[13:48] <cosmodad> persia: you don't possibly know what's the default hibernation/suspension scheme in Gutsy? (the one that takes please when I use the GUI to hibernate/suspend)
[13:48] <cosmodad> s/please/place/
[13:48] <persia> cosmodad: Actually, I know nothing about hibernation at all.  My apologies.
[13:48] <cosmodad> persia: that's alright. I'll figure it out myself.
[13:49] <cosmodad> I just need to determine whether the default scheme is still in action on my machine since I've tried quite a few things through the years with ubuntu.
[13:49] <cosmodad> tried=installed/removed
[13:50] <proppy> persia: norsetto: thanks
[13:51] <proppy> dpkg-reconfigure did the trick
[13:51]  * dholbach hugs siretart
[13:52]  * proppy hugs dholbach
[13:52]  * dholbach hugs proppy too
[13:55]  * Hobbsee checks the ML/
[13:55] <Hobbsee> well, the execution sucked, but it looks like i got my point more or less across.
[13:55] <ScottK> Good morning Hobbsee.
[13:55] <Hobbsee> hiya ScottK
[13:55] <persia> Hobbsee: It's just a matter of practice :)
[13:56] <Hobbsee> persia: sure.  i've had lots fo that :)
[13:56] <ScottK> persia: Don't put Hobbsee in mind of practicing executions.
[13:56] <Hobbsee> just not usually via ML.
[13:56] <Hobbsee> ScottK: like you havent done so before...
[13:57] <Hobbsee> ScottK: :)
[14:00] <huats> persia: I like your email on the mentoring process
[14:01] <proppy> norsetto: I sid chroot seems not be the best idea
[14:01] <persia> huats: Thanks.
[14:01] <norsetto> proppy: why?
[14:01] <proppy> norsetto: as viewvc is already updated and aliases to viewcvs in sid
[14:01] <proppy> norsetto: I just figure that when trying
[14:02] <proppy> norsetto: I should do etch -> unstable
[14:02] <proppy> norsetto: or testing -> unstable instead
[14:02] <norsetto> proppy: hmmm, can you install the last version of viewcvs then?
[14:02] <norsetto> proppy: and do un apt-get upgrade after
[14:03] <proppy> norsetto: viewcvs in sid *is* viewvc
[14:03] <proppy> norsetto: I have to get my hand on the previous previous of viewcvs
[14:04] <norsetto> proppy: now yes, but there is an old version still available
[14:04] <proppy> norsetto: and testing seems to have one
[14:04] <proppy> norsetto: you mean sid chroot with an old version of the deb ?
[14:04] <norsetto> proppy: yes, the one before the renaming
[14:05] <norsetto> proppy: but thats a bad idea perhaps, because it was before all these changes and is really not applicable anymore to debian
[14:05] <norsetto> proppy: yes, if you could try etch-unstable this should be
[14:06] <proppy> norsetto: I'm reading the Debian BTS again
[14:06] <proppy> norsetto: Now that I've worked a bit on the bug
[14:06] <proppy> norsetto: I'm pretty sure I'll understand it better
[14:08] <norsetto> proppy: you can check out which version is available where with "rmadison viewcvs"
[14:08] <norsetto> proppy: you can also use it with ubuntu with the option "-u ubuntu"
[14:10] <proppy> norsetto: how do I install a specific version then ?
[14:11] <norsetto> proppy: either you download it manually, or if you have the repo in sources.list you force the version with apt-get
[14:13] <qw354> всем привет
[14:13] <qw354> мм.. а почему тихо так
[14:13] <qw354> ?
[14:13] <zul> qw354: we speak english here
[14:13] <qw354> ok
[14:17] <huats> is there a step by step for merges ?
[14:17] <huats> or can anydody points out the big lines ? I've never done one.... and  I'd like too
[14:17] <huats> :-)
[14:18] <norsetto> zul: well, if you say so
[14:18] <norsetto> huats: pick up a merge and we will go through it together
[14:18] <huats> norsetto: ok
[14:19] <huats> norsetto: let's try to go for the gallery one
[14:20] <huats> if it is ok
[14:20] <norsetto> huats: you choose ... choose wisely though ;-)
[14:20] <kcotn> norsetto: i am intersted for  #155950 bug but i dont know what to do ??
[14:20] <huats> :*)
[14:21] <norsetto> kcotn: if that is the one I sponsors, there is already somebody working on it
[14:21] <huats> kcotn: I think it is too late
[14:21] <kcotn> norsetto: yes is this one
[14:22] <huats> norsetto: did I pick one with no pb at all ?
[14:22] <norsetto> kcotn: sorry about that, anyhow, you better check out the link I gave on my email first, to get an idea of what merges are and how to deal with them
[14:22] <norsetto> huats: don't worry, we will find a problem :-)
[14:23] <huats> :-)
[14:23] <huats> norsetto: but may be there is still something do with gallery ?
[14:23] <norsetto> huats: ok, so, what do you want to do, manual, mom or dad?
[14:23] <huats> norsetto: I have absolutly no opinion
[14:23] <bluekuja> amachu, do you wanna take care of Bug #156243?
[14:23] <huats> as being the tour guide, you can choose...
[14:23] <ubotu> Launchpad bug 156243 in qtdmm "Merge qtdmm 0.8.10-1 from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/156243
[14:24] <kcotn> norsetto: sure, i am reading these things now :)
[14:24] <norsetto> huats: ok, lets do mom now, shall we?
[14:24] <amachu> bluekuja: hi
[14:24] <amachu> yes
[14:24] <bluekuja> amachu, great, assign it yourself
[14:24] <huats> norsetto: go ahead
[14:25] <norsetto> huats: well, you know what a merge is?
[14:25] <huats> I think
[14:25] <huats> :-)
[14:25] <amachu> bluekuja: i just followed the doc
[14:25] <norsetto> huats: care to share?
[14:25] <amachu> and have few observations to make
[14:26] <huats> some patches/modifications has been done to a version, and an other upstream/debian appears that do not includes necesseraly these modifications, so it is needed to merge them
[14:27] <bluekuja> amachu, I guess you should start working on it, and ask me any question
[14:27] <norsetto> huats: ok, so, what do you think is the first thing to do, once grab-merge got all the needed stuff?
[14:27] <bluekuja> amachu, here or directly into the bug, so I can track your progres
[14:27] <amachu> ok...
[14:27] <huats> norsetto: in fact that was my first question : about grab-merge
[14:28] <huats> I've read to use it in a scratch-directory
[14:29] <huats> but it is not in my pbuilder env... just a scratch directory in my current environment ?
[14:29] <huats> right ?
[14:29] <norsetto> huats: yes
[14:29] <amachu> bluekuja: i have assigned.. and looking through it
[14:29] <huats> ok
[14:29] <bluekuja> amachu, perfect, brb
[14:38] <proppy> norsetto: root@nekun:/usr/src# apt-get source viewcvs=0.9.2+cvs.1.0.dev.2004.07.28-4.1
[14:38] <proppy> I didn't know about that syntax
[14:38] <proppy> :)
[14:39] <norsetto> proppy: isn't amazing how many things we learn every day?
[14:39] <proppy> norsetto: from you yes !
[14:39] <proppy> norsetto: do you mentor GLSL as well ?
[14:39] <huats> norsetto: sorry but how do you use grab-merge ?
[14:40] <norsetto> proppy: mind you, if you say that again I hug you
[14:40] <norsetto> proppy: do you have the script already?
[14:40] <proppy> norsetto: apt-get install phong
[14:40] <norsetto> ops, sorry
[14:40] <bigon> does somebody know how are handled source name changes if the binary package name are the same? should I ask removal of the source package first?
[14:40] <norsetto> huats: do you have the script already?
[14:40] <proppy> norsetto: debuilding viewcvs-0.9.2+cvs.1.0.dev.2004.07.28 to reproduce the behaviour on sid
[14:40] <huats> norsetto: yep
[14:41] <norsetto> huats: ok, just mkdir gallery, cd into it, and run grab-merge gallery
[14:42] <huats> and do I say yes to remove all files ?
[14:42] <huats> ok
[14:42] <huats> (I've answered my self)
[14:43] <norsetto> huats: the first time I used it, I answered no and it deleted everything anyhow :-)
[14:44] <huats> :-)
[14:44] <huats> do I have to ask Mathias Gug (the previous uploader) first ?
[14:44] <norsetto> huats: or maybe was the dad script? Oh well, one of the two
[14:44] <zul> imbrandon: ping
[14:44] <huats> :-)
[14:45] <amachu> bluekuja: the debian unstable (http://packages.debian.org/sid/qtdmm) has 0.8.10-1 while the ubuntu (http://packages.ubuntu.com/gutsy/science/qtdmm) has 0.8.8
[14:45] <norsetto> huats: this time is ok, he just sponsored the upload
[14:45] <huats> ok
[14:45] <norsetto> huats: but, yes, its good courtesy to check before
[14:45] <huats> ok
[14:45] <amachu> need to bridge that up
[14:46] <huats> norsetto: ok so now everythin is downloaded/unpacked
[14:47] <norsetto> huats: or you will get fujitsu performin his judo moves on you
[14:47] <norsetto> huats: or was it judo perfoprming his fujitsu moves? oh well
[14:47] <ScottK> FYI, https://launchpad.net/ubuntu/hardy now says active development.
[14:47] <huats> :-)
[14:48] <norsetto> huats: ok, so, have you checked REPORT?
[14:48] <huats> yep
[14:48] <norsetto> huats: and? problems? conflicts? looks good?
[14:49] <huats> norsetto: everything seems to be OK
[14:49] <amachu> bluekuja: i need to create update my pbuilder now for gutsy, i have it for feisty
[14:49] <minghua> So we are still having both MoM and DaD, right?
[14:49] <ScottK> Yes
[14:49] <norsetto> huats: ok, so the first thing to do is to look at the ubuntu changes, those of the old package
[14:50] <ScottK> The work to merge the U/I never got done
[14:50] <amachu> am doing a distribution upgrade right now
[14:50] <huats> norsetto: according there is no conflict
[14:50] <norsetto> huats: there should be a file called old_ubuntu_package.patch
[14:51] <huats> norsetto: so I should check that the produced patch is consistant with everything else...
[14:51] <norsetto> huats: in this case: gallery_1.5.5-pl1-1.1ubuntu1.patch
[14:51] <bluekuja> amachu, ok, I would suggest you to create a new tarball
[14:51] <bluekuja> amachu, so you can keep feisty one
[14:51] <norsetto> huats: do you follow me?
[14:51] <ScottK> Anyone who did advance uploads to gutsy-proposed, please upload your fixes to Hardy.
[14:51] <TheMuso> Hardy is open.
[14:51] <ScottK> Yes
[14:51] <huats> norsetto: I am
[14:51] <TheMuso> if people weren't already aware...
[14:51] <ScottK> TheMuso: see /topic
[14:52]  * norsetto goes to flood the server
[14:52] <Hobbsee> norsetto: you cant.  i'm already uploading lots of crack :P
[14:52] <TheMuso> ScottK: Did so in -devel.
[14:52]  * TheMuso needs a sbuild chroot first.
[14:52] <ScottK> No.  This one. I've already set it.
[14:52] <norsetto> huats: ok, so you checked the ubuntu changes?
[14:52] <huats> norsetto: in fac I was looking at that file already
[14:52] <amachu> bluekuja: i downloaded the source from http://www.mtoussaint.de/qtdmm.html#download
[14:52] <bluekuja> amachu, why?
[14:52] <bluekuja> amachu, I posted you dad and mom links
[14:52] <norsetto> huats: in this case its pretty easy, just oneliner
[14:53] <huats> norsetto: yep and the line for the Maintener field
[14:53] <proppy> Is there a policy avaiable (like python) for packaging web application ?
[14:53] <amachu> i missed it?
[14:53] <norsetto> huats: now, can you check the debian changes with respect to the old debian?
[14:53] <bluekuja> amachu, and anyway official website doesnt provide a package
[14:53] <bluekuja> amachu, which is the same of the archive
[14:53] <norsetto> huats: again there should be a file called new_debian_package.patch
[14:54] <amachu> ya
[14:54] <amachu> got it
[14:54] <norsetto> huats: which is what in this case?
[14:54] <bluekuja> amachu, so please use or mom/dad or if wanted to do it manually, get the source from debian/ubunut bts
[14:54] <bluekuja> *pts
[14:54] <huats> gallery_1.5.7-1..patch ?
[14:54] <norsetto> huats: ok, so, how do you check that (hint: do an ls before.....)
[14:55] <amachu> bluekuja: ok
[14:56] <bluekuja> hardy seems to be open
[14:56] <bluekuja> https://edge.launchpad.net/ubuntu/hardy
[14:56] <huats> norsetto: lsdiff -z ?
[14:56] <bluekuja> and the upload flood on hardy-changes confirms that
[14:56] <norsetto> bluekuja: ^
[14:56] <bluekuja> cool
[14:56] <bluekuja> good development circle to everyone
[14:56] <ScottK> It's already in /topic
[14:57] <huats> on the gallery_1.5.7-1.diff.gz file
[14:57] <bluekuja> yep, just saw it
[14:57] <norsetto> huats: well, that would not give you the delta wrt the old debian
[14:57] <huats> norsetto: but it gives the files that are impacted...
[14:57] <huats> right ?
[14:58] <proppy> norsetto: Last login: Tue Oct 23 11:33:23 2007 from host135-230-dynamic.22-79-r.retail.telecomitalia.it sweeet
[14:58] <norsetto> proppy: yes, that was me
[14:58] <norsetto> huats: yes, but what you need to do, is checking the changes
[14:59] <norsetto> huats: and the file you told me, contains ALL the changes between the two debian versions
[15:00] <huats> norsetto: ok, so I can have a look at the changelog in the debian latest version
[15:00] <norsetto> huats: do we need to know all the changes? All the 13 MByte of changes .....
[15:00] <norsetto> huats: you have the diff already, is there a way to filter out only what you need?
[15:01] <norsetto> huats: filter out what you need ......
[15:01] <norsetto> huats: filter out ......
[15:01] <huats> norsetto: filterdiff ?
[15:01] <norsetto> huats: filter ......
[15:01] <norsetto> huats: yes ....
[15:01] <huats> (I only knew that tool this morning when talking with you and persia))
[15:02] <norsetto> huats: for instance: filterdiff -i'*/debian/*' gallery_1.5.7-1.patch > gallery_1.5.7-1.patch.debian
[15:02] <proppy> huats: isn't amazing how many things we learn every day? (c) norsetto
[15:02] <norsetto> huats: so, we take out everything outside /debian
[15:02] <huats> :-)
[15:03] <norsetto> guys if you don't behave I'm goinna send you out of the classroom .....
[15:03] <huats> :-)
[15:03] <huats> ok
[15:04] <norsetto> huats: so, what is the change in the new debian wrt the old one?
[15:04] <jdong> norsetto: waah huats took my apple juice, make him fill out an "I word" card!
[15:04] <jdong> ;-)
[15:05] <huats> so now I can ;-)
[15:05] <huats> oups
[15:05]  * norsetto considers early retirement from Mentoring
[15:05] <jdong> norsetto: I think that sticks with you... forever and ever and ever :)
[15:05]  * norsetto considers his pension
[15:05] <huats> :-)
[15:06]  * norsetto decide to stick with it
[15:06] <bluekuja> jdong, heya :)
[15:06] <jdong> yo :)
[15:06] <bluekuja> :)
[15:06] <proppy> norsetto: I already tied your photo to the wall of my own personnal dojo
[15:06]  * jdong waits pitti e-mail, but only finds angry messages from his math TA...
[15:07] <norsetto> proppy: yeah, its good target practice
[15:07] <bluekuja> jdong, lol
[15:07] <norsetto> proppy: a nose shot its not worth much though, too easy a target
[15:07] <huats> norsetto: you want to know the diff in the new debian compared to the ubuntu one ?
[15:08] <norsetto> huats: no, the new debian wrt the old one
[15:08] <norsetto> huats: so that we can see if the ubuntu changes are covered, or not
[15:08] <huats> oh
[15:08] <huats> ok
[15:09] <proppy> norsetto: I have to agree, I prefer to aim at the viking-something figure in the back
[15:09] <norsetto> proppy: thats a cow!
[15:09] <huats> norsetto: Ok, i understood (I was very long...)  ubuntu changes are not covered
[15:10]  * TheMuso now has a hardy chroot, for i386 at least.
[15:10]  * proppy grats TheMuso
[15:10] <StevenK> TheMuso: Bit slow, aren't you? :-)
[15:10] <norsetto> huats: ok, so, now check what mom is proposing as new package
[15:10] <TheMuso> StevenK: Well since I only saw the hardy open notice a little while ago...
[15:10] <proppy> norsetto: I was able to reproduce the bug on debian
[15:11] <TheMuso> And, I'm doing other things at the same time.
[15:11] <proppy> norsetto: upgrading etch -> sid
[15:11] <proppy> norsetto: let me reply to the debian bug report
[15:11] <norsetto> proppy: good news, flood the DD with bugs ;-)
[15:11] <norsetto> proppy: I would open a new bug actually
[15:11] <proppy> norsetto: ok
[15:12] <proppy> norsetto: do not know about the debian flow at all
[15:12] <proppy> norsetto: I heard it is mailed based
[15:12] <norsetto> proppy: check it out, but I don't think there is another bug on the upgrade
[15:13] <norsetto> proppy: yes, the debian bts is email based, there should be a script (reportbug I think) that can be used though
[15:13] <proppy> norsetto: so I should report a bug 'Broken template in viewvc (sid) when upgrading from viewcvs(etch) ?
[15:13] <norsetto> proppy: sound good, remember to link it to the ubuntu bug, and remove the other bug which is not relevant
[15:15] <norsetto> huats: again, it is best to filter the patch, something like: filterdiff -i'*/debian/*' gallery_1.5.7-1ubuntu1.patch > gallery_1.5.7-1ubuntu1.patch.debian
[15:15] <proppy> norsetto: the bug is definitly related to this one too
[15:15] <proppy> norsetto: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409864
[15:15] <ubotu> Debian bug 409864 in viewvc "viewvc: No such file or directory: '/usr/lib/templates/directory.ezt' for SVN, but CVS works OK" [Important,Open]
[15:16] <proppy> norsetto:  For a workaround, either set the template_dir option in the [options]   section of your viewvc.conf and comment out all of the explicit   templates specified in the [templates] section, or just make sure   that every template in the [templates] section is specified with an   absolute path.
[15:16] <proppy> norsetto: that's exactly what my script do
[15:16] <proppy> norsetto: and someone pointed that as a workaround in this very bug report
[15:16] <norsetto> proppy: ah ok, didn remember that
[15:17] <norsetto> proppy: so, there is no need to raise a new bug then
[15:17] <proppy> norsetto: nor me, I just read the comments another time
[15:17] <huats> norsetto: I was doing that... before someone call me on my office phone ;-)
[15:17] <proppy> norsetto: as the bug is tagged as unreproducible
[15:17] <proppy> norsetto: I should comment my way to reproduce it I guess
[15:17] <norsetto> proppy: well, just propose your script in that bug then, and yes, say that you were able to reproduce and how
[15:18] <proppy> norsetto: and attach a viewvc-template not packaged as a way to automate the workaround
[15:19] <norsetto> proppy: sure
[15:19] <TheMuso> I'm assuming dpkg-striptranslations doesn't get run for PPA builds?
[15:20] <Fujitsu> TheMuso: At the moment it does, I believe, but I filed a bug on it some months ago.
[15:20] <huats> norsetto: so in that diff there is still the old ubuntu patch + some new translations
[15:21] <TheMuso> Fujitsu: Ok, thats kinda useful for me at this point, thanks.
[15:21] <norsetto> huats: ok, if you are happy with it, make your additions to the changelog and prepare the new source package
[15:21] <huats> ok
[15:22] <norsetto> huats: before doing that, I would also check if there is any bug in gallery which could be addressed in this upload too
[15:22] <Fujitsu> Bug #136399
[15:22] <ubotu> Launchpad bug 136399 in soyuz "PPA builders performing normal Ubuntu binary mangling" [High,New] https://launchpad.net/bugs/136399
[15:22] <Fujitsu> TheMuso: ^^
[15:23] <huats> norsetto: ok
[15:26] <TheMuso> Fujitsu: Turns out I don't need to worry about it any more, thanks anyway.
[15:32] <effie_jayx> dholbach, ping
[15:35] <norsetto> scottk: to be clear on the sru thingie, its just a new dput right?
[15:36] <ScottK> norsetto: You mean for Hardy?
[15:36] <norsetto> ScottK: yes, your email just sent
[15:36] <dholbach> effie_jayx: can you drop me a mail, I'm quite busy right now
[15:36] <ScottK> norsetto: With a different version number and distro in debian/changelog, but yes.
[15:36] <RainCT> hi
[15:37] <norsetto> ScottK: ah! ok, now I understand
[15:37] <huats> norsetto: regarding the merge
[15:38] <huats> in the changelog
[15:38] <huats> I do let mom as the author of the change ? or do I put mine ?
[15:38] <ScottK> huats: You
[15:38] <norsetto> huats: try to leave mom and see what happens ;-)
[15:39] <huats> sometimes I am so dumb
[15:39] <huats> ScottK and norsetto thanks
[15:39] <norsetto> huats: so, no new bugs which can be covered by this upload?
[15:40] <effie_jayx> dholbach,  cool
[15:40] <norsetto> huats: I wanted to check the debian bug about the ubuntu change, but their server seems to be down (proppy must be sending his bug mails)
[15:40] <dholbach> effie_jayx: thanks!
[15:41] <huats> norsetto: I was just preparing the changelog
[15:41] <huats> I was planning to have a look at the new bugs tonight
[15:42] <norsetto> huats: take your time, hardy is out only next April
[15:42] <huats> :-)
[15:42] <huats> by the way the new target is hardy
[15:42] <norsetto> huats: yes .....
[15:43] <huats> so I can create a pbuilder for it...
[15:44] <proppy> norsetto: few just have sorted 1600+ mail, for finding the accuratly the Debian BTS confirmation :)
[15:44] <norsetto> huats: I think you can already
[15:44] <huats> I do need a new bootstrap ?
[15:44] <huats> debbootstrap ?
[15:44] <huats> or do I copy the one from gutsy ?
[15:44] <ScottK> huats: Take a gutsy pbuilder and dist-upgrade it.
[15:45] <huats> ok
[15:45] <norsetto> huats: deboobstrap?
[15:45] <huats> norsetto: I meant debbootstrao
[15:45] <huats> rrrggghhhh
[15:45] <huats> debbootstrap
[15:45] <mruiz> bluekuja, hi! I attached the debdiff related to the bug 150876
[15:45] <ubotu> Launchpad bug 150876 in xen-meta "English error in description" [Low,Confirmed] https://launchpad.net/bugs/150876
[15:46] <bluekuja> mruiz, well done. Let me finish something and I move to it :)
[15:46] <mruiz> thanks bluekuja :-)
[15:46] <bluekuja> thanks to you mruiz :)
[15:47] <mruiz> bluekuja, you're welcome :-)
[15:47] <huats> ScottK sorry to ask but how do I dist-upgrade a pbuilder ?
[15:49] <ScottK> huats: You'll have to study the manpage for pbuilder for the exact syntax, but you use login and save-changes (or something close to that) and then gutsy/hardy sources.list and dist-upgrade while in the chroot.
[15:50] <huats> ok
[15:50] <huats> the pont I was missing was the save-changes
[15:50] <huats> thanks ScottK
[15:54] <proppy> norsetto: send the bug report to BTS think I'll take a few to show up
[15:55] <norsetto> proppy: yes, give them some minutes
[15:55] <proppy> norsetto: and checked that the viewvc-template python script fix the pb
[15:55] <proppy> norsetto: so I will reply with the script attached
[15:58] <proppy> norsetto: still not yet up :(
[15:59] <norsetto> proppy: last I checked the server was down
[16:04] <proppy> norsetto: just stalked your interview in behidnmotu
[16:04] <proppy> norsetto: nice cat
[16:05] <norsetto> norsetto: thats grand-minou ;-)
[16:06] <norsetto> proppy: when one talks to himself, is that a bad sign?
[16:07] <proppy> norsetto: grand-minou really ? my neightboor one is called minou-chat
[16:07] <StevenK> norsetto: No. When one answers themselves, it's worse.
[16:08] <norsetto> stevenk: hehe
[16:09] <norsetto> proppy: then we have petite-minette and microbe
[16:09] <proppy> norsetto: posted to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409864
[16:09] <ubotu> Debian bug 409864 in viewvc "viewvc: No such file or directory: '/usr/lib/templates/directory.ezt' for SVN, but CVS works OK" [Important,Open]
[16:09] <norsetto> proppy: what a fantasy eh.....
[16:09] <proppy> norsetto: my previous cat was called 'kernel' I know one called 'linux'
[16:10] <proppy> norsetto: the current one is 'roti'
[16:10] <proppy> norsetto: Let me reply to the BTS with the patch attached
[16:10] <norsetto> proppy: you mean, like roti-de-boeuf?
[16:11] <proppy> norsetto: yes
[16:12] <proppy> norsetto: s/patch/script
[16:16] <proppy> I forgot to point the ubuntu bug
[16:18] <ScottK> huats: I can verify that pbuilder upgrade approach works.  I just did it.
[16:19] <huats> ScottK:  I did it too...
[16:19] <huats> I don't know how to check it really works, but i dit
[16:19] <ScottK> Great.
[16:20] <huats> ScottK thanks
[16:21] <ScottK> huats: Try and update your upgraded pbuilder is a reasonable test.
[16:21] <proppy> norsetto: update bug #152438
[16:21] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Medium,Confirmed] https://launchpad.net/bugs/152438
[16:21] <proppy> norsetto: and Debian BTS as well
[16:22] <mruiz> bluekuja, any advance ?
[16:22] <bluekuja> mruiz, not yet on it
[16:23] <mruiz> bluekuja, ok...
[16:23] <bluekuja> mruiz, gonna ping you when reviewed
[16:23] <nxvl> where are the rules for debian/patches?
[16:24] <geser> nxvl: what rules?
[16:24] <nxvl> geser: it doesn't need rules?
[16:24] <nxvl> how do patches in debian/patches are apllied, by default?
[16:25] <huats> nxvl: hey
[16:26] <huats> nxvl: you remember this morning (yesterday everning for you)
[16:26] <huats> when you did the merge
[16:26] <geser> ah, depends on the patch system but usually through debian/rules
[16:26] <huats> you have added a line in the rules file
[16:26] <huats> that I already have added
[16:26] <geser> the documentation should have an example what to add to debian/rules
[16:27] <nxvl> huats: of course
[16:27] <nxvl> huats: and i think you are the person to help me on these
[16:27] <nxvl> huats: how do you make your patches to be apllied
[16:27] <geser> nxvl: which patch system do you use?
[16:28] <huats> dpatch
[16:28] <nxvl> huats: i'm trying to separate the patches and send to the DD as coordinate this $(5 hours ago)
[16:28] <huats> nxvl: in the rules file you add a line that include /usr/share/dpatch/dpatch.make
[16:29] <nxvl> huats: so, i only need to add the patches to debian/patches and list them on 00list sicen you do the work earlier?
[16:30] <huats> nxvl: dpatch is handling it for you, since it is already in it
[16:30] <nxvl> s/do/did
[16:30] <huats> so you can create the other patch
[16:30] <geser> huats: or if you use cdbs for packaging, cdbs has a ready file to include for dpatch
[16:30] <nxvl> huats: ]HUGS*
[16:30] <nxvl> huats: *HUGS*
[16:30] <huats> and as long as you include them in patches/
[16:31] <huats> and you list them in the 00list it is ok
[16:31] <huats> I think
[16:31] <huats> :-)
[16:31] <nxvl> huats: lets try is the only way to see if it's true
[16:31] <huats> you don't have to put a call in the rules file for every patch
[16:32] <huats> if is your question :-)
[16:32] <huats> geser: it was debhelper if I remember well...
[16:32]  * huats hugs back nxvl
[16:32] <nxvl> huats: yes it was
[16:34] <proppy> ScottK: have you take a look at bug #155839
[16:34] <ubotu> Launchpad bug 155839 in openct "Please sync openct_0.6.14-2 from Debian unstable (main) to Ubuntu hardy" [Undecided,New] https://launchpad.net/bugs/155839
[16:34] <proppy> what is missing ?
[16:34]  * ScottK can take a quick look, but not enough to upload it.
[16:35] <proppy> ScottK: np
[16:35] <ScottK> proppy: Forgot it was a sync.  That I should be able to deal with.
[16:36] <nxvl> should i include Makefile.in in the patches?
[16:36] <tonyyarusso> Oooof....I'm reaching the conclusion that Gutsy wasn't ready for release.
[16:36] <huats> nxvl: what do you mean ?
[16:37] <amachu> bluekuja: hi
[16:37] <bluekuja> amachu, heya
[16:38] <nxvl> huats: lsdiff shows me Makefile.in
[16:38] <ScottK> proppy: Looked good.  Confirmed and ack'ed to the archive.
[16:38] <amachu> bluekuja: the MoM says about the conflict
[16:38] <amachu> in debian/comtrol
[16:38] <bluekuja> yes?
[16:38] <proppy> ScottK: thanks
[16:38] <amachu> in debian/control
[16:38] <nxvl> huats: as well as the config's i have been told to remove, so i'm not sure about including it
[16:39] <amachu> bluekuja: fine.. i untarred qtdmm_0.8.10-1ubuntu1.src.tar.gz
[16:39] <bluekuja> amachu, y?
[16:39] <bluekuja> amachu, mom/dad does that for you
[16:40] <amachu> ok..
[16:40] <huats> nxvl: the lsdiff on the efax-gtk_3.0.15-1.patch right ?
[16:40] <bluekuja> amachu, small question
[16:40] <bluekuja> amachu, what did you do for grabbing stuff from dad/mom?
[16:40] <amachu> bluekuja: yes
[16:40] <bluekuja> I hope you did *not* wget file by file
[16:41] <amachu> grabbing stuff?
[16:41] <nxvl> huats: not, on efax-gtk_3.0.15-1.diff.gz
[16:41] <amachu> ok
[16:41] <bluekuja> amachu, yes
[16:41] <amachu> bluekuja: i used kget
[16:41] <huats> that was what I meant
[16:42] <bluekuja> amachu, wrong :)
[16:42] <bluekuja> amachu, did you read dad/mom istructions?
[16:42] <bluekuja> before starting up?
[16:42] <huats> you have to keep them
[16:42] <bluekuja> amachu, usually guidelines are there to be understood
[16:42] <huats> since it is not generated
[16:42] <bluekuja> and followed
[16:42] <bluekuja> :)
[16:42] <huats> it is done on purpose
[16:43] <huats> let's have a look at the efax-gtk_3.0.15-1 changelog
[16:43] <amachu> bluekuja: dad/mom instructions in?
[16:43] <bluekuja> amachu, suggestion--> grab-merge.sh
[16:43] <huats> and you'll see that some modifications happened to the Makefile.in
[16:43] <huats> and Makefile
[16:44] <amachu> ok
[16:44] <bluekuja> amachu, did you see it somewhere?
[16:44] <bluekuja> in starting guidelines?
[16:44] <huats> anyway you can remove the config stuff but not the Make one -)
[16:44] <bluekuja> at dad/mom homepage?
[16:45] <amachu> i remember
[16:45] <amachu> just a min
[16:45] <amachu> yes
[16:45] <nxvl> huats: that was my cuestion, thnx again
[16:45] <huats> :-)
[16:46] <huats> no problem
[16:46] <huats> it is the first time I can answer someone questions here !!!
[16:46]  * huats hugs everyone
[16:46] <huats> to celebrate
[16:46] <amachu> bluekuja: its in the homepage
[16:47] <bluekuja> amachu, yep
[16:49] <nxvl> huats: where was the page where we see the menu policy? did you remember?
[16:51] <huats> nxvl:  http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.2
[16:52] <nxvl> huats: thnx
[16:57] <nxvl> huats: ok, the patch are in sigle files on debian/patches, but now, how do i remove the old ones?
[16:57] <RainCT> Hobbsee: hi
[16:57] <Hobbsee> hiya RainCT
[16:57] <huats> old ones ?
[16:57] <huats> old patches ?
[16:58] <nxvl> huats: yes
[16:58] <nxvl> huats: backporting to orig source i think
[16:58] <huats> I am sorry I don't see the point
[16:59] <RainCT> Hobbsee: about bug 155845, «What happened to kubuntu-restricted-extras, ppc?  did it not deserve to have gnash?», I didn't add it since gnash depends on libgtk2. should I add it anyways?
[16:59] <ubotu> Launchpad bug 155845 in ubuntu-restricted-extras "Description says it will install flash, but it doesn't on amd64 systems" [Low,Confirmed] https://launchpad.net/bugs/155845
[16:59] <huats> by instance what do you want to remove
[16:59] <huats> ?
[16:59] <ScottK> fernando: Are you up for the Courier merge?  Let me know if you have questions.
[16:59] <nxvl> huats: in the lsdiff there is some non debian changes
[16:59] <nxvl> huats: i want to remove them
[17:00] <Hobbsee> RainCT: amarok also depends on libgtk2
[17:00] <huats> nxvl: I think that you should not remove them
[17:00] <nxvl> huats: what i'm doing is to change the package to dpatch and then i will send the debdiff to the DD
[17:01] <fernando> hey ScottK, I'm a little busy. but no questions yet
[17:01] <huats> the changes that are non debian ones are already there in the new debian package right ?
[17:01] <nxvl> huats: yes
[17:02] <huats> so there is no point of dealing with them, at least from my point of view...
[17:02] <ScottK> fernando: OK.  Just let me know.
[17:02] <huats> but once again maybe I am wrong
[17:02] <huats> nxvl: you should let them...
[17:02] <huats> nxvl: I am sorry
[17:02] <huats> nxvl: I really have to go
[17:02] <amachu> bluekuja: ya got that
[17:03] <huats> but I'll should be able to reconnect later tonight...
[17:03] <RainCT> Hobbsee: ok.. so should I add it there too?
[17:03] <Hobbsee> RainCT: sounds reasonable
[17:04] <RainCT> Hobbsee: (and about the patch, I just used   debdiff packagename.old packagename > packagename.debdiff )
[17:04] <RainCT> ok
[17:04] <huats> I am sure norsetto  or persia might be able to help on you on that before I come back
[17:04] <huats> once again, I am sorry
[17:04] <Hobbsee> RainCT: you need to do it in the dir that the two dsc's are in, iirc.
[17:05] <Hobbsee> or do you acutally need to do it in the source/  hmm.
[17:05] <amachu> brb
[17:05] <nxvl> huats: ok, have a nice day and thank you :D
[17:05] <huats> thanks too
[17:05] <nxvl> huats: you don't have to be sorry
[17:06] <RainCT> Hobbsee: ah yes, sorry, I meant the .dsc's of the old one and of the new one
[17:06]  * ScottK notes for the record that ESC :wq doesn't work in Kate.
[17:06] <RainCT> debdiff ubuntu-restricted-extras_10.dsc ubuntu-restricted-extras_11.dsc > ubuntu-restricted-extras_11.debdiff
[17:06] <bluekuja> mruiz, commented
[17:07] <Hobbsee> RainCT: hmm.  it shoul dhave worked
[17:07] <Hobbsee> RainCT: in that case, you need to delete the preceeding characters before the u-r-e/ dir
[17:07] <Hobbsee> so that the patch applies with patch -p1
[17:07] <mruiz> thanks bluekuja , I'll continue later
[17:08] <bluekuja> mruiz, k fine
[17:08] <bluekuja> amachu, done?
[17:10] <amachu> bluekuja: not done yet.. got through the grab-merge.sh
[17:10] <bluekuja> ah ok fine
[17:10] <bluekuja> :)
[17:13] <cosmodad> how do I revert patching done between <package>-ubuntuX and -ubuntuX+1?
[17:13] <cosmodad> I suppose there's some Debian/Ubuntu helper for that. Keyword would be fine.
[17:13] <RainCT> Hobbsee: http://launchpadlibrarian.net/10130712/ubuntu-restricted-extras_11.debdiff
[17:14] <RainCT> «Does flashplugin-nonfree actually work sufficiently well on amd64»   about that, I've no idea :P
[17:14] <Hobbsee> RainCT: looks much better.  what does `gstreamer0.10-pitfdll' do?
[17:14] <Hobbsee> yeah, i think i saw a few bugs about it, which i why i didnt add it before
[17:14] <mruiz> bluekuja, I uploaded a new version :-)
[17:15] <bluekuja> mruiz, checking
[17:16] <amachu> bluekuja: the MoM says about .DEBIAN and .UBUNTU files
[17:17] <bluekuja> amachu, after grabbing the source, check REPORT fil
[17:17] <bluekuja> and find out conflicts
[17:17] <bluekuja> fix them
[17:17] <amachu> ok
[17:17] <bluekuja> debuild
[17:17] <RainCT> Hobbsee: «GStreamer plugin for using MS Windows binary codecs», it's requested in bug 155770
[17:17] <ubotu> Launchpad bug 155770 in ubuntu-restricted-extras "ubuntu-restricted-extras doesn't recommend gstreamer0.10-pitfdll" [Wishlist,New] https://launchpad.net/bugs/155770
[17:17] <bluekuja> debdiff
[17:17] <Hobbsee> RainCT: oh, that one.  right
[17:17] <Hobbsee> yeah, i saw that come in
[17:22] <mruiz> bluekuja, I have to leave IRC right now... I'm waiting for your comments... thanks!
[17:22] <bluekuja> mruiz, uploading
[17:27] <dholbach>    QUESTION: where are debtags saved (the tags for each deb package)?
[17:27] <dholbach> ^ can somebody answer that?
[17:32] <RainCT> what are debtags? :P
[17:33] <jpatrick> dholbach: /var/lib/debtags
[17:33] <jpatrick> (I think)
[17:33] <cosmodad> how do I revert patching done between <package>-ubuntuX and -ubuntuX+1?
[17:34] <geser> Hobbsee: Hi, should I get my gnumed-client removed from -proposed (if it's possible)?
[17:34] <ScottK> geser: I don't think it's possible.  At this point we need to just make really sure it's well tested before --> gutsy-updates
[17:34] <Hobbsee> i have no idea
[17:36] <norsetto_> dholbach, jpatrick: I think the local repo is in /usr/share/debtags
[17:37] <jpatrick> norsetto_: well I have a 2.2MB file in there with them
[17:42]  * norsetto_ hugs geser, scottk and hobbsee
[17:42]  * ScottK does his first Hardy upload :-)
[17:42]  * Hobbsee hugs norsetto
[17:43] <norsetto> scottK: beat you already :-P
[17:44] <norsetto> anyone feels giving a look at: http://revu.tauware.de/details.py?upid=399 ?
[17:47] <cosmodad> I'm trying to revert an upgrade done to a specific Ubuntu package and re-merge with the latest Debian package. Someone (here) told me before I should revert the patches prior to merging.
[17:47] <cosmodad> Although I've been looking hard on how to revert, I cannot figure it out. Can anyone give me a hint?
[17:50] <nxvl> norsetto: i have made the changes u ask for, and updated the LP page
[17:50] <nxvl> norsetto: can u take a look please
[17:50] <norsetto> nxvl: yes, doing it already
[17:50] <norsetto> nxvl: I can modify it this time, but next time pls. make sure that the chnagelog entries will wrap before the 80 chars limit
[17:51] <nxvl> norsetto: oh, i didn't know that, i will keep it in mind
[17:52] <jpatrick> could someone look at http://revu.tauware.de/details.py?upid=379 ?
[17:52] <norsetto> nxvl: otherwise it looks good, I'll build, test and if its ok upload it soon, thanks for your work!
[17:53] <nxvl> norsetto: thnk u for your help, i'm glad to work with you :D
[17:53]  * nxvl hugs norsetto 
[17:53] <nxvl> now, going to work
[17:54] <nxvl> see you later
[17:54]  * ScottK hugs norsetto back.
[17:54]  * norsetto faints
[17:54] <jpatrick> norsetto: was it that awful?
[17:54] <jpatrick> :(
[17:55] <ScottK> jpatrick: That was me, not you.
[17:55] <jpatrick> ah, right :)
[17:57] <dholbach> thanks jpatrick, norsetto
[17:58] <jpatrick> no prob
[17:59] <ScottK> dholbach: Noted.
[17:59] <norsetto> dholbach: was that anywhere close to what you wanted?
[18:01] <dholbach> ScottK: hm?
[18:05] <zul> wik/win 10
[18:05] <zul> damn it
[18:12] <norsetto> this is new to me. When debuilding a merge, I get this warning message: Ubuntu merge policy: when merging Ubuntu packages with Debian, -v must be used
[18:12] <Hobbsee> norsetto: because keybuk will eat you otherwise.
[18:12] <Hobbsee> norsetto: you're not using merge-buildpackage, or whatever it is, from mom?
[18:13] <norsetto> Hobbsee: no, I just got a debdiff from the uploader and checking it
[18:13] <Hobbsee> norsetto: it's so that only the changelog up to the last ubuntu version is used - where you set what version is after the -v
[18:13] <Hobbsee> merge-buildpackage automates this for you.
[18:14] <norsetto> Hobbsee: well, thanks
[18:15] <Hobbsee> norsetto: but keybuk will yell at you if you dont specify the right -v value - or any
[18:17] <norsetto> well, suppose the last version was 3.0.15-1ubuntu1 and this one fater the merge 3.0.14-1ubuntu1, then the right command is debuild -S -sa -v3.0.14-1ubuntu1, right?
[18:17] <Hobbsee> fater?
[18:17] <imbrandon> moins all
[18:17] <norsetto> sorry: suppose the last version was 3.0.14-1ubuntu1 and this one after the merge 3.0.15-1ubuntu1, then the right command is debuild -S -sa -v3.0.14-1ubuntu1, right?
[18:18] <Hobbsee> yes
[18:18]  * norsetto just wonders why he has never seen that before
[18:20]  * Hobbsee heads to bed
[18:20] <jpatrick> g'night Hobbsee
[18:21] <norsetto> g'night Hobbsee
[18:24] <luk_> good night Hobbsee
[18:24] <nixternal> imbrandon: it is freakin' afternoon, what are you saying moin for? lazy bum :p
[18:25] <hypa7ia> hey motu folks, what's the process to get a Universe package updated if an old version was included in Gutsy?
[18:30] <hypa7ia> barring that does anyone know how to track down a package maintainer in motu?
[18:31] <slangasek> hypa7ia: universe doesn't strictly have package maintainers, it's collaboratively maintained
[18:32] <hypa7ia> ahh, good to know
[18:33] <hypa7ia> so the proper process from what i see in the MOTU FAQ is just to file a bug on the package
[18:33] <imbrandon> nixternal, haha
[18:33] <imbrandon> nixternal, listened to lugradio yet this week ?
[18:38] <nixternal> imbrandon: heh, just starting it right now
[18:39] <imbrandon> nixternal, about an hour and 5 minutes in see if you reconise someone , fskin hilarious imho
[18:39] <norsetto> ScottK: are we back to normal for srus  (ie. subscribe ubuntu-sru and not motu-uvf)?
[18:40] <ScottK> norsetto: Yes, but there is motu-sru.
[18:40] <ScottK> is /is no
[18:41] <ScottK> Normal = You upload it to proposed when it's fixed in Hardy and you think it's ready.
[18:42] <norsetto> ScottK: ok, thanks for that
[18:42] <ScottK> norsetto: If you found documentation referring to motu-sru, please fix it.
[18:42] <norsetto> scottk: sure
[18:43] <norsetto> ScottK: can you pls. unsubscribe motu-uvf from bug 155498 then?
[18:43] <ubotu> Launchpad bug 155498 in rutilt "rutilt 0.15-0ubuntu5 crashes while applying a profile" [Medium,Confirmed] https://launchpad.net/bugs/155498
[18:43] <ScottK> norsetto: No.  I already deactivated myself.
[18:44] <norsetto> scottK: ah
[18:44] <norsetto> scottk: well, never mind than
[18:44] <zul> imbrandon: ping
[18:47] <imbrandon> zul, pong
[18:54] <cosmodad> how'd one suffix customly modified package-names to differ them from official ones?
[18:54] <cosmodad> I thought of something similar to backports, e.g. ~cosmodad
[18:55] <ScottK> Should be fine.
[18:55] <cosmodad> okey-dokey
[19:15] <sistpoty> hi folks
[19:15] <jpatrick> hi sistpoty
[19:15] <sistpoty> hi jpatrick
[19:18] <ScottK> Heya sistpoty.
[19:18] <sistpoty> hi ScottK
[19:19] <adii>  HI
[19:20] <geser> Hi sistpoty
[19:20] <sistpoty> hi geser
[19:35] <deadwill> yo
[19:36] <deadwill> ScottK, PM?
[19:36] <ScottK> If it's quick.
[20:28]  * nixternal just did his first Hardy upload...woohoo! it is on!
[20:31] <cosmodad> can anyone help me out with a pdebuild prob? All build-deps can be satisfied except for a single one (libsplashy1-dev) even though it's part of the Gutsy rep (which `pbuilder create' was based on)
[20:31] <cosmodad> how'd I debug this issue?
[20:33] <ScottK> Is the package in Universe and do you have Universe enabled?
[20:34] <cosmodad> ScottK: it's in Universe which I have enabled on my machine prior to doing pbuilder create.
[20:34] <cosmodad> ScottK: do I have to tell pbuilder specifically about this as well?
[20:34] <ScottK> That doesn't mean it's enabled in the pbuilder.
[20:34] <ScottK> Yes
[20:34] <cosmodad> how'd I do that?
[20:35] <pochu> cosmodad: check https://wiki.ubuntu.com/PbuilderHowto#head-5e61fa0f52f7f2442fb20f074813bd691744460b
[20:35] <ScottK> man pbuilder is the snarky answer.  The easy way is to get the ubuntu-dev-tools package and use the pbuilder-dist script there.
[20:35] <sistpoty> any main sponsors around that could help me with bug #156362?
[20:35] <ubotu> Launchpad bug 156362 in nvidia-settings "should ship NVCtrl.h and NVCtrlLib.h" [Undecided,New] https://launchpad.net/bugs/156362
[20:35] <bluekuja> cosmodad, gedit /etc/pbuilder/pbuilderrc and uncomment other components
[20:36] <bluekuja> cosmodad, do a tarball update, that's all
[20:36] <bluekuja> or follow ScottK's advice as well
[20:36] <bluekuja> ;)
[20:36] <cosmodad> wow thanks all
[20:37] <bluekuja> cosmodad, np
[20:37] <cosmodad> which approach should I prefer?
[20:40] <ScottK> Whichever one you actually prefer.  Technically the get you to the same place.
[20:40] <cosmodad> oh I see, pbuilder-dist looks comfortable
[20:40] <ScottK> Beware that the Gutsy version doesn't actually work for Debian dists.
[20:42] <cosmodad> ScottK: you mean if I build against Gutsy reps?
[20:43] <ScottK> No, I mean if you use the Gutsy version of pbuilder-dist to make a pbuilder for a Debian dist, it won't work.
[20:43] <ScottK> For any Ubuntu release it's fine.
[20:44] <ScottK> To get it working for a Debian pbuilder takes a bit of hackage.
[20:44] <slangasek> ScottK: why is that, OOI?
[20:44] <cosmodad> ScottK: this in fact is supposed to be an Ubuntu release.
[20:44] <ScottK> It's a bug in the script.
[20:44] <cosmodad> ScottK: I'm interested in this bug anyway, out of curiosity.
[20:45] <ScottK> cosmodad: Bug a lot of us do work in Ubuntu
[20:45] <ScottK> Ubuntu/Debian
[20:45] <ScottK> Bug 140964 for details.
[20:45] <ubotu> Launchpad bug 140964 in ubuntu-dev-tools "pbuilder-dist tries Ubuntu components for Debian distro" [Medium,In progress] https://launchpad.net/bugs/140964
[20:45] <nixternal> devtools in hardy aren't picking up on the hardy in the changelogs...am I forgetting another hack in order to get the highlighting to go away?
[20:45] <ScottK> This particular bug is an example of why I dislike bzr repos for packages.
[20:46] <cosmodad> ScottK: "a bit of hackage" referred to pbuilder-dist only, right?
[20:46] <ScottK> Yes
[20:46] <cosmodad> ScottK: in that case, I'll evade pbuilder-dist for the moment
[20:47] <ScottK> cosmodad: Up to you.  For Ubuntu it works great.
[20:48] <ajmitch> hm, gutsy not doing much on the laptop when I'm trying to login today
[20:48]  * ajmitch kicks it
[20:49] <cosmodad> ScottK: thanks again.
[20:49] <ScottK> No trouble.
[20:50]  * sistpoty is off to bed
[20:50] <sistpoty> gn8 everyone
[20:50] <imbrandon> heya ajmitch
[20:50] <imbrandon> gnight sistpoty
[20:50] <ajmitch> hi imbrandon
[20:51]  * ajmitch wonders why it is playing stupid today, since there have been no updates
[20:51] <zul> hey ajmitch
[20:51] <ajmitch> hi
[20:51] <imbrandon> zul, i also had nixternaltry that lum , works perfectly
[20:51] <jcastro> I can't help but read "Hi imbrandon" as "Hi, I'm brandon."
[20:51] <ajmitch> jcastro: he was imaginative, that's for sure
[20:51] <imbrandon> jcastro, thats the exact point of the nick ;)
[20:52] <zul> imbrandon: nifty..
[20:52] <zul> imbrandon: if you give me about 20 minutes ill have a xbox kernel for you
[20:52] <imbrandon> kick ass
[20:52] <imbrandon> i'm gonna blog a bit about it too when i file the bug
[20:53] <zul> of course i dont know if it will work because you havent sent me one yet ;)
[20:53] <ajmitch> awesome, I login & kill stuff, and the desktop starts
[20:53] <imbrandon> zul, you know i owe your fist born beer for life for helping me ;)
[20:53] <ajmitch> (mostly)
[20:53] <zul> imbrandon: well wait til he is a bit older and i think he might appreciate it ;)
[20:54] <imbrandon> :)
[20:54] <imbrandon> jcastro, thats for pointing out that LR thing, that was hilarious
[20:54] <imbrandon> thanks*
[20:55] <jcastro> yeah, I literally fell out of my chair
[20:55] <ajmitch> imbrandon: hm?
[20:55] <jcastro> englishmen trying to mimic a southern accent, brilliant
[20:55] <ajmitch> jcastro: how's your open week going?
[20:55] <ajmitch> hah
[20:55] <imbrandon> jcastro, they did something similar when i was interviewd on LR
[20:55] <jcastro> ajmitch: it's _our_ openweek!
[20:56] <ajmitch> imbrandon: you were interviewed? I didn't realise we had such a celebrity
[20:56] <imbrandon> ajmitch, i got a mention on LR , you have to hear it to beleive it
[20:56] <jcastro> ajmitch: there were something like 260+ people in dholbach's packaging sessions
[20:56] <ajmitch> jcastro: not for my timezone :)
[20:56] <imbrandon> i was interviewed on LR in May, todays epsisode i just got mentionede
[20:56] <jcastro> ajmitch: hopefully it'll motivate some people to get involved, etc.
[20:56] <imbrandon> mentioned*
[20:56] <jcastro> I certainly learned from the session
[20:57] <imbrandon> the Q & A session should be nice too
[20:57] <imbrandon> i'm gonna pull and see how many other MOTU's i can have with me fielding Q's too
[20:57] <ajmitch> jcastro: at best I can catch the last session or two
[20:58] <imbrandon> yea the sessions should be a bit later IMHO
[20:58] <ajmitch> depends on which timezone you're aiming for :)
[20:58] <zul> imbrandon: i have to head home but ill be back later
[20:58] <imbrandon> evening central USA rocks :)
[20:58] <imbrandon> zul, kk
[20:59] <imbrandon> e.g. 2000 UTC onword
[20:59] <ajmitch> makes it fun trying to follow a team who always has irc meetings at 4am local time
[21:00] <imbrandon> yea that sucks
[21:00]  * ajmitch just gave up after awhile
[21:29] <norsetto> where is it possible to find remove requests in debian?
[21:31] <ScottK> norsetto: Info is here: http://wiki.debian.org/ftpmaster_Removals
[21:31] <norsetto> ScottK: excellent, thanks!
[21:31] <huats> norsetto: I am back with my merge
[21:31] <huats> ;)
[21:31] <ScottK> norsetto: You're welcome
[21:31] <huats> what is the good way to create the package ?
[21:31] <huats> merge-buildpackage ?
[21:32] <huats> is there a way to use pbuilder ?
[21:32] <norsetto> huats: I tend to use a manual method, like debuild
[21:32] <huats> or is it like always
[21:32] <huats> ok
[21:32] <huats> so
[21:32] <huats> same as always : debuild -S -sa
[21:33] <RainCT> good night
[21:33] <huats> and then pbuilder build ?
[21:33] <huats> RainCT: good night
[21:33] <huats> norsetto: so nothing changes in a merge than from a classical build
[21:34] <ScottK> If I've got a package with an installed config file, how do I get the question about the modified version of the config file asked?  Call debconf in the postinst?
[21:34] <norsetto> huats: it is a normal build, I just found out today that we just need to add a -v option to make the changelog trasparent to all the changes since the last ubuntu one, and thats it
[21:35] <norsetto> huats: but for you this is not necessary, its only if you need a source .changes
[21:36] <huats> ok
[21:43] <geser> norsetto: the PTS often has also a record (the bug number) why a package got removed
[21:44] <geser> ScottK: isn't dpkg handling configfiles itself?
[21:44] <norsetto> geser: ok, I'm in need just to check if a removal request has been issued already only
[21:45] <geser> norsetto: check the PTS for the package, it should have a comment about it
[21:45] <geser> ScottK: some packages use also ucf for config files hangling
[21:45] <ScottK> geser: I'm finding yes.  I'm researching it.
[21:46]  * ScottK thought it was debconf, but it is dpkg.
[21:47] <norsetto> geser: thx, I'll keep an eye on that then
[21:54] <slangasek> ScottK: if it's a conffile, dpkg prompts automatically any time there's a modified version on disk and the version in the new package has changed.
[21:54] <slangasek> if it's not a conffile, ucf is the best option
[21:55] <ScottK> slangasek: Thanks.  I think I've figured out how to teach dpkg it's a conffile.  I'm testing now.
[21:56] <slangasek> ScottK: is this an existing config file that you're trying to turn into a conffile, or a new package?
[21:56] <ScottK> It's an existing package with a config file that was not so marked.  I'm trying to fix it.
[21:57]  * ajmitch kills esd
[21:58] <ScottK> Well that didn't work...
[21:59] <slangasek> ScottK: ah, then you want the magic conversion bits... http://wiki.debian.org/DpkgConffileHandling I think
[22:00] <ScottK> slangasek: Thanks.  Looking
[22:01] <slangasek> ScottK: alas, that page doesn't seem to have the bits that are actually relevant here, so let me summarize
[22:02] <slangasek> ScottK: if the config file was previously installed as a non-conffile, calculate the md5sum of the version that was shipped in the old package; in the preinst of the new package, compare it to the md5sum of the file on disk; if they're equal, delete the file
[22:02]  * ScottK appreciates.
[22:02] <slangasek> ScottK: otherwise, leave the file alone and dpkg's conffile handling should pick up the conflict
[22:03] <ScottK> OK.  How does dpkg know it's a conffile?
[22:03] <ScottK> Actually I think I figured it.
[22:04] <ScottK> I think I missed .conffile vs .conffiles.
[22:04]  * ScottK tries again.
[22:05] <slangasek> ScottK: if you're using any of the standard packaging helpers (debhelper, or cdbs+debhelper), any files shipped under /etc are automatically made conffiles
[22:05] <slangasek> if you're not using them, why not? :), and if you're shipping a conffile outside of /etc you probably should'nt
[22:06] <ScottK> It's CBDS and it appears to not be finding it (it's in /etc).
[22:06] <ScottK> Hmm
[22:06] <slangasek> using the debhelper class?
[22:06] <ScottK> Good question - checking
[22:07] <ScottK> I have .../rules/debhelper.mk, but not class.
[22:07] <ScottK> Upstream ships the conffile in /usr/local and I move it.  Maybe I do it too late in the process.
[22:07] <ScottK> Hmmm
[22:07] <slangasek> ah, my mistake, it's not under class
[22:08] <slangasek> ah, at what point are you moving it?  Please move it as part of "install"
[22:08] <slangasek> for best results
[22:10] <ScottK> Looking back, (it's a python app) what I did was patch the provided setup.py to put in /etc.
[22:10]  * ScottK doens't know why that wouldn't just work.
[22:10] <slangasek> sounds like it should
[22:11] <ScottK> Well I'll google some more and see what I can come up with.  Thanks for helping.
[22:11]  * ScottK may try python-central for the first time to see if it manages it.
[22:17] <bmk789> are most packages compiled with the -O3 gcc flag or is there a standard optimization ubuntu uses?
[22:18] <slangasek> the standard optimization inherited from Debian is -O2
[22:18] <ScottK> slangasek: adding debian/binary_packagename.conffiles containing the path/filename of the conffile solved it.
[22:19] <slangasek> hmm
[22:19] <slangasek> ScottK: there aren't any DH_VERSION lines in debian/rules, are there?
[22:19] <slangasek> (which I think cdbs might override anyway, but)
[22:19] <ScottK> Not in debian/rules (it's vanilla CDBS).  I"ll check the build logs
[22:19] <bmk789> so -O2 is just the default or are packages only accepted at -O2?
[22:20] <ScottK> slangasek: dh_version does not appear to get called.
[22:21] <slangasek> ScottK: or a pre-existing debian/version file?  The thing is, debhelper from something like compat level 3 on is supposed to automatically treat any files installed under /etc as conffiles when building.
[22:21] <ScottK> Nope.  compat = 5 and no debian/version file.
[22:22] <ScottK> slangasek: I'm in the Debian Python Modules Team.  I'll go bug them as I expect it's something Python packaging related.  Thanks for all your help.
[22:24] <slangasek> ScottK: as long as dh_installdeb is called, conffiles are really supposed to be registered automatically, so that's really weird.  good luck then. :)
[22:24] <ScottK> Well that one definitely gets called.
[22:24] <ScottK> Thanks again.
[22:24] <slangasek> bmk789: you really shouldn't be using a different optimization level than -O2 without a particular reason, but it's not an absolute rule.
[22:25] <bmk789> ok thanks
[22:41] <lamego> what is the DEB*ARCH var ?
[22:41] <lamego> I mean, which
[22:52] <norsetto> well, thats it
[22:52] <norsetto> g'night all people
[22:52] <norsetto> g'night good people too
[22:52] <ajmitch> g'night norsetto
[22:53]  * ajmitch returns to trolling nixternal 
[23:18] <mruiz> hi all
[23:19] <mruiz> bluekuja, thanks for the upload :-)
[23:54] <desertc> Greetings masters of the universe.  I want to call your attention to a project that I think is extremely worthy of assistance.
[23:54] <desertc> https://bugs.launchpad.net/ubuntu/+bug/129081/
[23:54] <ubotu> Launchpad bug 129081 in ubuntu "[needs-packaging] Mumble" [Wishlist,In progress]
[23:56] <desertc> Mutter is an open source alternative to Team Speak and Ventrilo, neither of which have Linux clients.  I feel strongly that this software could have a significant impact on Linux desktop users, as no open source VoIP-conferencing-solution is popular, atm.
[23:57] <desertc> It looked like (a couple months back) that it was in line with getting into Gutsy, but I lost sight of the progress, and now the maintainer seems to be having communication negotiations through the bug-entry-system.
[23:58] <desertc> As I said, I think this is an important potential package, and I wanted to illuminate the software and it's potential, in case there were some champions in here that felt they could help out.
[23:58] <desertc> Thanks for all of your help and congratulations on a fantastic Gutsy Gibbon release.