[00:04] <classvoid> crimsun, gotcha
[00:11] <classvoid> crimsun, I forced installed the gnustep-devel package without gorm.app - the only error I'm getting now seems to be a pointer confusion with the objc in GormNibWrapperLoader.m - so working on tracing that now
[00:22] <crimsun> fabrice_sp: do you plan to convert 568619 to SRU format for lucid-proposed?
[01:17] <crimsun> classvoid: http://kernel.ubuntu.com/~dtchen/gorm.app_1.2.8-1ubuntu0.1.debdiff
[01:18] <crimsun> classvoid: I'd appreciate if you can test that debdiff so that we can proceed with the SRU process
[01:19] <crimsun> ah dang, karmic has a matching version
[01:49] <RoAkSoAx> SpamapS: /away not here
[01:49] <RoAkSoAx> upsy
[01:49] <RoAkSoAx> :P
[02:05] <G> Is Ubuntu using the dpkg-source 3.0 (i.e. should new packages use it or is lintian been overreactive)
[02:22] <RAOF> G: You can use it, or not, at your choice.
[02:39] <classvoid> crimsun, so not test it lol?
[02:40] <G> RAOF: thanks
[02:46] <classvoid> crimsun, yep that was the fix
[02:46] <classvoid> crimsun, sorry I got caught up in something
[03:41] <imbrandon> evening all
[03:43] <G> imbrandon: kia ora
[03:43] <G> hmmmm, I think this is a pull hair out moment
[03:43] <imbrandon> kia ora?
[03:43] <G> imbrandon: Hello in Maori
[03:43] <imbrandon> ahhh :)
[03:44] <imbrandon> i was hoping it was a "good thing"(tm)
[03:44] <ScottK> All depends on what you're in to.
[03:44] <crimsun> classvoid: did you test the fix locally? (build, install, execute)
[03:44] <imbrandon> G: if you choose not to use 3.0 please specifiy 1.0 in source/format though so others know that you intentionaly dident change
[03:45] <imbrandon> not a "rule" but good to follow imho
[03:45] <G> so, this upstream has a habbit of breaking compatability with previous versions and this bit of (rather useful software) needs an earlier version
[03:46] <imbrandon> G: sounds like a maintainers nightmare ;)
[03:46] <G> the library upstream actually released a special 'version' where they renamed the library so multiple copies could be installed, is this okay (I guess it's kinda like what I've seen with libpng iirc)
[03:47] <G> "This is an update of the original 0.5.1 release that renames exported library/header symbols and header install locations from 'celt*' to 'celt051*' in order to assist in packaging and deploying compatability versions of this prerelease alongside later, incompatible versions of celt. In addition, this release contains fixes to all bugs known to affect the original 0.5.1 release. "
[03:47] <imbrandon> that sounds evil, but dont go by what i'm saying strictly, i'm not a lib packaging guru
[03:48] <imbrandon> so its 0.5.1 + fixes but still versioned 0.5.1 , even more evil ...
[03:48] <G> imbrandon: it's released as 'celt-0.5.1.3' but really it's now celt051-0.5.1.3
[03:49] <imbrandon> crimsun: i been meaning to poke you on a personal note too, do you know of a gui mixer applet that could easily be used ( just for basic volume control ) in fluxbox
[03:49] <crimsun> alsamixergui
[03:49] <imbrandon> crimsun: thanks
[03:49] <G> imbrandon: btw, thanks for the format tip
[03:50] <crimsun> or have an 'x-terminal-emulator -e alsamixer' swallowed
[03:50] <imbrandon> G: yea as i said i'm not a lib package guru, only done a very little bit of it over my ubuntu-dev career the past few years, BUT something about that dont smell "right"
[03:50] <G> imbrandon: where/who is the best person to ask about it?
[03:51] <imbrandon> G: this is probably the place, as to who , i'm not 100% sure ...
[03:51] <imbrandon> ( or #ubuntu-dev durring "business" hours in GMT time )
[03:51] <imbrandon> but honestly porobavly would start here as you have
[03:52] <G> k, see libpng has got a libpng3 and a libpng12 package, so I guess there is some history of this happening
[03:53] <imbrandon> G: first thing i would do if you havent ( and dont take this wrong ) but RTFM ( specificly the debian lib package part ) its rather short and to the point, but in the meantime your on the right track in here with the questions , i
[03:53] <imbrandon> 'm just not 100% the best to awnser them all
[03:54] <G> actually, I'm wrong about libpng3/12
[03:54] <G> imbrandon: hmmm, I'll re-read that part
[03:54] <imbrandon> G: got an upstream url, and current ubuntu/debian source package name ? i'll take a cursory look so i can help a bit more specificly with q's if you wish
[03:55] <G> http://www.celt-codec.org/downloads/ atm there is libcelt in lucid which is 0.7.1
[03:55] <imbrandon> G: yea lib packing is its own beast i have learned, it has some very specific set of guidelines iirc
[03:55] <imbrandon> G: kk
[03:56] <G> I've done Library packaging before in the RH/Fedora world but yeah, seem to hit a brick wall here :)
[03:56] <G> (with this package)
[03:56] <imbrandon> G: as far as history, yea there is history in doing similar things to that but that dosent always mean its "correct" sometimes its to fix fubar stuff
[03:56] <G> turns out all my previous issues were due to silly mistakes like files named wrong :S
[03:56] <imbrandon> kinda gotta watch the changelog context too
[03:57] <imbrandon> yea i havent done any real packing for RPM based distros since the late 90's so i cant really speak to if its the same/diffrent
[03:58] <imbrandon> G: we all do it ( the silly mistakes ) its how to handle the fix and learn form it that counts :)
[03:59] <imbrandon> G: ok afk ~2 minutes gonna check out the webpage and apt-get the source
[03:59] <G> imbrandon: thanks, I'm reading the Debian bit again now
[04:00] <imbrandon> G: kk, yea i dident want it to seam like i was just telling ya to RTFM but in this case its pretty good docs and pretty short and to the point
[04:00] <imbrandon> seem*
[04:00] <imbrandon> from what i rember when i was actively working on libvisual-*
[04:01] <imbrandon> speaking of , i need to update libvisual-plugins badly/soonish
[04:03] <imbrandon> ok after a short cursory look , let me get this right, the "current" version is 0.7.1 both upstream and in the repos, but something else your working on needs 0.5.1 because the API/ABI isnt stable and to complicate things 0.5.1 was re-released upstream to rename the library and add some minor bugfixes
[04:04] <imbrandon> am i getting that right ?
[04:05] <G> yeah pretty much
[04:05] <imbrandon> assuming that the above is correct, the obvious question that comes to mind is can this other project/package be {,relatively}easily updated to the 0.7.1 API/ABI ?
[04:06] <G> I don't think so
[04:06] <imbrandon> k
[04:06] <G> now, looking at the Debian guide and how this library builds
[04:06] <imbrandon> sooo what we're looking at now is making them ( 0.7.x and 0.5.x ) live togather nicely but still follow guidelines for the distro
[04:07] <G> the 0.5.1.x builds with a soname of: libcelt051.so.0.0.0
[04:07] <G> which doesn't conflict with /usr/lib/libcelt0.so.0.0.0
[04:08] <G> upstream has done all the work that I can see to not make the two conflict
[04:09] <imbrandon> that seams feaseable to do and i can help with some general package and even maybe a bit of lib pacaking issues, but we're gonna have to enlist another MOTU/Core-dev/DD more familiar with the specifics of this situation, my first instinct is to find a (set of) pacakge(s) that do this same type issue that have a relitively active maintainer to pick his/her brain a bit
[04:10] <imbrandon> ( if anyone is reading this log and knows of such a person/package set feel free to speak up hehehe )
[04:10]  * G goes and has a look in apt for such possible packages
[04:11] <imbrandon> G: are you upstream for the other project or just packaing/intrested in it
[04:11] <imbrandon> wow lets see how many diffrent ways i can typo packing tonight
[04:11] <imbrandon> lol
[04:12] <G> imbrandon: quite interested in it
[04:12] <G> I actually worked a quite a bit with it in a previous job
[04:12] <G> imbrandon: not as many as I've forgotten sudo in front of aptitude or mispelt debuilder I'm sure :)
[04:12] <imbrandon> G: btw if you need a sponsor for uploads after this is all streight poke me , havent seen your IRC nick arround so i'm assuming your currently not a MOTU or Have PPU ( since the package dosent exist yet )
[04:13] <G> I'm a newbie
[04:13] <G> I've already got 2 down :)
[04:13] <G> in a PPA
[04:13] <imbrandon> and i dont mean just tonight , anytime, imbrandon@ubuntu.com or lp:~imbrandon has my contact info but i'm on IRC tons
[04:14] <G> so, we've got libxml++1.0-dev & libxml++2.6-dev
[04:14] <imbrandon> and its my prefered contact method , email being second
[04:14] <imbrandon> G: looks like a good place to start, who is listed as the maintainer
[04:15] <G> Ubuntu Developers
[04:15] <ScottK> imbrandon: I disagree about specifying 1.0.  No source/format means 1.0.  Anyone who thinks that can be reliably changed in on crack.
[04:15] <ScottK> Specifying is just busywork and encourages the crazies.
[04:15] <imbrandon> also just curious, does upstream ( as far as you know ) going to be doing further releases ( easp security updates ) for the 0.5.x branch , this can be a big factor in if we should actualy persue this path further
[04:16] <G> imbrandon: that I'm not sure about
[04:16] <G> imbrandon: however...
[04:16] <G> imbrandon: any security fixes for it can be obtained in conjuction with Red Hat
[04:16] <imbrandon> ScottK: well i more ment if the package is being updated anyhow, not a special delta/upload just for that AND you specificly want it 1.0 not just "i dont wanna do the work to update to 3.0 right now"
[04:16] <imbrandon> ScottK: but i see your point
[04:17] <G> so security fixes will be available
[04:17] <ScottK> imbrandon: Not specifying source/format = 3.0 means you don't want 3.0.  That's sufficient.
[04:17] <imbrandon> G: good, thats good news, packages that would be known not to have a ( esp security ) support path arent really suitable for inclusion in the repo IMHO
[04:18] <imbrandon> ScottK: true, i guess i was just over thinking it
[04:18] <G> so yeah, it should pass on a security sense
[04:18] <imbrandon> kk, was just a thought , figured i'd mention that before we got too far
[04:18] <ScottK> imbrandon: Not really.  the dpkg maintainers started out with that idea, but I think they've calmed down now.
[04:19] <imbrandon> ScottK: :)
[04:19] <G> imbrandon: okay, well what I might do is get a package in my PPA and see if I can find the person that really looks after libxml
[04:21] <imbrandon> G: yup, and rember this is all just sugestions based on my past experince as a ubuntu developer, please dont hesitate to "call me" on something if somethign i say seems wrong, and this way is by FAR not the only path to follow, just trying to get ya the path of leaste resistance, and yes a PPA to start off is probably a good idea ( maybe even a linked bzr branch with the packaging so others ( like me ) can help out now and then with a branc
[04:22] <G> I think I'll leave learning BZR to tomorrow :)
[04:23] <imbrandon> also looking at other ( smaller ) sets of packages might yeild a bit of good info too, not just one example, that way you dont accidently model after something that just a quark/workarround in that particular package set
[04:23] <imbrandon> G: yea this isnt a one day thing, just getting the process started will likely be a few days minimum
[04:24] <imbrandon> but once the basics are there and the policy is clear on what needs to be done it will go much faster/easier, and later updates will be MUCH easier
[04:24] <G> yeah, I used to do some Debian packaging in about 2005
[04:24] <G> so a bit is coming back to me, but it's changed quite a bit as well :)
[04:25] <imbrandon> plus you might find you actualy like packing and do some other packages in your spare time in the future :) the MOTU/Ubuntu-Dev team(s) are always looking for help even if its limited
[04:26] <G> yeah, sounds like what I want to get into again
[04:27] <G> imbrandon: FWIW, end goal is https://bugs.launchpad.net/ubuntu/+bug/500385
[04:28] <imbrandon> yea and one thing to note too as much as we are very very very much like debian packaing wise, policys might not always be 100% ( or even close ) to the same, so the documention for the technical aspects of packing IMHO are more plentful if you look for "debian" guides etc  and a little deeper on the "why's" of things, the policys for inclusion/updates/uploads/maintainers/etc etc etc ( the non strictly technical stuff ) you should learn/loo
[04:28] <G> and the two packages I've rolled so far are in dev-nigelj/ppa
[04:29]  * imbrandon looks at the bug 
[04:29] <imbrandon> G: yea even if you dont "get into" it full time , its something fun to know how to do and be able to help out with now and then as time permits
[04:30] <G> imbrandon: yeah agreed
[04:30] <imbrandon> plus makes filing useful bug reports easier ( and your morelikely to get a positive response/fix ) if you know at least a bit behind the secenes stuff
[04:32] <imbrandon> G: just curious, are all 3 of those "packages" listed part of the same upstream or at leaste same upstream team ?
[04:32] <imbrandon> ( again just trying to get a better overall picture )
[04:33] <imbrandon> also are you "Liang Guo" or are you working with him/her ( the person that filied the debian ITP "intent to package" )
[04:33] <G> imbrandon: qpixman & qcairo are (effectively) forks from the same upstream as SPICE, celt is xiph
[04:34] <G> nope, no idea who Liang Guo is
[04:34] <imbrandon> G: i mean the ones listed on the linked LP bug quote "There are probably 3 packages needed - vdesktop, spice client, spice server"
[04:34] <G> oh they are the same upstream
[04:35] <G> spice client & server are sub packages fromthe same source
[04:35] <G> vdesktop is a second source
[04:36] <imbrandon> G: ok then, the very next thing we need to do before going much further ( going to re-read the ITP to make sure its upto-date and he is still active with it ) is contact Liang Guo, he filed and ITP for it in Debian and if he packs it in debian it will sync to ubuntu "sutomatic" but its generaly a bad idea to have one package in ubuntu and one in debian both based on diffrent packaging ( keeps long term maintance to a minimum )
[04:37] <imbrandon> and if its packed in debian and packed diffrently in ubuntu ( but has the same "result" or accomplishes the same goal ) generaly the ubuntu package will be dropped in favor of the debian one
[04:37] <imbrandon> and we dont want to waste work/duplicate work in that way if not nessesary
[04:39] <imbrandon> G: if you dont mind whats your LP id so i know when i'm looking at your comments/bugs pertaining to this ( if you dont mind me asking )
[04:39] <G> imbrandon: yeah, the ITP has been inactive since it was filed Dec 09
[04:39] <G> imbrandon: dev-nigelj
[04:39] <imbrandon> kk
[04:39] <G> (Nigel Jones)
[04:40] <imbrandon> G: well dec-09 isnt really considered that long in Debian terms , so we need to be 100% certain, sometimes things ( annoyingly ) move a bit slower over there
[04:40] <imbrandon> lets atleaste touch base with him, i can draft the email and cc you and the debian ITP bug if you wish
[04:40] <imbrandon> i have done similar in the past
[04:40] <ScottK> That's the right thing to do.
[04:40] <G> imbrandon: yeah, would be interested
[04:40] <imbrandon> ( i'm assuming "him" no offence if its not , bad habbit )
[04:41] <G> (I had a look at his site, it is a him)
[04:41] <imbrandon> G: :)
[04:41] <ajmitch> imbrandon: I see there's no reply on the ubuntuone ITP?
[04:42] <imbrandon> ajmitch: nope, nor to a second email i sent to him too, and he is accepted me on jabber but i never see him online
[04:42] <ajmitch> possibly just a little busy at the moment, who knows
[04:42] <imbrandon> ajmitch: i'm thinking about sending one more email to that ITP being a just a little more direct
[04:42] <imbrandon> but not overbearingly
[04:42] <imbrandon> since we know he is atleaste semi active
[04:42] <ajmitch> best not to be annoying
[04:43] <imbrandon> right, not annoying, just a kinda "followup" since its been , what 2 weeks atleast
[04:43]  * imbrandon would neede to go back and look at the date 
[04:43] <imbrandon> s/neede/need
[04:44] <ajmitch> may 3
[04:44] <ajmitch> so ~ 2 weeks
[04:45] <imbrandon> ajmitch: i did have one more lower level package that is a requirement of some of the *ubuntuone* packages that i filied an ITP for that dosent currently have anything depending on it in debian and would block some of the other stuff, mind looking over my package job and being my debian sponsor for it ( possibly co-maintain it too if you so wish )
[04:45] <ajmitch> imbrandon: happy to
[04:46] <imbrandon> bascily its just a slightly modified ubuntu package ( minor cleanups and policy bumps etc ) i'll get the source/dsc reasy later this evening and shoot ya an email ( use you @ubutnu one ?? )
[04:46] <imbrandon> ready*
[04:46] <ajmitch> either that or @debian.org
[04:47] <imbrandon> kk
[04:47] <imbrandon> you deb one is ajmitch at , correct ?
[04:47] <ajmitch> yep
[04:47] <imbrandon> kk
[04:47] <imbrandon> i'll probably use that one since its going into debian, unless you feel strongly otherwise
[04:48] <ajmitch> nope, I prefer to use debian addresses for debian stuff
[04:48] <imbrandon> kk
[04:48]  * imbrandon wishes to have a @debian email address one day, my goal is by summers end, lets see if i can hold to it
[04:49] <imbrandon> G: ok i'm going to draft that email to the ITP and cc you/me in it, i'll ping ya back in here in a few so you can watch for the email
[04:50] <imbrandon> no need to reply or aything, but you might pay attention to the contents/thread as it will set the stage on how we proceed officialy ( you can still get the practice and possibly pre-work done in your PPA , it will be good to point the ITP there too if you get something fairly stable policy wise there )
[04:51] <imbrandon> aned help work out possible unknown/unforseen conflicts before they hit a wider audiance
[04:51] <imbrandon> and*
[04:53] <imbrandon> G: btw welcome to the ever fun ( no sarcasim intended ajmitch / ScottK , lol ) world of ubuntu maintaince :)
[04:53] <ScottK> imbrandon: I wouldn't have guessed you intended sarcasm.
[04:54] <G> imbrandon: if it's anything like Debian/Fedora I'm prepared :)
[04:56] <imbrandon> G: many many similarities with debian for sure, and we try to work as closely with/in their system as possible to limit the "man power" needed to long-term maintain the Universe, 16000+ packages in universe is alot to do for the unbeknown to many small team of dedicated ACTIVE motu's
[04:58] <imbrandon> if i had to guess i would say about ~40 ACTIVE motu's max at a given 90 day "cycle", maybe less, so any help is always aprecieted , even just small amounts, and its a HUGE plus if you strive to do things "the right way" even if its gray/means more initial work
[04:59] <imbrandon> but that number is totaly just made up by me, i wouldent even know where to get that metric
[04:59] <imbrandon> just an semi-uneducated guess
[04:59] <G> wow, I thought there would be more
[05:00] <ScottK> Many contributors aren't MOTU yet and have their work sponsored until they are.
[05:00] <ScottK> We get ~75% of our packages unmodified from Debian.  That helps a lot.
[05:00] <imbrandon> yea many people do, iirc there are about ~60 members of the MOTU team on LP with upload rights, but at any given time a few are inactive for any number of reasons , either long term due to burnout/other or just short vactaion type breaks
[05:01] <imbrandon> but yea as ScottK a TON of work also comes from non-MOTU's ( yet ) like your self that do something and get it sponsored by people like ScottK / myself / ajmitch or a plenthora of others ( although more of that is always welcome too )
[05:02] <G> now I know the right time to ask for new package endorsements in REVU :)
[05:04] <G> bbs, going to grab a coffee
[05:04] <imbrandon> i _try_ to be a jack of all trades ( and end up inevatibly being a master of none ) when it comes to ubuntu development , but that allows me to work on many intresting packages/projects and helps me personaly so i dont get burned out as easy ( change is good for me ) , and there is almost constantly a need for "sponsors" both MOTU and Core-dev and a jack-of-all is well suited for that too since even if he/she dosent know the correct way for
[05:04] <ScottK> G: Actually we generally prefer new packages to come in through Debian since you can take closer owership of packages that interest you there and it minimizes the maintenance burden here.
[05:04] <fabrice_sp> crimsun, re 568619: TBH, I totally forgot about it, so go ahead (I saw you had a debdiff)
[05:04] <ScottK> It's also generally easier there since there are so few of us.
[05:05] <fabrice_sp> ScottK, what do you think about bug #531973 ? Do you know if there is any plan to get back the -mpi packages in boost?
[05:06] <imbrandon> G: yea REVU is ok in theory, and if there were more strictly Ubuntu volenteers it would likely be more viable , but as it stands its generaly an under-utilized tool because as ScottK said we like to work inside debian as much as possible unless its something that is TRUELY ubuntu specific, but that is a very rare case
[05:06] <ScottK> It's technically accureate, but we don't provide the mpi packages.
[05:06] <ScottK> I'll comment in the bug.
[05:06] <fabrice_sp> ok, so my proposal to delete the -mpi-* packages from boost-defaults is right then
[05:07] <fabrice_sp> You also have bug #582420
[05:08] <imbrandon> G: the Debian equivilant of REVU is the "Mentors" program ( google the debian wiki ) at http://mentors.debian.net ( or .org, not 100% check the link ) and #debian-mentors on OFTC, dont feel we're pushing you there but its generaly a good idea to know it exists
[05:09] <imbrandon> etc etc etc
[05:10] <ScottK> fabrice_sp: yes.
[05:11] <fabrice_sp> ok. Thanks!
[05:11] <ScottK> Even better it means you can be TIL boost-defaults an not me.
[05:12] <G> back
[05:12] <ajmitch> heh
[05:12] <ajmitch> ScottK: for some reason noone really wants to touch boost
[05:12] <G> imbrandon: yeah, they changed that around shortly after I finished
[05:12] <G> it was similar but they revamped it a bit
[05:13] <ScottK> and yet we do anyway, don't we.
[05:13]  * ScottK goes off to bed.
[05:13] <fabrice_sp> ScottK, TIL?
[05:13] <ajmitch> fabrice_sp: Touched It Last
[05:13] <ajmitch> in other words, you're responsible for it for eternity
[05:13] <fabrice_sp> oh :-)
[05:14] <fabrice_sp> boost-defaults is quite easy: it's only a package that wraps the boost packages, so not so complicated to maintain :-)
[05:14] <fabrice_sp> and it's main, so someone will need to upload it :-)
[05:14] <ajmitch> we'll let you have the TIL on boost1.42 as well if you want
[05:15] <fabrice_sp> hmm, let me think a bit about it.... :-)
[05:15] <G> haha
[05:15]  * ajmitch touched boost1.40 last, but it's redundant in maverick
[05:16] <fabrice_sp> you're lucky: 1,42 is default in Maverick :-)
[05:16] <ajmitch> yes, the patch I'd stuck in 1.40 should be in 1.42
[05:16] <ajmitch> since I grabbed it from upstream SVN
[05:16] <fabrice_sp> lucky you :-)
[05:17] <G> imbrandon: I'm going to guess most of the virtualization work is been done in Debian not Ubuntu directly
[05:17] <imbrandon> G: i would assume that too, as is _most_ major kernel work, but i would need to verify that
[05:18] <imbrandon> gnight ScottK
[05:18] <G> oh wow, all the chromium/mozilla daily builds hit PPA at the same time? :P
[05:19] <imbrandon> fabrice_sp: i can upload if your talking tonight, if not i would poke ScottK  as he is more familiar with it
[05:19] <imbrandon> ( boost-defaults )
[05:20] <ajmitch> thought as was said, it's a tiny package, nothing really to worry about
[05:21] <fabrice_sp> imbrandon, cool ! I'm trying to fix some FTBFS in packages that uses it, so that would be great :-)
[05:21] <fabrice_sp> very tiny: only a debian directory :-)
[05:21] <imbrandon> ajmitch: :)
[05:21] <G> imbrandon: btw, if I wanted to supplement my packaging with patches (I'm thinking FTBFS) whats the right way of going about it
[05:21] <imbrandon> fabrice_sp: sure, np, i'm mostly IRC and Triaging stuff tonight anyhow, might poke a merge or two later, so i ahve time
[05:21] <imbrandon> have*
[05:22] <G> imbrandon: I'm guessing packages in Ubuntu aren't exactly owned by anyone?
[05:22] <G> based on what I'm seeing and Maintainer = motu in the debian/control files
[05:23] <imbrandon> G: correct so any MOTU/Core-Dev/Contributor with a sponsor could theroyeticly update/pacth the package, although see the above talk about TIL , _most_ atleast ping the person that touched it last(tm) to make sure its "ok" although that happens far less in Ubuntu than in Debian ( due to general policys )
[05:23] <fabrice_sp> G, exactly: ubuntu is team maintained, even if the TIL rule apply :-)
[05:23] <fabrice_sp> too slow :-)
[05:24]  * fabrice_sp stil wakes up...
[05:24] <imbrandon> G: correct, there is a wiki that explains the Maintainer field in Ubuntu, we have a very diffrent policy than debian but it works well imho ( as does debian policy for their release cycle / dev style )
[05:26] <imbrandon> and the TIL isnt a "rule" or "policy" per-se , its one of those courtsy things most of us try to follow, but not 100% set in stone for Universe packages
[05:26] <imbrandon> kinda just one of those things you pick up form hanging out in here
[05:26] <imbrandon> from*
[05:28] <fabrice_sp> it's not really a rule, right, but it's really useful as the last uploader should know a bit the package, and you could avoid uploading something bad
[05:28] <ajmitch> and for merges, it avoids duplication of effort
[05:28]  * fabrice_sp remembers uploading a fix to a FTBFS that was normal
[05:29] <fabrice_sp> yeah
[05:29] <ajmitch> since the last uploader may have spent time already getting something prepared
[05:29] <imbrandon> but if you have a solid patch/update to a package and the last person to touch it isnt readily available / or unresponsive ( this term is relitive and applies diffrently to debian and ubuntu and even certain packages in each too , another thing to just "catch onto" ) dont hesitate to get it sponsored ( or later when a MOTU upload it ) 9/10 the TIL person will be greatful , esp if you did the due diligance to ping them AND the change is sane
[05:29] <fabrice_sp> :-)
[05:30] <imbrandon> bascily the MAIN reason IMHO to ping the TIL person ( and again just my opinion ) is they likely are intimate with the package and can spot potential problems with a proposed change easier than just any ol' MOTU/Core-Dev
[05:31] <imbrandon> and/or may have been working on other changes localy ( bad habbit ) that could be uploaded at the same time
[05:32] <ajmitch> in semi-unrelated news, merging changelog by hand gets a bit tedious
[05:32] <imbrandon> but bzr pacakge branches ( or git in debian ) alieve alot of that latter problem
[05:32] <imbrandon> ajmitch: hehe, arent there tools for that , like mom
[05:32] <ajmitch> imbrandon: it's bdeing done by hand because LP *still* isn't updating properly
[05:33] <imbrandon> G: by allowing the TIL / psudo-maintainer to commit changes to bzr when they might not be 100% ready for an upload and/or dont warrent an upload by them selfs
[05:33] <imbrandon> ajmitch: ouch, isnt that a debian but though ( in the generated Sources{,.gz.bz2} ) ??
[05:33] <imbrandon> s/but/bug
[05:34] <ajmitch> imbrandon: yes, which breaks mirroring
[05:35] <imbrandon> G: but alot of this is just general ubuntu-dev guidelines , dont get overwelmed by the specifics just yet, me and other sponsors will help you with that part, mostly concentrate on the technical aspects of the packages and the rest will fall into place over time
[05:35] <imbrandon> esp if at first you just plan on touching this small subset of packages
[05:37] <imbrandon> ajmitch: i wonder ... if it would be sane for LP/Canonical to "mirror" the canoncial Debian archive ( i'm sure they do already ) and then re-generate the Sources{,.gz,bz2} for just that internal mirror that LP uses to do the bzr branches of debian packages
[05:37] <imbrandon> i guess it would depend on the ETA to a fix in debian too, no use in doing all that work if it will be fixed relitively soon
[05:38] <imbrandon> or if the signature/gpg mismatches would break other things even if it was internal only and only for the bzr imports, not say like buildd's
[05:38] <fabrice_sp> ajmitch, just use meld :-)
[05:38] <ajmitch> fabrice_sp: or just stick the new debian revision on top of the ubuntu changelog, and then add a new revision for the merge...
[05:39] <imbrandon> ajmitch: hahahah sounds like something i would do , shhhhh
[05:39] <fabrice_sp> meh, that's not fun!
[05:39] <fabrice_sp> :-)
[05:39]  * imbrandon has never done that .... *looks arround*
[05:39] <ajmitch> imbrandon: given that it's what a merge should do anyway
[05:40] <imbrandon> G: did you say you had some "dirty but working" packages of the modified 0.5.1 rerelease ? are you gonna put them in your PPA soonish ? i'd like to poke your initial job of them
[05:41] <imbrandon> ajmitch: yea i thinks its sane to do that, but the KDE team in general wants *ALL* changeslog entries preserved
[05:41] <imbrandon> not really needed IMHO, but meh
[05:41] <G> imbrandon: they are in PPA, but are stuck waiting for all the dail browser builds :)
[05:41] <G> https://launchpad.net/~dev-nigelj/+archive/ppa/+packages
[05:41] <imbrandon> G: kk, yea i dident nessesarly mean this minute, but i will grab them "soonish"
[05:41] <ajmitch> imbrandon: adding the debian revisions on top of the current ubuntu changelog preserves all revisions
[05:41] <imbrandon> great
[05:42] <G> imbrandon: you should be able to dget the .dsc file though :)
[05:42] <ajmitch> since it means I'm just adding 1.2.14-{5,6} on top of an already merged changelog
[05:42] <imbrandon> ajmitch: but not in order does it, or am i thinking about what you said wrong, i might be just visualising it wrong
[05:42] <ajmitch> you're probably thinking about it wrong
[05:42] <imbrandon> yea, likely
[05:43] <ajmitch> the debdiff that comes out of it looks right, at least
[05:45] <imbrandon> i'm thinking about cases like where debian is two or 3 revisions behind ubuntu ( same upstream version ) and then the DD/DM "merges" the ubuntu changes into the package and increments the -X revision but only add's that changelog entry, not all the previous ubuntu change log entries, so that it can be merged back into ubuntu with say one ubuntu delta left, well if it was upto the KDE fellas ( and i'm not saying they are wrong , its just "me
[05:46] <imbrandon> see what i mean, or was i clear as mud
[05:46]  * ajmitch needs some alcohol to understand that one
[05:48] <imbrandon> hehe so say i have gentoo_0.1-2 in debian and gentoo_0.1-2ubuntu3 in ubuntu, the DD "merges" the ubutnu all the revisions into gentoo_0.1-3 , but dosent add the Ubuntu changelog entries, instead adds something like "merged ubutnu revisions X,Y and Z" as the -3 changelog entry
[05:49] <G> imbrandon: when is the DIF?
[05:50] <imbrandon> when it comes time to do gentoo_0.1-3ubuntu1 KDE best practices are to add the gentoo_0.1-2ubtunu{1-3} changelog entries back in the changelog where they *should* appear , as well as obviously the new -3ubutnu1 changelog entry
[05:50] <ajmitch> imbrandon: you're assuming that ubuntu changes are going into debian, rather than being ubuntu-specific
[05:50] <ajmitch> https://wiki.ubuntu.com/MaverickReleaseSchedule
[05:50] <imbrandon> G: i'm not 100% certain this cycle, it should be on the release schedule wiki, one sec i'll look and link so you can have a refrence
[05:50] <ajmitch> looking at that, in 5 weeks time
[05:50] <ajmitch> assuming that the schedule isn't changed
[05:51] <fabrice_sp> imbrandon, AFAIU, it would be ok, as you will use 0.1-2ubuntu3 changelog as bases, paste the 0.1-3 debian entry and add your 0.1-3ubuntu1 on the top
[05:51] <fabrice_sp> so it would contain everything (or I am missing something :-/ )
[05:51] <imbrandon> G: yea that link, and as ajmitch said, it sometimes is adjusted a little, and this cycle its even more likely to be adjusted because of the shortened 10.10.10 release goal
[05:52] <G> right
[05:52] <ajmitch> fabrice_sp: that's exactly what I did
[05:52] <imbrandon> fabrice_sp: correct, but it would be just as correct IMHO to just add the 0.1-3ubuntu1 changelog entry leaving the other dropped like debian
[05:53] <imbrandon> ( changelog entry, no chnages them-selfs )
[05:53] <fabrice_sp> dropping entries in the changelog is not the way I've been teached :-)
[05:54] <fabrice_sp> but I see your point: if all Ubuntu changes have been adopted, what is the point of keeping the old changelog entries?
[05:54] <imbrandon> G: but as long as you check that page ( i would say weekly ) you should have a good idea of the general Freeze dates because as they change that page is generaly kept upto date fairly accurately
[05:54] <G> imbrandon: great thanks
[05:54] <G> imbrandon: saw your bug entry so was curious
[05:55] <fabrice_sp> DIF is only when the packages stop being imported auomatically: you can still request a sync with a bug report
[05:55] <imbrandon> fabrice_sp: well more like if debian dropped the changelog entries no real need to specificly go back and add them as long as the changes are actualy applied and they are summerized in the changelog where the DD merged them
[05:55] <imbrandon> but again, thats just my thought, i really dont know about "best practice" in that situation and the KDE Ubuntu says otherwise
[05:56] <imbrandon> KDE Ubutnu Team :)
[05:57] <imbrandon> G: yea, i wanted to update the Ubutnu bug before i sent the ITP reply email since I am refrencing it. just so eveyone is 100% clear on the intentions and no ones feelings get steped on
[05:57] <ajmitch> imbrandon: what are you trying to hijack today?
[05:58] <imbrandon> sometimes a "hostle" takeover of a ITP ( even via Ubuntu ) isnt looked upon nicely , and just adds unneeded tension
[05:58] <imbrandon> ajmitch: nothing myself, helping G ( as a mentor ) take over/help with the redhat vnc/nx clone/replacement
[05:58] <G> ajmitch: debbug 560721 (Spice)
[05:59] <ajmitch> talk about a confusing name
[05:59] <imbrandon> called "Spice" , not heard of it till tonight, but looks like a cool concept even if there are 100000 other things that have a similar goal
[06:00] <imbrandon> like NX/VNX/X11 Remote/RDP etc
[06:00] <imbrandon> VNC*
[06:00] <G> imbrandon: it's actually used for virtualization
[06:00] <G> low bandwidth sound and video transfer
[06:00] <ajmitch> the name is confusing because there's a circuit simulator already in debian called spice (package name ngspice)
[06:00] <imbrandon> only virtualization ? or just mostly/targeted twords ? admitidly i only read a small fraction of the sites homepage
[06:01] <G> imbrandon: targeted towards, but there is nothing stopping other implementations
[06:01] <imbrandon> ajmitch: ahhh like the old falcon prblems when Seveas was working on getting Falcon in Ubuntu/Debian and so was the Falcon programing Language/Compiler
[06:01] <imbrandon> G: ahh kk
[06:03] <imbrandon> G: i'm sure as you get further along in the process i'll inevatibly pickup more bits of info about it, heck i might even use/help pack it with ya if i get the itch ( i wouldent count on it though as i normaly touch alot of things and only very few maintain totaly or even partialy myself on a long-term basis , thus trying to help you along and not just saying "oh i'll package that for you", lol )
[06:04] <G> imbrandon: not expecting it on a gold platter :)
[06:05] <G> I'm happy to do the grunt, just getting it into a Ubuntu concept is what I'm having trouble with
[06:06] <imbrandon> actualy i think konversation ( no defaunct KDE3 irc client ) , apt-mirror ( i'm also 1/2 of upstream ) and libvisual/libvisual-plugins ( purely out of selfish reasons because no one else wanted to update them and i enjoy using them ) are really the only packages i keep "under my belt" in Debian/Ubuntu
[06:07] <imbrandon> G: totaly understood, its alot to take in, as the bits fall into place other things that arent explicitly explained will make more sense too i'm sure, its been so long since i was new to ubuntu its hard to rember but iirc thats how it was for me
[06:09] <imbrandon> and i had a few hearty souls like ajmitch, Riddell, crimsun, and StevenK around when I started to help me down the path your starting ( my first "fix" was to make kbfx [defaunct in KDE4] work , long long ago ).
[06:09] <imbrandon> :)
[06:09] <ajmitch> heh
[06:10] <imbrandon> and holy sh*it that was darn near 5 years ago, does not seam NEAR that long, more like 1.5 years or soemthing to be very honest
[06:11] <ajmitch> you're old :)
[06:11] <imbrandon> being more active at sometimes more so than others
[06:11] <imbrandon> ajmitch: if i'm old your ancient :)
[06:11] <imbrandon> lol j/k
[06:11] <ajmitch> quite true
[06:11] <ajmitch> now I must run off & catch a bus home
[06:11] <imbrandon> not age wise, but round these parts ;)
[06:11] <imbrandon> ajmitch: ttyl
[06:12] <imbrandon> ajmitch: you've been here pretty much since the inception of MOTU havent ya ?
[06:12] <imbrandon> or close
[06:14] <imbrandon> G: TONS of things have changed over the years, people, policy, workflow, etc. dont be afraid to adopt the workflows etc to your "style", in the end the main thing that matters is a stable package that is well maintained ( within reason ) and that it follows current policys where feasible/required
[06:16] <G> imbrandon: thanks
[06:16] <imbrandon> not tooooo much is set in stone, and new ideas/sugestions are always welcomed. you might also check out the #ubuntu-classroom channel and wiki as sometimes there are package maintance "classes" held , and other intresting things where you can quiz an "instructor" realtime and the logs are made public for others to learn from later too, some of it may be a bit basic for ya if your familiar even with 2005ish debian packing, but a good place t
[06:17] <imbrandon> not everything in there is development related, but there is generaly somewhat of a schedule posted somewhere on those wiki pages
[06:17] <G> yippee! spice builds :)
[06:17] <imbrandon> :)
[06:18] <G> well, I've worked out the BRs
[06:18] <imbrandon> G: what virt platform is it targeted to , i'm guesing Xen since it was intialy started/maintained by redhat
[06:19] <G> imbrandon: qemu/KVM
[06:19] <G> It's actually from Quramnet (brought by RH) that wrote KVM
[06:20] <imbrandon> and last question before i go RTFM myself on the project upstream website, does it work with other platforms like a {Free,Net}BSD, Darwin, Windows, or other Guest OS's ?
[06:20] <G> errr Qumranet
[06:20] <G> there is a Windows SPICE Client (I think Mac too)
[06:22] <imbrandon> i've seen the name in passing on the web, dont know much about them, i'm mostly an end user when it comes to Virtualzation like OpenVZ, KVM, or Zen ( linode rocks ), at work/home i tend to use VMware ( Server or ESXi ) , yes yes evil I know, that has a built in RDP "console" server
[06:23] <imbrandon> or on the off chance qemu-* for some ( often failed ) attempts at semi-native cross compiling for PPC/Sparc/Arm{el}
[06:23] <imbrandon> havent really done even that though since the PPC port of Ubuntu was dropped from offical status, lack of enough tuits i guess
[06:27] <imbrandon> G: ok ITP mail sent, you should get a CC soon and it should also show up as a reply to the ITP bug too
[06:27] <imbrandon> my outgain mail is a tad slow, so it might be ~20 minutes
[06:27] <imbrandon> outgoing*
[06:28] <G> btw, how can I cancel a PPA build?
[06:28] <G> made a big boo-boo
[06:31] <hyperair> G: upload a new one. quickly.
[06:31] <hyperair> G: oh you can also delete it.
[06:33] <G> hyperair: I'll try the upload method, sounds less intrustive :)
[06:33] <imbrandon> moins hyperair
[06:33] <hyperair> moins imbrandon
[06:34] <imbrandon> G: if you upload a new one make sure to incrment the version, i *think* the PPA will puke if you upload the same version even if its diffrent technicly
[06:34] <imbrandon> if you dont want to increment it, then wait till it "dies" and delete it
[06:35] <G> imbrandon: I've already fallen for that trick :)
[06:36] <hyperair> imbrandon: more like delete it, then wait for it to completely die.
[06:36] <imbrandon> hehe
[06:37] <G> ahhh PPA queue is up to 3 hours now :)
[06:38] <imbrandon> G: it will likely fluctuate this early in the cycle alot are doing the same as you, also i've personaly noticed that time to be a bit "off" sometimes it says "1 hour" and builds 10 minutes later, and other times it says "30 minutes" for 6 hours
[06:38] <imbrandon> :)
[06:38] <G> imbrandon: as there are 60 jobs and a lot of them are xulrunner/chromium/etc I'll believe the est
[06:39] <G> imbrandon: also, it originally quoted an hour, and an hour later I realised my mistake :P
[06:39] <G> and it only had built x86_64
[06:40] <imbrandon> i think the same person that wrote the code to esitime the buildscore/buildtime must have been on the Microsoft team for Windows download/file copy dialogs, hahah j/k no ill intended if that particular dev is in here ;)
[06:40] <imbrandon> estimate*
[06:40] <G> ahhhh, there are still 37 mozilla builds in the queue
[06:41] <imbrandon> i've doubed things that the time fluxuates greatly ( in both directions ) like that based on "Windows Time" , heh, bad i know
[06:42] <imbrandon> G: good thing mozilla builds fairly quickly, and a FTBFS would make it even quicker :P ( not that i hope thier dailies are broken )
[06:43] <G> imbrandon: yeah, I guess at least it's not OO.o :P
[06:44] <imbrandon> hahaha exactly
[06:45] <kobrien> :( packaging ain't going well
[06:49] <kobrien> does cdbs not have access to path?
[06:53] <imbrandon> kobrien: your debian rules should , like $(PATH) , or PATH:=/usr/bin:$(PATH)
[06:55] <hyperair> imbrandon: that shouldn't be necessary. the PATH should be set properly before debian/rules is called
[06:55] <imbrandon> hyperair: right, was more of a theroy example of what could be done, should have clarified that
[06:58] <hyperair> imbrandon: amending environmental variables generally doesn't work very well with make.
[07:00] <kobrien> imbrandon: I see. It can't seem to find a particular jar when packaging a java app. Think it's a path problem.
[07:01] <hyperair> imbrandon: oh whoops, env vars seem to work fine, but not stuff passed after "make"
[07:01] <hyperair> kobrien: the error?
[07:02]  * kobrien boots up dev machine
[07:02] <kobrien> been bugging me for days
[07:04] <kobrien> while it boots, I'll say it's a java app and I haven't had any luck in #ubuntu-java
[07:04] <kobrien> no one answered
[07:04] <hyperair> try #debian-java =p
[07:05]  * kobrien facepalm
[07:05] <kobrien> should of tried that
[07:05] <imbrandon> kobrien: yea #debian-java , or if you give us the error we can take a crack at it ( although i have never touched a java pacakge , and only barely a few java non-web apps )
[07:06] <kobrien> No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp
[07:06] <kobrien> I'll ask the debian guys too
[07:08] <kobrien> a quick google will tell me to install ant-optional and apache-ant-regexp, I did and no effect
[07:15] <kobrien> I should point out my jdk is sun-6
[07:17] <G> imbrandon: uh oh, run into a brick wall, GPLv2 + OpenSSL without an explicit exemption, upstream time :)
[07:22] <imbrandon> G: fun fun
[07:22] <imbrandon> G: I ran into that problem with a package a few years ago , never a fun thing because you dont know how upstream will react
[07:22] <imbrandon> G: hopefuly positively
[07:23] <imbrandon> kobrien: can you paste the complete build log to say pastebin ?
[07:23] <G> imbrandon: well thankfully... this is Red Hat and I can point to one of their docs that says OpenSSL isn't compatible with GPL :)
[07:23] <imbrandon> so i have a bit of context
[07:23] <imbrandon> G: true true, not just some single guy with barely buff time in his friends garage coding ;)
[07:23] <imbrandon> bad bad stereo type :) lol
[07:24] <G> actually, they've relicensed to LGPL
[07:24] <G> http://lists.freedesktop.org/archives/spice-devel/2010-April/000264.html
[07:33] <kobrien> imbrandon: sure thing
[07:33] <kobrien> will do another time...gotta run out for a few hours
[07:34] <imbrandon> kobrien: np, kk
[07:34] <eagles0513875> imbrandon: question how does one get a new package into the next release ?
[07:35] <eagles0513875> the packages that have reached their eol are mysql administrator and query browser
[07:35] <eagles0513875> they have been replaced with mysql workbench
[07:35] <eagles0513875> but query browser and administrator are still in the repos for lucid
[07:35] <imbrandon> eagles0513875: the easiest way is to get it accepted into Debian ( via say mentors.debian.net ) before DIF
[07:35] <eagles0513875> is there an irc channel for debian mentors
[07:35] <imbrandon> and then just have them conflict/replace the outdated packages
[07:36] <imbrandon> eagles0513875: #debian-mentors on OFTC ( irc.debian.org ) , although its quite in there sometimes, if you need help and cant find it in there feel free to poke us too
[07:36] <imbrandon> or both ;)
[07:37] <eagles0513875> imbrandon: there is one on freenode but its an invite only channel :(
[07:37] <imbrandon> eagles0513875: yea , a leftover from when debian officialy used freenode probably
[07:38] <eagles0513875> ahhh
[07:38] <eagles0513875> imbrandon: can you explain to me why going via upstream to get the obsolete packages replaced
[07:38] <ajmitch> as well as that, there are existing mysql-workbench packages at http://people.debian.org/~nobse/mysql-workbench-oss/pool/main/m/mysql-workbench-oss/ but not uploaded to debian yet
[07:39] <imbrandon> eagles0513875: well its not so much to get the obsolete packages replaced but more to get the new replacement packages IN
[07:39] <eagles0513875> ajmitch: ahhh ok
[07:39] <imbrandon> that has the side effect of removeing the old ones
[07:39] <eagles0513875> imbrandon: ajmitch just pointed out the link above that mysql workbench hasnt been uploaded to debian :(
[07:39] <eagles0513875> ajmitch: btw thanks for that info
[07:39] <eagles0513875> ajmitch: thats not even a good version
[07:40] <eagles0513875> 5.2 is almost out
[07:40] <eagles0513875> and they are no longer gonna provide support for 5.1
[07:40] <ajmitch> no, but they were done a number of months ago
[07:40] <imbrandon> eagles0513875: yup, if you care for it, you might email that person ( *should* be nobse@debian.org iirc ) and offer to help
[07:40] <eagles0513875> what was the irc channel imbrandon of debian
[07:41] <imbrandon> eagles0513875: it would be a good possible sponsor too
[07:41] <eagles0513875> what do you mean
[07:41] <imbrandon> the mentors ? irc.debian.org #debian-mentors , and http://mentors.debian.org
[07:41] <imbrandon> or .net , lemme look
[07:41] <eagles0513875> im in there
[07:41] <eagles0513875> debian.org
[07:41] <eagles0513875> hehe
[07:42] <imbrandon> ahh yea http://mentors.debian.net
[07:42] <imbrandon> anyhow i mean that to get them in debian you will need a "sponsor" to upload your packages
[07:42] <imbrandon> unless you are a Debian Devloper
[07:42] <imbrandon> or Debian Maintainer in come cases
[07:42] <imbrandon> some*
[07:42] <ajmitch> fwiw, work on mysql-workbench packages is being done in the pkg-mysql svn repository, last commit was 6 days ago
[07:43] <imbrandon> eagles0513875: in reality what that means is you can offer nobse soem help and possibly link him updated packges based on his initial work, and he MAY be your debian sponsor and upload those to Debian
[07:44] <eagles0513875> imbrandon: gotcha
[07:44] <imbrandon> i cannot speak for him but that looks like the correct path to get the results you want IMHO
[07:45] <imbrandon> eagles0513875: if you have no luck with that route in the next month ( 4 weeks ) start pushing for having you package put into ubuntu only ( the last week before DIF )
[07:45] <imbrandon> but not before then IMHO
[07:45] <eagles0513875> imbrandon: gotcha
[07:45] <eagles0513875> well there already exists the package for 10.04 from mysql themselves would it need to be repackaged
[07:48] <imbrandon> ugh wtf, iirc just informed me that the server ( auxilliary webserver for brandonholtsclaw.com subdomains ) has no space left on /
[07:48]  * imbrandon goes to investigate
[07:48] <imbrandon> s/iirc/irssi
[07:48] <imbrandon> ( it runs on said webserver )
[07:51] <G> imbrandon: is there anyway an author can relicense code without having to push a new tarball out? (I don't think so)
[07:51] <dholbach> good morning
[07:51] <eagles0513875> morning dholbach :)
[07:52] <ajmitch> hi dholbach
[07:52] <dholbach> hey ajmitch, hi eagles0513875
[07:52] <imbrandon> G: ummm I dont think so, well maybe technicly, but I would think to be clear and pass DFSG and Ubutnu guidlines for inclusion it would need a new ( or at leaste repacked, ewww ) tarbal
[07:53] <imbrandon> ajmitch or dholbach might be able to be more clear on that if they have run across it before
[07:53] <imbrandon> heya Baron dholbach :P
[07:53] <eagles0513875> imbrandon: emailed the debain mysql list
[07:53] <imbrandon> kk
[07:54] <dholbach> G: I don't think so
[07:54] <eagles0513875> imbrandon: would the existing workbench package from mysql need to be repackaged with the appropriate ubuntu naming convention im guessing ?
[07:54] <imbrandon> eagles0513875: yea it might hit debian legeal too, they would definately give ya the awsner ( maybe not the one ya want , lol )
[07:54] <imbrandon> eagles0513875: not repacked, just renamed if the name isnt correct
[07:55]  * ajmitch would prefer using the existing package in pkg-mysql's svn repository
[07:55] <dholbach> G: what we've done before is: if an upstream forgets to add the license text as LICENSE to the tarball, but it was clear which license it was under, then we let upstream know and add the license text just to speed up the process to get it into ubuntu
[07:55] <imbrandon> dpkg is smart enough top extract it to the correct dir
[07:55] <imbrandon> s/top/to
[07:55] <eagles0513875> imbrandon: well ill have to keep you informed of the response
[07:55] <eagles0513875> ajmitch: i used the one thats prepackaged and it works just fine
[07:55] <G> btw, Debian's policy is still GPLv3 & OpenSSL don't mix right?
[07:55] <imbrandon> eagles0513875: yea and see ajmitch mentions its in pkg-mysql's svn too ;)
[07:56] <imbrandon> G: no idea
[07:56] <imbrandon> G: re: licences
[07:58] <eagles0513875> G: and anyone whose interested http://www.opensource.org/licenses <---all open source licenses listed here can also submit your own license for review and possible acceptance
[07:58] <ajmitch> eagles0513875: wb.mysql.com doesn't appear to have source packages listed there, unless I'm missing it?
[07:58] <imbrandon> ajmitch: whats the diffrence between FeatureDefinitionFreeze and FeatureFreeze ? thats a new one on me since i've returned
[07:59] <eagles0513875> ajmitch: give me sec will link ya
[08:00] <ajmitch> imbrandon: feature definition freeze is "By this date, all features with updates to be landed in main for the release must be named and acked by the ReleaseTeam."
[08:00] <ajmitch> imbrandon: just click on it on the schedule :)
[08:00]  * imbrandon facepalms hypertext is a wonderfull thing
[08:01] <eagles0513875> ajmitch: http://dev.mysql.com/downloads/workbench/5.2.html <---scroll down and choose where it says select platform
[08:02] <ajmitch> yes, I don't see any source packages on there, unless the .tgz contains it
[08:04] <eagles0513875> ajmitch: usually sources are zipped in this case .tgz
[08:04] <eagles0513875> they do that to decrease the download size
[08:04] <ajmitch> I know that, but do they contain the debian or ubuntu-specific packaging?
[08:04] <imbrandon> source, but not "debian source pacakage" is what he was refereing too i'm assuming
[08:05] <eagles0513875> ajmitch: naming convention for ubuntu isnt followed but if you look there is a choice for ubuntu that they have there
[08:08] <ajmitch> ok, I've grabbed the .tar.gz & checked - it does have some debian packaging info, but could use some work
[08:08] <imbrandon> nice, debpacking in upstream, always fun, even when your the upstream making the mistake :P
[08:09] <ajmitch> yeah :)
[08:09] <eagles0513875> ajmitch: let me see what upstream decides to do
[08:09] <eagles0513875> as they have 5.1 waiting to hit the repos but thats no longer being supported and updated 5.2 is almost ready to become generally available
[08:28] <ajmitch> my karma is dropping again, I need to do moar uploads
[08:30] <imbrandon> ajmitch: hehe me 3
[08:30] <eagles0513875> and i need to get on the bandwagon and get into helping out
[08:30]  * ajmitch just uploaded 1, needs to be a few more
[08:30] <eagles0513875> packaging for now i guess
[08:31] <G> hmmm this is going to be fun :S
[08:34] <eagles0513875> G:
[08:34] <eagles0513875> what is
[08:36] <G> this Licensing issue
[08:36] <G> deviced that I better check before I leap for joy that LGPL & Openssl is okay
[08:37] <G> Looks like it is based on http://osdir.com/ml/linux.debian.devel.legal/2002-04/msg00022.html
[08:52] <eagles0513875> G: did you see the link i posted earlier about a listing of all open source license available
[08:52] <G> yep
[08:54] <G> but but it doesn't really touch compability between licenses
[08:54] <eagles0513875> gotcha
[09:08] <imbrandon> room went quiet ;)
[09:11] <eagles0513875> im here lol
[09:11] <eagles0513875> programming atm hehe
[09:18] <imbrandon> G: are all those pacakages on the SPICE website gplv3 or ...
[09:19] <G> imbrandon: so, package requires running 'sh autogen.sh'
[09:19] <imbrandon> G: if its a git checkout and/or upstream was lazy in making the tarbal ;)
[09:19] <G> for now I've got:
[09:19] <G> override_dh_auto_configure: ./autogen.sh --prefix=/usr
[09:20] <imbrandon> s/git/svn,git,bzr,other vcs/g
[09:20] <G> imbrandon: lazy tarball creation :)
[09:20] <imbrandon> k
[09:20] <G> imbrandon: GPLv2/soon to be LGPL, then the others are a mix of compat open licenses
[09:21] <imbrandon> ok i have to list each one, i'll grab the tar's
[09:22] <G> imbrandon: qpixmap = custom free (with retention of notice)
[09:23] <G> imbrandon: qcairo = MIT/LGPL
[09:23] <G> (dual license)
[09:24] <imbrandon> qpixman ?
[09:24] <G> errr sorry qpixman not map
[09:24] <imbrandon> ;)
[09:24] <G> you won't believe how many times I've done that :)
[09:25] <G> imbrandon: so whats your thoughts on overriding dh_auto_configure?
[09:25] <imbrandon> go ahead and do that for now, it will work and i'll poke arround to see if there is a "cleaner" way
[09:26] <imbrandon> other than slapping upstream upside the head
[09:26] <G> I thought about doing it as a quilt patch, but that made diff.gz as big as orig.tar.gz
[09:26] <imbrandon> heh , yea
[09:27] <imbrandon> btw what timezone are you in, its like 330am for me :) ( i'm a night owl alot though )
[09:27] <G> imbrandon: NZ +1200
[09:27] <Laney> overriding that target is fine and common
[09:27] <imbrandon> ahh
[09:27] <Laney> just make sure to clean up in the clean override
[09:28] <imbrandon> moins Laney
[09:28] <Laney> hey hey
[09:28] <G> Laney: yep, I've also got an override_dh_clean
[09:28] <G> Laney: Kia Ora
[09:47] <ajmitch> G: you're from NZ also?
[09:47] <G> ajmitch: yep
[09:47] <ajmitch> I should have seen, you were in #ubuntu-nz earlier today
[09:47] <G> always have been, except for when I was living in Brisbane, but we won't talk about that :)
[09:48] <ajmitch> just not one of the crowd saying 'morning' ;)
[09:48]  * ajmitch is in dunedin, though it seems most of the nz channel is in wellington
[09:49] <G> well I'm a JAFA
[09:49] <ajmitch> it can't be helped
[09:49] <G> agreed
[10:39] <imbrandon> hum why do i even read ubuntu-devel-discuss anymore, it just seems that as soon as one "remove package X from default" thread winds down or dies the next starts up ...
[10:40] <imbrandon> and Ryan Oram aka Mr. infinityOS seems to be behind starting the last few ...
[10:45] <Laney> I don't even bother to read that ml any more
[12:01] <mirsal> Hey there, could anyone check if I got the SRU stuff right on these: https://bugs.launchpad.net/ubuntu/+source/php-imagick/+bug/556469
[12:02] <mirsal> https://bugs.launchpad.net/ubuntu/+source/php-mcrypt/+bug/540208
[13:11] <ScottK> For a minute there I thought PHP was deprecated, but my hopes are dashed.
[13:20] <ajmitch> ScottK: can I file a removal request?
[13:21] <ScottK> I wouldn't mind.
[13:21] <ScottK> I understand since drupal is broken with php 5.3 ATM, it's pretty useless anyway.
[13:24] <ajmitch> I thought it wasn't broken, but coming up with the deprecation warnings
[13:25] <ajmitch> which can be ignored by changing php.ini
[13:32] <G> ouch looks like there is a memory leak somewhere in udev/libvirt land
[13:33] <G> "LEAK SUMMARY: definitely lost: 53,994 bytes in 681 blocks & indirectly lost: 339,538 bytes in 10,053 blocks"
[13:46] <G> hmmm any udev gurus around?
[13:47] <G> for reasons I've put in the bug I suspect that lp#571093 is a udev bug
[13:47] <G> https://bugs.launchpad.net/ubuntu/lucid/+source/libvirt/+bug/571093
[13:50] <Rhonda> I'm puzzled by bug #528957 being set to Fix Released for libsdl1.2 (Ubuntu) with a package in PPA? Is that proper?
[13:51] <Rhonda> ajmitch: Is the Fix Released really proper for that?
[13:51] <Rhonda> I always thought that's for when the package hits the regular pool?
[13:51] <ScottK> Rhonda: No.  In a PPA doesn't count for fixed.
[13:51] <bilalakhtar> Rhonda: Hi there! Can you sponsor a package for me in sid?
[13:51]  * Rhonda dances on ajmitch's nose. :P
[13:51] <Rhonda> bilalakhtar: Depends. :)
[13:52] <bilalakhtar> Rhonda: Atleast you could point out errors?
[13:52] <Rhonda> Still depends. Without further informations on which package, wether it's a new upstream release or even a total new package I can't tell you if I do find the time (soon enough) for looking at it.
[13:55] <bilalakhtar> Rhonda: Why is there such a long time for packages to get approved to go into debian?
[13:56] <Rhonda> Because the ftp master job for the NEW queue processing is an extremely unthankful job in many senses that most people like to avoid. Lack of manpower -> slow processing
[13:57] <Rhonda> Thankfully Tolimar seems to have a thick skin and does an extremely great job in recent times.
[13:57] <bilalakhtar> Rhonda: I mean that the DDs are very selective and lazy
[13:57] <Rhonda> Uh?
[13:58] <Rhonda> Accusing others doesn't help getting sympathy for what you want to achieve, you know …
[13:58] <bilalakhtar> Rhonda: So many RFS keep coming in debian-mentors mailing list, but one barely gets replies
[13:58] <Rhonda> About "lazy", there still is no "maverick" on packages.ubuntu.com.
[13:59] <bilalakhtar> Rhonda: I know that. I completely agree that you can't help me. I am not blaming you, but all the DDs
[13:59] <Rhonda> A mentors job is also not very fruitful. Actually I even regret to have advocated a certain person for becoming a DD.
[14:00] <bilalakhtar> Rhonda: and that person is carstenh
[14:00] <Rhonda> I can't help you because you still haven't told me what package you would want to get into sid but instead entangle me into a meta discussion. :D
[14:00] <Pici> I don't think this is a constructive discussion.
[14:00] <carstenh> bilalakhtar: no, I'm not
[14:01] <bilalakhtar> carstenh: But a few days ago, Rhonda said that he/she *regretted* to have advocated you
[14:01] <carstenh> bilalakhtar: and you just ensured that I don't sponsor anything from you. no she did not, reread the log please.
[14:01] <Rhonda> bilalakhtar: http://lug-owl.de/~frankm/dies_und_das/tbbt_S01E02_The_Big_Bran_Hypothesis_Sarcasm.png
[14:01] <jpds> Rhonda: packages> That's likely a djpig thing.
[14:02] <bilalakhtar> Sorry, carstenh and Rhonda for my false remarks
[14:02] <Rhonda> jpds: … as sole person. It usually is a very sane and good idea to avoid such single point of failures. And no, I didn't call djpig a failure with that statement, but the general concept. He seems to be extremely busy these days.
[14:04] <jpds> Rhonda: As we all are.
[14:05] <Rhonda> jpds: The thing is that he seems to be busy enough since about half a year or maybe even more.
[14:05] <Rhonda> And exactly for that reason such tasks shouldn't have only a single person to be able to do them.
[14:07] <Rhonda> jpds: Just for the record, I did do my part of the job, the packages.git repository has the required changes since 5th of May available. They just need to get pulled.
[14:07] <Rhonda> jpds: http://git.debian.org/?p=webwml/packages.git;a=shortlog;h=refs/heads/ubuntu-master
[14:08] <carstenh> Rhonda: just for the record, there wasn't even sarcasm that he possibly could have misunderstood in what you said a few days ago: 2010-05-11 15:10:39< Rhonda> carstenh: I regret to have advocated someone else, definitely not you. :)
[14:08] <Rhonda> carstenh: Could have missed that line. I usually apply the rule of doubt instead of accusion.
[14:09] <bilalakhtar> carstenh: sorry for my bad memory . I regret.
[14:10] <carstenh> bilalakhtar: :)
[14:14] <ScottK> bilalakhtar: Reading the recent backscroll it appears to me you are being more combative than we prefer in this channel.
[14:14] <ScottK> Accusing people of being lazy because they don't chose to volunteer in the way you would prefer is really inappropriate.
[14:14] <bilalakhtar> ScottK: agreed. regretted
[14:23]  * Rhonda . o O ( Still no clue wether bilalakhtar was talking about gconjugo, liboauth, python-tweepy, gurlchecker - or all of them )
[14:23]  * sebner pats Rhonda 
[14:24]  * mok0 pats sebner
[14:24] <bilalakhtar> Rhonda: Good guess. I was talking about liboauth. But looks like u r busy
[14:24] <sebner> mok0: :D
[14:24] <mok0> Hi sebner, any exams coming up?
[14:26] <Rhonda> bilalakhtar: I'm busy understanding what you would want from me. For a quick check on the gurlchecker debdiff you just wrote "New upstream release" into the changelog but seem to have switched from cdbs to quilt, from compat 5 to compat 7, and potentially a lot of more things. The debian/changelog isn't just cosmetically, it has to list what you changed in the package.
[14:26] <Rhonda> Given that there are such basic issues in this quick debdiff scan I'm not too sure wether I want to take a deeper look into the other packages, sorry.
[14:26] <sebner> mok0: not the next few weeks, still some stuff todo though, everything fine on your side? =)
[14:27] <mok0> sebner: yeah, just busy as usual (work)
[14:27] <bilalakhtar> Rhonda: Fine, will change that. I think you are busy, and should NOT trouble you more.
[14:27] <Rhonda> Please don't assume what you can't know. I am grown up and able to state myself when I'm busy. :)
[14:30] <Rhonda> bilalakhtar: For the liboauth copyright file, it doesn't make much sense to note down the exact URL for the download - that would mean you have to change the file with every single new upstream version. The directory index or similar is more than enough.
[14:31] <Rhonda> For liboauth-dev.install, I would cut down the man part to usr/share/man - there might get additional files dropped in at a later stage and you would miss them.
[14:31] <Rhonda> Why start off with compat 5 for a new package, just curious? Why not 7 right ahead?
[14:33] <Rhonda> It's still debateable wether debian/source/format containing 1.0 is actually needed, just FYI. This is buxy's sole standing and he was told by loads of people that this is a waste effort to want to go the path of requiring that.
[14:33] <bilalakhtar> Rhonda: I prefer 5 in packaging libraries
[14:33] <Rhonda> For what reason? :)
[14:33] <Rhonda> Your debian/watch file should use the sf.net redirectory, please read man uscan again.
[14:34] <Rhonda> … or I am mistaken here, checking.
[14:34] <bilalakhtar> Rhonda: this is a special case. liboauth doesn';t use sf to store files, bu t web hosting instead. see sourceforge.net/projects/liboauth/files
[14:34] <Rhonda> Ah, alright. Then the rest of the remarks are still valid, though.
[14:35] <bilalakhtar> Rhonda: If I don't use 1.0 in d/s/f then a lintian warning comes
[14:35] <Rhonda> And that lintian warning is an error that the lintian maintainer admited. :)
[14:36] <bilalakhtar> Rhonda: Is there a real problem with compat 5?
[14:36] <bilalakhtar> Rhonda: So should I use 3.0 (native) or what?
[14:37] <Rhonda> Is there a real reason why you prefer compat 5?
[14:37] <Rhonda> No, 1.0 is totally acceptable, but debian/source/format isn't required or needed for 1.0
[14:37] <sebner> Rhonda: lintian says something different :P
[14:38] <Rhonda> sebner: 15:35 <Rhonda> And that lintian warning is an error that the lintian maintainer admited. :)
[14:38] <sebner> oh
[14:38] <Rhonda> i.e. it will get removed with the next lintian release again.
[14:38] <bilalakhtar> Rhonda: Ok, I am moving to compat 7. removing the d/s/f and coming back in 15 mins
[14:38] <sebner> Rhonda: pff, it should be changed to: use 3.0 ftw!
[14:39] <Rhonda> sebner: For no good reason, and potentially breaking stuff? Sorry, I don't buy that. But that is a discussion that doesn't fit here, me thinks.
[14:41] <sebner> Rhonda: no good reason? 3.0 >>> 1.0, the real reason against it is the back-portability to lenny, dicussion about ubuntu development (tools) fit here ;D
[14:42] <Rhonda> Oh, versionitis? Just because 3 is bigger than 1?
[14:43] <Rhonda> Try to debdiff a v1 openoffice.org and then convert it to v3 and do a debdiff again - and take a look at the "speed".
[14:43] <Rhonda> 3.0 >>> 1.0 isn't a reason, it's a number comparison.
[14:44] <pixie79> when writing debconf files is there a way to automatically remove all template questions and answers from the db for a package without having to specify each one?
[14:47] <Rhonda> pixie79: Isn't that what db_purge does? Hmm, it removes the entries alltogether me thinks?
[14:47] <bilalakhtar> Rhonda: test build in chroot is working. uploading now
[14:47] <pixie79> Rhonda: i thought that, but then when i tried running my config file again it did not prompt for the questions
[14:49] <Rhonda> pixie79: What exactly do you try to accomplish?
[14:50] <bilalakhtar> Rhonda: How do I solve a lintian warning "configure-generated-file-in-source config.log"
[14:51] <Laney> remove it on clean
[14:51] <Rhonda> You remove it in the clean target?
[14:51] <Rhonda> s/\?//
[14:51] <pixie79> Rhonda: i am making a looping config script as part of the install as i need to make a config file that uses many of the same lines several times but with only a few words different dependant on user entered feedback
 For a minute there I thought PHP was deprecated, but my hopes are dashed. <[14:53] <mirsal> You made my day ^^
