[00:17] <EzraR> if an app is set up to run on diff OS's is it acceptable to break that functionality in the package to fix a bug? (Ubuntu is linux only)
[00:18] <EzraR> well actually its already broke
[00:18] <EzraR> i would just make it actually work for linux
[00:18] <EzraR> without fixing the larger bug
[00:21] <ScottK> EzraR: Yes.
[00:21] <ScottK> Bonus points for working in BSD land since Ubuntu has one downstream that uses that.
[00:23] <EzraR> it has diff configs for free,net, and open which would be best suited for that
[00:25] <EzraR> nm, im guessing free
[00:27] <wgrant> ScottK: We have a BSD downstream?
[00:28] <ScottK> wgrant: Nexunta or something like that?
[00:28] <wgrant> ScottK: That's OpenSolaris.
[00:28] <ScottK> Ah.
[00:28] <ScottK> EzraR: Nevermind
[00:28] <ScottK> That's what I get trying to remember stuff when I have flu.
[02:22] <FFEMTcJ> Could someone test my patch for Bug #481677 please
[02:24] <FFEMTcJ> I'm new at this, so would like some feedback if anyone has any.
[03:17] <lfaraone> How are sync requests scheduled? I see a NEW (to ubuntu) package in testing that I need synced to Lucid before I can do a sync request of a package with local changes.
[03:22] <ScottK> lfaraone: Just wait a bit.
[03:24] <lfaraone> ScottK: mk.
[04:06] <master> hello
[04:06] <master> umm
[04:06] <master> i would like to know
[04:06] <master> how to develop for ubuntu
[04:06] <master> i do C java and C++ and the likes
[04:10] <maco> master: hi :)
[04:12] <maco> i suppose you could have a look at the bugtracker.  the ones marked "triaged" are the ones that should have enough info for you to fix them, but you may want to start with triaged ones tagged "bitesize" to work your way up the tough ones if you're not too experienced yet
[04:12] <maco> note also that we're having the developer summit next week. you can listen in to streams of it and participate over irc...or at least just get a feel for how decisions happen around here and what new stuff is coming
[04:13] <maco> at some point, you'll probably want to learn to package up your patches. for that, i think daniel holbach's videos on youtube are fantastic
[04:14] <maco> master: is that the sort of info you were looking for?
[04:16] <maco> master: this is a good place to start https://wiki.ubuntu.com/UbuntuDevelopment
[04:17] <jmarsden> master: For MOTU-related stuff you can also start at https://wiki.ubuntu.com/MOTU/GettingStarted .  At some point reading the Packaging Guide https://wiki.ubuntu.com/PackagingGuide/Complete would also be good :)
[04:17]  * maco should get around to learning C++
[04:19] <maco> wow i dont think i ever actually read the wiki page i linked O_o
[04:23] <jmarsden> maco: Well, you became a MOTU without it, so you can't have missed *that* much :)
[04:23] <maco> jmarsden: i missed the bit about linking to "how to package without debhelper"
[04:24] <maco> also the sponsorship page? i apparently requested sponsorship rather wrong rather often. didnt know you were supposed to assign to nobody
[04:25] <master> k
[04:25] <master> but
[04:25] <master> im not sure how to go about making the patch
[04:25] <maco> ah ok
[04:25] <maco> have you ever used the diff command?
[04:27] <maco> hmm wait lets back up
[04:28] <maco> ok first, you find out what package contains whatever bug you want to fix. if its one on launchpad, youre good. if one you found "dpkg -S <program>" replacing <program> with the command that runs the program you found the bug in
[04:28] <maco> then you get that package in source form: apt-get source <package>
[04:28] <maco> then itll unpack a directory of source code for you
[04:29] <maco> i would then run: cp -lr original_source/ modified_source/ (replace original_source with the directory name)
[04:29] <maco> cd into modified_source/ and make whatever edits are necessary to fix the bug
[04:30] <maco> then run: diff -rU original_source/ modified_source/ > fixstuff.patch
[04:30] <maco> there's your patch!
[04:34] <maco> you can also make a debdiff, but there are directions elsewhere for that. a patch is good enough to attach to a bug report and have someone do something with it. if you want to know how to make a debdiff see daniel holbach & james westby's ubuntu open week session logs from a couple weeks ago
[04:34] <maco> master: does that help?
[04:38] <master> thanks so much maco
[04:38] <maco> no problem :)
[04:40] <master> what is the usual language the sources are in?
[04:40] <maco> most of GNOME is C, most of KDE is C++, both have a lot of Python programs as well
[04:40] <maco> ive yet to use my Java in FOSS
[04:40] <maco> underlying system stuff is usually C as well
[04:41] <master> k
[04:41] <master> cos i dont do python
[04:41] <maco> neither do i
[04:41] <maco> i just do C or Java
[04:41] <JanC> you can learn basic Python in less than 1 day  ;)
[04:42] <master> mm
[04:42] <master> ok
[04:42] <maco> yeah...ive done a couple of patches in python without knowing python
[04:42] <maco> it looks like pseudocode, but it happens to run
[04:42] <JanC> contrary to C++, you need about 10 years to learn basic C++  ;)
[04:43] <maco> haha...i need to get around to that
[04:43] <maco> only knowing how to code for the DE i dont use anymore is a little ick
[04:43] <JanC> even the inventor of C++ admits he doesn't understand C++, so...
[04:43] <maco> bjarne?
[04:43] <JanC> yeah  ☺
[04:44] <maco> ...he didnt say anything bad about c++ when he got up to speak about it
[04:44] <JanC> well, he wrote it in the book I have; actually he said he doesn't understand all the corner cases of C++
[04:45] <JanC> and AFAIK nobody does (there are no 2 C++ compilers that interpret it alike)
[04:46] <maco> hpux's c++ compiler will quote page & line numbers at you when you screw up
[04:46] <maco> of the C++ specification
[04:46] <JanC> which is why most projects agree to use only a subset of C++  ;)
[04:46] <maco> moz devs learned quickly that if it fails to compile on hpux, the hpux compiler is right
[04:47] <JanC> there are valid C++ constructs that can have 2 meanings according to the spec, no way a compiler can decide what's right  ;)
[04:47] <jdong> too bad the C++ specifications are non-free ;-)
[04:47] <jdong> in a quite literal financial sense of the term.
[04:47] <maco> jdong: thats rather sucky
[04:47] <jdong> indeed
[04:47] <JanC> jdong: well, the drafts that get approved are free most of the time
[04:48] <jdong> I needed it the other day to help a friend make a pedantic point on homework.
[04:48] <jdong> i.e. declaring an int main without explicitly returning.
[04:58] <master> open office is programmed in java rite?
[04:58] <jdong> no
[04:58] <jdong> it's primarily programmed in C++
[04:58] <JanC> no, most of OO.o is C++, with some parts in Java
[04:58] <master> o
[04:58] <master> ok
[04:58] <jdong> multimedia portions are in Java
[04:58] <master> 00.o???
[04:58] <jdong> but are "optional" ish.
[04:58] <JanC> e.g. the database is in Java IIRC
[04:59] <jdong> master: upstream insists that it's called OpenOffice.org
[04:59] <jdong> and never shortened in any other manner.
[04:59] <master> o
[04:59] <master> kk
[04:59] <JanC> jdong: OpenOffice is a company in the Netherlands that is way older than OO.o  ;)
[04:59] <jdong> :)
[05:00] <JanC> they actually distribute StarOffice and now OpenOffice.org
[05:00] <JanC> and help promote it
[05:01] <JanC> they do the whole "open office" stuff, including operating systems on server & desktop, applications, etc.
[05:01]  * jdong nods
[05:02] <JanC> they even promote Ubuntu  ☺
[05:11] <master> anyone here knows how to do OS programming
[05:14]  * maco looks at jdong 
[05:14] <maco> im not done with OS class yet
[05:15] <maco> but jdong knows everything about everything
[05:15] <jdong> jdong has currently enteredCriticalSection....
[05:15] <jdong> err that didn't sound right.
[05:15] <maco> hahahaha
[05:15] <jdong> I meant to express jdong is busy right now with WORK and not interruptible.
[05:15] <maco> critical section works...
[05:17] <Flannel> master: "OS Programming" could be a lot of things.  What are you trying to do?
[05:18] <master> lol
[05:20] <RAOF> OS programming: working out why grub2 sticks an invalid vg entry in its list of lvs, causing it to segfault.
[05:23] <DBO> RAOF, halp, Docky needs you
[05:23] <RAOF> DBO: Trade you a working grub for help on Docky? :)
[05:23] <DBO> mmmm, I suggest LILO, its the bestest
[05:23] <RAOF> Won't boot from lvm
[05:24] <RAOF> IIRC
[05:24] <jdong> it's called a /boot partition.
[05:24] <jdong> *ducks*
[05:24]  * DBO was being sarcastic
[05:49] <dtchen_> lilo does boot from lvms.
[05:50] <dtchen_> granted, I don't recall if it was a *SUSE setup
[05:51] <dtchen_> maco: eh, I'm quite certain I've bopped you over the noggin with "don't assign unless explicitly granted permission"
[05:51] <maco> dtchen_: yeah i know *that*
[05:51] <dtchen_> OTOH, you do have an amazing ability to tune out everything I say
[05:52] <maco> i mean i didnt know you were supposed to unassign after you attach your debdiff and before you subscribe sponsors
[05:53] <dtchen_> in all honesty, sure, you're supposed to, but if your sponsor can't be arsed to do that herself/himself, then...
[05:58] <fabrice_sp> dtchen_, grub2 also boot from lvms
[05:59] <dtchen_> fabrice_sp: yes. I'd be rather up a creek if it didn't.
[05:59] <fabrice_sp> :-)
[08:09] <LucidFox> I should say, Karmic is the first time I found the default desktop theme actually enjoyable.
[10:12] <m4rtin> hi, I've written a couple of patches for bugs in bash-completion and attached them to the relevant bugs; could someone give me information on what I do next? This is my first delve and I'm not sure what the "sponsor queue" is etc.
[10:22] <randomaction> m4rtin: have you created debdiffs?
[10:24] <m4rtin> randomaction: yes, I have uploaded the debdiff as an attachment on the bug and tested the fix using dpkg. Just read the Sponsoring process and gathered I am now supposed to subscribe the sponsors, so just did that. Was that correct?
[10:24] <randomaction> yes
[10:24] <randomaction> and set status to Confirmed
[10:25] <m4rtin> yep, status Confirmed, assigned-to: Unassigned
[10:25] <randomaction> if it's a regular bug (i.e. not security or SRU)
[10:30] <m4rtin> yeah, just regular - thank you :)
[10:31] <m4rtin> presumably it will then show up in the sponsor queue listed above (delayed?)
[10:31] <randomaction> yes it will
[10:34] <randomaction> m4rtin: is it bug 435055?
[10:35] <m4rtin> yes
[10:35] <m4rtin> (don't laugh! I appreciate it's a tiny bug, but I thought a small fix for a first attempt at submitting would be preferable)
[10:36] <randomaction> I'm not a MOTU but I think I can give you some hints
[10:36] <randomaction> so that your debdiff looks better
[10:37] <randomaction> the syntax for closing a bug in changelog is LP: 435055
[10:37] <randomaction> sorry, LP: #435055
[10:38] <randomaction> and the target in changelog should be lucid, not karmic
[10:39] <m4rtin> ah ok, let me fix that. Presumably I should change control and changelog and then re-"debuild"
[10:40] <randomaction> yes, or for such small changes you can hand-edit your debdiff
[10:42] <randomaction> and this package uses a patch system (quilt)
[10:42] <m4rtin> ah ok, thanks - my other question was, do you have any tips for this kind of situation: say I fix a bug and then want to work on another in the same package, the debdiff must be against the current source I assume, so installing will re-introduce the existing bugs I have fixed... any recommendations?
[10:43] <m4rtin> oh, does that (quilt) mean that I have missed something?
[10:44] <randomaction> you should format your change as a patch contained in debian/patches
[10:44] <randomaction> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[10:45] <m4rtin> damn. ok - let me go have a read
[10:49] <m4rtin> so, if I understand correctly, I should 1.) make my changes 2.) push a new patch 3.) create a quilt README 4.) quilt refresh 5.) pop the patch
[10:51] <m4rtin> no, I assume 1 and 2 were the wrong way around
[10:51] <randomaction> you run: 1) quilt push -a (applies all patches) 2) quilt new <patchname> 3) quilt add <filename> 4) <make a change> 5) quilt refresh
 would be bash_completion in your case
