=== ApOgEE- is now known as ApOgEEk === orly_owl_ is now known as orly_owl === asac_ is now known as asac === erhesrhsrtb54vyh is now known as Elbrus [03:48] urgh I've been makign so many hackages on my local install that my MOTU conscience is tingling. [03:48] * wgrant burns jdong at the stake. [03:48] jdong: Just use your backports conscience instead. It'll be fine [03:49] * StevenK files a backport request for libc6 from Intrepid to Hardy [03:49] :) [03:49] there we go. I "packaged" eclipse 3.4 :D [03:49] * jdong watches everyone step back... [03:50] StevenK: don't forget to also include libc6's rdepends to that list :) [03:50] stgraber: Ouch :-) [03:50] That turns into: "I'd like to backport Intrepid to Hardy." [03:51] yeah :) [03:51] let's do a copy of Intrepid and rename it to Hardy 8.04.2 [03:51] StevenK: libc6 wouldn't break much [03:52] jdong, Did you send it to pkg-java? [03:52] persia: it isn't april 1st quite yet :) [03:53] and I think people are still twitching from my MOTU prank last year :) [03:53] what prank was that? [03:53] * ajmitch does not recall it [03:53] Automatix? [03:53] https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/003513.html [03:54] yep [03:55] btw I love how much intrepid's lintian screams at a default dh_make with all boilerplates included :D [03:55] it has to be at least somewhat believable [03:55] jdong, The difference is that we have an interest in shipping eclipse, rather than it being the sort of software that makes us want to reinvoke the power of Miskatonic University on your domicile. [03:56] (not that you live in Waltham, but close enough) [03:56] persia: absolutely, and I totally agree with you there. Just I need eclipse now for a project tomorrow :D [03:56] * ScottK-laptop is busy trying to work around X bugs by shoving an xrandr call into the KDM init process. [03:56] that makes me feel better :) [03:57] jdong: is eclipse not in hardy? [03:57] maybe my conscience won't force me to divulge details on my "AMD64" skype package :) [03:57] coppro: not an appreciably recent version [03:57] coppro: significant improvements have been made to eclipse in the past two years [03:57] jdong, intrepid has the latest netbeans, unless you're already addicted to blue. [03:58] * ajmitch spots a jono [03:58] jdong: what version is the current? [03:58] persia: I'll have to try that out [03:58] coppro: 3.4 [03:58] hey ajmitch [03:58] :) [03:58] intrepid is 3.2 :( [03:58] jono: you must be in some weird timezone... [03:58] coppro: and so has Ubuntu been for as long as I can recall [03:58] btw, well done on your album :) [03:58] ah, so you just packaged 3.4? [03:59] coppro: that was a sarcastic joke [03:59] oh [03:59] I wasn't sure [03:59] coppro: it involved wget and cp -av calls in debian/rules [03:59] jdong, You didn't package it? [03:59] coppro: you'll get used to jdong... [03:59] persia: it fit in a .deb file and will suffice locally :) [03:59] jdong: How can I backport it if you didn't package it? [03:59] * persia is tempted to invoke ! [03:59] it is a jdong-approved 5-minute solution [04:00] ScottK-laptop: source changes! [04:00] btw, is there anyone not busy enough to REVU right now? [04:00] Bah. [04:00] jdong: Speaking of which, did you know that the sources for automated backports aren't signed? [04:00] coppro, Sure. I'll do one. It's been a while, and I should get into practice. No promises it will be a good review. Which one? [04:01] ScottK-laptop: I was unaware [04:01] ScottK-laptop: There's no way to sign them... and you can always grab them over HTTPS from LP. [04:01] persia: one second; I wasn't expecting a yes [04:01] wgrant: I thought the librarian was http [04:01] http://revu.ubuntuwire.com/details.py?package=metakit [04:01] ScottK-laptop: Oh, hmm. You're right, only stuff in P3As is streamed. [04:02] ScottK-laptop: by automated, you mean direct copies from one release to -backports? [04:02] That's why I wasn't complaining bitterly about that bug - I forgot it wasn't all over HTTPS. [04:02] alright, now time to dive back into another person's Java codebase. this should be fun. [04:02] ajmitch: Yes. [04:02] wgrant: Go complain. [04:02] right, so I'm not surprised that there's no gpg signature [04:03] It's fine internally, but then if have to grab the source to fix it, how do I get a trusted source on my box that I can sign and upload? [04:03] coppro, You should probably clean up your watch file, but why block new upstreams because there might be an ABI change? Isn't that expected? [04:03] Too much DNS cache poisoning these days for me to trust in DNS I really got it from where I thought I did. [04:04] ScottK-laptop: You'd have to verify against the changesfile, I guess. [04:04] But even that's probably not signed. [04:04] wgrant: It's not signed [04:04] And is over HTTP. [04:04] Damn. [04:04] persia: good point [04:04] ScottK, It's not just DNS. When was the last time you had an http request that didn't pass through a transparent proxy? [04:04] but as I understand it, 2.5 would be a rewrite [04:04] to the point of a new package [04:04] True. [04:05] coppro, I like to discourage having multiple versions as separate packages in the archive. Defend your stance. [04:06] persia: well, as far as I can tell from upstream, 2.5 would be a major change that would break backwards-compatibility, thus deserving a new package by policy as I understand it. [04:06] From where in policy do you take that understanding? [04:07] UbuntuGuide policy, probably. [04:07] I had the misfortune of seeing UbuntuGuide's Hardy sources.list earlier today. [04:07] persia: the fact that other packages are named by ABI version, like libc6 [04:08] I recall reading it somewhere, but it was several months ago [04:08] ABI version != app version [04:08] And ABI version != source name [04:09] it's not an app; it's a library [04:10] and multiple versions must exist to avoid breakage when a new, backwards-incompatible ABI comes out [04:10] That's the binary package name. While this sometimes applies for source package name, the use is incredibly rare, and must be defended. [04:11] ah, I see [04:11] I'm not using on the source package name [04:11] but I understand the point about the watch file [04:11] thanks for educating me! [04:12] No problem. Thanks for defending your point rather than just believing that it must be wrong :) [04:13] coppro, Now for the fun bit : since you clearly undrestand the value of having the binary name change when the ABI changes, why do you have a lintian override for the lintian check for this? [04:13] (yes, I've read README.Debian) [04:14] persia: because the package name is libmk4, which is the way the library is normally referred to by users. As such, naming it libmk-4 would be contrary to the existing usage, and libmk4-4 would be weird. I explained this in the changelog too! [04:14] * persia should start reading changelogs earlier [04:15] Upstream should be bothered about this, so that later it can be libmk-5, and users can just do -lmk [04:16] yeah, maybe if a new version ever looks to be coming out, I'll mention it. Changing it now would be more bother than help though [04:16] I don't really like updating config.{sub,guess} in debian/patches, but I suppose it's not invalid. Do others have opinions about this? [04:17] well, the problem was upstream used ancient versions [04:17] I was told to file a bug upstream and patch from the ubuntu versions, which I did [04:17] it was old enough to get a lintian warning [04:17] In my opinion, upstream shouldn't even ship those files, and we should use the ones from autotools-dev at build time. [04:19] * ajmitch wishes autofoo didn't exist [04:20] ajmitch, How would you prefer to do portable C? [04:21] by closing my eyes & hoping the problem disappears [04:21] Or do you think everyone ought permanently run Plan 9 on VAXen? [04:21] its only reason for existence is because of this portability mess [04:22] Indeed. So as long as we all use the same architecture and the same operating system, we don't have any issues. [04:22] I'm good with that. [04:22] and I was just expressing that I'd like that to be :P [04:24] Hi. Any idea on what to do with this bug: Bug #290164 ? [04:24] Launchpad bug 290164 in antlr "[Intrepid] cantlr package is not installable. Depends on antlr-gcj instead of libantlr-java-gcj" [Undecided,Confirmed] https://launchpad.net/bugs/290164 [04:25] persia: anything else? [04:25] fabrice_sp, Propose an SRU. Prepare an SRU patch. Talk to the SRU team. Looks like it falls under "completely fails to function" [04:25] ok. Thanks persia [04:25] coppro, I was distracted by autotools. [04:25] heh, no worries [04:25] * ajmitch is naughty & distracted persia [04:25] coppro, There's a bunch of files without license headers. [04:26] do I have to add those myself? [04:26] :( [04:26] ajmitch, You're incapable of being naughty : you define correct behaviour [04:26] if only that were true [04:26] coppro, No, you can't add those yourself : upstream has to add them. licensing is the one thing you can't just patch away. [04:26] ok [04:27] coppro, Also, you probably want to put the examples in /usr/share/doc/libmk4-dev/examples/ [04:28] coppro, Also, once I find missing licenses, I usually stop reviewing, as it's not possible to include until upstream fixes that : if you've not already, run lintian against your local build. [04:29] persia: lintian is clean except for one minor one [04:30] Which? [04:30] I forgot to add a description to a patch file [04:30] Then you already know the solution :) [04:30] yeah [04:31] shame it can't be included without license headers; I know that there was an old package for this lib but it was removed; I wonder if it did anything about them [04:31] Anyway, rejected for now. Go bug upstream : they should have a soname, and use -lmk, and license things properly, and not ship autotools hints files. [04:32] You'll find that license pickyness is inversely proportionate to the age of the package and the criticality of the package to making a system work at all. [04:32] metakit is new and non-essential, and so falls well into the extra-pickyness bucket. [04:32] heh [04:33] (hint: extra points for care and labour for fixing this by updating copyright of old essential packages) [04:33] the soname and -lmk definitely won't be fixed until the next ABI change; but the license headers and autotools hints could hopefully be fixed as a minor patch release [04:34] That sounds correct for an upstream who cares about the users. [04:34] it's mostly a 1-man dev [04:34] which makes things a lot easier in my experience [04:34] On a minor note, if you find a way to clean up the tests/ directory properly, that would probably be a good thing. [04:35] persia: well, I could build where they want me too [04:35] can you do cd within a make rule, or does that cause major breakage? [04:36] each line in a make rule is a separate subshell : you'll need to do some trickery. [04:36] no, that's what I want [04:36] just cd before each make command, I think [04:36] (please don't just stuff the whole rule into a single subshell : this is the wrong sort of trickery) [04:37] and modify paths accordingly [04:38] That sounds relatively sane, although if you're unlike ajmitch, and push the work of doing it properly into autotools, that might be harder to break later. [04:38] :P [04:39] man, getting gcc to build must be tricky [04:39] since building in project root is edgy at best [04:39] getting gcc to build it a little tricky. Getting gcc to build without having gcc available is days of fun. [04:41] I'm going to get very tired of "Graph this data and manage this system at https://landscape.canonical.com/" every time I ssh into an Intrepid box. [04:41] new adware? [04:41] Indeed. [04:41] Yes. [04:42] persia: Maybe you ought to ask the core-dev applicant who put that there why he thinks it's ok? [04:42] * ScottK-laptop declares victory and goes to bed. [04:43] ScottK, remove landscape-client to make that go away [04:43] NCommander: Sure, but is it appropriate for it to be there at all? [04:43] ScottK, not my department [04:44] yeah. [04:44] I like the new MOTD with useful information in it, just not the info-mercial. [04:45] ScottK, I thought that the new motd package just allowed changes, and that landscape-client or something used it to set that. [04:45] I haven't investigated. [04:45] * persia is unhappy about landscape-client being installed anywhere by default, but doesn't think that complaining would accomplish much [04:46] Well the client is at least FOSS. [04:46] * NCommander always wondered if it really is FOSS if the server implemenation is closed [04:46] i.e. liblaunchpadintergration [04:47] Well that's what AGPL is all about (not that I think that's a FOSS license) [04:47] landscape-client at least does some actual stuff all by itself. [04:48] ScottK, freeness isn't my concern. [04:48] Right. I can guess. [04:49] * ScottK-laptop ponders how he should feel about his volunteer server work ending up making the press release. [04:49] OK. Bed time. Really. [04:49] Good night all. [05:08] Question: [05:08] Why is Eclipse at v 3.2.2 in the ibex repos, if the current release is 3.4.1? [05:09] lukehasnoname, Because it's a very frightening package to update. [05:09] lukehasnoname, There's a bit of discussion about it in the Debian Java mailing lists, if you want details, and in the Debian BTS. [05:09] BTS? [05:09] Unless something goes tragically wrong, it really should be updated shortly after squeeze opens (and breaking the world is acceptable), and if that's soon enough, it can be pulled for Jaunty. [05:10] Bug Tracking System. [05:11] squeeze? [05:12] lenny+1 == squeeze [05:13] gotcha [06:25] * Hobbsee eyes blueyed [06:26] Hobbsee: Hrm? [06:26] someone might want to mention to him that we're in a freeze, and so syncs won't get done. [06:31] but it must be urgent, or it wouldn't have been filed [06:31] I bet [06:47] good morning [06:50] hi [06:51] hi ajmitch [06:57] Hi dholbach [06:57] (and ajmitch :-) ) [06:58] good morning dholbach [06:58] Hi ajmitch [06:59] hi geser, hi fabrice_sp === macd_ is now known as macd [08:23] motning everyone [08:23] morning === fabo_ is now known as fabo === woody86_ is now known as woody86 === boshhead_ is now known as boshhead [10:13] hi folks [11:01] hi folks [11:03] hihi === doko_ is now known as doko === LucidFox_ is now known as LucidFox === LucidFox is now known as Happiness === LjL-Temp is now known as LjL === Happiness is now known as Roleplaying === dholbach_ is now known as dholbach === LjL-Temp is now known as LjL [16:46] Where do I go if I want to request a package? [16:47] Repsa_Jih, simply requesting something from scratch rarely yields results, since you're asking people who might not care less about the app to put in their own time & effort. and an ancient proverb says: don't package something you don't use yourself [16:48] Mind you, wiki.ubuntu.com/UbuntuDevelopment/NewPackages might be a good place to start either way. [16:48] Some people troll for requested packages to look for new things to try, although this isn't exactly common. [16:49] Then what do you suggest I do? This is about I game I've been developping, but I am on Arch Linux. I'd like to get a deb package... Well, I'd probably best ask an Ubuntu user, right? [16:49] Repsa_Jih, what's the license, what's the app? [16:49] That's probably best. [16:50] Or for a game, you might also file an RFP (Request for Packaging) in Debian : the games team tend to include people happy to try out almost any game. [16:50] zlib/libpng license, app: http://annchienta.sf.net [16:50] * persia remembers seeing annchienta in REVU [16:51] I seem to remember lots of packaging updates just before each Ubuntu release, when they couldn't be used, and then not so many right after an Ubuntu release when it had a good chance to be uploaded. [16:52] Nope. I'm remembering incorrectly, according to http://revu.ubuntuwire.com/details.py?package=annchienta [16:53] Repsa_Jih, Looks like it just needs someone to update the package in REVU to the new upstream, fix the outstanding comments, and it should be good to go. [16:58] allright, thanks [17:02] persia: my 8 liters is consumed during my 2 hour morning workout, and then I drink 4 to 8 more during the day combined [17:02] since you left the other chan :) [17:02] nixternal, Wow! Do you not worry about hypoketosis? [17:02] haven't yet, but I also take a ton of supplements as well [17:03] Or do you just eat so many bananas that it doesn't matter. [17:03] i bet you need to pee a lot [17:03] I have cut back on the "blow up and become a monster" stage of my workouts [17:03] Oh, it's probably the supplements then. [17:03] (SCNR) [17:03] now I am in the "I need to lean out now and get chicks" stage :P [17:03] laga: speaking of pee...brb :) [17:16] <\sh> nixternal: you mean you will become the "KUbuntu-Hulk" (Blue Skin, Muscles, and any windows user will be punched to kde heaven)? ,-) [17:19] * sistpoty|work calls it a day... cya [17:24] OT, is there a substr function for char* in C++ or do I have to use a loop if I want to get ride of the first character? === RainCT_ is now known as RainCT [17:25] RainCT: add 1 to the pointer. [17:25] <\sh> RainCT: you mean, copy the string from char[1] to strlen(char[])? ,-) [17:25] ;3~ [17:25] oops. [17:27] \sh: no, copy what in Python would be x[1:8] to another variable.. so what jdong said [17:27] thanks :) [17:28] jdong: so.. that would be y = *x+1 , right? [17:28] <\sh> jdong: what if char* has only 2 byte, one real char and the \0 ? [17:30] \sh: is the null string not a valid string? [17:30] maye my C is a bit rusty. [17:30] RainCT: y = x + 1 [17:30] RainCT: but yeah you should probalby do a bit of testing on strlen(x) to make sure it is a valid operation :) [17:31] s/probably// [17:31] <\sh> jdong: for sure, but pointer arithmetic is a bit dangerous without knowing the real length of the char array [17:31] \sh: yeah, I agree with you on that. [17:31] I think checking strlen(x) > 1 will suffice for this case [17:31] RainCT, There are string manipulation functions in C for *char, and in C++ for String. You want to use those. Further, you probably want to test with something like kazken3さんが、ぜんぶ訳してくれました。to make sure it works for unexpected UTF8 data [17:32] (argh.. my X got mad :P) [17:32] jdong: yep, I'm already checking the length because I only want values that are 8 characters long :) [17:32] RainCT, 8 characters, or 8 bytes? [17:32] characters [17:33] even when that's 40 bytes? [17:33] <\sh> RainCT: http://www.cplusplus.com/reference/string/string/ [17:33] oh he did say C++. [17:34] dunno, but it's only numbers anyway (and the code is not to be released, so don't worry I won't kill your PC :P) [17:35] <\sh> RainCT: include int main() { std::string s,s2; s="Hello"; s2=s.substr(1,8); printf("%s",s2.c_str()); return(0);} should be correct [17:36] <\sh> oh my s="hello" is not > 8 ,-) please append ,-) [17:36] substr is smart enough not to misbehave in that situation ,right? [17:36] * jdong RTFMs [17:37] <\sh> jdong: http://www.cplusplus.com/reference/string/string/substr.html <- regarding this, it should be intelligent enough...but who knows ,-) [17:37] "If this value would make the substring to span past the end of the current string content, only those characters until the end of the string are used." [17:37] * persia recommends feeding it CJK input and seeing if it breaks [17:40] man just make Michael Casadevall 'n MOTU already! sheesh! [17:40] <\sh> I wonder if std::string is unicode safe [17:41] \sh: doesn't that depend on what you initialize the type to be for the template? [17:44] <\sh> jdong: could be...but using the default basic_string setting, I don't really think it's safe [17:45] \sh: I'd agree. [17:45] NCommander: ping [17:47] <\sh> jdong: I had a nice little python quiz last time: what is the result of (1 and -1) * (1 or -1) (enable python mode) ... [17:48] should be -1 * 1 [17:49] though I don't believe the short-circuit is actually officially stated :) [17:49] one of those use-it-while-it-lasts things [17:49] \sh, char is more fun than string :P [17:50] \sh: I've seen someone build an interesting string of lambdas anded and or'ed together, then the result is ()'ed. I'd consider that violent protest for switch/case constructs in python :) [17:51] <\sh> jdong: right :) but I was asking myself why? because if you swap the the first term to (-1 and 1) * (-1 or 1) , then the results of both terms are 1 * -1 ... so I though to myself, it's bug, because it shouldn't use signed values != 0 for a boolean true [17:52] o.O [17:52] <\sh> RainCT: they are interchangeable ;) the constructure also takes a const char * to initialize your string ,-) [17:52] <\sh> constructor ... [17:52] <\sh> damn I should go home and sleepä [17:54] <\sh> in the last couple of weeks I had too many strange things to explain (regarding bash, python and powershell ,-)) for myself [17:55] \sh: well (true and A) == A; true or B == b... There's got to be some weird logic or numbering system that one can make out of these operators :) [17:56] wait a second [17:56] I see what you're saying. [17:56] lol I should be paying attention to lecture right now... :) [17:57] <\sh> #!/bin/bash function foo() { echo "bla" ; ssh -f host.domain.tld "" > /tmp/fifofile ; ps -ef|grep "ssh \-f"|grep -vi "grep"|awk '{print $2}'; } process_id=`bla` ; echo $process_id ;exit(0) [17:57] \sh: if you get really bored, try (False, True) = (True, False) [17:57] hilarity ensues. [17:58] <\sh> jdong: well, True and False are just simple global constants..but the real boolean true in python is something != 0 , because 0 is the only false...but it's funny to play with those theoretical things ,-) [18:00] <\sh> if you set -x after #!/bin/bash you can see that it's stopping execution of the script when trying to call ssh -f ... and it waits there forever...until I discovered (and interpretated the man page correctly) that you can't do any piping to stdout in bash functions [18:01] \sh: Indeed, the core engine still behaves correctly in terms of boolean logic, but there are about 2000 uses of literal True and False in my site-packages that probalby won't be happy :) [18:02] <\sh> jdong: yepp :) [18:04] \sh: there's also weirdness in that bool([]) is false but [] != False :) [18:04] NCommander: a bit of analysis about the freeze I was getting on my ibook. I saw two types of messages in the kernel panic messages. Something like 'b43_interrupt_handler' and 'b43_rfkill'. Not sure what they mean exactly. Also I found out that I was uisng old firmware version for my broadcom wireless card. Since I updated to newer version the freezes are very less. I last 4 hours of use I have seen a freeze only once as opposed to 1 al [18:07] <\sh> jdong: the most annoying part of bool handling in python is: bool("True")==True but bool("False")!=False ... now this is totally stupid, especially when you work with configparser and you feed it str(False) [18:08] \sh: yeah, that's annoyingly inconsistent that bool(str) doesn't construct a boolean from its string representation. [18:09] <\sh> the bool object should have an automatic recognition of "False" str representation and convert it automatically to 0 [18:16] * POX hopes bool("False") will always be != False [18:17] use PHP if you want different [18:17] <\sh> POX: then it needs str(False) == "0" [18:17] POX: sure when converting a string object to a boolean [18:17] POX: but there needs to be an inverse-toString() constructor for bool too [18:17] i.e. something("False") should be str(False) [18:18] rather, something(str(False)) == False [18:18] and int() uses that definition for int(str) [18:18] thus adding to the inconsistency. [18:19] <\sh> bool(str(False))==True sometimes my brain just needs beer to understand this ,-) [18:19] \sh: probably the moral is don't be using str() as a serialization tool :D [18:19] Doesn't it all change in Python3.0 anyway? [18:20] Note that we have Python3.0 RC packages in Intrepid. [18:21] I hope so [18:21] that's the one chance this decade to start over and get it right. [18:21] <\sh> ScottK: well, let's play with 2.6 first, and try to make a smooth transition to 3.0 [18:21] beer! [18:22] yeah that's right, taunt the underaged. [18:22] <\sh> I think most apps coded with 2.3/2.4/2.5 will break [18:22] (no, i'm not highlighting on that) [18:22] <\sh> ogra: a good plan [18:22] jdong: are you underaged? [18:22] \sh: Yes, although there are a goodly number of tools and docs on how to port that should make it doable. [18:23] laga, he comes from the country where you can marry with 18 but not drink anything at your wedding ;) [18:23] <\sh> ScottK: right...but it's time consuming...just as timeconsuming as any new gnu c++ version ,-) [18:23] laga: I am indeed :) [18:23] jdong: oops. :) [18:23] ogra: don't forget get shipped off to Iraq. [18:24] oh, right :) [18:24] well, you elected him ... (at least some did) [18:24] Although that dichotomy (the age related one) has been around for ~ 2 decades now. [18:24] <\sh> ogra: yes, the court...the citizens voted differently...these days.. [18:24] * ogra points \sh to http://isitbeeroclock.com/ [18:25] <\sh> ogra: lol [18:25] yeah and now we have to choose between Mr inflate-your-tires energy policy and that other guy who will probably collapse in a few months. [18:25] fun fun fun. [18:25] well, he has at least an *intelligent* vice .... [18:25] *grin* [18:26] ogra: why can't they just replace her with Tina Fey for real? [18:26] but biden doesnt wink as cute [18:26] I'd go for that. [18:26] or cindy lauper :) [18:27] from an european POV your elections are quite a joke to be honest ... [18:27] ogra: from an American POV I agree. [18:27] the scary part is that the elected person is the most powerful in the world at the end [18:27] ScottK-laptop: (python3.0) seriously? in official repositories? [18:28] jdong: new_bool = lambda x : {"False": False, "0": False, 0: False}.get(x, bool(x)) [18:28] ogra, jdong: the elections are also making reddit, digg and other social news sites unusable [18:28] POX: Yes. It's in Universe, so not supported. [18:28] * ogra doesnt use either [18:28] POX: well. yes. of course one can do that. [18:28] ScottK-laptop: "not supported by canonical". [18:29] jdong: it's still PHP-like for me [18:29] laga: True, but in this case I think that adds up to 'not supported' [18:29] POX: https://launchpad.net/ubuntu/+source/python3.0 [18:29] ScottK-laptop: I'd say doko is brave :) [18:29] ScottK-laptop: yeah ;) [18:30] Brave would be one word for it. [18:45] POX: these are there for experiments [18:46] but in official release? [18:46] it's universe, and we'll update those to the final release [18:46] people complained about python2.5 in Etch even if it wasn't supported [18:46] don't ask me which motu did approve them ;p [18:46] i.e. pyversions -s [18:47] oh, so it wasn't your decision? [18:47] did we have 2.5 in etch? [18:47] yes [18:47] and lots of complains (at least I received lots of them) [18:48] ("why did you included it anyway if it's not supported") [18:48] s/included/include [18:53] I think for 3.0 the case is a lot clearer. There is a large porting task ahead for the Python community and so providing an easy way to support that without demolishing user systems is a good idea. === Kmos_ is now known as Kmos [19:17] <\sh> early adopting is a good thing for developers, most likely 2 teams in companies are working on project X, one fixing bugs in actual release, and one porting it to a new version of the devel language...is a good thing [19:19] morning [19:20] Hi ajmitch [19:21] good to see that people are still here & not passed out from stress [19:23] * ajmitch looks at -devel & uploads a new mc flagged as essential === quadrispro1 is now known as quadrispro [19:24] .oO( poor guy, he's reading -devel ) [19:25] ajmitch: And if you believe it's not essential you are clearly an idiot and don't get it. [19:25] * POX is not reding debian lists anymore, he's working on Debian instead [19:25] ScottK: obviously [19:26] POX: This was ubuntu-devel-discuss. [19:26] oh [19:26] :) [19:26] I don't read it either :) [19:26] Didn't miss much. [19:29] * pochu unsubscribed from -discuss long time ago [19:29] ScottK: yeah, I have spies that ping me when my name is mentioned somewhere ;) [19:29] I have enough with -devel :-) [19:29] ScottK: thanks, btw [19:29] heh [21:10] hey all :) [21:10] can someone review my package? :D [21:10] this is the link http://revu.ubuntuwire.com/details.py?package=bricker [21:10] I would really appreciate it :) [21:12] * nhandler goes to look at it [21:15] gulyan: please fix debian/changelog, it needs to be uploaded to jaunty instead of hardy [21:16] ok, I was waiting for the official release before updating the distribution [21:16] I'll change it now :) [21:19] hello MOTU's [21:19] hi marcin_ant [21:19] I would like to ask about some package I would like to modify [21:20] there is package named zope-pas [21:21] this software can be downloaded as upstream tar.gz but in this original tar there is subfolder containing source code /PluggableAuthService-1.4.2 [21:21] hi, i'm currently working on fixing bug 262708, which is fixed in debian. i was just going to copy their fix, but after looking through the changelog in the latest debian version of the package, the only changes since the last sync of this package are all bugfixes to get the package working, and are all relevant to ubuntu too. so, should i modify the package and bump the version to 'ubuntu1', or could i just request a sync of the pa [21:21] Launchpad bug 262708 in opencryptoki "package opencryptoki None [modified: /var/lib/dpkg/info/opencryptoki.list] failed to install/upgrade: trying to overwrite `/usr/lib/opencryptoki/stdll/libpkcs11_sw.so', which is also in package libopencryptoki0" [High,In progress] https://launchpad.net/bugs/262708 [21:22] but source package from debian/ubuntu contains source code in / [21:22] chrisccoulson: do you think it should be an SRU? [21:23] the package is not installable in its current state [21:23] gulyan: i've added some comments. i'm not a MOTU, though :) [21:23] chrisccoulson: ok, so for intrepid you should prepare an update not sync. [21:23] orig.tar.gz has all of it's content moved from /PluggableAuthService-1.4.2 to / and I'm reading maint-guide which says that wrong directory layout is not a reason to modify original tar.gz [21:24] gulyan: intrepid will be released tomorrow, you can't add new packages to intrepid [21:24] chrisccoulson: collapsing the changelog since the last sync to one entry, changing the details, including the version number, then explaining where the changes came from and giving proper attribution would work. [21:24] ok, thx for the comments and advice :D [21:24] should I consider this as a bug and in my new version of this package should I keep original directory layout from upstream tar? [21:25] i can do that. the only reason i asked is that there is also another bug which makes the software not work, which I was going to fix in the same debdiff. but that is also fixed in debian. if i apply both fixes, then the package is basically in sync with the latest debian package, but will have a different version number [21:25] i don't mind doing the work though, it's not going to take me too long to fix [21:45] update done to the package, thx again laga :) [21:46] could someone help me with packaging? [21:48] I just need like to know what to do if I got upstream tar with non-native directory layout [21:53] jdong: i'm doing some testing on what you asked in bug 264950. It looks good, another random port is automatically chosen. What do you think about this issue anyway? [21:53] Launchpad bug 264950 in azureus "Azureus doesn't allow ports above 49151" [Undecided,Incomplete] https://launchpad.net/bugs/264950 [22:13] is there anyone that can answer some trivial question about packaging? please [22:15] marcin_ant: probably nobody is arrogant enough that they would admit they could answer any trivial questions [22:15] marcin_ant: so better just ask your question and hope somebody knows [22:19] azeem: thing is -> I want to follow PackagingGuide so: [22:19] azeem: mkdir zope-pas [22:19] azeem: cd zope-pas [22:19] azeem: wget http://www.zope.org/Products/PluggableAuthService/PluggableAuthService-1.4.2/PluggableAuthService-1.4.2.tar.gz [22:20] azeem: cp PluggableAuthService-1.4.2.tar.gz zope-pas_1.4.2.orig.tar.gz [22:20] marcin_ant: why do you ask me? [22:20] azeem: tar -xzvf zope-pas_1.4.2.orig.tar.gz [22:20] I didn't say I can answer trivial questions [22:20] and I'm stuck because tar unpacks to PluggableAuthService-1.4.2 [22:21] that's usually not a problem [22:21] can I change internal directory structure of original tarball? [22:21] PackagingGuide says that I cannot.... [22:21] why do you want to change? What error/problem are you running into? [22:21] (sorry about asking you directly ;) ) [22:22] I should have source code unpackaged to directory with zope-pas-1.4.2 (in my example) right? [22:23] "should", not "must" [22:23] but original tarball has different directory structure [22:23] 23:17 < azeem> that's usually not a problem [22:23] 23:18 < azeem> why do you want to change? What error/problem are you running into? [22:24] ma10: my comments added [22:25] azeem: so are you saying that I can copy PluggableAuthService-1.4.2.tar.gz to zope-pas-1.4.2.orig.tar.gz [22:25] azeem: then untar this orig file [22:25] I thought you already did this above? [22:25] and then it will produce PluggableAuthService-1.4.2 [22:26] and should I just cd to this directory add debian subdir and build deb? [22:26] jdong: thanks, i was writing a reply of my own [22:27] azeem: ? [22:27] marcin_ant: why don't you try yourself? [22:27] it's doesn't scale at all if you ask for advice before every step you take [22:28] jdong: btw, i have the new version packaged and ready, what should I do? Open the please update bug as soon as jaunty archives are opened? [22:30] ma10: yeah let's upload it into Jaunty when it opens [22:30] ma10: does it build on Intrepid, too? :) [22:31] jdong: sure, where could i have tested it? :) i'd like to be able to backport before release.. [22:33] ma10: haha ok stupid question... See I'm drinking coffee now, the effect has not kicked in yet! [22:34] ma10: Unless ScottK is in a really bored mood (highly unlikely) let's just wait until Jaunty can upload, to do the backport. I don't expect that to be more than 1.5 weeks away. [22:34] azeem: ok thank you, my package build without errors [22:35] azeem: but then last question is - why when I will apt-get source zope-pas (current version) [22:35] ma10: btw thanks so much for taking care of Azureus -- it's been historically one of the most troubled/neglected packages in Ubuntu :) [22:36] azeem: this command will download zope-pas_1.4.2.tar.gz which has different internal directory structure? [22:36] azeem: it has /zope-pas-1.4.2/sourcecode.... ? [22:37] azeem: not /PluggableAuthService-1.4.2 like in orig.tar.gz? [22:37] zope-pas_1.4.2.tar.gz ? [22:37] marcin_ant: what is your .orig.tar.gz called exactly? [22:38] jdong: true, i'm still running it from a manual installation on hardy.. what a shame, it feels like windows.. my concern now is that we're diverging quite a bit from debian. Their last upload was a NMU with some weird stuff in it. I'm afraid the next merge will be painful.. [22:39] ma10: correct me if I'm wrong but Debian is still interested in preserving GCJ compatibility, right? [22:39] no I am wrong. [22:40] jdong: they gave up on that [22:40] azeem: ooooops sorry [22:40] azeem: you are absolutely right thank you [22:40] jdong: wait i try to grab a diff [22:40] azeem: in ubuntu there is 1.4.1 version which has orig.tar.gz like it should [22:41] azeem: I got 1.4.2 from some unofficial repository with modified upstream tar [22:41] azeem: thank you very much :) [22:41] cheers [22:52] jdong: http://paste.ubuntu.com/64334/ -- they dropped gcj and they now force it to run with the jre that was used for building, if i read the perl lines correctly.. [22:56] ma10: it doesn't look too unreasonable to me [22:57] jdong: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495514 it was discussed here. [22:57] Debian bug 495514 in azureus "azureus and openjdk" [Serious,Closed] [22:59] jdong: I don't know if hand-selecting jres in the startup script is a good approach. I mean java compatibility is a real problem, but I think it should be solved on a higher level, not in every single package's scripts. There should be an infrastructure for blacklisting jres as needed. [23:01] jdong: otherwise, you defy the purpose of the alternatives system [23:02] ma10: my personal opinion.. at this point Ubuntu selects a reasonable JRE by default (AFAIK) [23:02] ma10: we should respect the user's alternative. [23:02] ma10: now that was different when we used GCJ by default with which azureus is known not to work === asac_ is now known as asac [23:07] jdong: that's what i think. So, correct me if i'm wrong: build with default-jdk, depend on default-jre | java-runtime and launch by calling "java" directly. If the user selected alternative doesn't work with the package, well, that's his problem. A blacklisting system wuold help, but we should disregard the selected alternative [23:07] * we should not disregard.. sorry [23:09] ma10: at most I would blacklist the current version of GCJ or at least scream loudly if it's detected and continue anyway [23:09] ma10: but yes, I agree with you on this [23:10] jdong: screaming is problematic when not launching from terminal.. So we could conclude we should reject debian changes.. [23:10] btw is there any policy or guidelines about this stuff? [23:11] ma10: generally we don't like deviating from Debian but I think in this case it is reasonable to do. [23:11] ma10: for Azureus I'd recommend cooperating with upstream's wishes [23:11] I know at one point when I took over they had some harsh words about Debian's Azureus packaging and (by prejudice) what I was going to do. [23:12] I'm very interested in repairing that relationship [23:13] jdong: I had the same impact when i tried talking to them.. however their wishes are to ship their version of swt and the other libs together with the package.. i don't know if we can come down do this :) [23:14] ma10: no, that's not something we can do, unless they give very compelling and specific reasons why Azureus needs a special version of those libs in which case we might want to discuss bundling the SOURCE with the azureus build process [23:14] ma10: I didn't listen too carefully (or understand too well) -- they tried to tell me something along those lines with SWT [23:14] well actually I didn't want to hear it for emotional trauma reaasons [23:14] I believe they mini-forked SWT to have API calls and such that THEY wanted :) [23:15] that's bad.. i liked it better before this whole Vuze thing [23:37] could someone verify that the eagle package is not broken in intrepid?..... when i try to run or reinstall eagle after upgrading from hardy it crashes my X server [23:41] trying... [23:41] it's an application I just run? [23:41] hmm... works fine [23:41] Sylphid: it works for me, albeit, not that well, but it starts [23:42] danbh_intrepid, when i click on file after it loads it crashes X [23:43] hmm... [23:43] what file? [23:43] the file menu [23:43] hmm [23:43] its a bunch of ic diagrams [23:44] hmm.... must just be my machine for some reason === asac_ is now known as asac [23:44] heh, the pins are labeled, but where is the documentation of those pins? [23:44] Sylphid: try this command to install the somewhat default dependencies for your system! sudo apt-get install (k|x)ubuntu-desktop^ and dont forget the ^ [23:44] lemme try purging and reinstalling [23:46] hmm.. yea that did pick up a few extra libs [23:47] ok all installed. .... trying again will be back if it crashes again [23:49] nope still crashed X [23:54] what video driver are you using? [23:59] radeon === asac_ is now known as asac