[14:53] <bilalakhtar> Laney: thanks
[14:53] <bilalakhtar> Rhonda: beginning to upload
[14:54] <Rhonda> ScottK: Oh. ajmitch did mark it as Fix Released because it's fixed in maverick, not because he offered a package in his ppa. At least that's what it looks like on second thought. :)
[14:54] <ScottK> That's appropriate then.  Fixed in the development release counts as fixed released.
[14:59] <bilalakhtar> Rhonda: You could see the fixed package now on mentors.debian.net
[15:04] <mok0> persia: yesterday, you posted a snippet of code that implies you can make a powerpc sbuilder on an amd64 platform. Is that indeed the case?
[15:04] <persia> Yep.
[15:05] <persia> Mind you, powerpc isn't perfectly emulated.  Some builds work, some fail for reasons that I don't entirely understand.
[15:05] <mok0> persia: ... but the binaries run on the native platform?
[15:05] <persia> My experience with using powerpc and armel schroots on amd64 is that it can be useful to troubleshoot some build issues, but ends up producing some number of false negative results.
[15:05] <persia> Yep.  This is not cross-compilation.
[15:06] <mok0> That is way cool
[15:06] <persia> qemu has two ways it can work: "user" mode and "system" mode.  In the latter, one emulates an entire system, and runs an OS in there.  In the former, one just uses qemu as an interpreter for foreign binaries.
[15:07] <mok0> persia: I see... and the schroots are done via qemu these days?
[15:07] <persia> In lucid, lool added the necessary binfmt-misc hooks in to qemu-kvm-extras-static so that this just worked (for the set of stuff qemu can handle), and I used this to make pbuilder-dist and mk-sbuild be able to use them.
[15:07] <mok0> Ah, so it IS new :-)
[15:08] <persia> Well, there's some decision code.  If the schroot being constructed would require foreign-arch support, qemu-debootstrap is invoked rather than normal debootstrap (qemu-debootstrap is a wrapper around debootstrap that does the right things)
[15:08] <bilalakhtar> Looks like rhonda is away
[15:08] <persia> But the on-disk format is exactly the same: qemu just offers a means to run foreign binaries through binfmt-misc.  This is the same mechansim that allows us to run Windows programs in wine or Java as native executables.
[15:08] <mok0> persia: ok, here goes, I am reconstructing all my sbuilders
[15:10] <persia> There is a binary file in the chroot that handles the translation (to avoid needing to break the chroot), but foreign chroots work just fine on native.  So if you have a chroot on a USB stick, you can move it between different machines of different architectures, and it does the right thing (mostly)
[15:10] <mok0> persia: I am impressed
[15:12] <mok0> persia: so this is why the arch is now always baked into the name
[15:12] <mok0> name of the logical volume that is
[15:17] <mok0> persia: ugh, where does mk-sbuild put the chroot if you omit --vg=xxx ?
[15:22] <ScottK> New Jersey.
[15:22] <Pici> Eh?
[15:27] <mok0> ScottK is still drunk after UDS
[15:27] <sebner> lol
[15:27] <ScottK> No, it's not from UDS.
[15:28] <mok0> :)
[15:32] <mok0> Ah, /var/lib/schroot
[15:48] <lfaraone> One of my packages built successfully on armel, i386, and powerpc, but ftbfs on amd64. It builds locally, so I requested a rebuild. Is the issue reported in http://launchpadlibrarian.net/48697334/buildlog_ubuntu-maverick-amd64.php-imagick_2.1.1RC1-1build3ubuntu1_FAILEDTOBUILD.txt.gz transiant?
[15:57] <mok0> lfaraone: Looks like your package depends on a broken one
[15:57] <mok0> lfaraone: libmagickcore2-extra
[15:58] <mok0> lfaraone: is broken for that arch
[16:15] <lfaraone> Odd. https://edge.launchpad.net/ubuntu/maverick/amd64/libmagickcore2-extra says it's built
[16:17] <lfaraone> Unrelated, does bug 540208 seem too trivial for SRU?
[16:29] <persia> lfaraone: Note also that armel+i386+powerpc are 32-bit arches, so if something isn't ported to 64-bit it would demonstrate that behaviour (not in this case, but something to consider).  As long as we have ia64, it would FTBFS there too, although it sounds like ia64 may go away in the future if not enough people maintain it.
[17:01] <ScottK> It'll be around for at least one more cycle anyway
[17:11] <geser> lfaraone: php-imagick will FTBFS again on AMD64. It succeeded on i386 because it got build with the old graphviz.
[17:16] <geser> lfaraone: the problem is: libmagickwand-dev -> libmagickcore-dev -> libgraphviz-dev -> libcdt4 AND libmagickwand-dev -> libmagickcore2-extra -> libgraphviz4 AND libcdt4 conflicts libgraphviz4 => boom
[17:16] <geser> I assume imagemagick needs a rebuild with the new graphviz to resolve this
[17:17] <pixie79> hi all, i am having issues with a package i am making that it is not prompting for questions when installed via debconf. When doing a reconfigure or a reinstall it just uses the old values and not the new ones, any ideas?
[17:34] <pixie79> it would appear that it is just taking the dedaults each time, but also nothing is being written to the database, if i do a debconf/show and look for my package it is not there
[18:13] <lfaraone> soren: I've proposed a branch for merging into VMBuilder which unblocks VirtualBox support. (a three line fix, but it had rended the vbox component unusable) Should I wait for it to be merged upstream, or is it okay to apply it as a local patch in Maverick?
[18:14]  * lfaraone wants to SRU this fix sometime soon. 
[18:15] <lfaraone> geser: okay, so the solution would be to just rebuild imagemagick with a dummy ubuntu1 upload?
[18:15] <ScottK> lfaraone: If it's otherwise unchanged in Ubuntu, use build1
[18:17] <lfaraone> ScottK: okay. it already is at ubuntu1, so I'll just go with "ubuntu2", unless I should use "ubuntu1build1" :)
[18:17] <ScottK> lfaraone: ubuntu2 in that case.
[18:17] <geser> lfaraone: ubuntu2 is correct
[19:06] <imbrandon> anyone know of a package that does a dpkg-divert on a binary from another package to provide a wrapper for it off the top of their head that i can kinda poke at as an example ?
[19:23] <lfaraone> DktrKranz: would you have a chance to look at sponsoring http://mentors.debian.net/debian/pool/main/g/groundcontrol/groundcontrol_1.6.5-2.dsc?
[19:23] <lfaraone> DktrKranz: (to debian, that is)
[20:03] <ScottK> imbrandon: I think hardening-wrapper does that.
[20:04]  * kees looks up
[20:04] <soren> lfaraone: If you think it'll be valuable to put it in maverick at this point, feel free. I'm working on an SRU for Lucid, though, and expect to do another one in a couple of weeks.
[20:04] <soren> lfaraone: Your patch would likely be included in the next one.
[20:04] <kees> imbrandon: generally, diversions are to be avoided, but in some horrible cases (*cough*hardening-wrapper*cough*) there isn't much choice.
[20:05] <kees> imbrandon: generally coordinating use of alternatives is the better approach.
[20:10] <soren> kees: Hm... Why couldn't hardening-wrappers use alternatives?
[20:10]  * ScottK hears kees scream in the distance.
[20:12] <imbrandon> ScottK / kees : thanks
[20:13] <kees> soren: mostly because it needs to be a wrapper, and it needs to always win.  i.e. it isn't an alternative.
[20:13] <imbrandon> kees: understood, but this is for a work related pacakage that wont be in the archive and is working arround a bug in a binary only deb via another package
[20:13] <imbrandon> kees: so yea not ideal but still trying to do it as clean as possible given the circumstances ;)
[20:13] <kees> soren: but many things that first appear to be in need of diversions are better implemented with alternatives.  in my case, it wasn't so.
[20:13] <kees> imbrandon: righto
[20:14] <kees> soren: that said, hardening-wrapper is deprecated in favor of hardening-includes, which doesn't use diverstions, but requires the maintainer actually make changes to their build process.
[20:14] <soren> kees: Yeah, I'm trying to think up a way to do the job with alternatives... I can't :)
[20:16] <imbrandon> in this particualr case the binary only program calls /sbin/shutdown directly ( not even by $PATH , i mean directly ) so i need to divert shutdown on those systems to do the right thing when that package calls it via a /sbin/shutdown wrapper ( luckly the binary only program runs as its own user so this will make it fairly easy and a bit cleaner in the wrapper, just do my stuff if its that user and anyone else gets the real /sbin/shutdown is
[20:18] <kees> owchy
[20:18] <imbrandon> yea, that was my inital reaction, the next one was to send the devs of said program a big bag of s**t , but then i settled on this solution
[20:18] <kees> I would ... binary-edit the program to call /sbin/owchdown instead.  :P
[20:18] <imbrandon> lol
[20:19] <kees> and then write owchdown to do the right thing.
[20:19] <kees> who says not having the source means you can't change a program's behavior?  binary-edits and LD_PRELOAD can get you a long way.  :)
[20:21] <imbrandon> :)
[20:31] <ajmitch> morning
[20:31] <imbrandon> moins ajmitch
[20:32] <imbrandon> ajmitch: i'm working on 2 hours sleep today , lol, gonna crash hard tonight
[20:32] <ajmitch> Rhonda: yeah, the fixed/in progress thing for libsdl1.2 looks a bit messy, I should have closed the ubuntu task in the upload to maverick :)
[20:33] <ajmitch> imbrandon: awesome, I hope it's not due to wow :)
[20:33] <imbrandon> ajmitch: hah , not this time, stayed up too late doing some python learning/hacking
[20:33] <fabrice_sp> Anyone interested in sponsoring bug 531973?
[20:34] <fabrice_sp> imbrandon, you were volunteering this morning, right? :-D
[20:34] <ajmitch> ScottK will be, I'm sure :)
[20:34] <fabrice_sp> lol
[20:34] <imbrandon> fabrice_sp: yea but i cant at the moment, if no one has done it for you in about ~2 hours i can then
[20:35] <fabrice_sp> just trying: thanks anywaay :-)
[20:35] <ScottK> ajmitch: I'm relatively certain I don't care much.
[20:35] <imbrandon> no worries most of the time i would be happy to but i'm knee deep in some binary crft atm
[20:35] <imbrandon> cruft*
[20:35] <ajmitch> ScottK: it was worth a try, I'm getting ready for work
[20:36] <ScottK> Let's set up a rotation to take turns pinging imbrandon on a 4 - 6 minute interval to help him with his binary cruft productivity.
[20:36] <ajmitch> sounds good
[20:36] <imbrandon> lol
[20:36] <ScottK> OK.  That was mine.  You're next.
[20:36] <imbrandon> <detaches screen> j/k
[20:37] <Rhonda> ajmitch: Anyway, thanks for taking care of it!
[20:39] <ajmitch> even if I am horribly slow :)
[20:40] <fabrice_sp> Hey Rhonda: as a DD would you mind having a look at http://mentors.debian.net/debian/pool/main/a/aptoncd ? It's an update to an existing package and my usual sponsor (bddebian) is missing
[20:40] <Laney> we have a new channel for this
[20:40] <Laney> #debian-ubuntu @ oftc
[20:40] <fabrice_sp> oh, really?
[20:41] <fabrice_sp> ok: I'll check there then
[20:41] <Laney> I don't know if there are many DDs there yet though
[20:41]  * Laney eyes DktrKranz directhex Rhonda
[20:41] <Laney> :)
[20:41]  * fabrice_sp was thinking about exchanging sponsoring favours :-)
[20:43] <directhex> snuh?
[20:46] <Rhonda> fabrice_sp: Oh, Barry is your usual sponsor? Sweet. :)
[20:47] <Rhonda> Laney: Oh, didn't know!
[20:47] <Laney> it was a UDS thing
[20:47] <Laney> hopefully it takes off and facilitates sponsoring in both directions
[20:47] <Rhonda> So that's behind the derivates frontdesk that our DPL was talking about? :)
[20:47] <Laney> yes exactly
[20:49] <fabrice_sp> Rhonda, YES :-) that's a nice idea, because I'm still lost (this is the only package I maintain directly in Debian)
[20:59] <Elbrus> bug 577728 needs a rebuild of tuxcmd for lucid. what is the appropriate way to handle that bug? Assigning specific people?
[20:59] <Elbrus> (I filed the bug myself and can confirm that a rebuild helps).
[20:59] <Elbrus> creating a debdiff for a binNMU could be done of course, does that help?
[21:24] <fabrice_sp> Elbrus, follow a normal SRU process
[21:26] <Elbrus> fabrice_sp: thanks
[23:47] <arand_> Ok... so a package where "patch -p0 < debian/patches/bitlbee.conf.diff" is declared in  debian/rules. How does one go about patching that with something else?
[23:48] <arand_> (and keep it SRU-friendly)
[23:50] <crimsun> a number of ways: you can modify debian/patches/bitlbee.conf.diff (the interdiff will show up in the debdiff), or you can add a new patch and call patch again in debian/rules.
[23:50] <crimsun> both nasty, really, but kinda unavoidable in this context
[23:50] <Laney> you're patching bitlbee?
[23:50] <Laney> I just tried to use it and it didn't let me get on msn ;)
[23:53] <Laney> ah, fixed in 1.2.7
[23:54] <arand_> Laney: Yea, I'm trying out the SVN diff
[23:54] <arand_> Laney: I've got new version for karmic in my PPA which worked for me
[23:56] <arand_> Is there any good way to automate the packaging of a specific patch for several releases, other than actually doing it on each of them?
[23:57] <Laney> bzr merging might help
[23:58] <arand_> Mah, means I have to learn bzr :( high time, but still )