[10:53] <m4rtin> ok - I'll redo the patch and attach it. Thanks for the help and apologies for my ignorance
[10:53] <randomaction> and 0) export QUILT_PATCHES=debian/patches
[10:54] <randomaction> and dch (before or after, as you wish)
[10:54] <m4rtin> dch should be at step 4? or is this irrelevant?
[10:54] <m4rtin> (and do I need to submit a debdiff as well as the quilt diff?)
[10:55] <randomaction> additions to debian/changelog don't go into quilt patch
[10:55] <m4rtin> ah ok, so it doesn't matter when that is done
[10:55] <randomaction> generally, patch systems are used to track changes outside of debian/
[10:55] <randomaction> yes
[10:55] <m4rtin> and, therefore, I assume a debdiff is also used
[10:56] <randomaction> and quilt patch will make it into debdiff
[10:56] <m4rtin> oh ok great :)
[10:57] <m4rtin> actually, presumably the quilt patch system also deals with my problem of multiple changes, because I just push another change (provided there are no changes to the same file)
[10:58] <randomaction> if can fix several bugs in one upload (one debdiff)
[10:59] <randomaction> *you can
[10:59] <m4rtin> I think, as this is my first attempt, I'll stick to just fixing one very simple bug and learn to get it right
[11:07] <m4rtin> randomaction: do I need to do a quilt add README? PackakingGuide suggests so, but your instructions didn't
[11:08] <randomaction> it's required by Debian policy, so Debian maintainer of the package should do it at some point
[11:08] <m4rtin> but I should not?
[11:08] <randomaction> this qualifies as a general cleanup, so shouldn't be done in a bugfix
[11:09] <m4rtin> ok, thank you
[11:09] <randomaction> the difference between Debian and Ubuntu should be kept minimal for ease of maintenance
[11:09] <m4rtin> right, I've done my quilt refresh
[11:10] <m4rtin> do I then need to pop the patch?
[11:10] <randomaction> debuild will do it
[11:10] <m4rtin> oh ok, so now I just go through the same debuild process as usual?
[11:12] <randomaction> do you have a new patch created in debian/patches?
[11:12] <randomaction> and its name in debian/patches/series?
[11:13] <m4rtin> yep
[11:13] <randomaction> you should be ok to debuild then
[11:13] <m4rtin> great - I'll give it a shot
[11:22] <m4rtin> and it's up there
[12:17] <diwic> What is the reasoning behind disabling apport for a final release?
[13:36] <ari-tczew> sponsors, can someone take a look on bug #413657 ?
[14:51] <dtchen_> ari-tczew: you have e-mail WRT coccinelle.
[14:52] <dtchen_> diwic: no real need to flood LP
[14:56] <DktrKranz> whois Laney Laney
[14:56] <dtchen_> idle time, eh?
[14:57] <DktrKranz> damn... well, Laney, I will point you to a mail I've just sent to debian-legal wrt pidgin-facebookchat
[14:57] <DktrKranz> yup :)
[15:00] <diwic> dtchen_: but is it really necessary? LP has duplicate detection, and it would be useful to catch bugs in the stable distribution.
[15:00] <dtchen_> diwic: I'm not one to debate this particular policy :-)
[15:06] <iulian> DktrKranz: jpds is the maintainer of pidgin-facebookchat in Debian.
[15:08] <dtchen_> bddebian: hiya, any ETA for libsdl1.2_1.2.14 in Debian? Any way I can assist?
[15:08] <DktrKranz> iulian: err... indeed :)
[15:08] <DktrKranz> anyway, jpds and iulian: http://lists.debian.org/debian-legal/2009/11/msg00029.html
[15:08] <iulian> DktrKranz: Yea, I've read the mail.
[15:09] <iulian> Thanks.
[15:09] <bddebian> dtchen_: I know they asked upstream to add pkg-config files but other than that no, I don't know yet :(
[15:09] <DktrKranz> I'm not sure if it's your case, but if it is, thee could be legal troubles
[15:10] <iulian> DktrKranz: Indeed.
[15:10] <dtchen_> bddebian: ok. 1.2.14 is blocking a buttload of audio bugs for me, but that's not such a big issue; I'd just rather not spend cycles backporting to 1.2.13. Thanks!
[15:10] <chrisccoulson> diwic - apport is disabled in the stable distribution mainly because the bugs that users will report are all duplicates of the bugs we already know about from testing
[15:10] <chrisccoulson> in that case, all it does is annoy users and spam people subscribed to those bug reports
[15:11] <chrisccoulson> s/all/mostly
[15:11] <diwic> chrisccoulson: I thought LP automatically duplicated those with the existing ones
[15:12] <dtchen_> that would be part of the spam :-)
[15:13] <chrisccoulson> indeed, dtchen is right
[15:13] <chrisccoulson> apport is just not very useful in a stable distribution, when users are just going to report bugs that we already know exist
[15:14] <bddebian> dtchen_: Understood.  Let me see if I can push the issue.
[15:14] <dtchen_> bddebian: no sweat, seriously. I have so many other bugs. :-)
[15:15] <bddebian> Don't we all? :)
[15:16] <dtchen_> nah, I could use a few more. :-)
[15:16] <bddebian> I have a couple I could give you :)
[15:16] <dtchen_> I'm not saying bitrot is a good thing :-)
[15:17] <maco> wow this channel looks happy today
[15:17] <dtchen_> I think there's a coccinelle upload in your future, maco.
[15:18] <maco> ok
[15:18] <dtchen_> (http://kernel.ubuntu.com/~dtchen/upload_queue/)
[15:18] <maco> my keys are on laptop. think its ok to get it out?
[15:18] <diwic> chrisccoulson: I don't really agree, but at least I get the reasoning.
[15:18] <dtchen_> maco: (eh, you're ircing from class; I think you know the answer to that question)
[15:20] <maco> dtchen_ ...no?
[15:21] <Hobbsee> maco: look into debsign -r if you haven't already
[15:22] <StevenK> That assumes that her laptop or other machine with keys are network accessible
[15:23] <Hobbsee> true
[15:23] <maco> Hobbseeok
[15:23] <Hobbsee> but if they weren't accessible, then why would she be asking if it was ok to get them out?  ;)
[15:23] <maco> StevenK yeah i can get on the school vpn :)
[15:24] <maco> booo @ freenode java applet. it doesnt put a space after tab-completing names
[15:27]  * StevenK didn't know Freenode had one of those
[15:28] <maco> http://java.freenode.net/
[15:28] <maco> they added it when they banned mibbit
[15:28] <StevenK> Ahhh
[15:38] <jdong> they....
[15:38] <jdong> replaced an AJAX applet with a Java applet?
[15:43] <ari-tczew> qa.ubuntuwire.com isn't work :-(
[15:47] <maco> jdong they figured they could control the java applet better than they could abuses of mibbit
[15:47] <jdong> lol
[15:48] <jdong> if they switch it to Macromedia Shockwave they'd have no abuses!
[15:48]  * maco headdesk
[15:49] <StevenK> jdong: Or users
[15:50] <jdong> that's the whole point :)
[15:50] <jdong> or switch it to silverlight and only directhex will be on IRC.
[15:50] <jdong> *DUCKS* ;-)
[15:57] <bbigras> bug 476360 and bug 428017 has a fix uploaded to karmic-proposed. It's waiting for a MOTU SRU ACK. If someone has time. the first bug fix make the plugin work again
[15:58] <ScottK> jdong: ^^^
[15:58] <chrisccoulson> diwic - why don't you agree? what do you think would be the benefit for enabling it by default?
[15:58] <dtchen_> just missed him, apparently :/
[15:58] <bbigras> ScottK: thanks :)
[15:59] <chrisccoulson> heh, just noticed that. thanks
[16:00] <ari-tczew> any sponsor bored here? :P bug #482663
[16:01] <dtchen_> maco: *cough* s/karmic/lucid/ !
[16:01] <maco> dtchen_: yeah yeah just did that
[16:01] <maco> i noticed quick and poked Hobbsee
[16:02] <dtchen_> maco: danke
[16:02] <Hobbsee> yay for soyuz auto-rejecting it
[16:02] <maco> :( i screwed up already
[16:02] <dtchen_> that's hardly a screw-up
[16:03] <dtchen_> just don't break the toolchain like I did :-)
[16:03] <jdong> bbigras: both diffs look good to me
[16:03] <jdong> ScottK: am I blind, or is there no kopete-facebook in the queue/
[16:03] <jdong> (I hope those were uploaded against karmic-proposed, versioned properly)
[16:03] <maco> dtchen_: O_o
[16:03] <ScottK> jdong: It's not uploaded yet, but I think there's a debdiff in the bug
[16:04] <ScottK> Riddell said he was waiting on a ack to upload
[16:04] <jdong> hmmph two separate bugs
[16:04] <jdong> should we make one new SRU bug to encampass both diffs?
[16:11] <jdong> bbigras: ok I gave you an ACK on bug 476360 to proceed with karmic-proposed SRU'ing of both patches
[16:12] <jdong> I see Riddell already uploaded them to Lucid as one, so the same will work for karmic-proposed...
[16:12] <bbigras> jdong: ok thanks, is there documentation about how and where to upload it?
[16:13] <jdong> ScottK: can you help bbigras through the rest of the process? I gotta head out for a meeting right now
[16:14] <ScottK> jdong and bbigras: Not right now, as I'm heading out too, but we'll get it taken care of.
[16:15] <bbigras> ScottK: ok thanks. I'll ping Riddell to see if he has time
[16:53] <ari-tczew> ScottK: when ubuntu-archive will sync packages?
[17:01] <geser> ari-tczew: usually the archive admin of the day processes them, but with uds next week I don't expect to see them processed before the week after uds
[17:04] <ari-tczew> OK
[17:11] <goshawk> how do i modify a patch which have been created with quilt?
[17:13] <DrKranz> quilt push patchname; edit files; quilt refresh; quilt pop -a
[17:13] <geser> apply the patch with quilt, edit the files you need to modify (don't forget to add them, if they aren't already touched by that patch), "quilt refresh"
[17:21] <goshawk> sorry, very bad connection
[17:22] <goshawk> DrKranz: where should i run quilt push? in the root of the package or in debian dir?
[17:22] <DrKranz_> in package root, you probably have to export QUILT_PATCHES=debian/patches beforehand
[17:23] <goshawk> yes
[17:23] <goshawk> it works now
[17:23] <goshawk> ;)
[17:45] <serialorder> anyone know a way I can convert diff in RCS format to unified format?
[18:09] <DrKranz_> jdong: time to put your motu-sru hat on for bug #433924 ?
[18:18] <ari-tczew> how often https://merges.ubuntu.com/universe.html is updating?
[18:31] <jpds> ari-tczew: /topic #ubuntu-devel: MoM up to date as of Monday 4am, but now stalled
[19:58] <ScottK> jdong: Looking for an ack for Bug 384929
[19:59] <maco> jdong: while youre at it bug 317366 needs an sru ack
[20:11] <jdong> ok ok jdong just returned from 2 hours to himself
[20:11] <jdong> let him catch up and caffeinate first!
[20:11] <maco> jdong talks about jdong in the 3rd person?
[20:11] <jdong> for now he does
[20:14] <jdong> ScottK: 384929 acked.
[20:14] <ScottK> jdong: Thanks.
[20:16] <ScottK> Meh.  Too late (you added your comment)
[20:17] <jdong> and debdiff on 317366 is acked.
[20:18] <jdong> nov 5th... wonder why that never made it to my LP bugmail
[20:18] <jdong> oh. 15 minutes ago
[20:18] <jdong> must've been recently subscribed
[20:18] <maco> jdong: thanks
[20:19] <jdong> welcome :)
[20:20] <maco> jdong: that bug has tasks open for karmic and jaunty. is ack for both?
[20:21] <jdong> maco: I only saw a debdiff for Karmic, but a similar debdiff at jaunty would be covered under the ACK too :)
[20:21] <maco> jdong: okiedoo
[20:23] <serialorder> how would you list multiple lp bugs in a  changelog would (LP: #nnnn, nnnn2, nnnn3) work?
[20:23] <maco> i think you need to include LP: each time
[20:23] <jdong> that's correct.
[20:24] <serialorder> so it would be (LP: #nnnn, LP: #nnnn2, LP: #nnnn3)
[20:24] <jdong> correct
[20:24] <serialorder> ok thanks
[20:24] <maco> jdong: ergh...jaunty and karmic are both 9.06-1 so karmic's gettin -1ubuntu0.1, but what would jaunty get? O_o
[20:24] <jdong> ugh I hate this game.
[20:25] <maco> lucid got -2ubuntu1
[20:25] <jdong> well we've got a couple options here....
[20:25] <jdong> we could play the game the security team plays with Firefox releases
[20:25] <geser> 9.06-1ubuntu0.1.9.04 and 9.06-1ubuntu0.1.9.10 or something like that
[20:25] <jdong> i.e. 1ubuntu0.9.04.0
[20:25] <jdong> i.e. 1ubuntu0.9.04.1
[20:26] <jdong> or we can play geser's game :)
[20:26] <kees> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[20:27] <kees> when you have colliding versions, the best way to handle it is the ubuntu0.MM.mm.1 style
[20:27] <jdong> cool.
[20:27] <jdong> kees wins because he has a wiki citation!
[20:27] <kees> heh.  not sure if that counts, since I wrote it.  ;)
[20:28] <jdong> hahaha :)
[20:28] <jdong> well if I could make stuff up on the SRU wiki page I would too ;-)
[20:28] <kees> hehe
[20:28] <maco> 9.06-1ubuntu0.9.10.1) karmic-proposed; and
[20:28] <geser> jdong: quick write two wiki pages to trump kees' one wiki page :)
[20:28] <maco> (9.06-1ubuntu0.9.04.1) jaunty-proposed; ?
[20:29] <jdong> hahaha
[20:29] <jdong> maco: reasonable to me.
[20:29]  * jdong would eventually like to see backports use numeric suffixes too
[20:29] <jdong> since not very far from now we are gonna run out of ascending letters
[20:29] <maco> ok now what about the part where i realized jaunty was the same version *after* uploading karmic's?
[20:29] <ScottK> maco: You want 1ubuntu0.09.04.1
[20:29] <ScottK> (the missing leading 0 is important)
[20:30] <jdong> maco: that part, you've got ScottK with the big red button.
[20:30] <maco> ScottK: oh god. 2010 is coming.
[20:30] <ScottK> Yep.  2012 too
[20:30] <maco> haha
[20:30] <maco> UGLY version strings
[20:31] <dtchen_> no, ugly would be Qt.
[20:32] <dtchen_> I think I've done a few myself.
[20:32] <maco> ScottK: can you hit that button?
[20:32] <EzraR> people should only change packages with patches and link the patch to the changelog entry
[20:33] <EzraR> that would make life easy
[20:33] <kklimonda> maco: it's not that ugly - have you seen qt version from karmic? ;)
[20:33] <dtchen_> kklimonda: jinx
[20:33] <maco> does it have a "-really"?
[20:33] <kklimonda> yeah
[20:33] <dtchen_> no, no hyphen
[20:34] <jdong> did it hurt too much to bump the epoch?
[20:34] <kklimonda> right, no hyphen but really is there... and I can remember an even better version string from the past..
[20:35] <kklimonda> jdong: then we would have to convince debian maintainer to add epoch too
[20:35] <ScottK> maco: If you're going to use the release number approach you need to do it for both Karmic and Jaunty.
[20:35] <kklimonda> (I remember similar discussion from 6 months ago when we had a similar problem with python-storm)
[20:36] <serialorder> is there a way to convert a patch from rcs format to unified?
[20:36] <maco> ScottK: hence red button
[20:36] <maco> ScottK: im redoing with it for both of them
[20:36] <ScottK> OK.  Rejected
[20:36] <maco> thank ye
[20:36] <ScottK> No problem.
[20:36] <dtchen_> oh man, old-releases.ubuntu.com/ubuntu/pool/universe . *shudder*
[20:37] <maco> kklimonda: i remember apache or mysql or something like that having a "really" string
[20:37] <kklimonda> maco: I think it was mysql
[20:38] <maco> yeah i think so too
[20:38] <ScottK> Yep
[20:38] <kklimonda> and I think ScottK could find an even better example of weird version string from some -updates (I remember him pasting it in the past ;) )
[20:38] <ScottK> I think instead of really, we should use the IRC nick of the person that messed it up.
[20:38] <maco> haha
[20:40] <ScottK> I had to use an awful one in backports to revert a bad Flash backport once
[20:40] <dtchen_> man, you gals/guys are really triggering *all* my bad Ubuntu memories
[20:40] <dtchen_> vlc, flashplugin-nonfree, ...
[20:41] <ScottK> And from you, that's saying something.
[20:42] <maco> why?
[20:42] <ScottK> Given that you live inside a major nightmare
[20:42] <maco> because the packages he works on are most other people's bad ubuntu memories?
[20:42]  * maco ducks
[20:42] <mok0> heh
[20:45] <maco> kees: "SECURITY UPDATE: [how the bad guys could get you]" *snicker*
[20:45]  * jdong loved his markov generated security advisories
[20:48] <jdong> haha I still have a copy of it
[20:48] <jdong> http://jdong.mit.edu/~jdong/usnramble.txt
[20:49] <maco> jdong: LINEBREAKS
[20:50] <jdong> "ntpd does not check this privilege when executing
[20:50] <jdong> non-Postfix commands"
[20:50] <jdong> hahaha
[20:50] <jdong> they almost sound real.
[20:50] <maco> huh?
[20:51] <maco> oh...i see...
[20:51] <jdong> I fed all of the USN's up to some date through a markov generator :)
[20:51] <jdong> just to see what vulnerabilities it'd invent
[20:52] <mok0> jdong, on a different note, you need help with backports?
[20:52] <jdong> mok0: that would be appreciated, yes
[20:52] <mok0> jdong: I've been on the applicants list for quite some time
[20:53] <jdong> *looks
[20:53] <jdong> yes you are
[20:53]  * ScottK +1's mok0 for ubuntu-backporters.
[20:53] <jdong> well, welcome aboard, mok0 :)
[20:54] <mok0> Thanks :-)
[20:54] <jdong> are you familiar with what to do, or do you need a quick tour?
[20:54] <mok0> jdong, a quick tour might be good
[20:55] <serialorder> ill try one more time, is there a way to convert a patch from rcs format to unified?
[20:55] <mok0> jdong: but the packages that interest me the most are "leaf packages"
[20:55] <serialorder> sorry i mean a diff
[20:55] <ScottK> serialorder: I doubt anyone here knows.
[20:55] <jdong> mok0: leaf packages are definitely the ones that are best for backporting
[20:56] <jdong> general rules of thumb is that we'd prefer that they build cleanly with no source changes...
[20:56] <mok0> serialorder: rcsdiff ?
[20:56] <ScottK>  ^^^ The only one old enough to know.
[20:56] <jdong> for those, we just ask for 2 or so reports that the built package works
[20:56] <maco> serialorder: you could probably write a perl script...
[20:57] <mok0> mok0: errh, perhaps it's rdff
[20:57] <mok0> rdiff
[20:57] <jdong> and then all you have to do is verbally ACK and subscribe ubuntu-archive.
[20:57] <jdong> source change backports should be acked by a backporter and uploaded into the -backports pocket; and an archive admin will poke it through
[20:57] <jdong> umm... I believe nowadays we're using the "Confirmed" state to mark a backport that's approved and "in progress" to mark uploaded source-change backports
[20:58] <mok0> jdong: ... and should not introduce new dependencies I guess
[20:58] <jdong> idn if the UbuntuBackports wiki page has been updated to reflect that yet
[20:58] <ScottK> In progress for ones that are acked to the archive too
[20:58] <jdong> mok0: I personally don't have a big objection to needing to pull in new dependencies
[20:58] <jdong> it will make update-manager upset enough to request a partial upgrade
[20:58] <jdong> more importantly is don't break any reverse dependencies
[20:58] <ScottK> The biggest thing to worry about is things with rdpends.
[20:58] <ScottK> Yeah
[20:59] <jdong> and for server packages and other security-sensitive ones, keep in mind the maintenance commitment.
[20:59] <mok0> jdong: maintenance-commitment?
[20:59] <jdong> if we're backporting from one stable release to another, we can easily also backport over subsequent -security updates... but if we plucked mysqld from lucid right now...
[20:59] <serialorder> mok0, thanks looking at it
[21:00] <jdong> it's a bit troublesome if someone finds a security bug in it
[21:00] <mok0> jdong: so, you mean a maintenance commitment from the backporter to keep an eye on problems with the package?
[21:00] <jdong> mok0: right
[21:01] <ScottK> There's no formal commitment, we just don't want to get stuck in a position were it's hard to fix.
[21:01] <jdong> although technically we don't have a support/maintenance guarantee in Backports, we'd rather not take that to an extreme.
[21:01] <jdong> for example, in the past I've dug myself into a hole with Firefox backports before.
[21:01] <ScottK> jdong: Speaking of which, the qt4-x11 in hardy backports needs updating, but I can't find anyone to test it.  It should be a no-change from intrepid-security.
[21:01] <jdong> ended up that we had something like gutsy-backports firefox collecting dust and nobody cared enough to go freshen it up.
[21:02] <jdong> ScottK: hmm if it was a -security change, then my gut feeling would be to just backport it
[21:02] <kklimonda> btw, are there any plans to enable users to easily install selected packages from -backports ?
[21:02] <ScottK> jdong: Well it's also a big stack of other stuff too.
[21:02] <jdong> lovely.....
[21:02] <ScottK> kklimonda: There's a spec for it for Lucid
[21:03] <kklimonda> I almost remember reading something about iit
[21:03] <mok0> Well, I imagine there are many users who don't want to upgrade every 6 months... but still want newer versions and the bug-fixes that come with them. There's a balance between doing that and upgrading
[21:03] <jdong> mok0: absolutely
[21:03] <jdong> mok0: the challenge will be that the testing userbase rapidly declines as a release ages :)
[21:04] <mok0> Using backports should give you a certain amount of updates, but not everyrhing
[21:04] <kklimonda> and what is the general rule about backporting to LTS? for example could I backport package from LTS+2 to LTS? wouldn't it be a problem if someone tried to upgrade system to LTS+1?
[21:04] <ScottK> jdong: qt4-x11 | 4.4.0-1ubuntu5~hardy1 | hardy-backports | source and qt4-x11 | 4.4.3-0ubuntu1.4 | intrepid-security | source
[21:04] <jdong> kklimonda: should be backported to every release in between too
[21:05] <jdong> ScottK: oh groan. Any ABI/API changes there?
[21:05] <jdong> kklimonda: I guess the exception is for LTS's where LTS+1 is already out-of-support.
[21:05] <ScottK> jdong: Shouldn't be.  qt4-x11 promised compatibility
[21:05] <jdong> cool!
[21:05] <jdong> that means we've got an external party to blame right? ;-)
[21:05] <ScottK> Sure.
[21:06] <kklimonda> right, that's how our users will see it ;)
[21:06] <kklimonda> I just had to explain to the irritated user that we don't ship neither gtk+1.2 nor libartsc0 (or similar)...
[21:07] <jdong> haha and I had to explain the same about libstdc++5.
[21:07] <jdong> and it wasn't long ago that someone asked about gcc-2.95
[21:07] <kklimonda> the libstdc++ was always the mess..
[21:07] <maco> 2?
[21:07] <mok0> kklimonda: ... but if you want basic upgrades in GTK or QT versions, you might as well upgrade to a newer release
[21:07] <maco> someone asked in -kernel about 2.6.18 headers
[21:08] <jdong> lol
[21:08] <maco> did any release even ship 2.6.18? edgy was 17...
[21:09] <jdong> yeah we definitely had a 2.6.18.
[21:09] <kklimonda> btw, is it just me or had rmadison got faster for ubuntu lately? I don't have time to prepare a tea anymore ;)
[21:09] <ScottK> But I don't think we ever released with it
[21:10] <jdong> kklimonda: my umadison always gets rmadison answers the fastest.
[21:10] <jdong> (haha yes, uber madison)
[21:10] <dtchen_> no, we never released 2.6.18.
[21:11] <dtchen_> http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.*
[21:11] <jdong> it must be Debian I'm thinking of then
[21:12] <maco> jdong: yeah i think etch had it
[21:12] <maco> centos 5 definitely did
[21:12] <ScottK> Has.  It's still supported
[21:12] <maco> yeah that
[21:12] <dtchen_> linux-source-2.6.18 | 2.6.18.dfsg.1-24 |     oldstable | all
[21:12] <dtchen_> linux-source-2.6.18 | 2.6.18.dfsg.1-26 | oldstable-proposed-updates | all
[21:14] <kklimonda> dfsg? what non-free things linux source have?
[21:15] <maco> ScottK: green button?
[21:15] <jdong> kklimonda: the firmware tree.
[21:15]  * ScottK looks
[21:15] <mok0> kklimonda: the kernel has certain binary blobs that are non-free
[21:16] <ScottK> maco: The task for Jaunty needs to be accepted.
[21:17] <mok0> kklimonda: ... rather, certain kernel modules
[21:17] <maco> ScottK: can i accept it since jdong said ack in here?
[21:17] <ScottK> maco: Yes.  As a MOTU you can in general.
[21:17] <maco> ScottK: i meant in terms of policy
[21:17] <jdong> yes, you can accept the task :)
[21:17] <ScottK> Accepting that task is more like "Yeah, seems like something we might want to fix" whereas motu-sru ack is "this exact fix is approved to go in"
[21:18] <maco> ah ok
[21:18] <maco> ok button pressed
[21:18] <maco> your turn :P
[21:18]  * maco throws hot potato
[21:21] <ScottK> Done
[21:21] <maco> thank you
[21:22] <ScottK> Thank you for taking care of it.  My part's easy.
[21:23] <maco> hey its kklimonda's patch :P
[21:23]  * ScottK notes maco has the buildd's monopolized for all but armel and hppa at the moment.
[21:23] <ScottK> Yeah, but you get to thank him.
[21:23] <maco> hahahaha
[21:24] <maco> already did
[21:24] <maco> (hahahaha @ buildds)
[21:43] <ScottK> ari-tczew (or whoever was asking about qa.ubuntuwire.com): It's fixed.
[21:47] <fabrice_sp> ari-tczew, I'll put on hold the merge of incron: the Debian maintainer seems to be willing to include the patch
[21:52] <ari-tczew> fabrice_sp: I don't know what Debian maintainer is doing
[21:52] <ari-tczew> MoM comment was free, no bug request...
[21:52] <fabrice_sp> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548786
[21:52] <kklimonda> what are going to be requirenments for being Ubuntu developer after archive reorganization?
[21:53] <maco> kklimonda: the definition of ubuntu developer will change a bit
[21:53] <maco> kklimonda: youll apply to the team that covers the packages you concentrate on
[21:53] <fabrice_sp> ari-tczew, I usually reports all patches to Debian to see if Debian adopt the change, so that we can sync after, and reduce the Ubuntu worload
[21:53] <kklimonda> maco: so there will be a desktop team, server team, python team etc. ?
[21:54]  * TheMuso waves from a somewhat similar timezone as some of you.
[21:54] <fabrice_sp> ari-tczew, anyway, you should have asked me before working on the merge: I an the last uplaoder of the pacakge
[21:54]  * ScottK waves back to TheMuso
[21:54] <ScottK> kklimonda: Something like that.  What happens for packages covered by no team is subject of a session at UDS.
[21:55] <maco> kklimonda: theres going to generalist-dev too
[21:55] <ScottK> ari-tczew: fabrice_sp is correct.  The first thing is says on https://merges.ubuntu.com/universe.html is "If you are not the previous uploader, ask the previous uploader before doing the merge. "
[21:56] <kklimonda> ScottK: maybe it's time to admit we don't have manpower needed to maintain all of them? :/
[21:56] <ScottK> maco: How exactly that's going to work is not clear yet (at least to me)
[21:56] <ScottK> kklimonda: Universe has never been as well maintained as Main, but it has improved significantly in the last two years I've been around.
[21:56] <dtchen_> kklimonda: no one has ever claimed that "we" have enough manpower
[21:57] <TheMuso> i/c
[21:57] <kklimonda> dtchen_: true
[21:57] <dtchen_> and yes, it has gotten much better since 5.04
[21:57] <kklimonda> heh, I should get my stuff together and upload all patches for piuparts already..
[21:57] <fabrice_sp> that's why it's better to try to have changes adopted by Debian, instead of merging :-)
[21:58] <ScottK> fabrice_sp: +1
[22:00] <ari-tczew> OK devs
[22:01] <TheMuso> c
[22:01]  * TheMuso must be tired.
[22:01] <TheMuso> ]:)
[22:01] <ari-tczew> fabrice_sp: could you review this bug #434433
[22:01] <kklimonda> is python 2.5 going to be supported in lucid?
[22:02] <maco> TheMuso: why do you say that? because you just flew to yesterday?
[22:02] <ScottK> kklimonda: No.
[22:02] <maco> or from tomorrow to today. or something.
[22:02] <wgrant> One Python version? Excellent.
[22:02] <ScottK> So far
[22:02] <fabrice_sp> ari-tczew, I was having a quick look at bug 482657
[22:02] <TheMuso> maco: Something like that.
[22:02]  * ScottK doesn't know the 2.7 schedule
[22:02] <wgrant> ScottK: Mid-2010.
[22:03] <ScottK> Ah, good.
[22:03] <fabrice_sp> ari-tczew, there seems to be an empty change in debian/rules (dh_installchangelog)
[22:03] <ScottK> Of course we now have exactly no python version in common with Debian.
[22:03]  * ScottK wishes the Ubuntu and Debian python maintainers would coordinate better.
[22:03] <ari-tczew> fabrice_sp: and what next?
[22:04] <fabrice_sp> could you just check if this change has been reported to Debian, and if it seems to be willing to adopt it?
[22:04] <fabrice_sp> s/it seems/Debian seems/
[22:05] <kklimonda> ScottK: python-support ships symlinks for python-support.pth for both 2.6 and 2.5 versions - python-support.pth for 2.5 is a dangling symlink. Can I assume that the same will happen when we ship 2.7? i.e. there will be another dangling symlink for 2.7 installed?
[22:06] <ScottK> If we get 2.7, it won't be dangling.
[22:06] <ari-tczew> fabrice_sp: do you mean about dh_installchangelog ? if yes, it is only a mistake made by me, during edit debian/rules
[22:06] <serialorder> fabrice_sp, perhaps the MOTU merging guides should be updated with directive to check with debian to see if they will accept the merges
[22:07] <kklimonda> ScottK: but in the default instalation when we ship only one version
[22:07] <ScottK> kklimonda: That isn't always true
[22:07] <fabrice_sp> ari-tczew, yes.
[22:08] <fabrice_sp> serialorder, makes sense, yes. You just volunteered to do that, right? :-)
[22:08] <kklimonda> ScottK: so the best idea is to ignore it (this broken symlink is one of things that stops piuparts from working out of the box in ubuntu)
[22:09] <serialorder> fabrice_sp, i guess I did, I just sya that because I work on merges a lot and noboy has ever suggested asking debian to incorporate first
[22:09] <serialorder> if relevant i always submit upstream after themerge though
[22:10] <fabrice_sp> serialorder, I would say both, as Debian may want to integrate the patch before, but that's fine also
[22:10] <fabrice_sp> the goal is to reduce the difference between Debian and Ubuntu
[22:11] <fabrice_sp> so if it goes through upstream, it's fine also (but may take longer) :-)
[22:11] <serialorder> fabrice_sp, sorry i meant deabian not upstream
[22:12] <ari-tczew> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[22:13] <fabrice_sp> for forwarding to debian, submittodebian is your firend :-)
[22:13] <ScottK> kklimonda: I'm not 100% sure.
[22:13] <fabrice_sp> s/firend/friend/
[22:14] <fabrice_sp> it's also a matter of where we are in the dev cycle. Now, we are at the very beginning, so we have 'time' to try to get the patches adopted :-)
[22:15] <ari-tczew> fabrice_sp: you have acked my request, after sync by ubuntu-archive packages will mark as uploaded by me or by you?
[22:15] <fabrice_sp> ari-tczew, by you, I think
[22:16] <fabrice_sp> never paid attention to that
[22:16] <ScottK> ari-tczew: Should be by you, but sometimes it doesn't work out.
[22:16] <ari-tczew> yhym OK
[22:16] <fabrice_sp> ari-tczew, did you saw the comment of mterry in bug 434433
[22:17] <fabrice_sp> he is saying that he should be a sync, and not a merge
[22:17] <fabrice_sp> s/he/it/
[22:17] <ari-tczew> fabrice_sp: yes, but I have more trust for you, so I want to ask you :P
[22:18] <ari-tczew> so do I need to change bug's name and description to sync instead merge?
[22:19] <ScottK> ari-tczew: Yes
[22:20] <ari-tczew> fabrice_sp: you can give a review just now for sync
[22:21] <fabrice_sp> ari-tczew, you can trust him: he is also a MOTU :-)
[22:21] <fabrice_sp> it should be a sync, yes
[22:24] <ari-tczew> fabrice_sp: done, bug 434433
[22:25] <POX> ScottK: Ubuntu and Debian Python maintainers are^Wis the same person
[22:26] <fabrice_sp> ari-tczew, ok. I'm test building it right now
[22:27] <ScottK> POX: I know.
[22:31] <fabrice_sp> ari-tczew, ack'd. Bed time now. Bye
[22:32] <ari-tczew> thanks, bye