[00:04] crimsun, gotcha [00:11] 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] fabrice_sp: do you plan to convert 568619 to SRU format for lucid-proposed? === nobawk|away is now known as nobawk [01:17] classvoid: http://kernel.ubuntu.com/~dtchen/gorm.app_1.2.8-1ubuntu0.1.debdiff [01:18] classvoid: I'd appreciate if you can test that debdiff so that we can proceed with the SRU process [01:19] ah dang, karmic has a matching version [01:49] SpamapS: /away not here [01:49] upsy [01:49] :P [02:05] Is Ubuntu using the dpkg-source 3.0 (i.e. should new packages use it or is lintian been overreactive) === nobawk is now known as nobawk|away [02:22] G: You can use it, or not, at your choice. [02:39] crimsun, so not test it lol? [02:40] RAOF: thanks [02:46] crimsun, yep that was the fix [02:46] crimsun, sorry I got caught up in something === nobawk|away is now known as nobawk === nobawk is now known as nobawk1 === nobawk1 is now known as nobawk === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk [03:41] evening all [03:43] imbrandon: kia ora [03:43] hmmmm, I think this is a pull hair out moment [03:43] kia ora? [03:43] imbrandon: Hello in Maori [03:43] ahhh :) [03:44] i was hoping it was a "good thing"(tm) [03:44] All depends on what you're in to. [03:44] classvoid: did you test the fix locally? (build, install, execute) [03:44] 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] not a "rule" but good to follow imho [03:45] 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] G: sounds like a maintainers nightmare ;) [03:46] 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] "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] that sounds evil, but dont go by what i'm saying strictly, i'm not a lib packaging guru [03:48] so its 0.5.1 + fixes but still versioned 0.5.1 , even more evil ... [03:48] imbrandon: it's released as 'celt-0.5.1.3' but really it's now celt051-0.5.1.3 [03:49] 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] alsamixergui [03:49] crimsun: thanks [03:49] imbrandon: btw, thanks for the format tip [03:50] or have an 'x-terminal-emulator -e alsamixer' swallowed [03:50] 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] imbrandon: where/who is the best person to ask about it? [03:51] G: this is probably the place, as to who , i'm not 100% sure ... [03:51] ( or #ubuntu-dev durring "business" hours in GMT time ) [03:51] but honestly porobavly would start here as you have [03:52] k, see libpng has got a libpng3 and a libpng12 package, so I guess there is some history of this happening [03:53] 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] 'm just not 100% the best to awnser them all [03:54] actually, I'm wrong about libpng3/12 [03:54] imbrandon: hmmm, I'll re-read that part [03:54] 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] http://www.celt-codec.org/downloads/ atm there is libcelt in lucid which is 0.7.1 [03:55] G: yea lib packing is its own beast i have learned, it has some very specific set of guidelines iirc [03:55] G: kk [03:56] I've done Library packaging before in the RH/Fedora world but yeah, seem to hit a brick wall here :) [03:56] (with this package) [03:56] 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] turns out all my previous issues were due to silly mistakes like files named wrong :S [03:56] kinda gotta watch the changelog context too [03:57] 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] G: we all do it ( the silly mistakes ) its how to handle the fix and learn form it that counts :) [03:59] G: ok afk ~2 minutes gonna check out the webpage and apt-get the source [03:59] imbrandon: thanks, I'm reading the Debian bit again now [04:00] 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] seem* [04:00] from what i rember when i was actively working on libvisual-* [04:01] speaking of , i need to update libvisual-plugins badly/soonish [04:03] 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] am i getting that right ? [04:05] yeah pretty much [04:05] 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] I don't think so [04:06] k [04:06] now, looking at the Debian guide and how this library builds [04:06] 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] the 0.5.1.x builds with a soname of: libcelt051.so.0.0.0 [04:07] which doesn't conflict with /usr/lib/libcelt0.so.0.0.0 [04:08] upstream has done all the work that I can see to not make the two conflict [04:09] 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] ( 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] G: are you upstream for the other project or just packaing/intrested in it [04:11] wow lets see how many diffrent ways i can typo packing tonight [04:11] lol [04:12] imbrandon: quite interested in it [04:12] I actually worked a quite a bit with it in a previous job [04:12] imbrandon: not as many as I've forgotten sudo in front of aptitude or mispelt debuilder I'm sure :) [04:12] 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] I'm a newbie [04:13] I've already got 2 down :) [04:13] in a PPA [04:13] 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] so, we've got libxml++1.0-dev & libxml++2.6-dev [04:14] and its my prefered contact method , email being second [04:14] G: looks like a good place to start, who is listed as the maintainer [04:15] Ubuntu Developers [04:15] 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] Specifying is just busywork and encourages the crazies. [04:15] 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] imbrandon: that I'm not sure about [04:16] imbrandon: however... [04:16] imbrandon: any security fixes for it can be obtained in conjuction with Red Hat [04:16] 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] ScottK: but i see your point [04:17] so security fixes will be available [04:17] imbrandon: Not specifying source/format = 3.0 means you don't want 3.0. That's sufficient. [04:17] 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] ScottK: true, i guess i was just over thinking it [04:18] so yeah, it should pass on a security sense [04:18] kk, was just a thought , figured i'd mention that before we got too far [04:18] imbrandon: Not really. the dpkg maintainers started out with that idea, but I think they've calmed down now. [04:19] ScottK: :) [04:19] 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] 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] I think I'll leave learning BZR to tomorrow :) [04:23] 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] G: yea this isnt a one day thing, just getting the process started will likely be a few days minimum [04:24] 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] yeah, I used to do some Debian packaging in about 2005 [04:24] so a bit is coming back to me, but it's changed quite a bit as well :) [04:25] 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] yeah, sounds like what I want to get into again [04:27] imbrandon: FWIW, end goal is https://bugs.launchpad.net/ubuntu/+bug/500385 [04:28] Ubuntu bug 500385 in ubuntu "[needs-packaging] SPICE" [Wishlist,In progress] [04:28] 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] and the two packages I've rolled so far are in dev-nigelj/ppa [04:29] * imbrandon looks at the bug [04:29] 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] imbrandon: yeah agreed [04:30] 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] G: just curious, are all 3 of those "packages" listed part of the same upstream or at leaste same upstream team ? [04:32] ( again just trying to get a better overall picture ) [04:33] also are you "Liang Guo" or are you working with him/her ( the person that filied the debian ITP "intent to package" ) [04:33] imbrandon: qpixman & qcairo are (effectively) forks from the same upstream as SPICE, celt is xiph [04:34] nope, no idea who Liang Guo is [04:34] 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] oh they are the same upstream [04:35] spice client & server are sub packages fromthe same source [04:35] vdesktop is a second source [04:36] 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] 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] and we dont want to waste work/duplicate work in that way if not nessesary [04:39] 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] imbrandon: yeah, the ITP has been inactive since it was filed Dec 09 [04:39] imbrandon: dev-nigelj [04:39] kk [04:39] (Nigel Jones) [04:40] 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] lets atleaste touch base with him, i can draft the email and cc you and the debian ITP bug if you wish [04:40] i have done similar in the past [04:40] That's the right thing to do. [04:40] imbrandon: yeah, would be interested [04:40] ( i'm assuming "him" no offence if its not , bad habbit ) [04:41] (I had a look at his site, it is a him) [04:41] G: :) [04:41] imbrandon: I see there's no reply on the ubuntuone ITP? [04:42] 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] possibly just a little busy at the moment, who knows [04:42] ajmitch: i'm thinking about sending one more email to that ITP being a just a little more direct [04:42] but not overbearingly [04:42] since we know he is atleaste semi active [04:42] best not to be annoying [04:43] 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] s/neede/need [04:44] may 3 [04:44] so ~ 2 weeks [04:45] 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] imbrandon: happy to [04:46] 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] ready* [04:46] either that or @debian.org [04:47] kk [04:47] you deb one is ajmitch at , correct ? [04:47] yep [04:47] kk [04:47] i'll probably use that one since its going into debian, unless you feel strongly otherwise [04:48] nope, I prefer to use debian addresses for debian stuff [04:48] 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] 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] 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] aned help work out possible unknown/unforseen conflicts before they hit a wider audiance [04:51] and* [04:53] G: btw welcome to the ever fun ( no sarcasim intended ajmitch / ScottK , lol ) world of ubuntu maintaince :) [04:53] imbrandon: I wouldn't have guessed you intended sarcasm. [04:54] imbrandon: if it's anything like Debian/Fedora I'm prepared :) [04:56] 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] 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] but that number is totaly just made up by me, i wouldent even know where to get that metric [04:59] just an semi-uneducated guess [04:59] wow, I thought there would be more [05:00] Many contributors aren't MOTU yet and have their work sponsored until they are. [05:00] We get ~75% of our packages unmodified from Debian. That helps a lot. [05:00] 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] 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] now I know the right time to ask for new package endorsements in REVU :) [05:04] bbs, going to grab a coffee [05:04] 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] 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] crimsun, re 568619: TBH, I totally forgot about it, so go ahead (I saw you had a debdiff) [05:04] It's also generally easier there since there are so few of us. [05:05] 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:05] Launchpad bug 531973 in boost-defaults "[UNMETDEPS] libboost-mpi-dev has unmet dependencies in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/531973 [05:06] 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] It's technically accureate, but we don't provide the mpi packages. [05:06] I'll comment in the bug. [05:06] ok, so my proposal to delete the -mpi-* packages from boost-defaults is right then [05:07] You also have bug #582420 [05:07] Launchpad bug 582420 in boost1.42 "Please package boost-mpi and boost-mpi-dev" [Undecided,New] https://launchpad.net/bugs/582420 [05:08] 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] etc etc etc [05:10] fabrice_sp: yes. [05:11] ok. Thanks! [05:11] Even better it means you can be TIL boost-defaults an not me. [05:12] back [05:12] heh [05:12] ScottK: for some reason noone really wants to touch boost [05:12] imbrandon: yeah, they changed that around shortly after I finished [05:12] it was similar but they revamped it a bit [05:13] and yet we do anyway, don't we. [05:13] * ScottK goes off to bed. [05:13] ScottK, TIL? [05:13] fabrice_sp: Touched It Last [05:13] in other words, you're responsible for it for eternity [05:13] oh :-) [05:14] boost-defaults is quite easy: it's only a package that wraps the boost packages, so not so complicated to maintain :-) [05:14] and it's main, so someone will need to upload it :-) [05:14] we'll let you have the TIL on boost1.42 as well if you want [05:15] hmm, let me think a bit about it.... :-) [05:15] haha [05:15] * ajmitch touched boost1.40 last, but it's redundant in maverick [05:16] you're lucky: 1,42 is default in Maverick :-) [05:16] yes, the patch I'd stuck in 1.40 should be in 1.42 [05:16] since I grabbed it from upstream SVN [05:16] lucky you :-) [05:17] imbrandon: I'm going to guess most of the virtualization work is been done in Debian not Ubuntu directly [05:17] G: i would assume that too, as is _most_ major kernel work, but i would need to verify that [05:18] gnight ScottK [05:18] oh wow, all the chromium/mozilla daily builds hit PPA at the same time? :P [05:19] fabrice_sp: i can upload if your talking tonight, if not i would poke ScottK as he is more familiar with it [05:19] ( boost-defaults ) [05:20] thought as was said, it's a tiny package, nothing really to worry about [05:21] imbrandon, cool ! I'm trying to fix some FTBFS in packages that uses it, so that would be great :-) [05:21] very tiny: only a debian directory :-) [05:21] ajmitch: :) [05:21] 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] 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] have* [05:22] imbrandon: I'm guessing packages in Ubuntu aren't exactly owned by anyone? [05:22] based on what I'm seeing and Maintainer = motu in the debian/control files [05:23] 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] G, exactly: ubuntu is team maintained, even if the TIL rule apply :-) [05:23] too slow :-) [05:24] * fabrice_sp stil wakes up... [05:24] 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] 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] kinda just one of those things you pick up form hanging out in here [05:26] from* [05:28] 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] and for merges, it avoids duplication of effort [05:28] * fabrice_sp remembers uploading a fix to a FTBFS that was normal [05:29] yeah [05:29] since the last uploader may have spent time already getting something prepared [05:29] 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] :-) [05:30] 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] and/or may have been working on other changes localy ( bad habbit ) that could be uploaded at the same time [05:32] in semi-unrelated news, merging changelog by hand gets a bit tedious [05:32] but bzr pacakge branches ( or git in debian ) alieve alot of that latter problem [05:32] ajmitch: hehe, arent there tools for that , like mom [05:32] imbrandon: it's bdeing done by hand because LP *still* isn't updating properly [05:33] 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] ajmitch: ouch, isnt that a debian but though ( in the generated Sources{,.gz.bz2} ) ?? [05:33] s/but/bug [05:34] imbrandon: yes, which breaks mirroring [05:35] 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] esp if at first you just plan on touching this small subset of packages [05:37] 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] 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] 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] ajmitch, just use meld :-) [05:38] 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] ajmitch: hahahah sounds like something i would do , shhhhh [05:39] meh, that's not fun! [05:39] :-) [05:39] * imbrandon has never done that .... *looks arround* [05:39] imbrandon: given that it's what a merge should do anyway [05:40] 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] ajmitch: yea i thinks its sane to do that, but the KDE team in general wants *ALL* changeslog entries preserved [05:41] not really needed IMHO, but meh [05:41] imbrandon: they are in PPA, but are stuck waiting for all the dail browser builds :) [05:41] https://launchpad.net/~dev-nigelj/+archive/ppa/+packages [05:41] G: kk, yea i dident nessesarly mean this minute, but i will grab them "soonish" [05:41] imbrandon: adding the debian revisions on top of the current ubuntu changelog preserves all revisions [05:41] great [05:42] imbrandon: you should be able to dget the .dsc file though :) [05:42] since it means I'm just adding 1.2.14-{5,6} on top of an already merged changelog [05:42] 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] you're probably thinking about it wrong [05:42] yea, likely [05:43] the debdiff that comes out of it looks right, at least [05:45] 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] see what i mean, or was i clear as mud [05:46] * ajmitch needs some alcohol to understand that one [05:48] 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] imbrandon: when is the DIF? [05:50] 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] imbrandon: you're assuming that ubuntu changes are going into debian, rather than being ubuntu-specific [05:50] https://wiki.ubuntu.com/MaverickReleaseSchedule [05:50] 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] looking at that, in 5 weeks time [05:50] assuming that the schedule isn't changed [05:51] 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] so it would contain everything (or I am missing something :-/ ) [05:51] 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] right [05:52] fabrice_sp: that's exactly what I did [05:52] 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] ( changelog entry, no chnages them-selfs ) [05:53] dropping entries in the changelog is not the way I've been teached :-) [05:54] but I see your point: if all Ubuntu changes have been adopted, what is the point of keeping the old changelog entries? [05:54] 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] imbrandon: great thanks [05:54] imbrandon: saw your bug entry so was curious [05:55] DIF is only when the packages stop being imported auomatically: you can still request a sync with a bug report [05:55] 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] but again, thats just my thought, i really dont know about "best practice" in that situation and the KDE Ubuntu says otherwise [05:56] KDE Ubutnu Team :) [05:57] 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] imbrandon: what are you trying to hijack today? [05:58] sometimes a "hostle" takeover of a ITP ( even via Ubuntu ) isnt looked upon nicely , and just adds unneeded tension [05:58] ajmitch: nothing myself, helping G ( as a mentor ) take over/help with the redhat vnc/nx clone/replacement [05:58] ajmitch: debbug 560721 (Spice) [05:59] talk about a confusing name [05:59] 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] like NX/VNX/X11 Remote/RDP etc [06:00] VNC* [06:00] imbrandon: it's actually used for virtualization [06:00] low bandwidth sound and video transfer [06:00] the name is confusing because there's a circuit simulator already in debian called spice (package name ngspice) [06:00] only virtualization ? or just mostly/targeted twords ? admitidly i only read a small fraction of the sites homepage [06:01] imbrandon: targeted towards, but there is nothing stopping other implementations [06:01] 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] G: ahh kk [06:03] 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] imbrandon: not expecting it on a gold platter :) [06:05] I'm happy to do the grunt, just getting it into a Ubuntu concept is what I'm having trouble with [06:06] 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] 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] 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] :) [06:09] heh [06:10] 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] you're old :) [06:11] being more active at sometimes more so than others [06:11] ajmitch: if i'm old your ancient :) [06:11] lol j/k [06:11] quite true [06:11] now I must run off & catch a bus home [06:11] not age wise, but round these parts ;) [06:11] ajmitch: ttyl [06:12] ajmitch: you've been here pretty much since the inception of MOTU havent ya ? [06:12] or close [06:14] 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] imbrandon: thanks [06:16] 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] not everything in there is development related, but there is generaly somewhat of a schedule posted somewhere on those wiki pages [06:17] yippee! spice builds :) [06:17] :) [06:18] well, I've worked out the BRs [06:18] G: what virt platform is it targeted to , i'm guesing Xen since it was intialy started/maintained by redhat [06:19] imbrandon: qemu/KVM [06:19] It's actually from Quramnet (brought by RH) that wrote KVM [06:20] 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] errr Qumranet [06:20] there is a Windows SPICE Client (I think Mac too) [06:22] 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] or on the off chance qemu-* for some ( often failed ) attempts at semi-native cross compiling for PPC/Sparc/Arm{el} [06:23] 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] 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] my outgain mail is a tad slow, so it might be ~20 minutes [06:27] outgoing* [06:28] btw, how can I cancel a PPA build? [06:28] made a big boo-boo [06:31] G: upload a new one. quickly. [06:31] G: oh you can also delete it. [06:33] hyperair: I'll try the upload method, sounds less intrustive :) [06:33] moins hyperair [06:33] moins imbrandon [06:34] 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] if you dont want to increment it, then wait till it "dies" and delete it [06:35] imbrandon: I've already fallen for that trick :) [06:36] imbrandon: more like delete it, then wait for it to completely die. [06:36] hehe [06:37] ahhh PPA queue is up to 3 hours now :) [06:38] 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] :) [06:38] imbrandon: as there are 60 jobs and a lot of them are xulrunner/chromium/etc I'll believe the est [06:39] imbrandon: also, it originally quoted an hour, and an hour later I realised my mistake :P [06:39] and it only had built x86_64 [06:40] 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] estimate* [06:40] ahhhh, there are still 37 mozilla builds in the queue [06:41] i've doubed things that the time fluxuates greatly ( in both directions ) like that based on "Windows Time" , heh, bad i know [06:42] 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] imbrandon: yeah, I guess at least it's not OO.o :P [06:44] hahaha exactly [06:45] :( packaging ain't going well [06:49] does cdbs not have access to path? [06:53] kobrien: your debian rules should , like $(PATH) , or PATH:=/usr/bin:$(PATH) [06:55] imbrandon: that shouldn't be necessary. the PATH should be set properly before debian/rules is called [06:55]